Anthropic lanzó Claude Sonnet 5.5 el 28 de septiembre, seis días después de Opus 5.5. Con una tarifa de 2 $ por millón de tokens de entrada y 10 $ por millón de salida, cuesta exactamente la mitad que los 4 $ y 20 $ de Opus 5.5. Además, en la página de lanzamiento queda a escasos puntos de Opus 5.5 en la mayoría de las pruebas e incluso lo supera en Terminal-Bench 4.0, un benchmark realizado por la propia Anthropic. Para cualquier equipo que trabaje con varios agentes de desarrollo, la tentación evidente es migrar todos los Agents a Sonnet y ahorrarse la diferencia.
Sin embargo, las gráficas desglosadas por nivel de esfuerzo de esa misma página demuestran lo contrario. La cifra destacada en Terminal-Bench se obtuvo con el nivel de esfuerzo máximo de Sonnet, con un coste de 12,54 $ por intento. Con las configuraciones habituales para trabajar de forma continuada, el orden se invierte: Opus 5.5 en medium obtiene un 57,6 % por 2,94 $, Sonnet 5.5 en high alcanza un 43,0 % por 1,94 $, y Sonnet solo logra superar a Opus en medium cuando se sube a xhigh, registrando un 61,5 % por 5,30 $.
En resumen
Asigna por defecto el trabajo bien delimitado a Sonnet 5.5 en medium. Deriva las tareas extensas, ambiguas o transversales a Opus 5.5 antes que forzar Sonnet en xhigh: en las tres tablas de programación por nivel de esfuerzo publicadas por Anthropic, Opus en high supera a Sonnet en xhigh por un coste similar o inferior. Fíjalo como una regla explícita en el Agent, no como una preferencia informal: un Agent por cada nivel de modelo y esfuerzo, criterios de escalado claros y una definición de terminado («definition of done»). Sharkly no selecciona el modelo ni el esfuerzo; mantiene el registro de qué Agent llevó a cabo cada acción en la Task.
Qué respaldan los datos de lanzamiento
La tabla de lanzamiento, con el esfuerzo empleado en cada celda y la entidad que ejecutó la prueba:
| Benchmark | Reported by | Sonnet 5.5 | Opus 5.5 |
|---|---|---|---|
| Terminal-Bench 4.0 | Anthropic | 70.6% (max) | 66.4% (xhigh) |
| FrontierCode 1.1 | Cognition | 52.1% (xhigh), 46.2% (max) | 54.4% (max) |
| CursorBench 4.0 | Cursor | 55.5% (max) | 57.8% (max) |
| SWE-Bench Pro | Anthropic system card, max effort | 81.3 | 89.9 |
| HLE, with tools | Anthropic | 64.5% | 67.7% |
| OSWorld 2.1 | Anthropic | 80.1% | 81.8% |
Conviene señalar dos matices sobre la fila de Terminal-Bench. El system card documenta que las solicitudes marcadas afectaron al 10 % de las pruebas de Opus 5.5 frente al 1,5 % de las de Sonnet, y la evaluación independiente de Artificial Analysis situó a Sonnet 5.5 en un 63,6 %, no en el 70,6 %. Por su parte, SWE-Bench Pro muestra una ventaja de 8,6 puntos a favor de Opus. El posicionamiento de la propia Anthropic coincide con estos resultados: Sonnet 5.5 para tareas cotidianas bien acotadas y resolución de bugs, mientras que Opus 5.5 «sigue siendo claramente superior en trabajos complejos y abiertos».
Las cifras de portada también ocultan el dato esencial para definir una regla de enrutamiento: los resultados en los tres benchmarks de desarrollo en los niveles de esfuerzo que realmente se utilizarían, expresados en puntuación y coste por tarea.
| Benchmark | Sonnet 5.5 medium | Sonnet 5.5 high | Sonnet 5.5 xhigh | Opus 5.5 medium | Opus 5.5 high |
|---|---|---|---|---|---|
| Terminal-Bench 4.0 | 28.8%, $0.83 | 43.0%, $1.94 | 61.5%, $5.30 | 57.6%, $2.94 | 64.2%, $3.88 |
| CursorBench 4.0 | 39.2%, $0.70 | 47.8%, $1.67 | 53.1%, $3.88 | 52.5%, $2.91 | 56.0%, $3.97 |
| FrontierCode 1.1 | 36.5%, $0.24 | 49.4%, $0.42 | 52.1%, $1.59 | 54.6%, $0.80 | 54.0%, $1.09 |
Sonnet 5.5 representa la alternativa más económica en medium y high, franjas donde también obtiene sus puntuaciones más bajas. A partir de high, las trayectorias se cruzan: Sonnet en xhigh resulta más caro que Opus en medium en los tres casos y rinde por debajo de Opus en high en todos ellos por un importe equivalente o inferior. El modelo económico deja de serlo precisamente cuando se le exige rendir como el modelo superior. Hay que tener en cuenta que los costes de Sonnet en CursorBench corresponden a estimaciones de Anthropic y que ninguna de estas tareas refleja tu repositorio real, por lo que este punto de cruce debe considerarse una hipótesis que validar empíricamente.
La regla de enrutamiento, por escrito
En publicaciones anteriores argumentamos a favor de asignar modelos según el rol de cada Agent, de determinar qué agente debe asumir una tarea en función de su estructura y de formalizar los niveles en reglas explícitas. Sonnet 5.5 incorpora una variable adicional. En Terminal-Bench, el coste del mismo modelo en medium y en max se multiplica aproximadamente por 15 por intento (0,83 $ frente a 12,54 $), de modo que la instrucción «enviar esto a Sonnet» no es una regla completa si no especifica el nivel de esfuerzo.
| Tipo de tarea | Agent (modelo de runtime) | Esfuerzo | Motivo |
|---|---|---|---|
| Corrección de errores con reproducción y un test específico | Sonnet 5.5 | medium | La guía de prompting de Anthropic recomienda medium para programación con agentes en tareas bien delimitadas |
| Scaffolding de tests, documentación, changelog y actualización de dependencias | Sonnet 5.5 | medium | Alcance acotado, verificación económica y menos de un dólar por tarea en las tres tablas |
| Funcionalidad delimitada dentro de un solo módulo, con criterios de aceptación claros | Sonnet 5.5 | high | Sigue siendo más económico que Opus en medium en todas las métricas; el límite del rango útil de Sonnet |
| Triaje nocturno de gran volumen | Sonnet 5.5 | low, más una fase de verificación | El coste más bajo por ejecución, aunque en low puede notificar que ha finalizado sin haber ejecutado los tests |
| Refactorización extensa o ambigua, migración o cambios transversales | Opus 5.5 | medium o high | En high supera a Sonnet en xhigh en las tres tablas con un coste similar o más bajo |
| Planificación: desglosar una petición abierta en Tasks | Opus 5.5 | high | El trabajo complejo y abierto es precisamente el ámbito donde Anthropic destaca el liderazgo de Opus |
| Revisión del trabajo generado por otro Agent | Opus 5.5 y posterior validación humana | high | Un segundo modelo audita las pruebas; una persona da el visto bueno al resultado final |
El criterio de escalado es el punto donde la regla justifica su implementación. Cuando un Agent con Sonnet encuentra dificultades, la reacción espontánea suele ser incrementar su nivel de esfuerzo. Los datos indican que lo correcto es cambiar de modelo: una Task que exige Sonnet en xhigh es, a tenor de los números, una tarea para Opus en high. Establece tus propias condiciones; las siguientes sirven como referencia:
- La misma comprobación falló en dos ocasiones. Una persona reasigna la Task al Agent de Opus adjuntando el registro de errores; ningún proceso debe reintentarse en silencio en un nivel superior.
- El cambio involucra más archivos de los autorizados para un worker (por ejemplo, ocho) o modifica rutas que la Task no contemplaba.
- El Agent formula una consulta arquitectónica o de diseño en lugar de una aclaración sobre la descripción de la Task.
- Una categoría concreta de Tasks solo prospera con Sonnet por encima de high. Migra esa tipología al Agent de Opus en el próximo Sprint.
El criterio opera igualmente en sentido opuesto: aquellas Tasks asignadas a Opus que se completan sistemáticamente en un único intento y con diffs reducidos deben descender un nivel.
El impacto de cada modelo en la cola de revisión
Una regla que solo define el modelo y el esfuerzo se queda corta. La otra parte imprescindible es precisar qué constituye una entrega terminada, dado que cada nivel suministra al revisor un material muy distinto, y la revisión ya era el principal cuello de botella antes de ambas presentaciones. Las ejecuciones más baratas generan más diffs, no más horas de revisores.
La guía de prompting de Anthropic para Sonnet 5.5 describe con total franqueza lo que llegará al revisor:
- En low y medium solicita confirmación de forma prematura durante tareas complejas con agentes: lo que en el panel se traduce en una Task parada a las dos de la madrugada a la espera de intervención humana. Un participante de Hacker News atribuyó a esta conducta una puntuación de apenas el 7,4 % en un benchmark interno (frente al 17,8 % registrado por Sonnet 5).
- En low puede omitir la fase de verificación y dar el código por concluido sin haber corrido los tests. El estado «terminado» de un Agent de triaje carece de valor si no incluye la salida de las comprobaciones.
- En cualquier nivel de esfuerzo incorpora tests, documentación y pequeños archivos que nadie solicitó. Aunque parte de ese material sea útil, todo ello engrosa el diff que es necesario auditar.
- En xhigh y max añade rondas de revisión o subagentes revisores. La propia página de presentación aclara que esta fue la causa de que Sonnet 5.5 obtuviera un resultado inferior en FrontierCode en max respecto a xhigh: invocó con mayor asiduidad la herramienta de revisión de código de Claude Code, que se ramifica en numerosos subagentes, y en dos escenarios analizados por Cognition esto provocó timeouts o modificaciones fuera de alcance. Este tipo de desvíos representa la mayor carga para un revisor, al obligarle a rastrearlos línea por línea.
Opus 5.5 sobrecarga la cola por un motivo distinto. Anthropic indica que puede permanecer centrado en una tarea durante 18 horas o más, generando hasta 128k tokens de salida; por tanto, el reto reside en la magnitud de la entrega, no en el ruido accesorio, haciendo indispensable el paquete de traspaso que precisa todo revisor.
Por esta razón, la definición de terminado debe integrarse en las directrices del Agent worker, las cuales Sharkly suministra en cada ejecución:
Agent: sonnet-worker (Claude Code, claude-sonnet-5-5, effort medium)
Done means:
- The checks named in the Task ran. Paste each command and its exit
code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.
Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.
Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.
Cómo utilizar ambos niveles en Sharkly
Sharkly no elige el modelo ni configura los niveles de esfuerzo. La documentación de Agents lo especifica con claridad: «El Agent asume el modelo por defecto del Runtime. No garantiza ni muestra un nombre de modelo concreto. Modifique los modelos en la configuración del Runtime o de la herramienta Computer, nunca en el Agent». Tampoco existe un selector de profundidad de razonamiento en el Agent. Cada nivel corresponde a una configuración concreta de Claude Code dentro de una Computer; el Agent es simplemente el mecanismo mediante el cual el equipo le delega el trabajo.
La pauta es directa: un Agent por cada nivel. sonnet-worker opera sobre una Computer con Claude Code configurado en claude-sonnet-5-5, mientras que opus-lead lo hace en una ajustada a claude-opus-5-5. Como una Computer puede ser un contenedor, disponer de un segundo nivel no exige una máquina física adicional. Tres aspectos de la documentación de configuración de modelos de Claude Code garantizan que cada nivel se corresponda exactamente con su designación:
- Fija el identificador completo. El alias
sonnetúnicamente enlaza con Sonnet 5.5 dentro de la API directa de Anthropic (en Bedrock y Google Cloud sigue resolviendo hacia Sonnet 4.5), y Sonnet 5.5 exige Claude Code v2.1.284 o superior. - El modelo
defaultde Claude Code es Opus 5.5 en las modalidades Pro, Max, Team, Enterprise y en la API, por lo que cualquier Computer sin configuración previa opera de fábrica como un nivel Opus. - El esfuerzo predeterminado de Sonnet 5.5 en Claude Code es medium, equivalente al nivel worker descrito previamente. Su ajuste se realiza en la Computer, no en el Agent.
Debido a que Sharkly no puede constatar de forma infalible qué modelo utiliza un Runtime, conviene reflejar el nivel en el nombre del Agent y actualizar simultáneamente la denominación y la configuración técnica. La guía de configuración de Sonnet 5.5 detalla los pasos correspondientes.
Cuando una Task requiera la intervención combinada de ambos niveles, recurre a una Crew. Una Crew es una estructura reutilizable integrada por personas y Agents, coordinada por un Agent principal. Situando a opus-lead como coordinador y a los workers con Sonnet como miembros, el coordinador interpreta la Task, resuelve partes de forma autónoma o delega subtareas mencionando a un integrante, de modo que todos consoliden sus entregas sobre la misma Task. Este esquema materializa el modelo de orquestación con Opus sugerido en los debates de Hacker News, manteniendo los relevos a la vista del supervisor humano. En tareas breves y bien acotadas, prescinde de la Crew y asigna la ejecución directamente a sonnet-worker.
El alias opusplan de Claude Code implementa una variante de este flujo en una sola sesión: Opus asume la planificación y Sonnet se encarga de la ejecución. Su componente Sonnet corresponde a Sonnet 5.5 únicamente en la API directa de Anthropic; en plataformas como Bedrock, Google Cloud o Foundry resuelve hacia versiones previas de Sonnet. Resulta idóneo cuando una misma persona supervisa y ejecuta toda la sesión; por el contrario, conviene emplear dos Agents independientes cuando se requiera auditar con precisión qué entidad planificó y cuál llevó a cabo la implementación.
Hay un elemento que jamás se transmite entre niveles: el proceso de razonamiento. Los bloques de pensamiento («thinking blocks») de Sonnet 5.5 quedan circunscritos en exclusiva al modelo y a su conversación concreta. Ningún modelo ajeno puede interpretarlos, y Sonnet 5.5 tampoco tiene acceso a los de Opus 5.5. La reutilización de carpetas de trabajo dentro de una Crew comparte archivos del sistema, pero no la sesión del Agent previo. Las decisiones adoptadas por el coordinador solo llegarán al worker si quedan expresamente recogidas en la Task, materia que analizamos en un artículo monográfico dedicado a ello.
Nada de esto altera la responsabilidad última sobre la aceptación del trabajo. Los Agents se ocupan de investigar, programar, ejecutar comprobaciones y documentar los resultados. Las personas establecen las directrices, conceden autorizaciones y validan las entregas. Los importes analizados se cargarán de forma habitual en la factura de tu proveedor de IA, pues el consumo de los modelos se liquida a través de las suscripciones o claves de API configuradas en cada entorno. La asignación, las trazas de ejecución, las aclaraciones, el código generado y la revisión humana quedan centralizados en la Task con independencia del modelo que lidere las tablas el próximo trimestre. Este principio se mantiene inalterado entre distintos proveedores, tal como evidencia la comparativa entre Sonnet 5.5 y GPT-6 Sol. Si tu estrategia pasa por orquestar múltiples agentes de desarrollo sin quedar atado a un ecosistema cautivo, ese es con exactitud el problema para el que se ha diseñado Sharkly.
