Claude Opus 5.5 en Claude Code: qué cambia y cómo aprovecharlo

Claude Opus 5.5 llega con una promesa menos vistosa que “hemos vuelto a duplicar la inteligencia”, pero bastante más útil para quienes usamos Claude Code: debería responder más rápido, gastar menos cuota y ser más directo. Después de varias versiones en las que el modelo más capaz también podía ser el más pesado de aguantar, el cambio de carácter importa casi tanto como cualquier benchmark.

Mi interés con Opus 5.5 no está en saber si gana una gráfica preparada por Anthropic. Quiero saber qué cambia al abrir un repositorio, pedirle que investigue un error y dejarlo trabajar durante un rato. Las primeras experiencias no son unánimes, pero sí dibujan un modelo diferente: más rápido y contenido en muchos proyectos, aunque todavía capaz de sobrecomplicar una solución o quedarse atrapado en un bucle cuando el encargo es demasiado abierto.

Qué cambia realmente en Opus 5.5

Claude Opus 5.5 mantiene una ventana de contexto de un millón de tokens y permite hasta 128.000 tokens de salida. Su fecha de conocimiento fiable llega hasta junio de 2026. En Claude Code viene con razonamiento adaptativo: no se desactiva por completo, sino que el nivel de esfuerzo indica al modelo cuánto merece la pena pensar y explorar.

Anthropic asegura que las cargas habituales pueden resultar alrededor de un 40 % más baratas que con Opus 5 y que la generación es más de un 30 % rápida. Son cifras del fabricante, no una ley para todos los repositorios. Un agente que termina antes pero abre veinte archivos innecesarios puede gastar más que otro algo más lento; uno que produce menos texto también puede ahorrar mucha cuota sin haber razonado peor.

	Opus 5.5
Contexto	1.000.000 de tokens
Salida máxima	128.000 tokens
Entrada en API	4 dólares por millón de tokens
Salida en API	20 dólares por millón de tokens
Lectura de caché	0,20 dólares por millón de tokens
Esfuerzo inicial	Medium

También existe un modo rápido en la API, aún en vista previa, que puede aumentar hasta 2,5 veces la velocidad de salida a cambio de duplicar aproximadamente el precio hasta 8 y 40 dólares por millón de tokens de entrada y salida. Para una conversación interactiva puede tener sentido; para dejar un agente trabajando solo durante veinte minutos, yo preferiría medir antes si la espera es de verdad el cuello de botella.

Lo más interesante: parece menos hablador sin quedarse mudo

Una de las quejas con las versiones anteriores de Opus era la cantidad de ceremonia: repetir el encargo, anunciar cada búsqueda, explicar una decisión evidente y cerrar con una lista demasiado larga. Opus 5.5 parece reducir esa capa. En las primeras horas se repite que las respuestas son más cortas, que va antes al archivo relevante y que gasta bastante menos cuota en trabajos comparables.

No tomaría una respuesta corta como prueba de que el modelo ha mejorado. A veces la concisión es simplemente una omisión. La diferencia útil está en otra parte: que pueda resumir el plan en tres líneas, hacer el cambio, ejecutar las pruebas y explicar sólo las decisiones que no eran obvias. Cuando lo consigue, Claude Code se siente más como una herramienta y menos como una reunión.

Dónde se está notando la mejora

Las experiencias iniciales coinciden especialmente en cuatro tipos de trabajo:

• Errores de interfaz: detecta mejor estados visuales incoherentes y pequeños fallos que no aparecen en una prueba unitaria.
• Lectura de repositorios grandes: localiza antes el flujo principal y necesita menos rondas para construir un mapa útil.
• Implementaciones acotadas: modifica menos archivos cuando el contrato y la prueba de aceptación están claros.
• Respuestas para revisar: las explicaciones son más naturales y contienen menos coletillas defensivas.

La parte del consumo es la que más puede cambiar el uso diario. Si un plan permite más sesiones o aguanta mejor una tarea larga, deja de ser necesario reservar Opus para el último intento. Eso vale más que una diferencia pequeña en un benchmark que nunca se parece a nuestro proyecto.

Y dónde sigue fallando

No todo el mundo está viendo un salto. También aparecen sesiones en las que Opus 5.5 empieza con una solución razonable y después la convierte en una abstracción demasiado grande. En otras, repite una herramienta o insiste en un camino que ya ha fallado. La rapidez empeora la sensación cuando el rumbo es incorrecto: llega antes, sí, pero al sitio equivocado.

Otro punto molesto son los bloqueos de seguridad en tareas que, dentro de un repositorio propio, son legítimas. Analizar autenticación, cabeceras, permisos o un script de red puede activar restricciones según cómo esté descrito. Reformular el objetivo y dejar claro el alcance defensivo ayuda, pero no debería hacer falta negociar con el modelo para revisar nuestro propio código.

También hay que dejar pasar el efecto estreno. Los primeros días mezclan un modelo nuevo, límites de uso recién ajustados, usuarios probando prompts distintos y comparaciones hechas con tareas que no son equivalentes. Una impresión de dos horas sirve para descubrir el carácter del modelo; no basta para declarar que una versión ha quedado superada.

Opus 5.5 frente a 4.8: no todo es inteligencia

Opus 4.8 llevaba tiempo dentro de flujos ya afinados. Sabíamos cuánto contexto darle, qué nivel de esfuerzo funcionaba y en qué momento había que interrumpirlo. Por eso es normal que algunas personas aún lo noten más predecible. Un modelo nuevo puede ser mejor y, al mismo tiempo, encajar peor con un archivo CLAUDE.md escrito para los hábitos del anterior.

La diferencia que buscaría no es “5.5 escribe código más bonito”. Miraría estas preguntas:

• ¿Encuentra la causa antes de editar?
• ¿Mantiene el alcance o aprovecha para reorganizar media aplicación?
• ¿Ejecuta las pruebas que de verdad protegen el cambio?
• ¿Cuánta cuota queda después de una sesión equivalente?
• ¿La explicación final permite revisar el trabajo sin leer un ensayo?

Si 5.5 mejora tres de esos puntos, ya compensa aunque una respuesta aislada de 4.8 parezca más brillante. Si sólo es más rápido y necesita una segunda ronda para reparar lo que hizo en la primera, el ahorro desaparece.

Medium para trabajar, High para investigar

Medium es el valor inicial y me parece una decisión acertada. Para un bug con reproducción, una funcionalidad bien descrita o una prueba que ya falla, empezaría ahí. Subiría a High cuando el problema atraviesa varias capas, no está claro qué componente tiene la culpa o hace falta comparar alternativas antes de tocar el código.

Max no debería convertirse en el botón de “hazlo bien”. Cuanto más espacio le damos para pensar, más fácil es que explore hipótesis que no necesitábamos. Lo reservaría para una migración delicada, una revisión de arquitectura o un fallo que ya ha resistido dos intentos normales. Y aun así le pondría un límite de alcance.

Cómo reducir la verbosidad sin volverlo superficial

Pedir simplemente “sé breve” puede salir mal: el modelo recorta tanto la explicación como la comprobación. Prefiero definir qué debe omitir y qué no puede saltarse. Estas reglas encajan bien en CLAUDE.md:

- Empieza por la causa y el plan en un máximo de cinco líneas.
- No anuncies cada lectura, búsqueda o comando rutinario.
- No repitas mi encargo ni cierres con un resumen de lo evidente.
- Mantén el cambio dentro del alcance solicitado.
- Si detectas otro problema, anótalo aparte y no lo corrijas.
- Antes de terminar, ejecuta las pruebas relevantes y explica sólo
  los riesgos, decisiones no obvias y comprobaciones realizadas.

Esto no intenta controlar cada palabra. Le dice dónde gastar la atención. La investigación y las pruebas siguen siendo obligatorias; la narración de cada paso, no.

Un prompt práctico para no quemar la cuota

Investiga primero el flujo afectado y reproduce el problema.
Antes de editar, dime la causa probable y los archivos que tocarías.
Espera mi confirmación si el cambio supera esos archivos.
Implementa la solución mínima y añade una prueba de regresión.
Ejecuta sólo la suite relacionada; amplíala si aparece un fallo.
Termina con el diff lógico, las pruebas y cualquier riesgo pendiente.

La pausa antes de editar no siempre hace falta. En una tarea pequeña la quitaría para no añadir otra ronda. En una migración o un error mal definido resulta barata: evita que Opus utilice la mitad de la sesión construyendo la solución correcta para el problema equivocado.

Cambios que pueden afectar a integraciones

Quien use Claude Code de forma normal apenas debería notar la migración más allá del selector de modelo y esfuerzo. En la API sí conviene revisar la guía de cambios de Opus 5.5. El razonamiento adaptativo está siempre activo, algunas combinaciones de elección forzada de herramientas cambian y los bloques de pensamiento quedan ligados al modelo y a la conversación.

No actualizaría una integración importante sustituyendo únicamente el nombre del modelo. Primero guardaría varias peticiones reales, comprobaría herramientas, estructura de salida, latencia y coste, y después haría una comparación con la versión anterior. En agentes, un cambio pequeño de comportamiento puede romper más que un cambio evidente de formato.

¿Merece la pena cambiar ya?

Para Claude Code, sí merece la pena probar Opus 5.5 en trabajo diario, sobre todo si Opus 5 u 4.8 agotaban la cuota demasiado rápido. La combinación de mayor velocidad, respuestas menos infladas y un precio de API inferior va en la dirección correcta. Lo que todavía no compraría es la idea de que hace innecesario elegir bien el esfuerzo o escribir un encargo concreto.

Mi forma de adoptarlo sería sencilla: Medium, una tarea que ya conozco y un criterio de salida verificable. Después repetiría con un problema largo del repositorio. Si mantiene el alcance y deja más cuota al final, se queda. Si sólo parece brillante durante la primera media hora, 4.8 seguirá siendo una referencia útil mientras ajustamos las instrucciones.

Si lo probáis, contad qué tipo de tarea le disteis y con qué esfuerzo. Saber que fue bien o mal aporta poco; saber si era una interfaz, un refactor, un error de concurrencia o una migración permite comparar experiencias de verdad.