Claude Fable 5.1: los 3 breaking changes que rompen tu agente
DominicodeAyer por la tarde cambié una línea en un agente que llevaba once semanas en producción sin que nadie lo tocara.
claude-fable-5 → claude-fable-5-1. Eso es todo lo que pide la guía de migración a Claude Fable 5.1. Deploy, café, a otra cosa.
En mi cuenta no pasó nada. En la del cliente, abierta el lunes, las conversaciones largas empezaron a devolver un 400 con un mensaje que no había visto nunca: The block is bound to a different conversation.
El modelo no tenía la culpa. La tenía una función mía que reconstruía el system prompt en cada petición para inyectar la fecha de hoy. Con Fable 5 era invisible. Ahora invalida todos los thinking blocks posteriores y la API rechaza la petición entera.
Esa es la tesis de este post: actualizar el model ID es una línea; lo que rompe es cómo construyes el array de messages.
Qué es Claude Fable 5.1 y qué no cambia respecto a Fable 5
Claude Fable 5.1 es el modelo de razonamiento de gama alta de Anthropic, lanzado el 1 de septiembre de 2026 junto a Claude Mythos 5.1. Mantiene la ficha técnica de Fable 5 —ventana de 1M de tokens, 128K de output, $10 de input y $50 de output por millón— y su retirada no será antes del 1 de septiembre de 2027. Lo único que cambia de precio es el cache read. Lo único que rompe es cómo construyes el array de messages.
El resto de la ficha tampoco se mueve: mismo tokenizer que Fable 5, thinking adaptativo siempre activo con effort por defecto en high y knowledge cutoff en junio de 2026. La ventana de 1M es a la vez el valor por defecto y el máximo, a precio estándar de principio a fin.
Dónde puedes llamarlo: la API de Claude como claude-fable-5-1, Amazon Bedrock como anthropic.claude-fable-5-1, Google Cloud y Microsoft Foundry, además de Claude Code, Claude Enterprise y la Claude Platform. Mythos 5.1 (claude-mythos-5-1) es solo por invitación.
Si vienes de Fable 5, en la ficha técnica no hay nada nuevo que aprender. Lo nuevo está en dos sitios: tres cosas que dejan de funcionar y un precio que cambia la economía de los agentes largos.
Breaking change 1: tool_choice forzado devuelve 400 en Claude Fable 5.1
tool_choice: {"type": "any"} y {"type": "tool", "name": "..."} devuelven un 400 invalid_request_error con este mensaje literal:
tool_choice: type "tool" and "any" are not supported for this model.
Siguen funcionando {"type": "auto"} (el default) y {"type": "none"}. La misma validación se aplica al endpoint de token counting: si tenías un estimador de costes que replicaba el payload, también se cae.
El motivo tiene sentido. Con el thinking siempre activo, forzar la tool se salta el bloque de razonamiento y el modelo acaba metiéndolo en los argumentos.
El fix son dos cambios y ninguno es dramático:
// Antes (Fable 5): forzabas la tool para garantizar JSON válido
const res = await client.messages.create({
model: "claude-fable-5",
max_tokens: 4096,
tools: [extractInvoice],
tool_choice: { type: "tool", name: "extract_invoice" }, // 400 en Fable 5.1
messages,
});
// Después (Fable 5.1): auto + strict, y la orden va en el prompt
const res = await client.messages.create({
model: "claude-fable-5-1",
max_tokens: 4096,
tools: [{ ...extractInvoice, strict: true }],
tool_choice: { type: "auto" },
messages: [
...messages,
{
role: "user",
content: "Usa la tool `extract_invoice` para responder.",
},
],
});
Un aviso antes de que lo copies: ese mensaje se queda en el historial. Si lo inyectas en cada petición y lo borras en la siguiente, acabas de reproducir el breaking change 3. O lo dejas fijo, o lo mandas como system message de un solo turno, que lo verás más abajo.
Si lo que buscabas con tool_choice era JSON conforme a un esquema y no una herramienta de verdad, mueve el esquema a structured outputs y quítate la tool de en medio. El esquema pasa a ser el contrato, y un contrato hay que validarlo también en tu lado. Si lo que devuelve el modelo lo compruebas con un if (typeof x === "string"), en el curso de Zod para TypeScript está la versión que no se rompe cuando el esquema crece.
Breaking change 2: los thinking blocks están atados al modelo que los produjo
Cada thinking block registra qué modelo lo generó, y la compatibilidad es unidireccional. Fable 5.1 lee los bloques de modelos anteriores. Ningún modelo anterior lee los de Fable 5.1.
Traducción para quien tiene un router: si tu fallback salta de Fable 5.1 a Opus 5 a mitad de conversación, la API descarta el bloque antes de que el modelo lo vea. No cuenta como input_tokens, no se factura y no te avisa.
Ese silencio es el problema: tu agente sigue respondiendo, pero razona con menos contexto del que crees y en la traza no hay un error que investigar. Con el header beta thinking-binding-controls-2026-08-01 el descarte se reporta en input_transformations. Enciéndelo en staging antes de migrar.
Breaking change 3: editar turnos anteriores invalida los thinking blocks
Este es el que me mordió a mí.
Modificar cualquier cosa antes de un thinking block —el system, el array de tools o un mensaje anterior— provoca un 400 en la siguiente petición: The block is bound to a different conversation.
Patrones que invalidan todos los bloques posteriores:
- Editar, reordenar o eliminar un turno anterior conservando los siguientes.
- Inyectar texto por petición en un turno anterior (un recordatorio, una línea de estado) que borras en la siguiente.
- Reconstruir el
systemprompt o el array detoolsentre peticiones de la misma conversación. - Servir bytes distintos para la misma imagen o documento en una petición posterior. La comprobación mira los bytes, no la URL, así que una signed URL rotatoria del mismo fichero es válida.
Patrones que no invalidan nada:
- Eliminar una racha inicial de thinking blocks, del más viejo primero.
- Dejar que la compactación o el context editing server-side recorten el historial.
- Mover marcadores
cache_control. - Cambiar el
effortentre peticiones.
La regla mental cabe en tres palabras: trata la conversación como append-only.
Y aquí el detalle que explica por qué a unos les explota y a otros no: la comprobación se aplica a cuentas creadas a partir del 31 de agosto de 2026. En cuentas anteriores la API registra el desajuste pero solo actúa si mandas thinking.block_binding.prefix_mismatch_behavior, y Mythos 5.1 no la aplica nunca. Tu código puede estar roto hoy y no enterarte hasta que un cliente nuevo abra su cuenta.
Claude Code, claude.ai, Claude Managed Agents y el Agent SDK ya mantienen ese prefijo intacto por ti. El problema es tuyo solo si construyes el array messages a mano, que es lo que hacemos casi todos los que tenemos agentes en producción.
Los 3 breaking changes de Claude Fable 5.1, en una tabla
| Qué se rompe | Cómo se manifiesta | Fix |
|---|---|---|
tool_choice de tipo any o tool |
400 invalid_request_error inmediato, también en token counting |
tool_choice: auto + strict: true, o mover el esquema a structured outputs; la orden de usar la tool, en el prompt |
| Thinking blocks de Fable 5.1 enviados a un modelo anterior | Silencio: el bloque se descarta, no se factura, nadie avisa | Que el router no cambie de modelo a mitad de conversación; header thinking-binding-controls-2026-08-01 para verlo en input_transformations |
Editar system, tools o un turno anterior |
400 The block is bound to a different conversation, solo en cuentas creadas desde el 31/08/2026 |
Historial append-only; recordatorios con system messages de un solo turno; recortes con context editing server-side |
No es la primera vez: ya conté los 2 breaking changes de Claude Opus 5. El patrón se repite en cada release y siempre pilla al mismo tipo de código, el que trata el historial como un array mutable.
Precio de Claude Fable 5.1: el cache read baja un 75 %
El cache read de Claude Fable 5.1 cuesta $0,25 por millón de tokens, un 75 % menos que los $1,00 de Fable 5. El resto de precios no se mueve.
| Concepto | Fable 5.1 | Fable 5 |
|---|---|---|
| Input | $10 / MTok | $10 / MTok |
| Output | $50 / MTok | $50 / MTok |
| Cache write 5 min | $12,50 / MTok | $12,50 / MTok |
| Cache write 1 h | $20 / MTok | $20 / MTok |
| Cache read | $0,25 / MTok | $1,00 / MTok |
El mínimo cacheable sigue en 512 tokens y el Batch API mantiene su 50 % de descuento: $5 de input y $25 de output.
Pero el número que cambia la arquitectura es otro: en Fable 5.1 el cache read cuesta 0,025× el input base, cuando en el resto de modelos Claude es 0,1×. Es la excepción, no la norma.
Eso convierte un prefijo grande y estable en algo casi gratis de releer: Anthropic declara un ahorro en torno al 25 % en cargas típicas y hasta el 45 % en trabajo muy agéntico.
Fíjate en la simetría: los mismos patrones que invalidan los thinking blocks son los que te tiran la caché. Reconstruir el system en cada llamada no era un bug latente; era una factura que llevabas pagando desde antes de migrar.
Si nunca lo has medido en serio, empieza por cómo funciona el prompt caching en la API de Claude. Después, cómo medir el consumo real de tokens de un agente. Sin esas dos métricas, elegir modelo es una corazonada.
Tres novedades de Claude Fable 5.1 que sí vale la pena adoptar
Effort por mensaje (beta, header mid-conversation-output-config-2026-07-01). Cambias el nivel de effort a mitad de conversación sin invalidar la caché de prompt. Súbelo para los pasos difíciles, bájalo para los rutinarios:
const response = await client.beta.messages.create({
model: "claude-fable-5-1",
max_tokens: 4096,
output_config: { effort: "high" },
messages: [
{ role: "user", content: "Planifica la migración de SQLite a PostgreSQL." },
{ role: "assistant", content: "1. Exporta los datos. 2. Crea el esquema. 3. Importa y verifica." },
// El nuevo nivel entra en vigor desde el siguiente turno de usuario
{ role: "system", content: [], output_config: { effort: "low" } }, // sin texto: es un mensaje de control
{ role: "user", content: "Resume el plan en una frase." },
],
betas: ["mid-conversation-output-config-2026-07-01"],
});
Si tu editor subraya el role: "system" dentro de messages, es que el tipado de tu SDK todavía no lo incluye: actualiza el paquete antes de pelearte con TypeScript.
System messages de un solo turno (beta, header mid-conversation-system-clear-at-2026-08-21). Es literalmente el sustituto del patrón que ahora rompe. Va dentro del array messages, como un turno más:
{
"role": "system",
"clear_at": "next_user_message",
"content": "Los resultados están en tu bandeja. Revísala antes de ejecutar más código."
}
Tiene autoridad de system prompt durante el turno actual y deja de inyectarse en el prompt cuando llega un mensaje de usuario posterior. Se queda en messages y lo sigues mandando igual, así que nada anterior cambia: la caché sigue casando, los thinking blocks siguen válidos y un mensaje limpiado cuesta 0 tokens de input.
Progress updates entre tool calls (beta, header thinking-display-updates-2026-08-18). Con thinking.display: "updates" recibes como texto los avisos de progreso que el modelo escribe entre llamadas a tools, manteniendo el razonamiento oculto. Con el default "omitted" no llega nada y un turno agéntico de tres minutos parece un cuelgue.
Dos cambios de comportamiento de Fable 5.1 que verás sin tocar código
El parallel tool calling es más variable. Fable 5.1 puede hacer una llamada por turno donde Fable 5 agrupaba varias. No baja la calidad de la respuesta, pero cuesta tokens, round trips y tiempo de reloj. Se arregla con una instrucción de una línea pidiendo agrupar las lecturas independientes.
Y Fable 5.1 reescribe ficheros enteros para cambios pequeños. Donde esperas una edición quirúrgica, te devuelve el fichero entero. Mismo resultado, más tokens de output.
Claude Fable 5.1 vs Opus 5: la parte incómoda es que no es tu default
Lo dicen los propios docs de Anthropic: "For most workloads, start with Claude Opus 5". Fable 5.1 se reserva para razonamiento exigente y trabajo agéntico de largo recorrido, o para cuando tus evals con Opus 5 a effort alto se quedan cortas. Opus 5 cuesta $5 de input y $25 de output. La mitad exacta.
| Benchmark | Fable 5.1 | Fable 5 | Opus 5 |
|---|---|---|---|
| Terminal-Bench 4.0 | 55,8 % | 42,0 % | 52,3 % |
| Terminal-Bench-Science 0.1 | 52,6 % | 24,7 % | 29,0 % |
| OSWorld 2.0 (partial) | 77,9 % | 72,9 % | 75,4 % |
| OSWorld 2.0 (strict) | 41,7 % | 36,1 % | 39,6 % |
Mira Terminal-Bench 4.0: 55,8 % contra 52,3 %. Tres puntos y medio por el doble de precio. En Terminal-Bench-Science son 52,6 % contra 29,0 %, casi veinticuatro puntos, y ahí la decisión se toma sola.
La elección de modelo dejó de ser global. Se decide por tarea y con tus evals delante. Y si lo montas como router, recuerda el breaking change 2 y no cambies de modelo a mitad de conversación.
Qué es Claude Mythos 5.1 y quién puede usarlo
Claude Mythos 5.1 (claude-mythos-5-1) es el mismo modelo subyacente que Fable 5.1 con salvaguardas más permisivas. Comparte specs y precios. Solo por invitación, para participantes de Project Glasswing: organizaciones verificadas de ciberseguridad y ciencias de la vida. Con esas salvaguardas relajadas rinde más, 60,9 % en Terminal-Bench 4.0 frente al 55,8 % de Fable 5.1.
La noticia no es el modelo, es la separación. Por primera vez Anthropic distingue de forma tan explícita "el modelo que puedes usar" de "el modelo que rinde más si te verifican". Tiene lógica. Parte del rendimiento que pierde un generalista se va en negarse a cosas que en un laboratorio de biología son trabajo normal, como se veía venir en los agentes autónomos aplicados a proteínas.
Pero tenlo delante antes de comparar capturas de benchmarks: los números de un modelo con salvaguardas relajadas y los del modelo que tú puedes llamar no son comparables.
Cómo migrar de Claude Fable 5 a Fable 5.1, en 4 pasos
- Busca
tool_choiceen tu repo. Si apareceanyotool, cámbialo aautoconstrict: truey mueve la orden al prompt. Media hora. - Busca dónde reconstruyes el
systemo el array detools. Cualquiernew Date()ahí dentro es una bomba: sácalo a un mensaje de usuario o a un system message de un solo turno. - Audita tu router. Si puede cambiar de modelo a mitad de conversación, activa
thinking-binding-controls-2026-08-01en staging y mirainput_transformations. - Mide antes y después. Con el cache read a $0,25 tu arquitectura puede cambiar, pero solo si tienes el número delante.
El resto está en los docs de novedades de Fable 5.1; el trabajo de verdad está en tus evals.
Si construyes agentes con Claude y quieres el flujo completo de idea a producto, es lo que enseño en Construye con IA. Y en Dominicode Labs probamos estos patrones de historial append-only y routing por tarea sobre proyectos reales.
Una release de modelo no se mide por lo que el modelo hace mejor. Se mide por cuántas suposiciones tuyas deja de sostener.
Preguntas frecuentes
¿Tengo que migrar ya de Claude Fable 5 a Claude Fable 5.1?
No hay urgencia. Fable 5.1 no se retirará antes del 1 de septiembre de 2027. La razón para migrar es económica, no de soporte. Si tu carga es muy agéntica y relee un prefijo grande en cada turno, el cache read a $0,25 justifica la migración por sí solo.
¿Por qué Claude Fable 5.1 me devuelve un 400 con tool_choice?
Porque tool_choice: {"type": "any"} y {"type": "tool", "name": "..."} dejaron de estar soportados en Fable 5.1 y en Mythos 5.1. La API responde un invalid_request_error con el mensaje literal tool_choice: type "tool" and "any" are not supported for this model, y la misma validación se aplica al endpoint de token counting. Solo siguen siendo válidos {"type": "auto"} (el default) y {"type": "none"}. El fix es tool_choice: {"type": "auto"} con strict: true en la definición de la tool y la orden de usarla escrita en el prompt.
¿Cómo fuerzo ahora que el modelo llame a una tool concreta?
No puedes forzarla. Díselo en el prompt —"Usa la tool get_weather para responder"— y comprueba que la haya llamado antes de seguir. Sin tool_choice no hay garantía, solo una instrucción que el modelo cumple casi siempre. Si lo que necesitabas era JSON conforme a un esquema, usa strict: true con tool_choice: auto o mueve el esquema a structured outputs.
¿Por qué a mi compañero le da 400 y a mí no, con el mismo código?
Por la fecha de creación de la cuenta: la comprobación solo se aplica a las creadas a partir del 31 de agosto de 2026. En cuentas anteriores la API registra el desajuste pero no actúa salvo que mandes thinking.block_binding.prefix_mismatch_behavior. Tu código está igual de roto en ambos casos; solo cambia quién se entera.
¿Merece la pena Fable 5.1 frente a Opus 5?
Los propios docs recomiendan empezar por Opus 5, que cuesta la mitad. Fable 5.1 saca tres puntos y medio más en Terminal-Bench 4.0, pero casi veinticuatro en Terminal-Bench-Science. Si tu tarea es razonamiento exigente y agéntico de largo recorrido, la diferencia paga; para el resto, no.
¿Puedo usar Claude Mythos 5.1?
Solo si tu organización está aprobada en Project Glasswing, el programa por invitación para entidades verificadas de ciberseguridad y ciencias de la vida. No hay lista de espera pública: el acceso se pide a través de tu equipo de cuenta de Anthropic, AWS o Google Cloud. Es el mismo modelo con salvaguardas más permisivas y el mismo precio; si no estás dentro, tu referencia es Fable 5.1.
¿Puedo mezclar Claude Fable 5.1 y Opus 5 en el mismo agente?
Sí, pero no dentro de la misma conversación. Los thinking blocks de Fable 5.1 no los lee ningún modelo anterior, así que un router que salte a Opus 5 a mitad de hilo pierde ese razonamiento sin avisarte. Reparte por tarea y arranca conversación nueva al cambiar de modelo, o activa el header thinking-binding-controls-2026-08-01 para ver los descartes en input_transformations.
¿Dónde puedo usar Claude Fable 5.1?
En la API de Claude con el model ID claude-fable-5-1, en Amazon Bedrock como anthropic.claude-fable-5-1, en Google Cloud y en Microsoft Foundry, además de Claude Code, Claude Enterprise y la Claude Platform. No necesitas ningún header beta para llamarlo: los headers solo hacen falta para las funciones nuevas como el effort por mensaje o los system messages de un solo turno.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
¿Te resultó útil este artículo?
Compártelo con tu comunidad y ayuda a otros desarrolladores.