Claude Code Usa Esfuerzo Medio por Defecto. Cambiar a Máximo No Te Salvará.
Una gran sesión de código. 60 mensajes. Disparé /effort max tres veces, y tres veces lo cancelé. Resultado: "partially_achieved." Tres rondas de 25 minutos viendo a Claude dar vueltas en círculos mientras mi tarea real seguía ahí, sin tocar.
El asunto es este. Hice lo que se supone que hay que hacer. Claude Code sugiere /effort medium al instalarlo, ni lo pienso, cambio a high inmediatamente. Porque no puedo quemar todos mis tokens de todas formas, y porque Boris Cherny (el tipo que creó Claude Code) dijo que siempre uses la configuración más capaz.
Eso no arregló nada. Porque el problema nunca fue el nivel de esfuerzo. Fue lo que puse delante de él. Y nadie habla de esa parte. Los influencers prefieren felicitarse mutuamente por encontrar la posición correcta del slider.
TLDR: /effort max no compensa un contexto malo. Mis datos de 25 comandos de esfuerzo lo confirman. Las sesiones que resuelven tareas complejas de una sola vez comparten el mismo patrón de apertura: un plan estructurado antes del primer keystroke. Cambia tu default de medium a high, sí. Pero si eso es lo único que cambias, gastarás más tokens dando vueltas por los mismos errores. La secuencia real: plan estructurado primero, luego max effort. En ese orden.
Lo que Boris Cherny entendió antes que el resto de nosotros, y lo que mis propios datos de sesión confirmaron después de una semana de seguimiento, es que el slider es lo último que deberías tocar. No lo primero.
La Sesión Que Me Hizo Cuestionar el Slider
Sesión 271c43dd. La recuerdo porque /insights la marcó después como una de mis más largas.
60 mensajes. Tres veces escalé a /effort max durante la misma sesión, esperando resolver por fuerza bruta un bug de imagen de portada que debería haber sido directo. Claude se metió a fondo con problemas de sincronización de iCloud. Luego pivoteó a conflictos de path de fnm. Después se zambulló en resolución de node_modules. Doce horas de contexto, y el modelo estaba pensando cada vez más duro sobre las cosas equivocadas.
Las portadas nunca se arreglaron.
Es como pelear contra un boss en un RPG donde sigues usando el mismo hechizo maximizado, una y otra vez, y el boss simplemente se cura. En algún momento tienes que parar y leer la entrada real del bestiario. El hechizo nunca fue el problema. Estabas atacando la debilidad equivocada.
No tenía la configuración equivocada. Tenía el pasillo equivocado.
Esa realización se siente rara, porque significa que la cosa que todos están ocupados optimizando (el slider) es la última variable que importa, no la primera.
Max effort en el pasillo equivocado es solo remar más rápido.
Antes de descubrir qué arregla esto realmente, necesitas entender qué se supone que hace el slider, y por qué incluso su creador no se queda ahí.
El Creador de Claude Code Usa Max. Pero Ese No Es Su Verdadero Movimiento.
Boris Cherny es algo así como un semidiós para mí. Mitad humano, mitad proceso daemon que nunca para de enviar código.
El tipo envía 20 a 30 pull requests cada día. Ni una sola línea editada a mano desde noviembre. Opus 4.6, pensamiento extendido, máximo esfuerzo, siempre encendido. Antes de Anthropic, pasó 7 años en Meta liderando calidad de código en Facebook, Instagram, WhatsApp y Messenger. Creó Claude Code solo en septiembre de 2024, empezando con un chatbot de terminal que podía decirle qué música estaba escuchando. Todo el asunto fue, en sus propias palabras, accidental.
Su razonamiento para siempre usar el modelo más caro es contraintuitivo: en realidad es más barato. Sonnet necesita tres iteraciones para llegar al resultado correcto. Opus necesita una. El costo total de tokens para Opus termina siendo menor a pesar del precio más alto por token, porque dejas de pagar por loops de corrección. La mayoría de la gente mira el precio por token y elige el modelo más barato. Boris mira el costo total por tarea completada y elige el más inteligente.
Pero esa es la parte que todos ya citan de sus entrevistas. La parte que se saltan es lo que pasa antes de que cualquiera de eso importe.
Boris empieza aproximadamente el 80% de sus sesiones en modo plan. Y el modo plan no es algún sistema de orquestación sofisticado. Él mismo lo describió: todo lo que hace es inyectar una oración en el prompt que dice "por favor no escribas código todavía." Eso es todo. Codificó la funcionalidad en 30 minutos un domingo por la noche después de leer issues de GitHub donde los usuarios ya estaban haciendo esto naturalmente en sus prompts. Lo envió el lunes por la mañana.
El principio subyacente: una vez que el plan es bueno, el código es bueno. Sus palabras, no las mías. Y es probablemente la cosa más importante que ha dicho sobre Claude Code que nadie parece internalizar realmente. El modelo, el nivel de esfuerzo, el pensamiento extendido, todo eso viene después del plan. Siempre después.
Incluso dijo que el modo plan probablemente tiene una vida útil limitada. Tal vez un mes. Porque eventualmente el modelo simplemente descubrirá por sí mismo cuándo planear. Pero ahora mismo, en esta ventana, el trabajo del humano es hacer bien el plan. El trabajo de preparación antes de empezar a cocinar. Todo lo demás sigue de ahí.
(Vale la pena notar: Boris trabaja en Anthropic con acceso privilegiado al modelo. Envía a una velocidad que la mayoría de nosotros no igualaremos, y su flujo de trabajo está optimizado para entrega de alta velocidad de 20-30 PRs al día. El patrón se transfiere a tus proyectos. Los números exactos probablemente no.)
Boris usa max effort. Pero hace modo plan primero.
21 de 25: Lo Que Mis Comandos de Esfuerzo Realmente Muestran
Los números crudos primero.
/insights auditó mis últimos 25 comandos de esfuerzo desde el 16 de marzo. 21 veces usé /effort max. Una vez /effort medium. Una vez /effort high. Dos checks. No soy alguien que empiece bajo y escale gradualmente. Voy directo a max en cualquier cosa que se vea aunque sea ligeramente no trivial.
Y ahora mismo, esto está pasando en todas partes. Anthropic acaba de cambiar oficialmente Opus 4.6 a "medium effort" como el default para suscriptores Max y Team. El post del changelog recolectó más de mil likes. Devs en todo el tablero están descubriendo que esta configuración existe y corriendo a subirla. Como lo puso Todd Saunders: la mayoría de la gente usando Claude Code está obteniendo tal vez el 40% de lo que el modelo puede hacer con los defaults.
Así que sí. Cambia el default. Esa parte está resuelta.
Ahora el número que realmente importa: mis peores sesiones, las maratones de 60 mensajes terminando en "partially_achieved," esas también corrían /effort max. Misma posición del slider que mis mejores sesiones. Mismo modelo. Mismo pensamiento extendido. La diferencia en resultado no fue el nivel de esfuerzo.
Es como tener dos cocinas con exactamente el mismo horno profesional. Un chef hizo el trabajo de preparación por adelantado con contratos de prompt estructurados. El otro solo subió la temperatura y esperó lo mejor. Mismo horno. Cenas muy diferentes.
(Los datos de /insights no registran qué nivel de esfuerzo está activo por turno de conversación, solo cuando escribes el comando slash. Así que este análisis está basado en patrones observados, no correlación directa esfuerzo-a-resultado por mensaje. El patrón sigue siendo difícil de ignorar.)
21 veces max effort. Mis peores sesiones también.
¿Qué separa las sesiones que resuelven de una vez de las sesiones que se espiralan? La respuesta apareció en las sesiones de 2 mensajes.
La Variable Real: Lo Que Pasa Antes de Que Escribas la Tarea
Esto es lo que mi historial real de sesiones revela cuando ordenas por eficiencia.
Sesiones donde /effort max cambió el resultado: refactoring complejo con tests de no regresión (sesión 8fd1e558). Escribir el esqueleto para mi libro sobre contratos de prompt (sesión ae7d6686). Bugs arquitectónicos donde Claude necesitaba razonar a través de múltiples archivos a la vez. Tareas con ambigüedad genuina donde el razonamiento más profundo del modelo realmente tenía algo útil que masticar.
Sesiones donde /effort max no cambió nada: contexto de repo equivocado ("no, el blog de Astro, no este"), deriva de alcance donde Claude empezó a modificar archivos que nunca mencioné ("¿por qué tocaste ollama, no pedí eso?"), prompts de apertura ambiguos donde describí mi frustración en lugar de describir la tarea.
¿Y las sesiones que resolvieron de una vez? ¿Las sesiones de 2 a 4 mensajes que resolvieron tareas complejas al primer intento?
Todas abren de la misma manera.
"Implementa el siguiente plan:" seguido de un bloque de contexto estructurado.
Cuatro de mis diez sesiones más eficientes usan exactamente este prefijo. Una sesión de 2 mensajes con un plan estructurado consistentemente supera a una sesión de 60 mensajes con /effort max y sin contexto inicial. Cada vez en mis datos. Ni siquiera está cerca. Las sesiones de 2 mensajes se sienten casi aburridas, como ver a alguien seguir una receta. Las sesiones de 60 mensajes se sienten como un raid sin tank y sin healer. El DPS de todos está maximizado pero el party se wipe de todas formas.
El desglose que salió de esto no es complicado:
/effort max importa cuando la tarea tiene ambigüedad arquitectónica genuina. Múltiples archivos, dependencias no obvias, razonamiento que requiere mantener varias restricciones en paralelo. Para esas tareas, max effort vale el tiempo de respuesta extra.
Un plan estructurado por adelantado importa en todo lo demás. Funcionalidades rutinarias, arreglos de bugs, migraciones, cualquier cosa donde sabes cómo debería verse el resultado pero el modelo no tiene suficiente contexto para ir en la dirección correcta.
Para tareas críticas, quieres ambos. Plan primero, max effort segundo. Esa combinación es lo que resuelve de una vez.
(Una salvedad que importa: "Implementa el siguiente plan:" funciona cuando el plan está realmente estructurado. Un plan vago más max effort te da el mismo resultado que un prompt vago más max effort. La calidad del plan es la variable, no su presencia formal.)
"Implementa el siguiente plan:" le gana a /effort max sin contexto. Cada vez.
Lo que Boris llama modo plan, lo que mis datos llaman "Implementa el siguiente plan:", es el mismo principio. Y está ausente del 90% de los flujos de trabajo de Claude Code que veo online.
Cambia el Default. Luego Cambia Lo Que Pones Delante de Él.
El default medium es una decisión que Anthropic tomó para manejo de costos a escala. No una recomendación para tu flujo de trabajo. El changelog lo confirma. Si estás en un plan Max o Team y sigues corriendo medium, estás dejando capacidad sobre la mesa. Cambia a high como tu baseline. Reserva /effort max para tareas con complejidad arquitectónica real, del tipo donde Claude necesita razonar a través de múltiples archivos y mantener varias restricciones en su cabeza. En trabajo mecánico (deploys, pushes, migraciones repetitivas), high es suficiente y notablemente más rápido.
Pero si cambiar el slider es lo único que cambias, gastarás más tokens llegando a la misma respuesta equivocada con más confianza.
Garry Tan optimizó la capa de revisión, atrapando errores después de que Claude escribe código. La mayoría de devs optimizan el slider, el poder crudo del modelo. Ninguno de los dos aborda el verdadero cuello de botella: lo que Claude entiende antes de empezar a trabajar. La capa de input. La que determina si todo ese poder de procesamiento va en la dirección correcta o contra una pared.
Tres cosas para recordar.
Uno: cambia el default de medium a high al instalar. Es una decisión de Anthropic para manejar costos de infraestructura, no una recomendación para tu flujo de trabajo. El changelog lo confirma, está hecho, siguiente.
Dos: /effort max no compensa un contexto de inicio malo. Mis 25 comandos lo muestran. Boris Cherny sabía esto desde el principio. Por eso codificó el modo plan un domingo por la noche antes de hablar sobre qué modelo usar.
Tres: la secuencia que funciona es deprimentemente banal. Un plan estructurado. "Implementa el siguiente plan:". /effort max. En ese orden. No es glamoroso. Pero es lo que mis sesiones de 2 mensajes que resuelven de una vez tienen en común, y lo que mis sesiones de 60 mensajes no tienen.
El slider /effort es lo último que tocar, no lo primero.
Fuentes y enlaces
Boris Cherny sobre flujos de trabajo de Claude Code, modo plan, y la paradoja de costo de Opus: YC Light Cone podcast, Pragmatic Engineer podcast, Lenny's Podcast (2025-2026).
Changelog de Anthropic sobre el default de medium effort de Opus 4.6 para suscriptores Max/Team: @ClaudeCodeLog.
(*) La portada es generada por AI. El modo plan de Boris también se generó en 30 minutos, así que al menos la portada está en buena compañía.