Mazinger OS · disponibilidad del agente

Cadena de fallback de LLM

Cinco escalones encadenados para que ningún mensaje se pierda por una credencial vencida, una cuota agotada o un proveedor caído. Con el mapa de a quién se le avisa y en qué situación.

23-jul-2026

La tesis

El problema no es que falte un plan B. Es que el plan B llega tarde.

Hoy, cuando una corrida falla, el sistema marca el motor como caído y lanza el error igual. El mensaje del usuario muere. El siguiente sale bien, pero ese ya se perdió. Con seis escalones y esa mecánica, cada transición sigue costando un mensaje.

La pieza que falta no son más motores: es reintentar el mismo pedido en el escalón siguiente, sin que el usuario se entere. Todo lo demás de esta página existe para que ese reintento sea seguro, barato y automático.

Cómo leer la página

Leyenda

Suscripción
Coste 0 por token. Login OAuth.
API de pago
Factura por token. Depende de crédito.
Caído
Fuera de servicio.
Aviso
Dispara WhatsApp a los admins.

El recorrido

Los escalones

Ordenados de más barato a más caro. La cadena arranca siempre en el escalón sano más alto y baja solo lo necesario. Los cuatro primeros son Anthropic; el último sale de Anthropic y por eso está dibujado aparte.

suscripción 0 Suscripción Claude login OAuth en disco · es el camino por defecto de hoy avisa sesión vencida o rota cuota semanal agotada por token 1 API key 1 la key eclipsa al login OAuth · misma calidad, con factura avisa se quedó sin crédito o la key fue revocada por token 2 API key 2 igual que la key 1, pero siempre de OTRA organización avisa también sin crédito suscripción 3 Suscripción de respaldo 2ª suscripción, de otra organización mail y token de un login previo, inyectados solos avisa la de respaldo también vencida acá se termina Anthropic fuera de Anthropic 4 Proxy de traducción un endpoint, y por detrás el motor que quieras OpenAI Gemini MiniMax Otro proveedor se agregan y se reordenan en la configuración del proxy, sin tocar Mazinger avisa fallan todos Cadena agotada alerta grave a los 4 admins + se le dice al usuario qué pedido se perdió 529 sostenido: el corto saltea los cuatro entra directo acá Anthropic · calidad completa
La escalera. Se baja un escalón solo cuando el de arriba se declara muerto, y cada bajada dispara un aviso. Los cuatro primeros comparten proveedor: si Anthropic se cae, se caen juntos. Cruzada la línea punteada empieza otro terreno, y por eso el escalón 4 está dibujado aparte. Si tampoco responde, el sistema no inventa: dice exactamente qué pedido se perdió.
EscalónCómo se activaQué hay que saber
0 · SuscripciónQuitando ANTHROPIC_API_KEY del entorno del subprocesoCuenta Max 20x. Es el camino por defecto de hoy
1 · API key 1Seteando ANTHROPIC_API_KEYLa key eclipsa al login OAuth: es el mecanismo que ya usa el fallback actual
2 · API key 2Igual que la key 1, con la segunda claveSiempre de otra organización de Anthropic: así no comparte el pool de rate limit y no cae junto con la key 1
3 · RespaldoDirectorio propio (CLAUDE_CONFIG_DIR) con el mail y el token de un login previo, inyectados de forma automáticaEs una segunda suscripción, también de otra organización. No hay paso manual: la credencial se inyecta sola. Cada suscripción vive en un solo lugar, así no se desloguean entre sí al rotar
4 · ProxyANTHROPIC_BASE_URL al proxy, solo en ese subprocesoUn solo escalón que por detrás prueba varios proveedores, en el orden que definas. Agregar uno nuevo no toca el código de Mazinger
Los cuatro primeros son el mismo proveedor. Escalones 0 a 3 son toda infraestructura de Anthropic: una saturación del proveedor se los lleva a los cuatro a la vez. Por eso la cadena tiene un atajo, el corto de proveedor, que en ese caso los saltea enteros en vez de recorrerlos uno por uno perdiendo tiempo. Meter Claude vía Bedrock o Vertex daría un escalón de igual calidad con infraestructura independiente; queda como decisión consciente de no hacerlo por ahora.

Los dos últimos escalones

Cómo entra cualquier otro proveedor

El truco que hace posible todo esto es que el agente habla un idioma, el de Anthropic, y hay una pieza que traduce ese idioma a cualquier otro proveedor. Así se agregan motores sin tocar código ni agente cuando se requiera switchear.

El agente habla siempre el mismo idioma: el de Anthropic escalón 4 Proxy de traducción traduce y reparte, en orden OpenAI · GPT Gemini MiniMax Otro proveedor el orden lo decidís vos: primero el mejor, o primero el más barato si uno falla, el proxy prueba el siguiente solo y Mazinger ni se entera
Un escalón, muchos motores. El proxy concentra a todos los proveedores alternativos en un solo escalón de la cadena, y por eso sumar uno nuevo cuesta una línea de configuración en vez de un despliegue. Los reintentos entre proveedores ocurren dentro del proxy: para Mazinger todo eso es un único escalón que responde o no responde.
Por qué esto además desbloquea a OpenAI y Gemini. El obstáculo no era el proveedor, era el binario. Cambiar de motor ejecutable significa otro almacén de conversaciones, y como el sistema guarda un único identificador de sesión por conversación, el usuario perdería el hilo en silencio. El proxy esquiva el problema entero: es el mismo binario de siempre, solo apuntando a otra dirección. El historial sigue siendo un archivo local y la conversación sigue viva. Por eso GPT y Gemini entran por acá y no por un motor aparte.
PiezaDónde viveQué pasa si se cae
Escalones 0 a 3AnthropicEl corto los saltea de una y entra al escalón 4
Un proveedor dentro del proxyOpenAI, Gemini, MiniMax…El proxy prueba el siguiente de su lista, sin que Mazinger intervenga
Escalón 4, el proxyUn proceso propio, en el mismo servidorCadena agotada: alerta grave y aviso del pedido perdido

El proxy corre como un proceso más del servidor, con el mismo gestor que levanta a los demás, así que si se cae se reinicia solo. Y no agrega un punto único de fallo nuevo: si el servidor muere, ya murió todo lo demás.

El mecanismo

Cómo se pasa de un escalón al siguiente

No todo error hace bajar un escalón, y algunos no deberían hacer bajar ninguno. La cadena hace una pregunta a la vez, de arriba hacia abajo: la primera que responde «sí» decide qué hacer, sin ramas que seguir.

El escalón falló se hace una pregunta a la vez, de arriba hacia abajo ¿Fue un tropiezo del proveedor? timeout · 500 · 529 sí Reintentá acá mismo un 529 dura segundos y suele pasar si no cede en 60 s Salta directo al proxy el corto saltea el resto de Anthropic no ¿Se quedó sin credencial válida? 401 · sin crédito · cuota llena sí Bajá al escalón siguiente y avisá solo si es seguro reintentar: coste $0 no Caso de borde: el pedido en sí está mal (400, prompt larguísimo). Se falla sin recorrer la cadena. Con mensajes cortos casi nunca pasa. «Sin crédito» no entra acá: cuenta como credencial caída.
Se lee como un triage. La primera pregunta que responde «sí» decide. Un tropiezo se reintenta en el escalón y, si no cede en 60 s, salta directo al proxy (esa caja). Una credencial caída baja al escalón siguiente. El tercer caso casi no ocurre: nota al pie.
El 429 y el 529 parecen primos, pero piden lo contrario. El 429 es un límite tuyo, de esa credencial: bajar a otra key o a otra cuenta te da una cuota nueva y resuelve. El 529 es una señal global de que Anthropic está saturado; la suscripción, las dos keys y la cuenta de respaldo pegan todas contra la misma capacidad, así que bajar escalones no cambia nada. Por eso el 529 es el único error que justifica saltar directo a otro proveedor. Y es también el motivo por el que la espera tiene que ser aleatorizada: si todos reintentan a la vez, alimentan la misma saturación que están esperando que pase.
El detalle que hay que acertar. "Sin crédito" llega como un 400, igual que un pedido mal formado. Si se clasificara solo por el código HTTP, una key sin saldo se trataría como pedido inválido y la cadena no bajaría: el usuario se quedaría sin respuesta con cuatro escalones sanos al lado. Por eso el orden de evaluación mira primero cuota y credencial, y el pedido malo al final. El detector de cuota que ya existe en el repo reconoce el texto "credit balance is too low", así que esa pieza ya está resuelta.

Cuando el problema es el proveedor

El corto de proveedor

Si Anthropic está saturado, recorrer sus cuatro escalones antes de llegar a otro proveedor es latencia regalada: los cuatro van a fallar igual. El corto los saltea de una y se cierra solo cuando el proveedor vuelve.

Todo por Anthropic operación normal arranca en el escalón 0 Anthropic salteado el corto está activado va directo al proxy (escalón 4) Probando si volvió deja pasar un pedido de prueba a Anthropic 529 sostenido 60 s o 5 fallos seguidos del proveedor tras enfriarse 60 s la prueba anduvo: vuelve todo a Anthropic la prueba falló: se enfría otra vez El contador es por ventana de tiempo y se resetea solo: fallos sueltos a lo largo del día no acumulan hasta abrir el corto por error. Solo cuentan errores del proveedor. Un 401 o un «sin crédito» nunca abren el corto: son de esa credencial, no de Anthropic.
Lo importante es el tercer estado, el que prueba si Anthropic ya volvió. Sin él, el sistema seguiría respondiendo desde afuera mucho después de que el proveedor se recuperó, porque nadie se anima a volver a probar. Con él, la vuelta a la normalidad es automática y cuesta un solo pedido de prueba.
Por qué el umbral no es "el primer 529". La mayoría de los episodios de saturación se resuelven en unos 30 segundos, y para eso ya está el reintento dentro del mismo escalón. Abrir el corto al primer error empujaría a todo el mundo fuera de Anthropic por un simple hipo. El disparo a los 60 segundos es el punto donde deja de ser un hipo y pasa a ser una caída.
La regresión que hay que blindar. El corto no debe abrirse con fallos de credencial. Una sesión OAuth muerta con cuatro escalones sanos detrás no es una caída de Anthropic: si eso abriera el corto, el sistema saltaría a otro proveedor sin ninguna necesidad. Un 401 nunca es señal de que el proveedor esté caído.

Los eslabones como conjunto

Qué cubre cada uno, y qué solo cubre el conjunto

Cada escalón tapa un modo de fallo distinto. Ninguno solo alcanza; encadenados, cubren todo el espectro salvo una caída total del proveedor.

Modo de falloQuién lo tapaQué pasaba antes
Sesión OAuth vencida o rotaAPI key 1Caída total hasta reinyectar a mano (18 min el 22-jul)
Cuota semanal de la suscripción agotadaAPI key 1Ya cubierto por el fallback actual
API key sin créditoAPI key 2Sin red: fallo directo al usuario
Las dos keys sin créditoSuscripción de respaldoSin red
Las dos suscripciones vencidasEl proxy, con el proveedor que definasSin red
Pico transitorio de Anthropic (529)Reintento aleatorizado en el mismo escalónSe perdía el mensaje
Saturación sostenida de AnthropicEl corto saltea 0 a 3 y entra al proxy de unaSin red, y recorriendo escalones inútiles
Un proveedor alternativo caídoEl proxy prueba el siguiente de su lista, soloSin red
Degradación crónica sin caída visibleAlerta por tasa si el respaldo pasa del 5% del tráficoInvisible: la factura subía sin que nadie lo notara

Estado actual, sin cambios

Qué se avisa, y qué llega al teléfono

Todo aviso del sistema termina en el mismo lugar: un WhatsApp a cuatro personas. No hay filtros ni destinatarios por tipo de aviso: los cuatro reciben todo.

LA SITUACIÓN · EJEMPLOS LAS 4 PERSONAS Se gasta la cuota Se cae la sesión de Claude El agente no responde Se cae un escalón Una suscripción por vencer Un solo WhatsApp sin filtros por tipo los 4 reciben todo Nicolás Middi 5491132439048 Bautista Priano 5492235712000 Germán Middi 5491138175235 Mario Chueca 34648077232
Una sola vía, cuatro teléfonos. Cualquiera de estas situaciones, y varias más, produce el mismo WhatsApp a las mismas cuatro personas. No hay ruteo por tipo ni por persona: el mensaje sale una vez y llega a los cuatro. La lista de la izquierda es una muestra; el detalle completo está en la tabla de abajo.

Qué situación dispara cada aviso

SituaciónQué dice el mensajeSe repite
Se está gastando la cuota
al 80%, 90% y 95%		 Avisa el porcentaje de uso y la hora a la que se renueva. Aclara que al 99% se cambia solo a modo API para que nada falle Una vez por cada escalón
Se agotó la cuota
al 99%		 Avisa que se cambió automáticamente a modo API: los mensajes siguen saliendo, ahora con coste por token Una vez, al cambiar
Se cayó la sesión de Claude
y el modo API la cubre		 Avisa que la sesión caducó, que ya activó el modo API solo, y dice qué hay que hacer: rehacer el login en el servidor. Aclara que mientras tanto se factura por consumo Con espera entre avisos
El agente no responde
falló la sesión y también la API		 El más grave: avisa que los mensajes de los usuarios están quedando sin respuesta, y da los dos pasos a revisar (crédito de la clave, y rehacer el login) Con espera entre avisos
Se quedó sin tokens en pleno uso Avisa la hora y el error concreto, y advierte que mensajes, tareas programadas y jobs van a seguir fallando hasta renovar la cuota Máximo uno cada 30 min
Volvió la normalidad Avisa que la cuota se renovó y que se volvió al modo suscripción, sin coste por token Una vez, al volver
Los mensajes están escritos para actuar, no para informar. Los dos avisos de sesión caída incluyen el comando exacto a ejecutar en el servidor. Esa es la diferencia entre un aviso que se lee y uno que se resuelve.

Qué avisos suma la cadena

Situación nuevaQué diría el mensaje
Se cayó un escalón y otro lo reemplazóCuál se cayó, por qué, y cuál está sirviendo ahora. El usuario no se enteró de nada
Anthropic está saturadoQue se saltearon los cuatro escalones de Anthropic y se está sirviendo desde otro proveedor
Sirviendo desde fuera de AnthropicCon qué proveedor se está respondiendo mientras dure
Una suscripción está por vencerCuál, y qué día caduca. Llega a los 7, 3 y 1 día, para que renovarla sea una tarea agendada y no una urgencia
El plan B trabaja de másQue un escalón de respaldo pasó del 5% del tráfico en 24 h: hay algo roto arriba aunque nada se haya caído
Se está facturando por APIQue el modo API sigue activo, con el gasto acumulado. Recordatorio cada 24 h
No respondió ningún escalónLa más grave: se agotó la cadena entera y hay pedidos de usuario perdidos
El punto débil de todo esto. Los avisos viajan por el mismo WhatsApp que usa el sistema para trabajar. Si se cae el servidor, no sale ningún aviso: el 26-jun, cuando un proceso desbocado tumbó la máquina, era imposible avisar. Queda un rastro escrito en el servidor, pero nadie lo mira en el momento. Hace falta un aviso por una vía que no dependa de Mazinger.