Migrar de Claude Opus 5 a Opus 5.5: qué cambia para quienes llaman a la API

Anthropic lanzó Claude Opus 5.5 el 22 de septiembre de 2026. Para cualquiera que llame a la API de Claude, la actualización es una sola cadena: claude-opus-5 pasa a ser claude-opus-5-5.

Prueba Apidog hoy

Lo que hay detrás de esa cadena es un 20% más barato por token en ambos sentidos, limita una sola respuesta a 128,000 tokens de salida, se afirma que produce la salida un 30% más rápido y está diseñado para mantenerse en una sola tarea durante 18 horas o más. Nada de eso está libre de consecuencias para el código que ajustaste contra Opus 5.

Este es el segundo salto de migración en esta línea de modelos y no se parece en nada al primero. De Opus 4.8 a Opus 5 fue una migración de corrección: los valores predeterminados se movieron por debajo de código que funcionaba, y una combinación de solicitud que antes era válida empezó a devolver un 400 duro. Este salto es una migración de presupuesto y de envolvente operativa. El trabajo consiste en volver a medir números que ya mediste una vez, porque todos y cada uno de ellos se movieron. Opus 5.5 además llegó el mismo día que dos nuevos modelos de OpenAI, lo cual es una historia aparte.

El diff, en las únicas celdas que podemos documentar

Concepto	Opus 5	Opus 5.5	Cambio
ID del modelo	claude-opus-5	claude-opus-5-5	una cadena
Entrada, por millón de tokens	$5.00	$4.00	20% menos
Salida, por millón de tokens	$25.00	$20.00	20% menos
Escritura en caché, por millón	consulta la página del proveedor	$5.00	desconocido
Lectura de caché, por millón	consulta la página del proveedor	$0.20	desconocido
Modo rápido, por millón	consulta la página del proveedor	$8.00 entrada, $40.00 salida	desconocido
Tokens de salida máximos	consulta la página del proveedor	128,000	desconocido
Ventana de contexto	consulta la página del proveedor	1,000,000	desconocido

Las celdas en blanco son deliberadas. Anthropic publicó el lado de Opus 5.5 en su página del modelo y no vamos a reconstruir el lado de Opus 5 de memoria, porque un número equivocado en un modelo de costes es peor que uno ausente. Saca esas cinco filas de la página de precios de Anthropic antes de construir una estimación de ahorro sobre ellas.

1. El cambio de id es real, el 20% es real, el 40% hay que leerlo con cuidado

Cambia la cadena y pagas un 20% menos por token en ambos sentidos. Esa parte es aritmética: de $5 a $4 en entrada, de $25 a $20 en salida, el mismo recorte en ambos lados.

Anthropic también dice que Opus 5.5 cuesta un 40% menos de ejecutar que Opus 5. Esas dos cifras no están en conflicto, pero tampoco son la misma afirmación. Un recorte del 20% por token no puede producir por sí solo una reducción del 40% en la factura. La otra mitad tiene que venir de que el modelo use menos tokens para terminar el mismo trabajo, y la eficiencia de tokens depende del tipo de carga de trabajo de una forma en que una hoja de precios no.

Así que trata el 40% como un motivo para volver a medir, no como un número para meter en una previsión. Reproduce una porción representativa del tráfico real de la semana pasada contra ambos ids de modelo con prompts y ajustes idénticos, compara los bloques usage en lugar de tu impresión sobre ellos, y multiplica los recuentos reales de tokens por las nuevas tarifas. Tu respuesta caerá en algún punto entre el 20% y el 40%, y dónde caiga te dice algo útil sobre cuánto de tu prompt nunca fue necesario.

2. La línea de caché es el mayor cambio de precio de la tabla

Las lecturas de caché en Opus 5.5 cuestan $0.20 por millón de tokens frente a $4.00 de la entrada nueva, un descuento del 95%. Las escrituras de caché cuestan $5.00 por millón, una prima de $1.00 sobre los $4.00 que habrías pagado por enviar esos tokens sin caché.

Esa prima se paga sola con el primer acierto, y con cambio. Escribir un prefijo cuesta $1.00 por millón más que no cachearlo. Cada lectura posterior de ese prefijo ahorra $3.80 por millón. El punto de equilibrio está en aproximadamente un cuarto de una relectura, lo que en la práctica significa: si el prefijo se reutiliza aunque sea una vez, cachearlo fue lo correcto.

Esta es la forma sobre un prompt de sistema de 200,000 tokens, que es un tamaño normal en cuanto pegas un paquete de especificaciones OpenAPI:

Patrón	Coste de 10 llamadas
Entrada nueva en cada llamada, $4.00/M	$8.00
Escribir una vez a $5.00/M, luego 9 lecturas a $0.20/M	$1.36

Los mismos prompts, el mismo modelo, un 83% menos. La solicitud que te da la segunda fila marca el prefijo de forma explícita:

{
  "model": "claude-opus-5-5",
  "max_tokens": 4096,
  "system": [
    {
      "type": "text",
      "text": "<your 200k-token spec bundle>",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {"role": "user", "content": "Which endpoints changed between v2 and v3?"}
  ]
}

Luego lee la respuesta para confirmar que obtuviste un acierto, porque una caché que crees tener y no tienes es la más cara de todas:

"usage": {
  "input_tokens": 41,
  "cache_creation_input_tokens": 204800,
  "cache_read_input_tokens": 0,
  "output_tokens": 612
}

En la primera llamada, cache_creation_input_tokens lleva la carga. En todas las llamadas posteriores, ese número debería caer a cero y cache_read_input_tokens debería recogerla. Si no lo hace, algo en la cadena anterior está mutando tu prefijo, normalmente una marca de tiempo, un id de solicitud o una lista de herramientas reordenada. Guardar una llamada en Apidog y dispararla dos veces es la forma más rápida de ver cuál de los dos campos se mueve. Toda la aritmética, incluido cuándo vale la pena cachear un contexto de 1M, está en los cálculos de coste de caché de Opus 5.5.

3. Una respuesta de 128,000 tokens es un problema del cliente antes que un problema del modelo

Opus 5.5 devolverá hasta 128,000 tokens de salida en una sola respuesta. A $20 por millón, eso son $2.56 por una única llamada al máximo, algo que conviene saber antes de que alguien ponga max_tokens al límite dentro de un bucle de reintentos.

El problema mayor es todo lo que hay entre el modelo y tu código:

• Tiempos de espera de lectura HTTP. Una respuesta así de larga tarda minutos, no segundos. Los tiempos de espera predeterminados de los clientes en la mayoría de SDKs y proxies inversos son más cortos que eso.
• Búferes de proxies y pasarelas. Una pasarela que almacena en búfer el cuerpo completo antes de reenviarlo retiene megabytes por cada solicitud en vuelo, y algunas simplemente cortarán la conexión.
• Llamadas sin streaming. Sin streaming esperas todo el tiempo sin nada que mostrar y nada que guardar como punto de control.
• JSON truncado. Alcanzar max_tokens en medio de un objeto produce JSON inválido, no un objeto parcial que puedas rescatar. Comprueba stop_reason antes de parsear.

Subir max_tokens porque el límite máximo aumentó es la mitad fácil. Conseguir que tu cadena de tiempos de espera, tus búferes y tu parser estén de acuerdo con el nuevo límite es la mitad que provoca el incidente.

4. Una salida más rápida no significa una espera más corta

Anthropic afirma que Opus 5.5 produce la salida un 30% más rápido que Opus 5. La velocidad de salida es solo uno de los términos de la latencia que realmente sirves. El tiempo hasta el primer token, los reintentos y las colas van a su lado, y un modelo que hace streaming más rápido puede seguir sintiéndose más lento si piensa más antes de que llegue el primer token.

Así que mídelo. Lanza un conjunto fijo de prompts representativos contra ambos ids de modelo desde la misma posición de red, y registra p50 y p95 por separado para el tiempo hasta el primer token y para el tiempo total. La latencia media oculta el caso que te despierta por la noche.

Si guardas escenarios de prueba de API en Apidog, esto es un trabajo pequeño: clona una solicitud guardada, cambia el id del modelo, ejecuta ambas según una programación y lee la serie temporal de tiempos de respuesta en lugar de un cronómetro. La idea es entrar en la migración con un número de partida, porque después de hacer el cambio no hay forma de conseguirlo.

5. El modo rápido es exactamente el doble de tarifa

El modo rápido en Opus 5.5 cuesta $8.00 por millón de entrada y $40.00 por millón de salida. Puestos junto a los $4.00 y $20.00 estándar, la regla de precios es fácil de recordar: el modo rápido es exactamente un 2x en ambos lados.

Eso convierte la decisión en aritmética en lugar de criterio: si la latencia en una ruta concreta vale la pena como para duplicar la factura de tokens de esa ruta, úsalo ahí; si no, no lo uses. El reparto habitual es modo rápido en rutas interactivas y tarifas estándar en trabajo por lotes y en segundo plano.

6. Trata la tabla de benchmarks como un motivo para probar, no como un resultado

Las cifras publicadas por Anthropic para Opus 5.5 son sólidas: Terminal-Bench 4.0 con 66.4%, FrontierCode v1.1 con 54.4%, CursorBench 4.0 con 57.8%, GDPval-AA v2.1 con 1846 Elo, AutomationBench con 40.0%, Humanity's Last Exam con 67.7% usando herramientas, OSWorld 2.0 con 81.8% y Chartography con 89.0%. Artificial Analysis, un tercero y no ninguno de los dos proveedores, lo coloca primero de 212 modelos en su índice con una puntuación de 58.

Otras dos afirmaciones del proveedor importan más operativamente que competitivamente. Opus 5.5 está diseñado para mantenerse en una sola tarea durante 18 horas o más, lo que rompe muchas suposiciones habituales sobre tiempos de espera, reintentos y reanudabilidad. Y Anthropic informa de un 85% menos de intentos exitosos de eludir límites, lo cual es una propiedad comprobable de tus propios endpoints en lugar de una propiedad que heredas.

Nada de esto te dice si Opus 5.5 es mejor con tus prompts. Ejecuta tu propio conjunto de evaluaciones con ambos ids antes de pasar producción, por la misma razón por la que no desplegarías una actualización de base de datos basándote en las cifras de benchmark del proveedor.

Lista de comprobación de la migración

1. Cambia claude-opus-5 por claude-opus-5-5 en un servicio, no en todos.
2. Lee la guía de migración de Anthropic para este salto antes de dar por hecho que la superficie de parámetros no ha cambiado. El salto de 4.8 a 5 movió valores predeterminados en silencio, así que verifica en lugar de inferir.
3. Reproduce una porción de tráfico real contra ambos ids y compara los bloques usage.
4. Recalcula tu gasto mensual a $4 y $20, y por separado a $5 las escrituras de caché y $0.20 las lecturas de caché.
5. Confirma los aciertos de caché en cache_read_input_tokens en lugar de confiar en que el prefijo es estable.
6. Sube tus tiempos de espera de lectura HTTP y revisa los búferes de la pasarela antes de que alguien ponga max_tokens cerca de 128,000.
7. Registra la latencia p50 y p95 con ambos ids antes de hacer el cambio.
8. Decide el modo rápido ruta por ruta, a 2x de tarifa.
9. Vuelve a ejecutar tu propio conjunto de evaluaciones. Los benchmarks del proveedor son el motivo para probar, no la prueba.

Opus 5.5 es una versión más barata, más rápida y de mayor duración de un modelo que ya llamas. El riesgo de la migración no es que el cambio de cadena falle. Es que arrastres un modelo de costes, un tiempo de espera y un valor de max_tokens que estaban dimensionados para otro modelo.

Preguntas frecuentes

¿Es claude-opus-5-5 un reemplazo directo de claude-opus-5? Trátalo como tal solo después de consultar la guía de migración de Anthropic para este salto. El cambio de id es una edición de una línea, pero el salto anterior en esta línea movió valores predeterminados sin cambiar la forma de la solicitud, así que verificar es un seguro barato.

¿Cuánto más barato es Opus 5.5? Un 20% menos por token en ambos sentidos, de $5 a $4 en entrada y de $25 a $20 en salida. Anthropic indica por separado una reducción del 40% en el coste de ejecución, lo que implica ganancias de eficiencia de tokens además del recorte de tarifas. Mide tu propia carga de trabajo para ver en qué punto entre ambas cifras acabas.

¿Cuánto cuesta el almacenamiento en caché de prompts en Opus 5.5? Las escrituras cuestan $5.00 por millón de tokens y las lecturas $0.20 por millón, frente a $4.00 de la entrada sin caché. Una sola reutilización de un prefijo cacheado paga con creces la prima de escritura.

¿Cambia algo en mi cliente el límite de 128,000 tokens de salida? Normalmente sí. Revisa tus tiempos de espera de lectura HTTP, el almacenamiento en búfer de tu pasarela y si haces streaming. Comprueba también stop_reason antes de parsear, porque alcanzar el límite en medio de un objeto produce JSON inválido en lugar de un objeto truncado.