Claude Fable 5: qué cambia para automatizar con IA

Respuesta corta: Claude Fable 5 volvió. Es el modelo más capaz de Anthropic para razonamiento exigente y trabajo agéntico de largo alcance, con 1 millón de tokens de contexto y precio de $10 por millón de tokens de entrada y $50 de salida. Si automatizás servicios o bots con IA, el cambio que de verdad te toca no es el hype: Fable 5 ahora incluye clasificadores de seguridad que pueden rechazar pedidos, y ese rechazo llega como una respuesta exitosa (HTTP 200), no como error. Prepará tu integración para manejar tres cosas: refusals, fallback a otro modelo y las nuevas reglas de billing.

Qué es Claude Fable 5 (y Mythos 5) y por qué volvió

Claude Fable 5 es, según Anthropic, su modelo más capaz de disponibilidad amplia: pensado para el razonamiento más exigente y para tareas agénticas de largo alcance —esas donde el modelo tiene que sostener un plan a lo largo de muchos pasos sin perder el hilo.

Su acceso estuvo cortado y hace poco fue restaurado. Anthropic publicó un comunicado oficial sobre el redespliegue de Fable 5 y Mythos 5; los motivos exactos del corte y de la vuelta están en ese texto. Lo concreto para vos como desarrollador es que hoy volvió a estar disponible de forma general.

Junto con Fable 5 aparece Claude Mythos 5, que comparte exactamente las mismas capacidades pero sin los clasificadores de seguridad. Mythos 5 no es de acceso general: se ofrece en disponibilidad limitada a clientes aprobados dentro de Project Glasswing. Si no tenés acceso a Mythos 5, usás Fable 5, que ofrece las mismas capacidades.

Specs que importan si automatizás

Fable 5 y Mythos 5 comparten specs y precio. Lo que a mí me interesa cuando armo un bot o un servicio automático:

• Contexto de 1M de tokens por defecto y hasta 128k tokens de salida por request. Podés meterle documentos enteros, historiales largos o bases de conocimiento sin fragmentar tanto.
• Precio: $10 por millón de tokens de entrada y $50 por millón de salida. En automatizaciones que corren solas, esto multiplicado por volumen importa: conviene medirlo antes de soltarlo en producción.
• Adaptive thinking siempre activo: es el único modo de razonamiento. No podés desactivarlo (thinking: disabled no está soportado); la profundidad se controla con el parámetro effort, que también regula el costo.
• El razonamiento crudo nunca se devuelve: obtenés un resumen del razonamiento o directamente nada, según thinking.display. En conversaciones multi-turno hay que reenviar los bloques de thinking sin tocarlos.

Para trabajo agéntico también trae soporte de effort, task budgets (en beta), memory tool, ejecución de código y llamadas a herramientas programáticas. Es, en resumen, un modelo diseñado para agentes, no solo para chat.

El cambio grande para bots: los refusals

Acá está el punto que más me importa y por el que escribo este post. Fable 5 incluye clasificadores de seguridad que pueden rechazar ciertos pedidos. Y el detalle técnico es el que te puede romper una automatización si no lo tenés en cuenta:

Cuando Fable 5 rechaza un pedido, la Messages API devuelve stop_reason: "refusal" como una respuesta exitosa HTTP 200, no como un error. Además te informa qué clasificador lo rechazó. Mythos 5 no tiene estos clasificadores, así que esto aplica solo a Fable 5.

¿Por qué es un problema si automatizás? Porque el reflejo típico al integrar una API es: "si el status es 200, salió bien, sigo". Con Fable 5 ese supuesto se rompe. Un 200 puede ser un rechazo, y si tu bot lo trata como éxito, publica una respuesta vacía, guarda basura o rompe el flujo silenciosamente. Hay que leer el stop_reason, no solo el código HTTP.

Cómo no romper tu automatización: fallback y billing

La buena noticia es que un pedido que Fable 5 rechaza normalmente lo puede atender otro modelo de Claude. Hay tres formas de reintentar:

• Server-side: le pasás el parámetro fallbacks y la API reintenta por vos (en beta en la Claude API y en la plataforma de AWS).
• Client-side: usás el middleware del SDK (TypeScript, Python, Go, Java y C#) para reintentar desde el cliente en cualquier plataforma.
• Manual: te armás el reintento vos mismo, en cualquier lenguaje.

Y lo de billing es más justo de lo que esperaba: no te cobran un pedido que se rechaza antes de generar output. Cuando reintentás en otro modelo, el fallback credit te reembolsa el costo de prompt-cache del cambio, así no pagás dos veces por lo mismo. Si querés el ejemplo completo de punta a punta, Anthropic publicó un cookbook de refusals, fallback y billing.

Cómo lo estoy encarando en mis automatizaciones

Uso IA en casi todas las plataformas donde trabajo para automatizar servicios y bots, así que esto no es teoría para mí. Dos ejemplos reales míos que hoy corren sobre Google Gemini:

• Un bot diario que predice el estado del sargazo en la Riviera Maya, combinando Gemini, datos climáticos y un modelo Random Forest con ~80% de acierto.
• Mi resumen tech semanal, que se genera y publica solo con un pipeline automatizado (GitHub Actions + RSS + IA).

El problema que veo con Fable 5: si mañana migrara el generador de noticias a Fable 5, un stop_reason: "refusal" que mi código tratara como éxito publicaría un post vacío o a medias, sin que nadie se entere hasta que sale al aire.

Qué hago: el patrón que aplico es chequear el stop_reason antes de usar la respuesta, y tener un fallback a otro modelo listo. En pseudo-código de una automatización en Node:

const res = await client.messages.create({
  model: 'claude-fable-5',
  messages,
});

// Un 200 no garantiza contenido usable: puede ser un rechazo.
if (res.stop_reason === 'refusal') {
  // No lo trato como error de red. Reintento en otro modelo.
  return generarCon('claude-sonnet-5', messages);
}

publicar(res);

Qué haría distinto: antes armaba estos flujos asumiendo que un 200 era contenido bueno y validaba solo "que no esté vacío". Con Fable 5 el chequeo tiene que ser explícito sobre el motivo de corte. Un detalle más que no ignoraría: Fable 5 y Mythos 5 tienen retención de datos de 30 días y no admiten zero data retention, así que para automatizaciones con datos sensibles hay que tenerlo en la cuenta.

Preguntas frecuentes

¿Qué diferencia hay entre Claude Fable 5 y Claude Mythos 5?

Comparten capacidades, contexto de 1M de tokens y precio. La diferencia es que Fable 5 incluye clasificadores de seguridad que pueden rechazar pedidos y Mythos 5 no. Además, Mythos 5 solo está disponible en acceso limitado a través de Project Glasswing.

¿Un rechazo de Claude Fable 5 cuenta como error?

No. Cuando Fable 5 rechaza un pedido, la Messages API devuelve stop_reason: "refusal" como una respuesta exitosa HTTP 200, no como error. Tu integración tiene que detectar ese caso y no tratarlo como un fallo de red.

¿Me cobran si el modelo rechaza mi pedido?

No, si el pedido se rechaza antes de generar cualquier output no se factura. Y si reintentás en otro modelo, el fallback credit reembolsa el costo de prompt-cache del cambio para que no lo pagues dos veces.

¿Puedo desactivar el modo de razonamiento en Fable 5?

No. El adaptive thinking siempre está activo y thinking: disabled no está soportado. Controlás la profundidad y el costo con el parámetro effort. Además, el razonamiento crudo nunca se devuelve: solo un resumen u omitido.

¿Sirve Claude Fable 5 para automatizar bots y servicios?

Sí, es el modelo más capaz de Anthropic para trabajo agéntico de largo alcance, con contexto de 1M de tokens. Pero si automatizás, tu integración debe manejar refusals y tener un fallback a otro modelo para que un rechazo no rompa el flujo.

Para cerrar

Que Fable 5 haya vuelto es una gran noticia si trabajás con agentes: tenés el modelo más capaz de Anthropic con 1M de contexto. Pero la letra chica —refusals que llegan como 200, fallback y billing— es justo lo que separa una automatización que aguanta producción de una que se rompe callada un domingo a la madrugada.

Si estás montando bots o servicios con IA y querés que no se caigan ante un rechazo, escribime y lo vemos juntos.