Migrar a Claude Opus 5.5: 5 ajustes que dan 400

En pocas palabras: Cambiar solo el nombre del modelo a Claude Opus 5.5 (22/09/2026) o Sonnet 5.5 (28/09/2026) devuelve HTTP 400 si usás thinking: disabled, tool_choice any o tool, computer_20251124 en la API de Claude, historial editado con thinking o un advisor no admitido.

Para migrar a Claude Opus 5.5 desde Opus 5 no alcanza con cambiar el nombre del modelo: cinco configuraciones devuelven HTTP 400, entre ellas thinking: disabled, tool_choice any o tool, computer_20251124 y el historial editado. Las guías oficiales de Anthropic documentan todas.

Claude Opus 5.5 es un modelo de Anthropic para programación agéntica de larga duración y trabajo de conocimiento, con ID claude-opus-5-5 y un precio de USD 4 por millón de tokens de entrada y USD 20 de salida, según la página oficial de novedades. Claude Sonnet 5.5 (claude-sonnet-5-5) es el modelo de la línea Sonnet, con los mismos precios que Sonnet 5 salvo las lecturas de caché. Los dos exigen cambios de código.

¿Qué es Claude Opus 5.5 y en qué se diferencia de Sonnet 5.5?

Opus 5.5 tiene thinking adaptativo siempre activo y se controla con el parámetro effort. Sonnet 5.5 acepta dos valores de thinking.type, adaptive y between_tools, según la guía de migración de Sonnet 5.5. Esa es la diferencia que más vas a notar al modificar el código.

En precios, Opus 5.5 baja de USD 5 / USD 25 (Opus 5) a USD 4 / USD 20 por millón de tokens de entrada y salida. Sonnet 5.5 mantiene los precios de Sonnet 5, pero las lecturas de caché cuestan USD 0,10 por millón, la mitad que antes.

Las fechas de lanzamiento (22 y 28 de septiembre de 2026) salen del artículo de dev.to, no de las páginas oficiales que revisamos.

¿Cómo migrar a Claude Opus 5.5 sin recibir error 400?

Para migrar a Claude Opus 5.5 sin errores hay que revisar cinco puntos: thinking, tool_choice, computer use, edición del historial y, en Sonnet 5.5, el modelo advisor. Cada uno devuelve HTTP 400 si queda igual que en Opus 5 o Sonnet 5.

#	Configuración	Qué pasa	Arreglo
1	thinking: disabled	400 en Opus 5.5 y en Sonnet 5.5 (en Opus también enabled con budget_tokens)	Opus: omitir thinking y bajar effort. Sonnet: between_tools con effort high o menor
2	tool_choice any o tool	400 en ambos, también al contar tokens	auto + strict: true + indicar en el prompt cuándo llamar la herramienta
3	computer_20251124	400 en la API de Claude y Google Cloud	computer_toolset_20260801, sin header beta
4	Historial editado con bloques de thinking	400 en cuentas creadas desde el 31/08/2026; en las anteriores se descarta el bloque	Historial append-only
5	Advisor no soportado	400 en Sonnet 5.5	Opus 5, Opus 5.5, Sonnet 5.5, Fable 5/5.1 o Mythos 5/5.1

Ojo con el alcance de la evidencia: el autor del artículo fuente reprodujo solo el primer caso contra la API, el 6 de octubre, y dice que esos 400 no tuvieron cargo. Los otros cuatro vienen de la documentación oficial, que nosotros no probamos. Para más detalles técnicos, mirá nuestra comparativa entre Sonnet y Opus.

Ponele el escenario típico: subís el modelo nuevo a staging, el endpoint responde, los tests con mocks pasan en verde, mergeás con la tranquilidad de quien cambió una sola línea y a la mañana siguiente el log está lleno de invalid_request_error porque un helper que nadie tocaba hace meses seguía mandando thinking: disabled.

¿Cómo apago el thinking en Claude Opus 5.5 y Sonnet 5.5?

En Opus 5.5 no se puede apagar: el thinking está siempre activo y la única palanca es output_config.effort. En Sonnet 5.5 se baja al mínimo con thinking: {"type": "between_tools"}, que elimina el thinking previo a la respuesta.

El mensaje de error de Opus 5.5, tal como lo documenta Anthropic: “thinking.type.disabled” is not supported for this model. Use “thinking.type.adaptive” and “output_config.effort” to control thinking behavior. Donde antes desactivabas, ahora omitís el campo thinking (equivale a adaptive) y bajás el effort.

Para Sonnet 5.5, el antes y el después de la guía oficial:

# Sonnet 5
client.messages.create(
 model="claude-sonnet-5",
 max_tokens=16000,
 thinking={"type": "disabled"},
 output_config={"effort": "xhigh"},
 messages=[...],
)

client.messages.create(
 model="claude-sonnet-5-5",
 max_tokens=16000,
 thinking={"type": "between_tools"},
 output_config={"effort": "high"},
 messages=[...],
)

Los límites de between_tools son estrictos:

• Solo hasta effort high. Con xhigh o max devuelve 400. Para esos niveles, adaptive.
• No acepta otros campos. display, budget_tokens y block_binding también dan 400.
• No tolera effort distinto por mensaje. Si necesitás variar el effort por turno, usá adaptive.
• Sin herramientas, no hay thinking. La respuesta sale sin razonar; las tareas de varios pasos conviene moverlas a adaptive.

¿Qué uso en lugar de tool_choice any o tool en Claude 5.5?

¿Cómo reemplazo el tool_choice forzado?

Mandá tool_choice: {"type": "auto"}, marcá la herramienta con strict: true y escribí en el prompt cuándo debe usarse. Opus 5.5 y Sonnet 5.5 rechazan any y tool con un 400, incluso en el endpoint de conteo de tokens.

El cambio tiene una consecuencia que la fuente no subraya: con auto el modelo puede contestar sin llamar a la herramienta, así que tu código tiene que tolerar una respuesta en texto. Los límites de strict: máximo 20 herramientas por request y additionalProperties: false en cada objeto. Si lo que querías era JSON, output_config.format (structured outputs) es el camino. Sobre eso hablamos en las capacidades y la API de Opus 3.

En Amazon Bedrock hay una trampa. Ahí ninguno de los dos modelos tiene structured outputs, strict incluido, así que mandás auto, nombrás la herramienta en el prompt y validás el input vos.

¿Qué pasa con computer use?

En la API de Claude y en Google Cloud, computer_20251124 devuelve 400 y se declara computer_toolset_20260801, sin header beta. Sonnet 5.5 rechaza además computer_20250124 en todas las plataformas. Amazon Bedrock conserva computer_20251124.

Si mandabas el header fine-grained-tool-streaming-2025-05-14, sacalo: junto a un toolset da 400. En su lugar, eager_input_streaming: true en cada herramienta que lo necesite. El agent loop también cambia (bloques tool_use de miembros, acciones en lote, toolset_name en los resultados), así que no es un reemplazo de string.

¿Por qué editar el historial de la conversación da 400 con Opus 5.5 y Sonnet 5.5?

Los bloques de thinking quedan atados al modelo que los generó y al prefijo de la conversación. Si cambiás system, tools o turnos anteriores y reenviás esos bloques, la API devuelve 400 en cuentas creadas desde el 31/08/2026 a las 00:00 UTC, según Anthropic. En cuentas más viejas se descarta el bloque.

La receta oficial es mantener el historial append-only. Las alternativas, todas de las fuentes: Te puede servir nuestra cobertura de nuestra guía general sobre Claude.

• Cambiar instrucciones: con un mensaje {"role": "system", ...} a mitad de conversación, que además conserva el caché de prompt.
• Cambiar herramientas: con tool_addition y tool_removal; con el beta inline-tools-2026-09-15 se pueden incluir definiciones completas.
• Achicar el historial: con compactación bajo demanda (beta compact-2026-09-04), que devuelve un bloque resumen firmado que mandás primero en el siguiente request.

Los bloques de Sonnet 5.5 además están atados a la cuenta: enviados desde otra organización se descartan sin aviso. Y un dato de enrutamiento: Opus 5.5 lee thinking de Opus 5 y modelos anteriores, pero no de los modelos Fable ni Mythos. Si tenés un router o fallback, parte del razonamiento previo se pierde en el cambio.

¿Qué advisors acepta Sonnet 5.5?

Con Sonnet 5.5 como ejecutor, el advisor tiene que ser Opus 5, Opus 5.5, Sonnet 5.5, Fable 5 o 5.1, o Mythos 5 o 5.1. Opus 4.8, 4.7 y 4.6, Sonnet 5, Sonnet 4.6 y Haiku 5.5 devuelven 400. El consejo llega cifrado en un bloque advisor_redacted_result, así que no podés leerlo en la respuesta.

¿Qué cambios no dan error pero afectan el resultado al migrar?

El más importante es el effort por defecto: Opus 5.5 corre en medium y Opus 5 corría en high. Si copiás un request sin effort, baja un escalón sin avisar. Según el artículo de dev.to, Anthropic afirma que 5.5 en medium iguala o supera a Opus 5 en high; es un dato del fabricante, así que medilo con tus propios evals.

• Más thinking por turno. Con el mismo effort, Opus 5.5 piensa más que Opus 5, sobre todo en xhigh y max. La guía recomienda arrancar con max_tokens de 64k en esos niveles.
• UI de progreso muda. El texto entre llamadas a herramientas llega en bloques thinking, vacíos con el display por defecto. Hay que usar display: "summarized" o, en beta, "updates".
• Lectura por posición. Si tu código hace content.text, se rompe porque la respuesta puede empezar con un bloque de thinking.
• Más categorías de rechazo. Opus 5.5 suma bio. Según dev.to, desde el 24/09 los rechazos sin salida en bio, frontier_llm y reasoning_extraction se facturan.
• Caché y soporte. El mínimo de caché de prompt en Opus 5.5 es de 512 tokens y Priority Tier no está soportado.
• Retiro. Dev.to indica que Sonnet 4.5 se retira el 30/11/2026, con Sonnet 5.5 como reemplazo.

¿Qué está confirmado y qué no?

• Confirmado en documentación oficial: los errores 400 de thinking, tool_choice, computer use e historial; el effort medium por defecto; los precios de Opus 5.5; los advisors permitidos en Sonnet 5.5.
• Solo en dev.to: las fechas de lanzamiento, la reproducción del caso 1 el 6/10, la facturación de rechazos desde el 24/09, la fecha del 7/10 para las lecturas de caché y el retiro de Sonnet 4.5.
• Sin verificar: que medium rinda igual que high en tu caso, el escáner de terceros y el issue de LangChain que figura entre las fuentes del encargo, que no pudimos leer.

¿Cómo reviso mi código antes de migrar?

Una propuesta editorial, no un método de la fuente ni algo que hayamos probado: buscá en tu repositorio los cinco patrones ("disabled", budget_tokens, tool_choice con any o tool, computer_20251124 y el modelo advisor), corregí cada hallazgo y después corré un smoke test en staging con max_tokens bajo. Después, un sweep de effort sobre tus propios evals. Cubrimos ese tema en detalle en qué ocurre al migrar prompts a Ollama.

El autor del artículo fuente publicó un escáner open source, claude5-migration-kit, que marca estos casos por archivo y línea. No lo revisamos ni lo avalamos. Tené en cuenta que el mismo autor vende una guía de 70 páginas a USD 19, y que lo gratuito está en las guías oficiales. Nuestros colegas de donweb.news lo analizan en crear un agente de IA en n8n.

Errores comunes al migrar a Claude Opus 5.5

• Reemplazar disabled por enabled con budget_tokens. En Opus 5.5 también da 400. La salida es omitir el campo y bajar el effort.
• Usar between_tools con xhigh o max. Da 400. Si necesitás ese nivel de effort, pasá a adaptive.
• Confiar en tests con mocks. Un mock no valida contra la API, así que el 400 aparece recién en un entorno real.
• Arrastrar parámetros de la era 4.x. La guía oficial dice que temperature, top_p y top_k con valores no default se rechazan, y lo mismo pasa con el prefill del turno assistant.

Preguntas Frecuentes

¿Por qué me da error 400 en Claude Opus 5.5 si solo cambié el nombre del modelo?

Porque Opus 5.5 rechaza configuraciones que Opus 5 aceptaba: thinking: disabled, tool_choice any o tool, computer_20251124 en la API de Claude y Google Cloud, y el historial editado con bloques de thinking. Revisá esos cuatro puntos en tu código.

¿Cómo apago el thinking en Claude Opus 5.5?

No se puede: el thinking adaptativo está siempre activo. Omití el campo thinking y bajá output_config.effort (low, medium, high, xhigh o max) para gastar menos tokens de razonamiento.

¿Qué uso en lugar de tool_choice any en Claude Opus 5.5?

Usá tool_choice: {"type": "auto"} con la herramienta marcada strict: true y una instrucción en el prompt sobre cuándo llamarla. Si solo querías JSON válido, pasá el esquema a output_config.format.

¿Qué es between_tools en Claude Sonnet 5.5?

between_tools es el valor de thinking.type de Sonnet 5.5 que reemplaza a disabled. El modelo no piensa antes de responder y solo escribe notas breves entre llamadas a herramientas, que llegan como bloques de thinking. Funciona con effort high o menor.

¿Qué cambia entre Claude Opus 5 y Opus 5.5 en el esfuerzo por defecto?

El effort por defecto baja de high en Opus 5 a medium en Opus 5.5. Un request sin effort corre un nivel más bajo, así que conviene fijarlo de forma explícita y repetir tus evals.

Conclusión

Migrar a Claude Opus 5.5 es un cambio de contrato con la API, no de nombre de modelo. Cinco configuraciones devuelven 400, y varios cambios silenciosos (effort medium, texto entre herramientas en bloques de thinking, rechazos facturables según dev.to) alteran costo y comportamiento sin ningún error.

Lo que te conviene hacer: buscar los cinco patrones en tu código, fijar el effort a mano, leer los bloques por tipo y dejar el historial append-only. Después medí con tus propios casos, porque la mejora de medium contra high es un dato del fabricante que nadie validó de forma independiente para tu carga.

Fuentes

• Guía de migración de Claude Opus 5.5 – documentación oficial de Anthropic
• Guía de migración de Claude Sonnet 5.5 – documentación oficial de Anthropic
• Novedades de Claude Opus 5.5 – cambios incompatibles y precios
• Claude Opus 5.5 / Sonnet 5.5: 5 settings that return 400 – artículo de dev.to