Claude Opus 5.5 vs Sonnet 5.5: cuál usar para programar

Claude Opus 5.5 y Claude Sonnet 5.5 son los modelos de Anthropic para programar con más capacidad y con más velocidad, respectivamente, en el momento de crear esta entrada. Y la duda es la de siempre: ¿necesitas Opus o te basta con Sonnet? Para responderla hemos lanzado las mismas 4 tareas de un proyecto Laravel con Claude Code, 3 veces con cada modelo, y hemos validado cada resultado con tests que el modelo no veía.

Los 2 modelos resolvieron todas las tareas sin un solo test en rojo. Sonnet 5.5 tardó la mitad y generó un 40 % menos de tokens, que son las unidades en las que el modelo cuenta el texto: más o menos, una palabra corta o un trozo de una larga. Opus 5.5 escribió más tests y se adelantó más veces a casos que el enunciado no pedía. En esta entrada tienes qué los diferencia, los resultados de cada tarea con lo que cambia en el código y cuándo compensa cada modelo.

Qué diferencia a Opus 5.5 de Sonnet 5.5

Opus 5.5 salió el 22 de septiembre de 2026 y Sonnet 5.5, el 28 de septiembre de 2026. Haiku 5.5 llegó el 7 de octubre de 2026, pero se queda fuera de esta comparativa. En su anuncio, Anthropic presenta Opus 5.5 para las tareas largas en las que trabaja por su cuenta, como agente, y Sonnet 5.5 como el complemento más rápido para el día a día: crear funciones, corregir bugs y revisar código.

Esto es lo que te afecta al programar, según la tabla de modelos de Anthropic y la documentación de Claude Code:

• Los 2 tienen una ventana de contexto de 1 millón de tokens y hasta 128.000 tokens de salida.
• Los 2 razonan antes de responder y deciden cuánto según el effort, el nivel de razonamiento que les pides. En Opus 5.5 ese razonamiento no se puede desactivar.
• En Claude Code, los 2 arrancan con effort medium. En la API, Opus 5.5 también, pero Sonnet 5.5 arranca en high.
• Opus 5.5 es el modelo con el que arranca Claude Code si no eliges otro, en todos los planes, y Sonnet 5.5 es el Sonnet por defecto con la API de Anthropic, como recoge el changelog de Claude Code.
• En la API se piden como claude-opus-5-5 y claude-sonnet-5-5, y en Claude Code los alias opus y sonnet ya apuntan a ellos.

Si vienes de la generación anterior, las comparativas Claude Sonnet 5 vs Claude Opus 4.8 y Claude Opus 5 vs Fable 5 te sirven para ver cuánto ha cambiado.

Cómo lo hemos probado

Partimos de una API de reservas de salas de reuniones con Laravel 13.35, PHP 8.5, Pest y Larastan en el nivel 6. Larastan es el análisis estático de PHPStan con las reglas de Laravel. El proyecto lleva un CLAUDE.md, el archivo de instrucciones que Claude Code lee al empezar cada sesión, con 3 reglas: cada cambio lleva su test, los tests que ya existen no se modifican y al terminar tienen que pasar los tests y el análisis estático. Sobre él lanzamos 4 tareas con Claude Code 2.1.296, 3 veces con cada modelo. Todas las ejecuciones arrancan desde el mismo commit, sin memoria ni ajustes de sesiones anteriores y con el effort por defecto, medium.

Cada ejecución se valida con tests que el modelo no ve, 41 entre las 4 tareas, que se añaden al proyecto cuando ha terminado. Solo cuenta como buena si pasan esos tests y la suite entera, con los que haya escrito el modelo, si Larastan no da ningún error y si los tests que ya había siguen intactos. Las cifras de cada tarea son la mediana de sus 3 ejecuciones, es decir, el valor del medio.

Resultados

Los 2 modelos resolvieron las 4 tareas en las 3 repeticiones: 12 de 12 cada uno, con todos los tests en verde y Larastan sin errores. Con el mismo resultado en los tests, la diferencia está en el tiempo, en los tokens y en lo que cada modelo hace sin que se lo pidas.

Sumando las 12 ejecuciones de cada modelo, Opus 5.5 necesitó 609 segundos y 58.987 tokens de salida, y Sonnet 5.5, 319 segundos y 35.704 tokens. Sonnet tarda la mitad y genera un 40 % menos de tokens de salida. En tokens de entrada, que son el contexto que lee el modelo en cada petición, Opus llegó a 1,6 millones y Sonnet se quedó en 1,06 millones, un tercio menos. En esa cuenta entra también lo que la API reutiliza de su caché de una petición a la siguiente.

Además, Opus escribió más tests que Sonnet en todas las ejecuciones de las 4 tareas. Vamos a ver cada tarea, con sus medianas y lo que cambia en el código. En las cifras, cada turno es una vuelta del modelo: lee lo que tiene, decide y pide ejecutar algo.

Crear reservas

La primera tarea es una función nueva a partir de una especificación: un endpoint para crear reservas, con las horas en bloques de 15 minutos y sin solaparse con otra reserva activa de la misma sala.

• Opus 5.5: 56 segundos, 6 turnos y 6.095 tokens de salida.
• Sonnet 5.5: 29 segundos, 4 turnos y 3.965 tokens de salida.

Esta tarea tiene un problema que el enunciado no menciona: 2 peticiones que llegan a la vez para la misma franja pueden pasar las 2 la comprobación de solapes y crear 2 reservas que se pisan. Opus lo resolvió en las 3 ejecuciones, con la comprobación y la creación en una transacción que bloquea la fila de la sala con lockForUpdate(). Sonnet lo hizo en 1 de las 3. Ningún test lo comprueba, así que esa diferencia no aparece en los resultados de la validación.

En tests, Opus escribió entre 20 y 24 y Sonnet, 18 o 19, contando como un test cada caso de los datasets de Pest, que repiten el mismo test con una lista de valores.

El bug de la medianoche

La segunda es un bug: el informe de ocupación de una sala suma al primer día todos los minutos de una reserva que cruza la medianoche, en lugar de repartirlos entre los 2 días. Hay que corregirlo y añadir un test de regresión.

• Opus 5.5: 32 segundos, 6 turnos y 2.424 tokens de salida.
• Sonnet 5.5: 18 segundos, 4 turnos y 1.246 tokens de salida.

Los 2 corrigieron el cálculo. La diferencia está en los tests: Sonnet añadió siempre un único test con el ejemplo del enunciado. Opus añadió además, en las 3 ejecuciones, el caso de una reserva que ocupa varios días enteros, y en una de ellas, el de una reserva que acaba justo a las 00:00.

Las consultas del listado

La tercera es de rendimiento. El listado de salas tiene el clásico problema N+1: una consulta para las salas y 2 más por cada sala. La tarea pide que el número de consultas no dependa del número de salas, sin cambiar la respuesta.

• Opus 5.5: 44 segundos, 6 turnos y 3.993 tokens de salida.
• Sonnet 5.5: 27 segundos, 6 turnos y 2.489 tokens de salida.

Los 2 modelos cuentan las reservas próximas con withCount() y cambian la forma de cargar la próxima reserva de cada sala. En 2 de sus 3 ejecuciones, Opus añadió al modelo Room una relación nextReservation() con ofMany(). Con eager loading, la carga anticipada de relaciones de Eloquent, esa relación trae la próxima reserva de todas las salas en una sola consulta. Sonnet usó esa relación en 1 ejecución, en otra, una subconsulta y en la tercera, una consulta con row_number(). Es una función de ventana de SQL, que numera las filas dentro de cada grupo, y necesita MySQL 8 o posterior, como avisa Sonnet en su resumen. Las 6 soluciones hacen el mismo número de consultas con 3 salas que con 30, y 4 como mucho.

Reservas semanales en hora de Madrid

La cuarta es una función con una trampa que el enunciado no menciona: crear una serie de 1 a 12 reservas semanales a la misma hora de Madrid, guardadas en UTC, y no crear ninguna si alguna se solapa.

• Opus 5.5: 65 segundos, 5 turnos y 7.073 tokens de salida.
• Sonnet 5.5: 32 segundos, 4 turnos y 4.173 tokens de salida.

La trampa es el cambio de hora. El 25 de octubre de 2026 España pasa al horario de invierno, así que las 09:00 de Madrid son las 07:00 UTC el 19 de octubre y las 08:00 UTC el 26 de octubre. Si sumas las semanas sobre la hora en UTC, la reserva de después del cambio cae una hora antes. Y si sumas en hora de Madrid pero guardas la fecha sin pasarla a UTC, Eloquent la guarda tal cual, con la hora de Madrid.

Aquí esperábamos ver la diferencia, y no la hubo: las 6 soluciones suman las semanas en hora de Madrid y después pasan cada fecha a UTC, y las 6 lo explican en su resumen final con un ejemplo de antes y después del cambio de octubre. Todas escribieron además un test propio que cruza ese cambio, y 2 de las ejecuciones de Opus, otro con el de marzo, cuando se adelanta la hora.

La diferencia salió en otro sitio. Si cada reserva de la serie dura más de una semana, la segunda se solapa con la primera. Para comprobarlo hemos enviado a cada una de las 6 soluciones la misma petición: una serie de 2 semanas con reservas de 8 días. Las 3 de Opus y 2 de Sonnet responden 422 y no crean nada. La tercera de Sonnet crea las 2 reservas, solapadas, y su resumen final lo reconoce: "si una reserva dura más de 7 días, las reservas de la propia serie se solaparían entre sí. No lo he controlado porque no lo pedías". Opus lo controló y lo cubrió con un test en las 3 ejecuciones.

Es también la tarea en la que más se nota el razonamiento: Opus dedicó a pensar entre 1.520 y 1.750 tokens por ejecución y Sonnet, entre 252 y 372. Y en tests, Opus escribió entre 16 y 21 frente a 12 o 13 de Sonnet.

Cuál usar para programar

Con estos datos, nuestra recomendación es Sonnet 5.5 para el trabajo del día a día: tareas con una especificación clara, bugs acotados y cambios de rendimiento como los de esta prueba. Pasa los mismos tests, en la mitad de tiempo y con bastantes menos tokens, y eso se nota en la espera y en el consumo de tu plan o de tu cuenta de la API.

Opus 5.5 compensa cuando lo que te preocupa es lo que no está en el enunciado. En esta prueba se adelantó a la concurrencia en las 3 ejecuciones de crear reservas, controló siempre el solape dentro de la serie y escribió más tests de los casos límite. Si la tarea toca dinero, permisos, reservas o cualquier sitio donde un caso raro sale caro, merece la pena esperar esos segundos de más.

Ten en cuenta el alcance: son 4 tareas pequeñas y bien definidas, con 3 repeticiones, sobre un proyecto pequeño. Con tareas largas, mal especificadas o que obligan a recorrer un proyecto grande, la diferencia puede ser otra. Si quieres otra mirada a cuándo hace falta Opus en un proyecto Laravel, tienes también ¿Necesitas Opus para programar en Laravel?

Cambiar de modelo en Claude Code

Si Claude Code arranca con Opus, para trabajar con Sonnet tienes que elegirlo. Para una sola sesión, al arrancar:

claude --model sonnet

Dentro de una sesión, /model sonnet lo cambia y además lo guarda como tu modelo por defecto para las siguientes. Y si una tarea concreta necesita más razonamiento, antes de pasarte a Opus puedes probar a subir el effort de Sonnet con /effort high. Los alias, el effort de cada modelo y qué ajustes se guardan lo tienes explicado en la lección Qué modelo usar en Claude Code.

Espero que te sirva. Si quieres aprender a trabajar con Claude Code en tus proyectos de principio a fin, no te pierdas el curso Claude Code.