600 upvotes de rabia: por qué todos dicen que Opus 5 es insufrible
Le pides a Opus 5 un arreglo de dos líneas y recibes una tesis doctoral. En el subreddit de Claude Code, un hilo titulado «Opus 5 is insufferable» ha superado los 600 upvotes y 178 comentarios, con el autor acusando al modelo de hablar un idioma inventado que llama «Unintelligiblish». Y Reddit es el sitio educado: en X, un desarrollador publicó solo una captura de los comentarios de código que genera Opus 5 y juntó 9.700 likes. Boris Cherny, creador de Claude Code, defendió públicamente al modelo y se llevó la respuesta más votada, «this response is part of the problem», con 2.843 likes.
| Dónde | Señal |
|---|---|
| r/ClaudeCode, «Opus 5 is insufferable» | 600+ upvotes, 178 comentarios |
| X, captura de los comentarios de código de Opus 5 | 9.700 likes |
| X, respuesta a la defensa de Boris Cherny | 2.843 likes |
Mientras las quejas se acumulaban, Anthropic publicó discretamente una guía de prompting dedicada a Opus 5 que casi nadie abrió. Así que hicimos la prueba que nadie hace: reproducir los comportamientos que sacan de quicio a todo el mundo, aplicar la guía línea por línea y medir el salto en las mismas tareas.
Qué cambió de verdad en Opus 5: thinking, contexto y el dial effort
Tres cambios explican casi todo lo que están viviendo los desarrolladores.
El thinking está activado por defecto: el modelo razona en un bloque privado antes de cada respuesta, y solo se puede desactivar en effort high o por debajo. La ventana de contexto pasa a un millón de tokens, tanto por defecto como de máximo. Y el tercer cambio es el que importa para las quejas de verbosidad: el effort —el parámetro que decide cuántos tokens gasta el modelo pensando, llamando herramientas y escribiendo la respuesta— se convierte en el dial central, con cinco niveles y high por defecto.
| Effort | Comportamiento |
|---|---|
| Low | Agrupa las llamadas a herramientas, sin preámbulo, confirma en una frase |
| High (defecto) | Multiplica las llamadas, explica el plan antes de tocar nada, comenta sus cambios en detalle |
| Extra high / Max | Explora más archivos, blinda los casos límite; el thinking ya no se puede desactivar |
Si la segunda fila suena exactamente como tus sesiones, es porque llevas desde el primer día en el valor por defecto. El effort no es un mando de verbosidad, y ese malentendido es lo que llena los hilos de Reddit.
Un apunte más: Anthropic declara abiertamente que Opus 5 escribe respuestas más largas que los Opus anteriores y termina las tareas por completo en vez de dejar placeholders. Parte de lo que vives como un bug es una decisión de diseño documentada, y una decisión documentada se puede reconfigurar.
Los cuatro comportamientos de rabia, reproducidos a demanda
No tuvimos que buscar ninguno.
Verbosidad. Le pedimos a Opus 5 que explicara una función —una pregunta cuya respuesta cabe en dos frases— y llegaron secciones, subtítulos y advertencias, con el tono de un informe de auditoría. El comentario más votado del hilo describe lo mismo: frases de anuncio grandilocuentes del estilo «acabamos de descubrir algo que lo cambia todo», seguidas de diez minutos de comandos de shell.
Over-engineering. Un usuario cuenta lo de un archivo de decisiones de 7.000 líneas; al pedirle que lo limpiara, Opus 5 cortó 1.200 líneas y luego añadió 600 nuevas para documentar los borrados. Reprodujimos el patrón en una feature pequeña: nuestra instancia añadió un paso de verificación que nadie pidió y escribió docstrings de veinte líneas sobre funciones de cinco.
Scope creep. Pides X, el modelo decide que el tema real es Y y te explica por qué en ocho párrafos.
Malas noticias enterradas. Un comentarista describe un muro de texto explicando que todo salió genial, con un asterisco a tres cuartos del camino que admite que algo se rompió. Nosotros también lo vivimos: nuestra instancia anunció una migración exitosa, y la línea que admitía que los tests de integración seguían rotos estaba en el séptimo párrafo.
La rabia es real y se reproduce a demanda. Queda saber si es ajustable.
La guía oficial de domesticación que casi nadie abrió
La guía se llama Prompting Claude Opus 5, está en la documentación de Anthropic y responde al hilo de Reddit punto por punto. Su frase más importante cabe en una línea: el effort controla cuánto piensa el modelo, no cuánto habla. Bajar el effort reduce el volumen de pensamiento pero no acorta de forma fiable la respuesta visible, así que todos los que bajan el effort para callar al modelo tiran de la palanca equivocada.
Para la longitud, la guía es explícita: pídela con palabras claras, con una instrucción de concisión en el system prompt. Y dice algo que nadie espera de Anthropic: hay que quitar instrucciones de tus prompts. Si tu archivo de instrucciones dice «verifica tu trabajo antes de responder», borra la línea: Opus 5 ya se comprueba solo, y líneas así disparan pasadas de verificación extra, es decir tokens quemados para nada. Boris Cherny lo resumió en una frase: Opus 5 necesita menos prompting, no más.
El resto de la guía cubre los demás agravios metódicamente —una sección sobre la narración del agente, otra sobre la longitud de los archivos generados, otra sobre el encuadre de scope, otra sobre subagents, otra sobre la autocorrección— y cada sección te da el bloque de prompt exacto para copiar, no un consejo vago.
El effort sweep: misma tarea, cinco niveles, medidos
Un effort sweep es lanzar la misma tarea en cada nivel de effort y comparar tokens, tiempo y calidad. La guía recomienda rehacer uno si arrastras la configuración de un modelo anterior. En la práctica son cuatro runs y una comparación.
En Claude Code el effort se fija de tres formas: un comando dentro de la sesión, un flag al arrancar o una clave en tu archivo de settings —esta última te da un valor por defecto distinto por proyecto cuando tus repos no tienen las mismas necesidades.
Lanzamos el mismo arreglo de bug en low, medium, high y extra high, en cuatro sesiones limpias.
| Nivel | Resultado en nuestro arreglo de referencia |
|---|---|
| Low / Medium | Arreglo equivalente por una fracción de los tokens de high |
| High | El valor por defecto; ningún salto de calidad en un bug de una línea |
| Extra high | Más archivos explorados, casos límite blindados: útil en un refactor pesado, excesivo aquí |
Coincide con lo que anuncia la guía cuando dice que uses los niveles bajos con generosidad como principal control de coste. Un detalle de API antes de que lo scriptees: en extra high y max el thinking ya no se puede desactivar, y la petición devuelve un error 400 si lo intentas.
El uso más rentable del sweep es la code review. Anthropic afirma que la precisión de review de Opus 5 se mantiene en los niveles bajos de effort, lo que permite una pasada rápida y barata al commit y otra profunda después. Lo probamos en uno de nuestros diffs: la pasada low encontró los dos mismos bugs reales que la extra high, por alrededor de un quinto de los tokens.
Así que el primer ajuste que cambia tu factura es elegir el effort por tipo de tarea en vez de dejarlo todo en el valor por defecto: low o medium para el día a día y las reviews, extra high para los trabajos grandes. La verbosidad, en cambio, no se movió ni una palabra.
Dónde vive de verdad el interruptor de la verbosidad
Como el effort no acorta las respuestas, la longitud se fija por instrucción, y dónde pones esa instrucción importa tanto como lo que dice. Otro usuario del subreddit de Claude Code pasó días probándolo, y su primera conclusión coincide con la nuestra: el output style Concise integrado solo recorta la salida un 6 por ciento aproximadamente. Lo que funcionó fue poner una instrucción de concisión real en el slot output style y en ningún otro sitio: la misma frase como hook, o como regla en el archivo de instrucciones, no cambió nada.
Un output style es el slot de Claude Code que define cómo escribe el asistente, frente a lo que sabe. Construimos el nuestro con la redacción de la guía oficial: respuestas cortas y enfocadas, advertencias reducidas, un resumen de alto nivel salvo que se pidan los detalles.
| Dónde vive la regla de concisión | Efecto en la longitud |
|---|---|
| Preset Concise integrado | ~6 por ciento más corta |
| Hook, o regla en el archivo de instrucciones | Ningún cambio medible |
| Slot output style | Informe de cinco secciones → un párrafo y una lista de archivos |
La guía añade dos instrucciones hermanas que copiamos tal cual: una para la narración del agente, que encuadra cuándo puede el modelo comentar lo que hace, y otra para los archivos escritos en disco, porque los informes y los Markdown generados también se hinchan.
Para las reglas que nunca se disparan, el mismo post de Reddit da el criterio: una regla tiene que nombrar un momento reconocible y una acción concreta. «Mantén el changelog al día» nunca se dispara. «Cuando modifiques un archivo de la carpeta de código fuente, añade una línea al changelog en el mismo commit», sí.
Queda un tic verbal que estos bloques no cubren: la autocorrección narrada. A Opus 5 le encanta anunciar que corrige una frase anterior aunque la corrección no cambie nada para ti, y la guía tiene una instrucción dedicada: señalar una corrección solo si el error cambiaría tu código o tus decisiones, y arreglar el resto en silencio. Desde que esa línea entró en nuestra config, los falsos mea culpa desaparecieron.
La verbosidad se doma, pero no con un interruptor: con cuatro bloques de prompt colocados en los slots correctos.
Frenar el over-engineering borrando tus propios prompts
El agravio número dos se arregla quitando texto, no añadiéndolo. Empezamos purgando toda petición de verificación de nuestros prompts, tal como ordena la guía, y el bucle de verificación extra desapareció con ellas.
Después, para el scope, la guía trae una instrucción de encuadre que pegamos tal cual: entrega lo que se pidió al alcance previsto, señala en una frase si existe un enfoque mejor y sigue con la tarea pedida en vez de transformarla por tu cuenta. En la feature que había disparado nuestras docstrings de veinte líneas, repetimos exactamente la misma petición con ese encuadre: el diff bajó de nueve archivos tocados a tres, sin paso de verificación parásito.
Dos ajustes de la misma familia merecen una línea cada uno. Para code review, deja de escribir «reporta solo los problemas serios»: Opus 5 lo toma al pie de la letra y sub-reporta, así que pide todo y filtra en una segunda pasada. Y si el modelo lanza subagents a la mínima, también está documentado: Opus 5 delega con más facilidad que sus predecesores y cada subagent multiplica el coste. La guía da una instrucción que reserva la delegación para trabajos realmente paralelos, y desde la versión 2.1.217 Claude Code expone dos variables de entorno que topan en duro la profundidad de spawn y los agentes simultáneos.
| Tope | Por defecto |
|---|---|
| Profundidad de spawn de subagents | 3 niveles |
| Agentes simultáneos | 20 |
Esos valores por defecto explican cómo una sesión puede desmadrarse tanto sin pedirte opinión. El over-engineering no es un destino del modelo: son en buena parte tus prompts antiguos volviéndose en tu contra.
Lo que ningún bloque de prompt arregla
El límite es duro: la guía arregla la forma de lo que Opus 5 dice, no lo que decide hacer. Parte de las quejas del hilo describen otra cosa que verbosidad: un modelo que reconoce una restricción explícita, promete respetarla y hace lo contrario desde el primer turno. Ese agravio no tiene sección en la guía, y ninguno de nuestros bloques de prompt lo hizo desaparecer. Lo vimos una vez en nuestras pruebas: una restricción explícita sobre una API que no había que tocar, reconocida en la respuesta y saltada dos turnos después. Una vez en una semana de sesiones está lejos del naufragio que describen algunas quejas, pero es el tipo de error que ningún ajuste excusa cuando cae sobre código en producción.
También hay un coste de entrada. El sweep quema tokens reales: nuestras cuatro sesiones de prueba se comieron el equivalente a un día grande de trabajo en un plan de 20 dólares, y un usuario del hilo cuenta que el plan max más grande apenas sobrevive un fin de semana en effort high. Y ninguno de estos ajustes es portable: el output style, el encuadre de scope y los topes de subagents viven en tu config, así que cada máquina y cada proyecto hay que afinarlos de nuevo.
Si tu problema es el ruido, la guía lo arregla. Si tu problema es un modelo que hace lo que le da la gana, no te salvará, y el comentario más votado del hilo después de la queja original sigue siendo «vuelve al Opus anterior».
Domarlo o huir de él: nuestro veredicto
Nos bastaron veinte minutos de ajustes: el effort elegido por tipo de tarea en vez del valor por defecto, una instrucción de concisión en el slot output style, el encuadre de scope de la guía en el system prompt y las peticiones de verificación borradas de nuestros archivos antiguos.
| Métrica en nuestra tarea de referencia | Antes | Después |
|---|---|---|
| Longitud de la respuesta | Informe de cinco secciones | ~5× más corta, un párrafo + lista de archivos |
| Tamaño del diff | 9 archivos tocados | 3 archivos tocados |
| Coste de code review | Pasada extra high | ~1/5 de los tokens, los dos mismos bugs reales |
Sin cambiar de modelo ni de plan. Si tus quejas son la verbosidad y el over-engineering, haz este ajuste antes de cambiar de modelo: todo está documentado y el salto se ve desde el primer diff. Si tu problema es un modelo que ignora tus restricciones desde el primer turno, ningún prompt de la guía lo repara: mantén las tareas sensibles en un modelo que te obedezca y vuelve a probar Opus 5 en la próxima actualización.
AIDive