Claude Sonnet 5.5: cómo calibrar effort sin sobreactuar

Cuando un agente falla una tarea compleja, subir el esfuerzo parece la corrección obvia. El modelo razona más, explora más rutas y revisa con mayor profundidad. Pero una operación real no premia actividad: premia un resultado aceptable dentro del alcance, el tiempo y el presupuesto acordados. Si el agente añade archivos no solicitados, abre rondas de revisión innecesarias o agota el timeout, más trabajo puede reducir la probabilidad de aceptación.

Anthropic lanzó Claude Sonnet 5.5 el 28 de septiembre de 2026 y documentó cinco niveles de effort. La publicación oficial afirma mayor velocidad y menor costo por tarea frente a Sonnet 5, pero son mediciones del proveedor que no reproducimos. La señal más útil para ingeniería es otra: en FrontierCode, el resultado a max effort quedó por debajo de xhigh porque algunas ejecuciones iniciaron revisiones con subagentes, excedieron el tiempo o hicieron cambios fuera del alcance. Este artículo se publica un día calendario después en Lima.

Effort controla cuánto razonamiento y autonomía dedica el modelo a una solicitud. En Sonnet 5.5, low, medium, high, xhigh y max no son presupuestos fijos ni equivalen a los niveles de una versión anterior. Con más esfuerzo, el agente puede sostener una tarea más larga, comprobar su trabajo y resolver ambigüedades; también puede interpretar una petición abierta como permiso para añadir documentación, pruebas o refactors relacionados. El control modifica el recorrido completo, incluidas herramientas, reintentos y decisiones de parada.

Por eso la unidad de comparación no debe ser una respuesta aislada ni el número de tokens. Debe ser la tarea terminada y aceptada: entrada fijada, acciones permitidas, artefacto esperado, verificaciones obligatorias y criterios de rechazo. Dos niveles pueden producir código correcto, pero solo uno puede conservar el diff acotado y terminar antes del límite. En otro tipo de tarea, el nivel menor puede detenerse demasiado pronto. La política correcta depende de la forma del trabajo, no de una jerarquía universal de inteligencia.

Primero separa cargas que realmente exigen conductas distintas. Una extracción con esquema fijo, una respuesta de soporte con fuentes, un parche de un archivo y una migración ambigua no deberían compartir el mismo default solo porque llaman al mismo modelo. Para cada clase registra tamaño de entrada, herramientas disponibles, reversibilidad, costo del error, duración máxima, artefacto esperado y si una persona puede aclarar dudas. Ese sobre convierte la palabra «complejo» en restricciones observables.

Después crea casos representativos y casos frontera dentro de cada clase. Conserva las mismas entradas, versiones de herramientas, límites y jueces al comparar effort. Incluye solicitudes incompletas, datos contradictorios, una dependencia caída y un caso que debe pedir aprobación. Si cambias simultáneamente el prompt, el modelo, el harness y el nivel, no sabrás qué causó la mejora. El barrido debe aislar una decisión y dejar una línea base reproducible.

Define gates independientes: corrección funcional, cumplimiento del alcance, uso válido de herramientas, evidencia suficiente, latencia, costo total y necesidad de corrección humana. Un resultado falla si rompe un contrato crítico aunque su promedio sea alto. Para código, por ejemplo, separa pruebas pasadas, archivos permitidos, ausencia de cambios laterales, revisión aceptada y tiempo de ciclo. Para soporte, separa exactitud factual, citas, privacidad, tono y escalación correcta.

Mide también la variabilidad. Ejecuta cada caso varias veces cuando el riesgo y el presupuesto lo permitan, porque una sola trayectoria puede esconder una cola problemática. Reporta aceptación completa, no solo el porcentaje de respuestas correctas, y conserva los motivos de rechazo. La pregunta de release es «¿qué nivel cruza todos los gates con suficiente estabilidad?», no «¿qué nivel obtuvo la mayor puntuación agregada?». Esa diferencia evita comprar razonamiento que no mejora el resultado operativo.

No limites solo tokens. Fija máximo de llamadas de herramientas, duración, archivos o registros modificables, intentos por dependencia y rondas de auto-revisión. El agente debe conocer la condición de parada y el siguiente estado seguro: entregar el artefacto, pedir una aclaración, escalar o abortar sin efectos. Un nivel alto sin estos bordes puede convertir diligencia en deriva. Un nivel bajo sin criterio de completitud puede devolver un plan cuando el contrato exigía ejecución.

Las instrucciones de Sonnet 5.5 reconocen que xhigh y max pueden iniciar revisiones adicionales y acciones relacionadas. Anthropic propone indicar que el agente se detenga cuando la tarea y sus checks estén completos, y que no lance revisores si no se solicitaron. Ese patrón es generalizable: el prompt delimita iniciativa, mientras el runtime impone límites que el prompt no puede garantizar. Conserva ambos, porque una frase no sustituye cuotas, permisos ni cancelación efectiva.

Empieza cada clase en el nivel mínimo que supera sus gates, no en el máximo disponible. Escala cuando aparezca una señal definida: plan incompleto, dependencia no resuelta, verificación fallida, incertidumbre material o tarea que cruza un umbral de longitud. No escales por frustración después de cualquier error; algunos fallos requieren mejor contexto, una herramienta reparada o aprobación humana, y más esfuerzo solo repetirá el problema con mayor costo.

Registra nivel inicial, motivo de escalación, herramientas ya usadas, estado reversible y resultado final. La escalación no debe borrar el primer intento ni duplicar efectos. Después vuelve a evaluar periódicamente y baja el nivel si el prompt, las herramientas o el modelo mejoran. Una política que solo permite subir convierte cada avance del sistema en costo permanente. El router debe aprender qué complejidad necesita, no confundir antigüedad con criticidad ni volumen con dificultad.

Supongamos un agente que recibe una disputa, consulta contrato y factura, propone una respuesta y crea una tarea si detecta una inconsistencia. La extracción de campos empieza en low; el análisis con dos documentos coherentes, en medium. Si las condiciones comerciales se contradicen, el router pasa a high con el mismo snapshot y exige citar cada conclusión. Ningún nivel puede emitir una nota de crédito: esa acción queda fuera del sobre y requiere aprobación financiera.

El equipo compara cinco gates: campos correctos, evidencia trazable, decisión de escalación, respuesta dentro del SLA y cero efectos no autorizados. Si high mejora conflictos pero añade tareas duplicadas, no se aprueba hasta corregir idempotencia. Si xhigh aporta una explicación más elegante pero tarda demasiado y no cambia la aceptación, se conserva high. Si max busca anexos no solicitados, el gate de alcance lo rechaza aunque la respuesta sea correcta. El escenario es ilustrativo y no representa un cliente ni resultados de Wasyra.

Los resultados publicados por Anthropic dependen de sus harnesses, jueces, prompts y despliegues previos al lanzamiento. No ejecutamos Sonnet 5.5 ni verificamos sus afirmaciones de velocidad, costo o benchmarks. Tampoco asumimos que la anomalía entre max y xhigh aparecerá en otra carga. La lección transferible es metodológica: un control de esfuerzo puede cambiar alcance, herramientas y conducta de parada, por lo que debe evaluarse como una política de ejecución completa.

Aprueba un nivel cuando supera todos los gates relevantes con variabilidad aceptable y un costo total sostenible. Mantén una ruta explícita para escalar y otra para detenerse. Repite el barrido cuando cambien modelo, prompt, herramientas, límites o distribución de casos. Y conserva los rechazos: suelen mostrar si el siguiente paso es más razonamiento, mejor contexto, un control de runtime o una decisión humana.

Un buen router no presume que más es mejor. Selecciona el esfuerzo mínimo que completa la tarea, preserva el alcance y deja evidencia para revisar. Si necesitas convertir esa política en un piloto con casos reales, permisos y gates de release, el servicio de agentes a medida de Wasyra puede diseñar el recorrido. Es un servicio de implementación separado del producto disponible en agents.wasyra.com.