Vercel anunció que Claude Opus 5.5 ya está disponible en AI Gateway, el mismo día que GitHub lo habilitó en Copilot y que Anthropic publicó el modelo. Anthropic dice que rinde al nivel de Fable 5.1, con ~30% más de velocidad y ~40% menos de costo por tarea que Opus 5. Eso es lo que todos van a titular.
Lo que casi nadie va a leer es el párrafo del medio: hay dos cambios de API que convierten requests que hoy funcionan en HTTP 400.
Por qué importa
La señal acá no es el benchmark. Es que Anthropic retiró dos palancas de control que mucha gente usó para domesticar al modelo, y las retiró en el mismo release que promete más autonomía. Según el changelog de Vercel, Opus 5.5 rechaza los requests que deshabilitan el thinking o le fijan un presupuesto, y rechaza los que exigen una tool call o fuerzan una herramienta específica.
Traducido: el modelo decide cuánto pensar y vos no podés obligarlo a llamar a una función. Durante dos años el patrón de integración fue el contrario — forzar una tool para conseguir JSON estructurado, capar el thinking para acotar latencia y costo. Ese patrón se terminó. No es un detalle de release notes, es un cambio de contrato entre tu harness y el modelo.
Y encaja con el resto del anuncio. La nota de Vercel remarca que Opus 5.5 reporta en lenguaje llano qué hizo, qué encontró y qué necesita después. GitHub, por su lado, dice que en pruebas tempranas resolvió tareas de forma comparable a Opus 5 usando bastante menos pasos y tokens, y que se recuperó rápido de errores en tareas multi-paso. El modelo se está posicionando como algo que supervisás, no como algo que controlás request por request.
Qué cambia en la práctica
Si tenés un agente en producción con Opus 5, el cambio de modelo no es una línea en una variable de entorno. Es una auditoría de tu capa de llamadas.
| Antes (Opus 5) | Ahora (Opus 5.5) |
|---|---|
| Thinking desactivable o con presupuesto fijo | Thinking siempre adaptativo; el modelo decide |
| Forzar una tool call para obtener JSON | Structured outputs; forced tool use retirado |
| Forzar una herramienta específica | Promptear hacia ella y reintentar en el harness |
| Control fino de latencia por request | Effort y prompting como únicas palancas |
El flujo de migración que yo seguiría es corto y aburrido, que es como tienen que ser las migraciones:
┌────────────────────────────┐
│ grep del campo thinking │
│ y de tool_choice forzado │
└─────────────┬──────────────┘
▼
┌────────────────────────────┐
│ ¿JSON por tool forzada? │
│ sí ─► structured outputs │
└─────────────┬──────────────┘
▼
┌────────────────────────────┐
│ retry en el harness para │
│ tool calls que no salen │
└─────────────┬──────────────┘
▼
┌────────────────────────────┐
│ canary con tráfico real │
└────────────────────────────┘
El punto tres es el que más subestiman. Si antes forzabas la herramienta, tu código nunca tuvo que manejar el caso "el modelo contestó texto en vez de llamar la función". Ahora ese caso existe siempre, y el changelog es explícito: promptear hacia la tool, después atrapar y reintentar los fallos en tu harness. Eso es lógica nueva, con sus propios tests.
Dos cosas más del material que cambian decisiones de arquitectura. Primero, la ventana es de 1M de tokens de contexto con hasta 128K de salida y corte de conocimiento en junio de 2026 — si tenías una estrategia de chunking armada para ventanas chicas, quizás sobra la mitad. Segundo, hay controles opcionales de inferencia regional y Zero Data Retention en el gateway, que es exactamente lo que te piden en un compliance review de cliente corporativo. Vercel además aclara que refleja el pricing del proveedor sin markup ni platform fee sobre inferencia, incluso con BYOK.
Y un detalle que solo aparece en el changelog de GitHub: Opus 5.5 pone una marca de agua en sus salidas de texto. No cambia significado, calidad ni legibilidad, ni suma tokens ni costo. Si trabajás con clientes que tienen políticas sobre contenido generado por IA, esto es una conversación que conviene tener vos antes de que la tengan ellos.
Cuándo NO usarlo
Hay tres escenarios donde yo hoy me quedaría en Opus 5, sin culpa.
- Latencia con SLA duro. Si tu producto promete respuesta en X milisegundos y lo lograbas apagando el thinking, perdiste la palanca. "~30% más rápido en promedio" no es lo mismo que "predecible": con thinking adaptativo, la varianza por request queda del lado del modelo. Antes de migrar, medí p95 y p99 con tu tráfico real, no con el benchmark de nadie.
- Pipelines que dependen de tool calls determinísticas. Si tu sistema asume que cada turno produce sí o sí una llamada a función, el reintento en el harness no es un parche de una tarde: es cambiar la máquina de estados. Migrá cuando tengas tiempo de hacerlo bien.
- Costos ya optimizados con presupuestos de thinking. "40% más barato por tarea" es la cifra de Anthropic comparando contra Opus 5 en su configuración. Si vos ya venías recortando thinking a mano, tu línea base es otra y ese 40% no te aplica igual. El material no da números para ese caso, así que la única respuesta honesta es medirlo vos.
Agrego un matiz que salió en la cobertura de Latent Space: junto a las ganancias de eficiencia mencionan también ineficiencia compensatoria en el uso de tokens en algunas tareas de frontera. O sea, la mejora no es uniforme. Si tu carga de trabajo vive en el borde de lo que el modelo sabe hacer, el ahorro puede evaporarse.
Qué haría hoy
Lo probaría primero donde el riesgo es mío y no del cliente: en mi propio flujo de desarrollo. Está en Copilot para Pro+, Max, Business y Enterprise, con rollout gradual, y en AI Gateway se conecta a los agentes de código vía CLI de Vercel. Ahí el costo de que salga mal es una sesión molesta, no un incidente.
En paralelo, haría el grep de thinking y de tool choice forzado en todos los servicios que tocan la API. Eso lleva veinte minutos y te dice si la migración es un cambio de string o dos semanas de trabajo. Enterarte por un 400 en producción es la peor forma posible de averiguarlo.