Rastrear la disponibilidad de modelos, cuando un modelo desaparece de la noche a la mañana

El 9 de junio de 2026 Anthropic lanzó Claude Fable 5, una clase por encima de Opus. El 12 de junio ya no estaba, en todo el mundo para todos, porque un control de exportación de EE. UU. bloqueó el acceso tras un jailbreak reportado. Tres días después del lanzamiento, cualquiera que hubiera clavado un flujo de trabajo a Fable se quedó con un nombre de modelo muerto y una pipeline que no devolvía nada. Fable volvió el 1 de julio, global y también en la UE, pero eso el 12 de junio no lo sabía nadie. Casi tres semanas de producción muerta, y en el momento del corte no podías saber si serían tres días, tres semanas o nunca.

No es un caso aislado, es el estado normal de 2026. Los modelos se retiran de forma planificada (Claude 4 se retiró el 15 de junio), se suspenden de la noche a la mañana, se bloquean por regiones o se les aprieta el rate limit. La pregunta no es si se te va a caer un modelo, sino cuándo. Este playbook te enseña a montarte de forma que la caída de un solo modelo no te tumbe.

1. Entender de cuántas maneras puede desaparecer un modelo

No existe solo "retirado". Cuatro casos que tienes que distinguir, porque dan distinto margen de aviso:

Deprecación planificada. El proveedor anuncia con semanas de antelación una fecha de apagado. Aquí tienes tiempo, si te enteras del anuncio. Suspensión de un día para otro. Control de exportación, disputa legal, incidente de seguridad. Cero aviso, como con Fable. Bloqueo regional. El modelo funciona, solo que no desde tu ubicación. Endurecimiento del rate limit. El modelo está, pero tu cupo de repente no alcanza. Los cuatro llevan al mismo resultado desde el punto de vista de tu flujo: la llamada falla. Solo cambia el margen de aviso.

2. Nunca clavarse a un solo modelo

Ese es el error de fondo. Un nombre de modelo escrito a fuego en un único sitio, sin plan B. Cuando ese nombre muere, tu flujo muere con él.

La forma de pensar que necesitas: un modelo es un recurso intercambiable, no una pieza fija. No construyes "con Fable", construyes "con el modelo más fuerte disponible, y ahora mismo ese es Fable". La diferencia suena académica, pero es todo el asunto. En cuanto piensas así, la caída de un modelo es un cambio, no una rotura.

3. Definir una cadena de fallback, entre proveedores

Una cadena de fallback es una lista ordenada: si el primer modelo no va, coge el segundo, luego el tercero. Lo importante es que la cadena no se quede dentro de un solo proveedor. Si un bloqueo de exportación alcanza a todos los modelos de un proveedor, un fallback a la misma casa no te sirve de nada.

Por eso una cadena robusta mezcla las casas. Por ejemplo: arriba el modelo tope que realmente quieres, debajo la clase intermedia sólida de otro proveedor, abajo del todo un modelo barato que casi siempre funciona. Así sobrevives incluso al caso de que caiga un proveedor entero. Qué clases de modelo hay en los tres grandes y para qué bastan está en la lección Panorama de modelos 2026.

4. Comprobar la disponibilidad de forma activa, no enterarte en el corte

No esperes a que se queje un cliente. La mayoría de proveedores tienen una página de estado y un endpoint que lista los modelos disponibles ahora mismo. Una simple llamada contra esa lista de modelos, una vez al día o antes de una tirada importante, te dice si tu modelo primario sigue ahí antes de que te apoyes en él.

No necesitas construir nada grande. Basta con una comprobación pequeña que recoja la lista de modelos disponibles y mire si el tuyo está dentro. Si ya no está, te enteras en tus condiciones, no en las del corte.

5. Centralizar los nombres de modelo en un solo sitio

Si tu nombre de modelo está en cinco puntos del código o en cinco herramientas distintas, un cambio se convierte en una búsqueda con margen de error. Pon la elección del modelo en un único sitio, un fichero de configuración, una variable de entorno, un campo central. Así cambiar de modelo es tocar un sitio, no cinco.

Es la misma disciplina que en Claude Code con el ajuste fallbackModel. Cómo se ve eso en concreto lo enseña el playbook Configurar modelos de fallback. Pero el principio vale en todas partes, sea cual sea la herramienta: una sola fuente de verdad para la elección del modelo.

6. Degradación elegante, mejor flojo que nada

Cuando se cae tu modelo tope, un modelo más flojo casi siempre es mejor que ninguna respuesta. Una tarea de clasificación también corre en la clase intermedia, quizá con un pelín menos de precisión. Un resumen sale algo más plano en el modelo económico, pero sale.

Por eso construye tu cadena de forma que degrade hacia abajo en vez de abortar. El término técnico es graceful degradation, degradación elegante. Para las tareas realmente duras, arquitectura de código profunda, razonamiento largo de varios pasos, puede que solo valga el modelo tope. Entonces la respuesta honesta en ese punto no es "cualquier modelo", sino "espera a que vuelva el bueno". Pero eso es la excepción, no la regla.

7. Probar el cambio antes de que arda

No quieres descubrir en un corte real si tu cadena de fallback funciona. La prueba pragmática: pon un momento como primario un nombre de modelo que no exista, o uno al que no tengas acceso, y mira si tu sistema salta limpio a la siguiente entrada de la cadena. Si va, sabes que el mecanismo entra. Después devuelves el modelo correcto.

Es un mini test de caos. Romperlo a propósito una vez, observar, enderezarlo. Cinco minutos que te ahorran una noche en vela cuando toque.

8. Vigilar coste y calidad en el fallback

Una cadena de fallback casi siempre apunta hacia abajo, del modelo tope caro al más barato. Eso está bien, en el corte sale más barato en vez de más caro. Solo cuida de no meter por descuido un modelo más caro como fallback, porque entonces justo el corte del que querías protegerte es el que más te cuesta.

Y ten en cuenta que un fallback cambia la calidad. Si tu sistema salta en silencio a un modelo más flojo y nadie se da cuenta, la salida puede ser peor durante semanas sin que lo sepas. De ahí el siguiente paso.

9. Monitorización que te avise cuando entra la cadena

Un fallback que ocurre en silencio es solo media solución. Quieres saber cuándo tu sistema ha cambiado a un modelo sustituto, sobre todo si ha caído hasta la última entrada de la cadena. Basta con un único aviso, un correo, un mensaje de Telegram, una entrada en un canal, con la información "modelo primario caído, ahora corriendo sobre el fallback X".

No lo hagas demasiado ruidoso. Si cada hipo te manda un mensaje, a los tres días dejas de mirarlo. Avisa del caso que de verdad cuenta: la cadena está en el último modelo, o el modelo tope lleva horas caído. El principio es el mismo que el de las alertas para automatizaciones, descrito en la lección Cuando fallan las automatizaciones.

10. Cuándo nada de esto te afecta

El cierre honesto. Si solo usas IA de vez en cuando en una ventana de chat y no tienes una pipeline que deba seguir corriendo, no necesitas cadena de fallback. Si se cae tu modelo, coges otro a mano y ya. Todo este esfuerzo compensa solo cuando algo corre automáticamente y no puede pararse, un agente, un flujo, un servicio para otros.

Pero ese es justo el umbral entre usuario de IA y operador de IA. Un usuario nota el corte y espera. Un operador ha previsto y apenas lo nota. Cuándo compensa siquiera la clase tope cara y cuándo basta la intermedia lo profundiza el playbook Clase Mythos, cuándo compensa.

Fuentes

• Claude Fable 5: lanzamiento (09/06/2026), suspensión mundial por control de exportación de EE. UU. (12/06/2026), levantamiento y vuelta global incluida la UE (01/07/2026): la lección del panorama de modelos documenta la secuencia, anuncios de Anthropic en https://www.anthropic.com/news
• Resumen de modelos de Claude y avisos de deprecación: https://platform.claude.com/docs/en/about-claude/models/overview
• Notas de lanzamiento y retirada de modelos de OpenAI: https://help.openai.com/en/articles/9624314-model-release-notes
• Resumen de modelos de Gemini: https://ai.google.dev/gemini-api/docs/models

Los nombres de modelo y su disponibilidad cambian rápido. Si lees esto meses después, comprueba el estado actual en los enlaces de arriba.