Vercel habilitó Claude Fable 5.1 en su AI Gateway, el mismo día que Anthropic presentó Fable 5.1 y Mythos 5.1. Fable queda disponible de forma general y Mythos sigue restringido a socios de confianza, con salvaguardas específicas de ciberseguridad y ciencias de la vida. El detalle que más me interesa no está en las mejoras de rendimiento: está en un párrafo operativo del changelog.
Por qué importa
Vercel lo dice sin vueltas: Anthropic envía Fable 5.1 con clasificadores de seguridad de ciberseguridad y biología activados, y aunque encontrar vulnerabilidades en código fuente está permitido, parte del trabajo rutinario de programar y debuggear todavía puede ser rechazado. Eso no es una nota al pie. Es un cambio en el modelo de fallas de tu integración.
Hasta ahora, cuando pensabas resiliencia frente a un proveedor de LLM, pensabas en timeouts, rate limits y errores 5xx: fallas transitorias, con retry y backoff. Un rechazo por clasificador no es eso. Es una respuesta legítima del proveedor, no determinista respecto de tu input, y reintentar el mismo pedido al mismo modelo no la arregla. Si tu pipeline trata todo lo que no es 200 como "error temporal", vas a ver reintentos infinitos y trabajo agéntico que se cuelga a mitad de camino.
Hay un segundo dato que ordena la foto. Según el resumen de Hipertextual sobre el anuncio, Fable 5.1 y Mythos 5.1 son exactamente el mismo modelo: lo que cambia entre uno y otro son las salvaguardas. La capacidad no se recorta, se recorta la superficie de lo que responde. Para quien integra, eso significa que el comportamiento que vas a ver no depende solo del prompt, sino de una capa de política que el proveedor puede mover sin que cambie el identificador del modelo.
Qué cambia en la práctica
La respuesta que propone Vercel es declarar fallbacks a nivel de gateway. Se agrega un array models dentro de providerOptions.gateway con los modelos a intentar: el Gateway manda primero a Fable 5.1 y, si Anthropic lo rechaza, recorre el array en orden y devuelve la respuesta del primero que responda. Funciona en todos los formatos de API del Gateway: Chat Completions, Messages y OpenAI Responses.
{
"model": "anthropic/claude-fable-5.1",
"providerOptions": {
"gateway": {
"models": [ /* Opus 5, luego Sonnet 5 */ ]
}
}
}El ejemplo del changelog cae a Opus 5 y después a Sonnet 5. Los identificadores exactos conviene tomarlos del listado de modelos del Gateway, no de un post: acá lo importante es la forma, no el string.
┌───────────────┐
│ Tu request │
└───────┬───────┘
│
▼
┌───────────────────────────┐
│ AI Gateway │
│ models: [A, B] │
└───────┬───────────────────┘
│ 1) Fable 5.1
▼
¿clasificador rechaza?
│ no │ sí
▼ ▼
respuesta 2) Opus 5
│ ¿rechaza?
▼
3) Sonnet 5 ─► primera OKEsto tiene consecuencias que no aparecen en el snippet. La primera es de observabilidad: si el modelo que responde puede no ser el que pediste, tu telemetría tiene que registrar cuál respondió efectivamente, en cada llamada. Sin eso, cualquier análisis posterior de calidad o de costo está mezclando poblaciones distintas. La segunda es de evaluación: tus evals dejan de correr contra un modelo y pasan a correr contra una cadena. Si el fallback no pasa tus tests, no es un fallback, es una bomba de tiempo.
La tercera es de costos. Según Anthropic, Fable 5.1 alcanza resultados iguales o mejores que Fable 5 incluso con niveles de esfuerzo bajo o medio, porque evita atajos que degradaban el resultado final. Si eso se sostiene en tu carga real, la palanca no es solo el modelo: es el nivel de esfuerzo. Vale medirlo antes de asumir que hay que ir siempre al máximo.
Para agentes, el camino que documenta Vercel es correr vercel ai-gateway coding-agents setup y seleccionar anthropic/claude-fable-5.1 dentro del agente, con soporte para Claude Code, Codex, OpenCode, Cursor y Pi.
Cuándo NO usarlo
El bloqueante más duro no es técnico. Anthropic no soporta Zero Data Retention para Fable 5.1: prompts y completions se retienen 30 días, aunque no se usen para entrenar. Si trabajás con un cliente que firmó no retención, o con datos regulados, esa línea sola te saca el modelo de la mesa. No hay configuración del lado del Gateway que lo compense.
| Escenario | Fable 5.1 hoy |
|---|---|
| Agente largo, multi-etapa, con búsquedas encadenadas | Es donde la nota ubica la mejora. Sí, con fallbacks declarados. |
| Análisis de vulnerabilidades en código propio | Permitido explícitamente por Anthropic. |
| Debug y refactor rutinario en CI | Riesgoso: el clasificador puede rechazar sin previo aviso. |
| Datos bajo contrato de no retención | No. No hay ZDR y hay 30 días de retención. |
| Prompt corto, de una sola pasada | Poco que ganar; la mejora está concentrada en trabajo largo. |
Tampoco pondría fallbacks silenciosos en flujos con salida estructurada estricta. Si un contrato de tipos o un formato de tool call depende de un modelo puntual, degradar a otro sin avisar te cambia el output en producción y lo vas a descubrir por un bug de datos, no por una alerta. Ahí prefiero fallar explícito y encolar el pedido.
Y una advertencia sobre el entusiasmo: el material disponible describe mejoras en programación, investigación científica agéntica y flujos empresariales, pero no publica números que yo pueda verificar acá. Migrar por confianza en un anuncio no es una decisión de ingeniería.
Qué haría hoy
Lo pondría detrás del Gateway solo en el trabajo agéntico largo, con el array de fallbacks configurado desde el día uno y con logs del modelo que respondió realmente. Dejaría los pipelines cortos donde están hasta tener una medición propia. Y antes de cualquier cosa, revisaría el contrato de retención con el cliente: en muchos proyectos, ese chequeo termina la discusión antes de que empiece.