AIDive

Pack de vídeo

Domar Opus 5: barrido de esfuerzo, prueba de concisión y guía oficial, medidos

11 min de lectura

TL;DR

  • Unos veinte minutos de ajustes eliminan casi todo el ruido del que se quejan los usuarios de Opus 5: el esfuerzo elegido por tipo de tarea, una regla de concisión en el slot de output style, el encuadre de alcance de la guía en el system prompt, y cada línea "verify your work" borrada de los viejos archivos de instrucciones.
  • El esfuerzo no es un dial de verbosidad. Controla cuánto piensa el modelo y cuántas llamadas a herramientas hace, no la longitud de la respuesta visible. Bajarlo para que se calle es tirar de la palanca equivocada.
  • Dónde vive una regla de longitud importa más que su redacción: el preset Concise integrado movió la salida un 6 por ciento aproximadamente, la misma regla como hook o en el archivo de instrucciones no cambió nada, y una regla real en el slot de output style convirtió un informe de cinco secciones en un párrafo más una lista de archivos.
  • El exceso de ingeniería se arregla borrando texto, no añadiéndolo. Purgar las peticiones de verificación y pegar el encuadre de alcance de la guía llevó nuestro diff de referencia de nueve archivos a tres.
  • Los esfuerzos low y medium encontraron los mismos dos bugs reales que la pasada extra-high en nuestro diff de revisión, por aproximadamente un quinto de los tokens.
  • Lo que ningún bloque de prompt arregla: un modelo que reconoce una restricción explícita y la esquiva dos turnos después. Lo vimos una vez en una semana de sesiones, y la guía no tiene ninguna sección sobre ello.

Lo que dicen las fuentes

El enfado es real y medible. El hilo de r/ClaudeCode titulado "Opus 5 is insufferable" superó los 600 votos y los 178 comentarios, y su autor acusa al modelo de hablar un idioma nuevo que llama "Unintelligiblish" s3. En X, un desarrollador publicó solo una captura de los comentarios de código que había generado Opus 5 y reunió 9,700 likes s6. Cuando el creador de Claude Code defendió el modelo en público, la respuesta que lo cuestionaba juntó 2,843 likes s7.

Tres cambios internos explican buena parte de lo que sienten los usuarios. El thinking viene activado por defecto y solo se puede desactivar con esfuerzo high o inferior; la ventana de contexto pasa a un millón de tokens, por defecto y como máximo; y el parámetro de esfuerzo se convierte en el dial central, con cinco niveles, low, medium, high, xhigh y max, siendo high el valor por defecto s2. El parámetro controla cuántos tokens gasta el modelo pensando, llamando a herramientas y respondiendo. Con esfuerzo low el modelo agrupa las llamadas a herramientas, actúa sin preámbulo y confirma en una frase. Con esfuerzo high multiplica las llamadas, explica su plan antes de tocar nada y comenta sus cambios en detalle s2. Si esa segunda descripción suena a tus sesiones, llevas usando el valor por defecto desde el primer día. Un detalle de API que conviene saber: con xhigh y max el thinking ya no se puede desactivar, y la petición devuelve un error 400 si lo intentas s2.

Los cuatro comportamientos de los que todos se quejan se reproducen a demanda. Verbosidad: una pregunta de dos frases volvió con secciones, subtítulos y advertencias estilo auditoría; el comentario más votado del hilo describe anuncios grandilocuentes del tipo "we discovered something that changes everything" seguidos de diez minutos de comandos de shell s3. Exceso de ingeniería: un usuario cuenta un archivo de decisiones de 7,000 líneas, y cuando pidió una limpieza el modelo recortó 1,200 líneas y luego añadió 600 para documentar los borrados s3. Ampliación del alcance: pides X, el modelo decide que el tema real es Y y lo explica en ocho párrafos. Malas noticias enterradas: un muro de texto que dice que todo salió bien, con un asterisco a tres cuartos del camino que admite que algo se rompió s3.

La guía oficial, "Prompting Claude Opus 5", responde al hilo punto por punto. Su frase más importante: el esfuerzo controla cuánto piensa el modelo, no cuánto habla; bajar el esfuerzo reduce el volumen de thinking pero no acorta de forma fiable la respuesta visible s1. La longitud hay que pedirla con palabras claras, con una instrucción de concisión en el system prompt. La guía también dice algo que pocos esperan de un proveedor: quita instrucciones. Si tu archivo de instrucciones contiene "verify your work before answering" o "add a final verification step", bórralo, porque Opus 5 ya se autocomprueba y esas líneas provocan sobreverificación y tokens quemados s1. El creador de Claude Code lo resumió igual: Opus 5 necesita menos prompting, no más s5. El resto de la guía tiene una sección por queja: narración del agente, longitud de los archivos generados, encuadre de alcance, subagents, autocorrección, cada una con el bloque de prompt exacto para copiar s1.

En revisión de código, la guía afirma que la precisión se mantiene con esfuerzos bajos, lo que permite una pasada rápida y barata al hacer commit y una pasada profunda más tarde s1. También advierte contra "only report serious problems": Opus 5 lo toma al pie de la letra y reporta de menos, así que pide todo y filtra en una segunda pasada s1. En delegación, Opus 5 lanza subagents con más facilidad que sus predecesores y cada uno multiplica el coste; la guía ofrece una instrucción que reserva la delegación para trabajos grandes y realmente paralelos s1, y Claude Code añade desde la versión 2.1.217 dos variables de entorno, CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH y CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, cuyos valores por defecto son tres niveles de profundidad y veinte agentes simultáneos s9.

El hallazgo sobre el slot viene de un segundo hilo. Un usuario de r/ClaudeCode pasó días probando dónde funciona una regla de concisión: el estilo de salida Concise integrado solo recortó la salida un 6 por ciento aproximadamente, y la misma instrucción como hook o como regla del archivo de instrucciones no cambió nada; lo que funcionó fue una instrucción real en el slot de output style s4. El mismo post da el criterio para las reglas que nunca se activan: una regla debe nombrar un momento reconocible y una acción concreta. "Keep the changelog up to date" no se activa; "when you modify a file under src/, add a line" sí s4.

Mediciones

Experimento Montaje Resultado
Barrido de esfuerzo, mismo arreglo de bug low, medium, high, xhigh, cuatro sesiones limpias low y medium produjeron un arreglo equivalente con una fracción de los tokens de high; xhigh exploró más archivos y blindó los casos límite
Revisión de código en uno de nuestros diffs pasada low vs pasada xhigh low encontró los mismos dos bugs reales que xhigh con aproximadamente un quinto de los tokens
Ubicación de la regla de concisión preset Concise vs slot de output style preset: un 6 por ciento más corto aproximadamente; regla en output style: un informe de cinco secciones pasó a ser un párrafo más una lista de archivos
Encuadre de alcance en la función de docstrings encuadre de la guía pegado, líneas de verificación eliminadas el diff pasó de nueve archivos tocados a tres, sin paso de verificación parásito
Esquive de restricción una semana de sesiones una restricción explícita "do not touch this API" reconocida y luego esquivada dos turnos después

Protocolo: un arreglo de bug de referencia y una pequeña función de nuestro propio repo, repetidos en sesiones nuevas de Claude Code. El esfuerzo se fijó por sesión con /effort, --effort o effortLevel en settings.json s8. La regla de concisión se construyó con la redacción de la guía (respuestas cortas y centradas, menos salvedades, resumen de alto nivel salvo que se pida detalle) s1. Coste del ejercicio: las cuatro sesiones del barrido consumieron el equivalente a una jornada de trabajo intensa en un plan de 20 dólares, y un usuario del hilo cuenta que su plan 20x apenas le dura un fin de semana con esfuerzo high s3.

Veredicto

Ajuste Keep, try o skip Por qué
Esfuerzo por tipo de tarea (low o medium a diario y en revisiones, xhigh para refactors grandes) Keep Los mismos bugs encontrados con un quinto de los tokens en revisión
Regla de concisión en el slot de output style Keep Único slot donde la regla movió la salida más allá del 6 por ciento aproximado
Regla de concisión como hook o línea del archivo de instrucciones Skip Sin cambio medible
Borrar las líneas "verify your work" Keep El bucle de sobreverificación desapareció con ellas
Encuadre de alcance de la guía en el system prompt Keep Diff de nueve archivos a tres
Límites de subagents con variables de entorno Try Los valores por defecto de 3 de profundidad y 20 simultáneos explican las sesiones descontroladas
"Only report serious problems" en prompts de revisión Skip El modelo reporta de menos; pide todo y filtra después
Opus 5 en tareas donde ignorar una restricción es inaceptable Skip por ahora Un esquive en una semana, nada en la guía lo aborda

Haz esto el lunes

  • Abre tu archivo de instrucciones y borra cada línea que pida al modelo verificar, comprobar de nuevo o añadir un paso final de verificación.
  • Pon effortLevel en medium en el settings.json de tu repo diario, y reserva xhigh para una rama de refactor para comparar.
  • Escribe una regla de concisión con la redacción de la guía y ponla en el slot de output style, no en un hook ni en el archivo de instrucciones.
  • Pega el bloque de encuadre de alcance de la guía en tu system prompt: entregar lo pedido con el alcance previsto, señalar un enfoque mejor en una frase, continuar con la tarea solicitada.
  • Ejecuta tu próxima revisión de código dos veces, una con low y otra con xhigh, y cuenta los bugs reales que encuentra cada pasada antes de seguir pagando por la profunda.
  • Reescribe cualquier regla que nunca se activa para que nombre un momento y una acción, siguiendo el patrón "when you modify a file under src/".
  • Pon CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH y CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS por debajo de sus valores por defecto durante una semana y vigila tu factura de tokens.
  • Mantén una restricción estricta en un prompt de un repo sensible y comprueba dos turnos después si el modelo todavía la respeta.

Para ir más lejos

  • Lee la guía "Prompting Claude Opus 5" completa, no solo la sección de verbosidad: narración, longitud de archivos generados, alcance, subagents y autocorrección tienen cada uno un bloque listo para copiar s1.
  • La página de esfuerzo documenta los cinco niveles y el error 400 al desactivar el thinking con xhigh o max; léela antes de automatizar el esfuerzo por proyecto s2.
  • La referencia de settings muestra dónde viven effortLevel y los output styles para que tus ajustes difieran por repo s8.
  • La documentación de subagents explica los límites de profundidad y concurrencia detrás de los valores por defecto 3 y 20 s9.
  • El post "How I got Opus 5 actually usable" contiene la comparación completa de slots, incluida la cifra de aproximadamente 6 por ciento del preset Concise s4.
  • El hilo "insufferable" merece leerse más allá del comentario más votado: la historia del archivo de decisiones de 7,000 líneas y los reportes de esquive de restricciones están en las respuestas largas s3.
  • El breve intercambio en X entre el creador de Claude Code y sus críticos enmarca la postura "less prompting, not more" en pocas líneas s5.

Fuentes

  • Prompting Claude Opus 5, Anthropic. Por qué leerlo: los bloques de prompt exactos para cada queja, y la frase que dice que el esfuerzo no es un dial de longitud.
  • Effort parameter, Anthropic. Por qué leerlo: los cinco niveles, su comportamiento y la restricción del thinking con xhigh y max.
  • Opus 5 is insufferable, r/ClaudeCode. Por qué leerlo: el catálogo de comportamientos que reconocerás, con los reportes del coste de los planes en las respuestas.
  • How I got Opus 5 actually usable, r/ClaudeCode. Por qué leerlo: la única prueba slot por slot de dónde funciona una regla de concisión.
  • Boris Cherny on Opus 5 prompting, X. Por qué leerlo: el enfoque del propio mantenedor, menos prompting en lugar de más.
  • Screenshot of Opus 5 code comments, X. Por qué leerlo: la imagen de 9,700 likes que hizo mainstream la queja de verbosidad.
  • Opus 5 output thread, X. Por qué leerlo: la respuesta de 2,843 likes que muestra lo poco que caló la defensa.
  • Claude Code settings, Anthropic. Por qué leerlo: dónde se guardan effortLevel y los output styles por proyecto.
  • Claude Agent SDK: subagents, Anthropic. Por qué leerlo: el modelo de profundidad de lanzamiento y concurrencia detrás de los dos límites de entorno.

FAQ

¿Bajar el esfuerzo hace Opus 5 más corto?

No. El esfuerzo reduce el volumen de thinking y de llamadas a herramientas, no la respuesta visible. La longitud viene de una instrucción de concisión explícita, y el slot de output style es donde funcionó en nuestras pruebas.

¿Debería cambiar de modelo?

Si tu queja es el ruido y el exceso de ingeniería, haz primero el ajuste de veinte minutos: la diferencia se ve en el primer diff. Si tu queja es un modelo que ignora restricciones explícitas, nada en la guía lo arregla; deja las tareas sensibles en un modelo que obedezca y vuelve a probar en la próxima actualización.

¿Son portables estos ajustes?

No. El output style, el encuadre de alcance y los límites de subagents viven en tu configuración, así que hay que volver a ajustarlos en cada máquina y cada proyecto.

¿Cuánto cuesta el barrido de esfuerzo?

Nuestras cuatro sesiones de prueba usaron el equivalente a una jornada de trabajo intensa en un plan de 20 dólares. Hazlo una vez con una tarea de referencia y luego elige un valor por defecto por repo.