El nivel de esfuerzo de Claude Sonnet 5.5 no equivale al mismo nivel en Sonnet 5: por qué copiar tu configuración anterior puede salir caro

Un mismo número, un comportamiento distinto

Cuando una integración migra de un modelo a otro dentro de la misma familia, la tentación natural es conservar toda la configuración que ya funcionaba: mismo prompt, mismo nivel de esfuerzo de razonamiento. Con Claude Sonnet 5.5, la propia guía de prompting de Anthropic advierte de que esa costumbre puede salir cara. El parámetro effort es el control principal de cuánto piensa el modelo, y con él varían a la vez la calidad, la latencia y el coste; el problema es que sus niveles se han recalibrado en Sonnet 5.5, así que un nivel no produce la misma cantidad de razonamiento que ese mismo nivel en Claude Sonnet 5. Anthropic lo dice sin rodeos: conviene correr una prueba nueva contra las propias evaluaciones, en lugar de trasladar sin más el valor que se usaba antes.

Qué cambia exactamente entre una generación y la siguiente

Dos comportamientos documentados ilustran por qué no basta con mantener el mismo número. El primero es que, a un nivel de esfuerzo dado, Sonnet 5.5 tiende a pensar más por turno que Sonnet 5, sobre todo en los niveles xhigh y max: el mismo valor que antes producía una respuesta rápida puede ahora generar bastante más razonamiento interno antes de contestar, con el coste y la latencia que eso implica. El segundo es de valor por defecto: Claude Code y las aplicaciones de Claude usan Medium como nivel por defecto en Sonnet 5.5, mientras que la Claude Platform sigue usando High; quien no fije el nivel de forma explícita puede acabar comparando comportamientos distintos sin darse cuenta de que la diferencia viene de una configuración por defecto que cambió entre superficies, no del modelo en sí.

El dato que la propia Anthropic reconoce en su propia documentación: más esfuerzo no siempre es mejor

El detalle más honesto de todo este cambio, y el que menos circula fuera de la documentación técnica, es este: en la prueba de referencia Terminal-Bench 4.0, Sonnet 5.5 puntúa peor en el nivel máximo, max, que en el nivel inmediatamente inferior, xhigh —un 46,2% frente a un 52,1%—, y la propia Anthropic lo señala en una nota a pie de página de su tabla de lanzamiento en lugar de esconderlo. Es un resultado que contradice la intuición de que el nivel más alto de esfuerzo siempre da el mejor resultado, y es exactamente el tipo de matiz que una migración hecha de memoria, sin pruebas propias, no detectaría: quien suba a max pensando que es la opción más segura puede estar sacrificando calidad además de gastar más.

La recomendación práctica de Anthropic para evitar este tipo de sorpresas es concreta: empezar bajo y medir. Se sugiere arrancar en un nivel de esfuerzo bajo y subirlo solo si la calidad de las respuestas lo pide, comprobando el resultado en cada escalón con las propias pruebas de evaluación en lugar de asumir que un nivel más alto es automáticamente mejor. Dicho de otro modo: el barrido de niveles no es un lujo opcional al migrar de modelo, es la única forma de saber en qué punto de la escala recalibrada conviene quedarse.

La opción intermedia para cuando no hace falta pensar antes de cada respuesta

Sonnet 5.5 no permite desactivar el pensamiento por completo —una solicitud con thinking: {"type": "disabled"} devuelve un error que remite directamente a la alternativa—, pero sí ofrece un término medio pensado para tareas con herramientas: thinking: {"type": "between_tools"}, disponible con esfuerzo high o inferior. Con esta opción, Claude no razona antes de la primera respuesta si la solicitud no usa herramientas, lo que da una respuesta de solo texto comparable a la que producía disabled en Sonnet 5; en cambio, si la tarea sí encadena llamadas a herramientas, el razonamiento se activa entre esas llamadas, en los puntos donde de verdad aporta valor decidir el siguiente paso. Para flujos conversacionales sencillos que ocasionalmente necesitan una herramienta, esta opción evita pagar el coste de un razonamiento inicial que no se va a usar, sin renunciar a él en el resto de la tarea.

Matices antes de fiarse de un solo barrido

Conviene no generalizar demasiado rápido a partir de una sola prueba de referencia como Terminal-Bench 4.0: el patrón de que un nivel más alto rinda peor que uno intermedio puede no repetirse igual en una tarea completamente distinta, como resumir documentos o generar código en un lenguaje distinto al que se probó. La única forma fiable de saber qué nivel conviene para un caso de uso concreto es correr el propio conjunto de evaluaciones contra varios niveles de esfuerzo y comparar los resultados con datos propios, no con la tabla de otro.

Por qué importa hoy

Para cualquier integración que ya use la API de Claude y esté evaluando el salto a Sonnet 5.5, dar por bueno el nivel de esfuerzo que funcionaba en Sonnet 5 es, según la propia documentación de Anthropic, una forma casi segura de pagar de más o de recibir peor calidad sin saber por qué. El ejercicio de hoy es sencillo: coger el nivel de effort que se usa actualmente en producción, correr un barrido de low a max contra las propias pruebas, y fijar el nuevo valor con datos delante en lugar de con la costumbre del modelo anterior.

Conviene además separar dos decisiones que suelen mezclarse sin darse cuenta: cuánto piensa el modelo, que controla effort, y si piensa antes de la primera respuesta o solo entre llamadas a herramientas, que controla el propio tipo de thinking. Un equipo puede mantener un effort relativamente bajo para tareas sencillas y aun así beneficiarse de between_tools en un flujo conversacional con herramientas ocasionales, o subir el effort solo en el tramo de la tarea donde de verdad se necesita más profundidad de razonamiento, en lugar de aplicar el mismo nivel a toda la conversación de principio a fin. Tratar ambos parámetros como palancas independientes, en vez de como un único interruptor de «más o menos potencia», suele dar un ajuste más fino entre coste, latencia y calidad que subir o bajar un solo número a ciegas.