ComunidadBóvedaOpus 5.5 vs. Sonnet 5.5
Los dos planean · los dos construyen · la diferencia es otra

Opus 5.5 vs. Sonnet 5.5: cuándo usar cada modelo

No es «Opus planea y Sonnet construye». Es: ¿ya sabes qué hay que entregar… o todavía no? Con esa pregunta eliges bien casi siempre. Aquí va la regla, las señales de cada lado, los números sin inflar y el combo que sí funciona.

De qué va

En corto: si el trabajo está acotado y lo puedes checar, Sonnet 5.5. Si está abierto, pide juicio y equivocarte sale caro, Opus 5.5. Y si para que Sonnet empate tuviste que subirlo a máximo, ya no es el barato: usa Opus.

Los dos modelos salieron con seis días de diferencia y mucha gente se quedó con una frase: Opus piensa, Sonnet pica código. Suena bien y te hace elegir mal, porque los dos codean, los dos planean y los dos arman documentos. Lo que los separa es otra cosa: Sonnet rinde cuando el trabajo ya tiene forma, y Opus cuando hay que decidir cuál es esa forma. Esta página te da la pregunta para distinguirlos, lo que dicen las pruebas (con el nivel de esfuerzo en que se midió cada una) y cómo moverte entre los dos en Claude Code.

Diez secciones y ocho prompts para copiar. Si quieres todo lo de Sonnet 5.5 por su lado, está en su guía.

guía comunidad · septiembre 2026opus 5.5sonnet 5.5acotado vs. abiertolos dos arrancan en mediosin código

Ficha

Antes de empezar

Nivel
Principiante. No se escribe código: se copian prompts y, si usas Claude Code, un par de comandos de una línea.
Qué necesitas
Una cuenta de Claude. Para cambiar a Sonnet 5.5 dentro de Claude Code, la versión 2.1.284 o posterior.
Qué NO necesitas
Programar ni una llave de API. Todo pasa en claude.ai, las apps, Claude Code o Cowork.
Cuánto toma
Diez minutos de lectura. La regla de la §01 se aprende en cinco segundos; lo demás es para que la uses con criterio.
Qué te llevas
Una pregunta para elegir modelo, las señales para cambiarte a mitad de camino y un combo de tres pasos para lo grande.
Verificado
29 de septiembre de 2026, contra los anuncios de Sonnet 5.5 y Opus 5.5, el system card de Sonnet 5.5, el blog de Anthropic para desarrolladores, la documentación de Claude Code, Artificial Analysis y la prueba publicada de CodeRabbit.

01 · La regla

La pregunta que decide: ¿ya sabes qué hay que entregar?

Olvida por un momento cuál es «el bueno». Los dos son buenos. La pregunta útil es qué tan definido está el trabajo antes de que se lo des a Claude.

Acotado y se puede checar

→ Sonnet 5.5

Hay un spec, un test, una plantilla o un «terminado cuando» claro. Sabes cómo se ve el resultado bueno y puedes comprobarlo en un minuto.

Abierto, con juicio y caro de equivocarse

→ Opus 5.5

Parte del trabajo es decidir qué hay que hacer. Hay que elegir entre opciones que no son obvias, y si se equivoca, el error se paga después.

Tres preguntas antes de elegir

Pregunta 1

¿Hay spec, test, plantilla o «terminado cuando»?

Si puedes escribir en dos líneas qué quieres y cómo se ve terminado, ya tienes la mitad del camino hacia Sonnet. Si no puedes, eso que falta es justo el trabajo de Opus.

Pregunta 2

¿Puedes checar el resultado tú?

Un test que pasa, un deck que sigue la plantilla, un bug que ya no aparece. Si tú puedes revisar rápido, un error de Sonnet te cuesta una vuelta más. Si no puedes, necesitas más criterio del lado del modelo.

Pregunta 3

¿Cuánto cuesta equivocarse?

Cambiar el texto de un botón no duele. Tocar pagos, cuentas de usuarios, datos o una decisión de arquitectura que vas a cargar meses, sí. Mientras más caro el error, más se justifica Opus.

Tres «sí, sí, barato» → Sonnet 5.5. Un solo «no sé» en la primera, o un «carísimo» en la tercera → Opus 5.5. Si para que Sonnet empate a Opus tienes que subirlo a extra-alto o máximo, ya perdiste la ventaja. Eso tiene su propia sección, la 05.

02 · El mito

«Opus planea, Sonnet construye» es una receta, no la regla

La frase no salió de la nada. En el anuncio de Sonnet 5.5 hay un testimonio de Kevin Ngo, desarrollador creativo, que dice esto:

«Cuando Claude Opus 5.5 pone la arquitectura y el marco general de un juego, me sentiría seguro dejando que Sonnet 5.5 lo implemente.»

Es un buen flujo de trabajo, y Claude Code hasta tiene un modo que lo hace solo (lo ves en la §08). Pero es cómo trabaja una persona, no cómo están hechos los modelos. Si lo tomas como regla, vas a mandar a Opus a picar lo que Sonnet ya resolvía y a Sonnet a decidir cosas que le quedan grandes.

Lo que dice Anthropic, sin poesía

  • Sonnet 5.5 es más fuerte en «tareas del día a día bien acotadas, arreglar bugs y crear documentos, presentaciones y hojas de cálculo pulidos», con buen ojo para el diseño.
  • Opus 5.5 «sigue siendo claramente más fuerte en trabajo complejo y abierto que pide criterio sostenido».
  • Y en su blog para desarrolladores, Anthropic dice que Sonnet 5.5 funciona mejor «cuando la tarea tiene un spec claro y una forma de checar el resultado». Es la regla de la §01, dicha por ellos.

Fíjate en lo que no dice: no dice que Sonnet no planee ni que Opus no programe. Habla de qué tan abierto está el trabajo, no de qué parte del trabajo es.

Por qué la receta sí funciona

«Opus planea, Sonnet construye» funciona porque el plan convierte un problema abierto en uno acotado. El plan es el puente. Sonnet sabe planear; lo que pasa es que cuando el plan ES el entregable, Opus se equivoca menos. Y cuando el trabajo ya llega acotado, no hace falta el puente.

Lo que sí es verdad

Los dos codean

Sonnet también sostiene tareas largas

Epic Games lo tuvo en tareas de varias horas sobre decenas de miles de líneas. Si el plan ya existe, Sonnet puede con la obra completa.

Los dos planean

Un plan chico no necesita a Opus

Planear un cambio de tres archivos con un objetivo claro es trabajo acotado. Sonnet lo planea y lo ejecuta en el mismo tirón.

Los dos hacen docs

Y Sonnet está especialmente fino ahí

Documentos, decks con plantilla y hojas de cálculo son de lo primero que Anthropic le atribuye a Sonnet 5.5, no a Opus.

La diferencia real

Juicio sostenido vs. trabajo con spec

Opus gana cuando hay que decidir muchas veces seguidas sin que nadie le diga qué es lo correcto. Ahí es donde un error se compone.

03 · Sonnet 5.5

Cuándo Sonnet 5.5: ya sabes qué entregar

Úsalo primero cuando aparezca cualquiera de estas señales. Es más rápido, se come tu plan más lento y en el trabajo del día a día queda pegado a Opus.

Señal 1

Hay spec, test, plantilla o «terminado cuando»

El resultado bueno ya está descrito. Claude solo tiene que llegar ahí.

Señal 2

Es el trabajo de todos los días

Un bug, una feature chica, la revisión de cada PR, tickets, documentos, presentaciones, hojas de cálculo.

Señal 3

Quieres iterar rápido

Muchas vueltas cortas: pruebas, ves, corriges. Aquí la velocidad pesa más que un poco de criterio extra.

Señal 4

Vas a pedir mucho de lo mismo

Revisar cada commit, procesar una pila de documentos, agentes que corren muchas veces. El ahorro de plan se multiplica.

Señal 5

Importa cómo se ve

Interfaces, pantallas y decks. Anthropic le reconoce buen ojo para el diseño, y los probadores dicen que sigue plantillas con muy poca edición.

Frases que suenan a Sonnet

  • «Arréglame este test.»
  • «Haz la feature que ya te describí.»
  • «Pásame esto a 10 diapositivas con esta plantilla.»
  • «Revisa este PR.»

Esfuerzo: medio, y ahí déjalo

Sonnet 5.5 arranca en esfuerzo medio en Claude Code y en las apps. No lo subas a máximo «por si acaso»: en la §05 ves por qué eso sale caro. Si una tarea acotada no sale en medio, prueba alto; si tampoco, cámbiate a Opus antes de seguir subiendo.

Tres prompts para copiar

Arregla un test que falla

Acotado y checable: el test pasa o no pasa.

El test [NOMBRE DEL TEST O ARCHIVO] está fallando.

1. Córrelo y dime en dos líneas por qué falla.
2. Arregla el código, no el test, salvo que el test esté mal. Si crees que el test está mal, dímelo antes de cambiarlo.
3. No toques nada que no tenga que ver con esta falla.

Terminado cuando: ese test pasa y los demás tests siguen pasando.

La feature que ya describiste

El qué ya está decidido. Sonnet solo tiene que construirlo.

Quiero agregar esto: [DESCRIBE LA FEATURE EN DOS O TRES LÍNEAS].

Cómo debe funcionar:
- [COMPORTAMIENTO 1]
- [COMPORTAMIENTO 2]
- [QUÉ PASA SI ALGO SALE MAL]

Sigue el estilo del código que ya existe. Si algo de lo que pido choca con cómo está hecho el proyecto, pregúntame antes de decidir tú.

Terminado cuando: puedo [LA ACCIÓN QUE LO PRUEBA, por ejemplo: guardar un contacto y verlo en la lista] y no se rompió nada de lo que ya funcionaba.

Un deck con tu plantilla

Hay plantilla y hay material. El resultado se revisa de un vistazo.

Te adjunto mi plantilla y [EL MATERIAL: un reporte, notas, cifras].
Arma [NÚMERO] diapositivas para [QUIÉN LAS VA A VER].

- Respeta la plantilla: colores, tipografías y acomodos.
- Una idea por diapositiva, con un título que diga la conclusión.
- Cada cifra sale del material. Si falta una, déjala marcada como pendiente.

Terminado cuando: son exactamente [NÚMERO] diapositivas, todas con la plantilla, y ninguna cifra es inventada.

04 · Opus 5.5

Cuándo Opus 5.5: hay que decidir qué entregar

Arranca aquí, o escala aquí, cuando la tarea todavía no tiene forma o cuando un error se paga caro. Se come tu plan más rápido, y en estos casos vale la pena.

Señal 1

El pedido es «resuélvelo» y no hay arquitectura

Nadie ha decidido todavía cómo se hace. Decidirlo es la tarea.

Señal 2

Hay decisiones de producto, no solo de código

Qué sacrificar, qué priorizar, qué va a necesitar el usuario en seis meses. Eso es juicio, no ejecución.

Señal 3

El agente se va a quedar solo mucho rato

En una tarea larga sin que estés encima, cada decisión chueca se apila sobre la anterior. Ahí el criterio sostenido paga.

Señal 4

Una revisión donde un bug colado duele

Autenticación, pagos, datos de usuarios. Para el PR de todos los días, Sonnet; para el que no puede fallar, Opus.

Señal 5

Preguntas de «¿qué deberíamos hacer?»

Investigar, comparar opciones, recomendar. Cuando la respuesta no se puede checar con un test, necesitas el modelo con más juicio.

El dato de las revisiones difíciles

CodeRabbit, que hace revisión de código automática, probó los dos modelos con 13 casos difíciles: bugs que se esconden bien. Sonnet 5.5 con pensamiento cazó 6. Opus 5.5 en su modo normal cazó 8, y en máximo, 10.

Cuatro de esos 13 casos no los cazó ninguna configuración de Sonnet que probaron. Su conclusión: Sonnet 5.5 es el Sonnet más convincente que han probado para la revisión que corre en cada PR, y Opus sigue siendo la opción para los cambios de alto riesgo.

Frases que suenan a Opus

  • «¿Cómo partimos este sistema?»
  • «Este diseño está mal, rediséñalo.»
  • «Déjalo corriendo estas horas y avísame cuando termine.»
  • «¿Qué deberíamos hacer con esto?»

Esfuerzo: medio también

Opus 5.5 piensa siempre y arranca en esfuerzo medio en Claude Code. Ese medio ya rinde fuerte: no empieces en máximo. Súbelo solo cuando veas que se salta pasos en algo que de verdad es difícil.

Dos prompts para copiar

Cómo partimos este sistema

No hay respuesta correcta todavía. Hay que decidirla.

Quiero reorganizar [EL SISTEMA O LA PARTE DEL PROYECTO] porque [EL PROBLEMA QUE TIENES HOY].

Antes de tocar nada:
1. Explora cómo está hecho hoy y dime qué es lo que de verdad lo complica.
2. Dame dos o tres formas de partirlo, con lo que gano y lo que pierdo en cada una.
3. Recomienda una y dime qué tendría que ser cierto para que fuera la equivocada.
4. Dime qué NO conviene tocar, y por qué.

No escribas código todavía. Quiero decidir primero.

Revisión de un cambio que no puede fallar

Pagos, cuentas, datos. Aquí un bug colado duele.

Revisa este cambio: [EL PR, LA RAMA O LOS ARCHIVOS].
Toca [QUÉ: cobros / inicio de sesión / datos de usuarios], así que un error aquí sale caro.

Busca en especial:
- Casos que el código no contempla (valores vacíos, dobles clics, pagos repetidos, usuarios sin permiso).
- Cosas que funcionan en la prueba pero pueden fallar con datos reales.
- Cualquier cambio que afecte algo fuera de lo que el PR dice que hace.

Para cada hallazgo: dónde está, qué pasaría en el peor caso y qué tan seguro estás. Si no encuentras nada grave, dilo; no rellenes.

05 · La trampa

Si Sonnet pidió máximo, usa Opus

Sonnet 5.5 es el que se come tu plan más lento, pero solo mientras lo dejes en esfuerzo bajo o medio. El anuncio lo dice así: en los niveles altos puede rendir parecido a Opus, con un gasto parecido. Y la prueba donde Sonnet «le gana» a Opus enseña por qué.

Terminal-Bench 4.0, nivel por nivel

Bajo

Sonnet 5.5
20.0 %
Opus 5.5
38.5 %
Lo que pasa
Opus casi dobla a Sonnet.

Medio (con el que arrancan los dos)

Sonnet 5.5
28.8 %
Opus 5.5
57.6 %
Lo que pasa
Opus saca el doble. Este es el nivel en el que trabajas si no tocas nada.

Alto

Sonnet 5.5
43.0 %
Opus 5.5
64.2 %
Lo que pasa
Opus sigue claramente arriba.

Extra-alto

Sonnet 5.5
61.5 %
Opus 5.5
66.4 %
Lo que pasa
Casi empatan. Este 66.4 es el mejor resultado de Opus.

Máximo

Sonnet 5.5
70.6 %
Opus 5.5
64.8 %
Lo que pasa
Aquí sí gana Sonnet. Es el 70.6 que se volvió titular.

Datos de la gráfica por nivel que publicó Anthropic en el anuncio de Sonnet 5.5. Terminal-Bench mide tareas completas en una terminal: instalar, configurar, depurar.

Lo que te dice la tabla

  • Sonnet solo alcanza a Opus cuando lo subes al tope. En el nivel en el que trabajas todos los días, Opus saca el doble.
  • Y subir el esfuerzo no es gratis: mientras más alto, más piensa y más se come tu plan.

Barato por token no es barato por resultado

Artificial Analysis, que mide modelos por su cuenta, corrió su índice con los dos en máximo. Sonnet 5.5 gastó cerca de 60 % más tokens por tarea que Opus 5.5. Es el gasto más alto que han medido en cualquier modelo.

O sea: cada tarea de Sonnet en máximo es más larga. Lo que ahorras porque cada token de Sonnet pesa menos, lo pierdes porque usa muchos más.

Y en máximo, a veces rinde menos

En FrontierCode, una prueba de código difícil, Sonnet 5.5 sacó 52.1 % en extra-alto y 46.2 % en máximo. Anthropic lo explica en una nota: en máximo se pasaba de tiempo y hacía cambios fuera de lo que se le pidió.

Dos cosas que no funcionan

  • Un prompt enorme en Sonnet con esfuerzo máximo «para que piense como Opus». Es justo el caso en el que el barato sale caro: más tokens, más tiempo y el mismo techo de criterio.
  • Pedirle en el prompt que piense menos para que gaste menos. Anthropic lo dice directo: pedírselo no baja el razonamiento de forma confiable. Lo que lo baja es el nivel de esfuerzo.

La regla: si para que Sonnet te dé lo que quieres tienes que subirlo a extra-alto o máximo, deja de subir. Corre la misma tarea con Opus 5.5 en medio.

06 · Los números

Siete pruebas, sin inflar

Estas son las siete pruebas que más sirven para comparar a los dos. Cada una dice algo cierto y cada una se puede usar para vender una mentira. Por eso la tabla trae las dos columnas.

GDPval-AA v2.1 · trabajo de oficina real

Sonnet 5.5
1844
Opus 5.5
1846
Qué dice
Empate técnico en tareas de trabajo del conocimiento: documentos, análisis, presentaciones.
Qué NO dice
Que dé igual cuál uses en todo: es un promedio de muchas tareas, no tu tarea. Además se corrió sobre una versión previa con un error menor.

CursorBench 4.0 · programar dentro de un editor

Sonnet 5.5
55.5 %
Opus 5.5
57.8 %
Qué dice
Opus arriba, por poco. En código del día a día, Sonnet queda muy cerca.
Qué NO dice
Que Sonnet «casi empate» en medio: los dos se midieron en máximo.

Terminal-Bench 4.0 · tareas completas en terminal

Sonnet 5.5
70.6 % (máximo)
Opus 5.5
66.4 % (extra-alto)
Qué dice
Una de las dos donde Sonnet queda arriba, y aquí solo en su nivel más alto.
Qué NO dice
Que Sonnet programe mejor siempre. En medio, Opus saca el doble (§05).

SWE-Bench Pro · cambios grandes en repos reales

Sonnet 5.5
81.3 %
Opus 5.5
89.9 %
Qué dice
El hueco más grande de la tabla: en cambios que tocan muchos archivos de proyectos vivos, Opus se despega.
Qué NO dice
Que Sonnet no pueda con un repo grande: 81.3 es muy alto. Dice quién se equivoca menos en lo difícil.

AutomationBench · flujos de negocio (de Zapier)

Sonnet 5.5
44.7 %
Opus 5.5
42.5 %
Qué dice
Sonnet queda arriba en automatizaciones con reglas claras. Encaja con la regla: trabajo acotado.
Qué NO dice
Que Sonnet sea mejor agente en todo. Y Opus sacó 42.5 al volver a correr las tareas que había rechazado; sin eso, 40.0.

FrontierCode 1.1 · código difícil

Sonnet 5.5
46.2 % (máximo) · 52.1 % (extra-alto)
Opus 5.5
54.4 %
Qué dice
En lo difícil, Opus pica adelante.
Qué NO dice
Que 52.1 sea el titular de Sonnet: es su resultado en extra-alto. En máximo bajó.

Artificial Analysis · índice independiente

Sonnet 5.5
56 (#2)
Opus 5.5
58 (#1)
Qué dice
Los dos arriba de todo lo que han medido, Opus primero.
Qué NO dice
Cuánto cuesta llegar ahí: Sonnet gastó ~60 % más tokens por tarea.

GDPval, CursorBench, Terminal-Bench y FrontierCode vienen del anuncio de Sonnet 5.5; SWE-Bench Pro y AutomationBench, de su system card; el índice, de Artificial Analysis. Salvo que la tabla diga otro nivel, todo se midió en esfuerzo máximo.

Leídas juntas: en trabajo del día a día casi empatan; en lo difícil y abierto, Opus abre hueco. Justo lo que dice la regla de la §01.

Las ocho pruebas del anuncio, con su letra chica completa, están en la guía de Sonnet 5.5.

07 · Para arrancar

¿Con cuál empiezo?

Lo oficial

  • En Claude Code, el modelo por defecto es Opus 5.5 en Pro, Max, Team y Enterprise. Si nunca tocas nada, trabajas con Opus.
  • La documentación de Anthropic dice que la mayoría del trabajo arranca en Opus 5.5. Es el lado seguro: no se queda corto de juicio.

La regla de la casa

Si ya sabes qué quieres y cómo se ve terminado, cámbiate a Sonnet 5.5. Vas más rápido y cuidas tu plan. Si no sabes ni qué estás pidiendo, quédate en Opus, y bájate a Sonnet cuando ya exista el plan.

Anthropic no lo dice con estas palabras: su default sigue siendo Opus. Lo que sí dice es que Sonnet 5.5 funciona mejor cuando hay un spec claro y una forma de checar el resultado. De ahí sale esta regla.

Con cuál arrancar, por situación

Hay spec clara y una forma de checar

Primero
Sonnet 5.5, en medio
Después
Opus solo si falla una o dos veces por juicio

Todavía no sabes bien qué pedir

Primero
Opus 5.5, en medio
Después
Sonnet construye cuando ya existe el plan

El ir y venir de todos los días

Primero
Sonnet 5.5
Después
Opus para la parte difícil

La revisión de cada PR

Primero
Sonnet 5.5
Después
Opus para los cambios delicados

Un agente que va a correr horas

Primero
Opus 5.5
Después
Sonnet para subtareas acotadas que el agente delegue

Pulir un deck, una hoja o una interfaz

Primero
Sonnet 5.5
Después
Casi nunca hace falta Opus

No quieres pensar en esto

Primero
Opus 5.5 (el default)
Después
Pruebas Sonnet cuando una tarea se repita

Tres señales para subir a Opus a media tarea

Señal 1

Se inventa alcance

Hace cosas que no le pediste o toca archivos que no tenían que ver. Le falta criterio para saber dónde parar.

Señal 2

Se queda corto de juicio

A la primera o segunda vuelta, la solución funciona pero es la equivocada. Resuelve lo que dijiste, no lo que necesitabas.

Señal 3

El fallo resultó caro

Te das cuenta de que la tarea tocaba algo delicado. No sigas con Sonnet solo porque ya empezaste.

Antes de subir, una pregunta: ¿le faltaba algo o decidió mal? Si le faltaba un archivo, un dato o un ejemplo, dáselo y repite con Sonnet: cambiar de modelo no arregla contexto que no tiene. Si tenía todo y aun así eligió mal, eso es juicio, y el juicio es de Opus.

Los comandos, dentro de Claude Code

Cambiar a Sonnet 5.5 (versión 2.1.284 o posterior)

/model sonnet

Regresar a Opus 5.5

/model opus

Opus en modo plan, Sonnet al ejecutar

/model opusplan

Volver al esfuerzo medio si lo subiste

/effort medium

Si aún no ves Sonnet 5.5, actualiza con claude update. /model deja el modelo elegido como tu default para las sesiones nuevas. En claude.ai y en las apps, el modelo se cambia en el selector de modelo del chat.

08 · El combo

El combo que sí funciona, sin volverlo religión

Para algo grande que todavía no tiene forma, la receta de «Opus planea, Sonnet construye» sí sirve. Solo le falta un paso: Opus revisa al final, cuando el cambio es de alto riesgo. Así queda:

Paso 1 · Opus

Plan, restricciones y qué no tocar

Opus decide cómo se hace y lo deja por escrito. Ese documento convierte el trabajo abierto en trabajo acotado.

Paso 2 · Sonnet

Implementa, itera, pule

Con el plan como spec, Sonnet construye rápido y sin comerse tu plan. Es la parte más larga del trabajo.

Paso 3 · Opus, a veces

Revisa solo si es de alto riesgo

Si el cambio toca pagos, cuentas o datos, Opus revisa. Si es un cambio tranquilo, sáltate este paso.

Los tres prompts

Paso 1 · Opus: el plan y lo que no se toca

Con /model opus. El resultado es un documento, no código.

Vamos a construir [LO QUE QUIERES CONSTRUIR]. Todavía no escribas código.

Escribe un plan en un archivo PLAN.md con:
1. Qué vamos a construir y qué queda fuera.
2. Las decisiones importantes y por qué las tomaste.
3. Los pasos, en orden, cada uno con su «terminado cuando».
4. Qué NO hay que tocar y por qué.
5. Lo que te dé duda y yo tenga que decidir.

Escríbelo para que otro modelo lo pueda seguir sin preguntarte nada.

Paso 2 · Sonnet: construye el plan

Con /model sonnet. Ahora sí hay spec: es trabajo acotado.

Lee PLAN.md y constrúyelo paso por paso.

- Sigue el orden del plan. Al terminar cada paso, comprueba su «terminado cuando» antes de pasar al siguiente.
- No toques nada de la lista de «qué NO hay que tocar».
- Si algo del plan no se puede hacer como está escrito, detente y dímelo en vez de improvisar otra solución.

Al final: qué pasos quedaron, cómo comprobaste cada uno y qué quedó pendiente.

Paso 3 · Opus otra vez, solo si es de alto riesgo

Con /model opus. Sáltate este paso si el cambio no toca nada delicado.

Compara lo que se construyó contra PLAN.md.

1. ¿Se respetó lo que no había que tocar?
2. ¿Hay alguna decisión del plan que se implementó distinto, y eso importa?
3. ¿Qué casos pueden fallar con datos o usuarios reales?

Ordena los hallazgos de más grave a menos grave. Si todo está bien, dilo en una línea.

El atajo: opusplan

Si trabajas en Claude Code, /model opusplan hace los pasos 1 y 2 sin que cambies de modelo a mano: en modo plan piensa Opus 5.5, y cuando apruebas el plan construye Sonnet 5.5. El paso 3 lo pides tú, con /model opus.

  • No todo necesita el combo. Si el pedido ya es claro, todo el ciclo puede ir en Sonnet.
  • Y si un error te revienta el proyecto, todo el ciclo puede ir en Opus. Ahí gastar más plan sale barato al lado del error que te ahorras.

09 · Lado a lado

Ventajas y desventajas

Sonnet 5.5

Gana

  • Se come tu plan más lento y es más rápido.
  • Casi empata a Opus en trabajo del día a día.
  • El mejor default cuando hay spec o mucho volumen.
  • Fino en documentos, decks, hojas e interfaces.

Pierde

  • Se queda corto cuando el problema no cabe en un «terminado cuando».
  • En máximo gasta tanto que deja de ser el barato.
  • En revisiones difíciles caza menos que Opus.
  • En cambios grandes de repos reales, Opus se le despega (SWE-Bench Pro: 81.3 contra 89.9).
  • Más esfuerzo a veces lo empeora: en FrontierCode rindió menos en máximo que en extra-alto.

Opus 5.5

Gana

  • Mejor en lo abierto, lo de muchos pasos y lo que no puede fallar.
  • El techo más alto en código difícil.
  • Su esfuerzo medio ya rinde fuerte, y siempre piensa.
  • Tiene fast mode si necesitas velocidad sin cambiar de modelo (va con créditos de uso, fuera de tu plan).

Pierde

  • Se come tu plan más rápido.
  • Más lento en el ir y venir de todos los días.
  • Un desperdicio para «cambia el texto de este botón».

10 · Lo honesto

Las dos mentiras, y lo que más se pregunta

Mentira 1

«Siempre Opus, porque es el bueno»

Te comes tu plan más rápido en trabajo que Sonnet ya cerraba igual de bien. En GDPval, que mide trabajo de oficina real, quedaron a dos puntos.

Mentira 2

«Siempre Sonnet, porque ganó Terminal-Bench»

Ese 70.6 es en esfuerzo máximo, su techo. En medio, que es donde trabajas, Opus sacó el doble. En el trabajo sucio y abierto, Opus sigue siendo el de juicio.

Preguntas frecuentes

›Entonces, ¿para qué pago Opus?

Para las tareas donde equivocarse sale caro o donde nadie sabe todavía qué hay que hacer. Son menos que las del día a día, pero son las que más duelen. Si tu plan incluye Opus, úsalo ahí y deja lo demás a Sonnet: te rinde más el plan y no pierdes calidad donde importa.

›Sonnet no me está sirviendo. ¿Me paso a Opus?

Primero revisa el pedido. Si tu prompt es «mejora esto», no tienes un problema de modelo: tienes un problema de spec. Escribe qué quieres y cómo se ve terminado, y repite con Sonnet. Si con eso tampoco sale, o si la tarea resultó ser decidir qué hacer, entonces sí: Opus.

›¿Y si no tengo tiempo de pensar cuál usar?

Deja Claude Code como viene, en Opus 5.5. Es el lado seguro. La regla de esta guía sirve para ahorrar plan y ganar velocidad, no para evitar un desastre.

›¿Subir el esfuerzo de Sonnet no es lo mismo que usar Opus?

No. Sube lo que piensa, pero no le da el mismo criterio, y en máximo gasta tanto que pierde la ventaja (§05). Si medio no alcanza, prueba alto; si alto tampoco, cámbiate a Opus.

›¿Sonnet 5.5 tiene fast mode?

No. Fast mode es de Opus: lo hace hasta 2.5 veces más rápido, pero en suscripción se cobra con créditos de uso, fuera de tu plan, aunque todavía te quede plan. Si lo que quieres es velocidad sin pagar aparte, eso es Sonnet.

›¿Esto aplica en claude.ai y en Cowork?

La regla sí: acotado contra abierto no depende de dónde trabajes. Lo que no se ha dicho es cuál viene por defecto en claude.ai o en Cowork. Revisa el selector de modelo de tu cuenta; en las apps, los dos arrancan en esfuerzo medio.

›¿Y Fable 5.1 o Haiku?

Quedan fuera de esta comparación. Fable es el de arriba de la familia y en Pro se cobra aparte; Haiku es el más ligero. Los cuatro, con cuándo usar cada uno, están en la guía de qué modelo usar.

Guía de la bóveda

Esta guía es una de las gratuitas de la bóveda.

Si te llevas una sola cosa

No preguntes cuál es el bueno: pregunta si ya sabes qué hay que entregar. Si hay spec y lo puedes checar, Sonnet 5.5 en medio. Si hay que decidir y equivocarse sale caro, Opus 5.5. Empieza en Sonnet cuando ya sabes qué quieres, escala a Opus cuando la tarea te lo pida, y no al revés por ego.

Dónde sigue cada tema

Lo nuevo sale primero en Instagram

Ahí aviso cuando entra una guía nueva a la bóveda y cuando algo de esto cambia.

@soyenriquerocha

Cuándo se verificó esto

Cada dato de esta página se contrastó el 29 de septiembre de 2026 contra los anuncios oficiales de Sonnet 5.5 y Opus 5.5, el system card de Sonnet 5.5, el blog de Anthropic para desarrolladores, la documentación de modelos de Claude Code, los análisis de Artificial Analysis y la prueba publicada de CodeRabbit. Los modelos recién salidos cambian rápido: defaults, versiones y disponibilidad se mueven. Si algo no cuadra con lo que ves en tu cuenta, lo que manda es tu cuenta.