Si Claude Opus 4.6 de repente se siente peor, no hace falta empezar por la teoría de que Anthropic rebajó oficialmente el modelo para todos. A fecha del 10 de abril de 2026, los docs oficiales y el status history no confirman un universal downgrade. La pregunta realmente útil suele ser otra: ¿estás viendo un mismatch de thinking mode, un problema de contexto en conversaciones largas, presión de shared usage o una diferencia de ruta entre claude.ai, Claude Code, Desktop y la API?
El primer paso más seguro es menos dramático de lo que parece. Fija una sola surface, abre una sesión nueva y cambia solo una variable cada vez. No cambies prompt, modelo, thinking setting y ruta al mismo tiempo. Si después del control específico de la rama el mismo task sigue saliendo superficial, olvidadizo o inestable, entonces ya hay razones para tratarlo como un repeatable issue y guardar evidencia para escalar.
Nota de verificación: los release notes de Anthropic, las páginas de ayuda sobre extended thinking y usage and length limits, y el comportamiento actual de producto relacionado con Opus 4.6 se volvieron a revisar el 10 de abril de 2026, porque esta respuesta depende del comportamiento presente de las superficies y no de recuerdos vagos.
Antes de discutir downgrade, decide en qué rama estás
Claude Opus 4.6 empeoró suena a un solo problema, pero casi siempre mezcla causas distintas.
| Lo que estás viendo | Rama más probable | Primer movimiento | Qué suele confirmarlo |
|---|---|---|---|
| En claude.ai las tareas difíciles salen demasiado planas | mismatch de thinking mode | Repetir el mismo task en un chat nuevo con thinking explícito | La calidad mejora cuando el thinking queda fijado |
| Los hilos largos empiezan a olvidar instrucciones o decisiones anteriores | manejo de contexto | Abrir una sesión nueva con un handoff breve | La sesión nueva conserva mejor las restricciones importantes |
| Después de un día pesado todo parece peor | presión de shared usage | Mirar el estado de usage y repetir el task en una ventana más limpia | En condiciones de menos presión el comportamiento mejora |
| claude.ai, Claude Code, Desktop y la API se sienten muy distintos | route differences | Fijar una sola ruta y comparar el mismo task allí | En una ruta fija el resultado se vuelve más consistente |
La razón para separar estas ramas no es teórica. Es para no desperdiciar el primer arreglo útil. Si el problema real es contexto largo, seguir puliendo prompts solo añade ruido. Si el problema real es route drift, los benchmarks no te van a sacar de la confusión.
Qué cambios oficiales de 2026 sí afectan la sensación de calidad
Los release notes de Anthropic dicen que Claude Opus 4.6 se lanzó el 5 de febrero de 2026. En la API, Anthropic ahora empuja adaptive thinking y el control effort como la forma actual de ajustar el razonamiento. En cambio, en el chat de consumo extended thinking aparece como un modo opcional. Eso ya basta para decir que el comportamiento de thinking no es idéntico entre la API y claude.ai.
Además, Anthropic explica que cambiar extended thinking abre un chat nuevo, y que cambiar la versión del modelo también abre un chat nuevo. Muchas comparaciones que la gente siente como antes vs ahora no son realmente same-task / same-route / same-state. A menudo comparan un hilo largo con un chat nuevo, o dos rutas con distintos estados de thinking.
Hay otra capa importante: Anthropic dice que las conversaciones largas se gestionan resumiendo mensajes anteriores, y en la API documenta compaction como mecanismo separado. Estos hechos oficiales importan para el diagnóstico, pero no equivalen a una confirmación oficial de que Opus 4.6 se volvió universalmente peor.
Rama 1: thinking mismatch se confunde muy fácil con el modelo bajó
Cuando la queja es de repente responde más superficial, lo primero no es mirar benchmarks sino fijar el thinking behavior. Extended thinking en Claude chat y adaptive thinking en la API influyen en la profundidad de razonamiento, pero no son un único interruptor universal.
Por eso una comparación sin thinking fijo engaña con facilidad. Un answer rápido en consumer chat, una llamada API con poco effort y una sesión anterior que razonó más profundo pueden producir una diferencia enorme de sensación. Si lees esa diferencia como el modelo empeoró, estás mezclando settings y rutas con regresión real.
El control test útil es sencillo: un task difícil, una sola ruta fija, una sesión nueva y thinking explícito. Si ahí la brecha se reduce de forma clara, el diagnóstico se parece mucho más a thinking mismatch que a universal downgrade.
Rama 2: el drift de contexto en sesiones largas no es lo mismo que pérdida de capacidad
La segunda queja frecuente no es responde poco, sino de pronto olvida cosas. Anthropic explica que en conversaciones largas se resumen mensajes anteriores y que la API tiene compaction como continuation path independiente. Una sesión muy larga ya no está operando en el mismo régimen de contexto que al principio.
Por eso olvida contexto y se volvió más tonto no deberían tratarse como sinónimos. Parte de las restricciones importantes puede quedar solo en forma resumida. En ese escenario, el mismo task puede sentirse distinto sin que eso demuestre una caída global de inteligencia.
El mejor first fix aquí no es un mega-prompt más largo, sino un clean handoff. Abre una sesión nueva, resume objetivo, restricciones no negociables y artifacts realmente necesarios, y vuelve a correr el task. Si la sesión nueva mejora claramente, estás mucho más cerca de una diagnosis de contexto que de una prueba de downgrade universal.
Rama 3: shared usage pressure cambia las condiciones de tu comparación
Anthropic dice que claude.ai, Claude Code y Claude Desktop comparten un mismo usage pool. También dice que el headroom real depende del modelo, la feature, el tamaño de archivos y la longitud de la conversación. Eso ya basta para que un día pesado se sienta muy distinto de uno ligero.
Aquí conviene no pasarse de la evidencia. Los docs oficiales no dicen cuando el usage está alto, Anthropic baja la calidad a propósito. Lo que sí sostienen es algo más estrecho: si comparas sesiones con distintos niveles de pressure, distinta longitud y distinta carga, probablemente ni siquiera estás comparando la misma situación.
Por eso el movimiento correcto es operativo. Mira el estado de usage y repite el mismo tipo de task en una ventana más limpia. Si el problema vive sobre todo en condiciones de más presión, eso se parece mucho más a una comparación ruidosa que a una prueba de downgrade. Si tu dolor real termina siendo más de límites generales que de diagnóstico de calidad Opus, te conviene seguir con nuestra guía sobre el límite diario de Claude o con la guía sobre usage extraño en Claude Code.
Rama 4: claude.ai, Claude Code, Desktop y API no son la misma experiencia
Mucha confusión nace de aplastar varias execution surfaces en un solo relato. Eso es un error. Claude chat tiene su propia lógica de model switching, extended thinking y manejo de conversación. Claude Code mete tools y repo context. Desktop se parece al chat de consumo, pero no es idéntico. La API vive con thinking controls, contrato de contexto largo y compaction propios.
Por eso una comparación que salta entre superficies es muy ruidosa. Una complaint sobre Claude Code puede describir un workflow con tools, una sesión vieja o una carga distinta. Una diferencia entre API y chat puede ser simplemente una diferencia de route logic. Ambas experiencias son reales, pero no implican por sí mismas un solo cerebro Opus degradado en todas partes.
La comparación justa exige one fixed route. Si al fijar surface y context state el problema desaparece, ya tienes una diagnosis de route issue. Solo si el problema permanece dentro de una ruta fija gana peso la hipótesis de un issue serio.
El recovery order más útil
La parte más importante de esta guía no es una teoría nueva, sino el orden.
- Fija una sola surface.
No mezcles chat, Code, Desktop y API en el mismo test. - Abre una sesión nueva.
El contexto viejo es la fuente más rápida de ruido. - Haz thinking explícito.
No adivines el default behavior. - Cambia solo una variable cada vez.
Route, edad del hilo y thinking setting no deben moverse juntos. - Revisa la presión de usage.
Si el día fue muy pesado, repite el task en una ventana más limpia. - Escala solo un fallo repetible.
Un mal día no equivale a un issue reproducible.
Cuándo cambiar de route, cuándo cambiar de modelo y cuándo escalar
Cambiar de surface tiene sentido cuando la evidence apunta a un route-specific problem. Cambiar de modelo tiene sentido después, no antes. Si todavía no has separado thinking mismatch, drift de contexto o mixed-route comparison, el model switch solo va a tapar la causa.
Escalar tiene sentido cuando en una sola ruta fija, después de un fresh-session control test y de la corrección específica de la rama, el mismo task sigue fallando de forma desproporcionada. En ese momento conviene guardar surface, si la sesión era nueva o resumed, thinking setting, estado aproximado de usage y el task que reproduce el problema.
FAQ
¿Anthropic ha confirmado oficialmente que Claude Opus 4.6 empeoró?
No. A fecha del 10 de abril de 2026, los docs oficiales y el status history no confirman un universal downgrade.
¿Que olvide contexto en hilos largos demuestra pérdida de capacidad?
No necesariamente. Primero hay que considerar la summary logic del consumer chat y compaction en la API.
¿Extended thinking y adaptive thinking son lo mismo?
No. Consumer chat y API muestran behaviors de surface distintos.
¿Por qué claude.ai y la API se sienten como productos diferentes?
Porque lo son en términos de route, controls y contrato de contexto.
¿Cuándo dejo de tocar prompts y paso a escalation?
Cuando el problema sigue reapareciendo en una ruta fija después de la sesión nueva y del fix específico de la rama.