El domingo 2 de agosto a las 17:15, mi sistema de 61 agentes recibió el primer golpe. Un error seco en el log: HTTP 402: Insufficient Balance. Para la madrugada del lunes, cuatro crons estaban muertos, dos de ellos el que publica este mismo artículo. El responsable de todo: un saldo de -$0.04 USD en mi cuenta de DeepSeek.
Cuatro centavos. Menos de lo que cuesta un caramelo. Y sin embargo tuvieron el sistema LLM entero de rodillas durante más de 24 horas.
La cadena, minuto a minuto
Así se ve la cascada desde errors.log, con las horas reales:
- 17:15 — Primer 402. Cae el cron de aprendizaje profundo (
Knowledge Acquisition), que es de los que más tokens consume. - 17:21 — Cae su verificador,
Post-Learning Verifier. El sistema pierde su capacidad de aprender de lo que ejecuta. - 19:10 — Le toca al EEAT Publisher, el cron que publica un artículo de experiencia propia cada noche. Intenta tres veces, rebota contra el 402, muere a las 19:18.
- 22:22 — Cae
obsidian-nightly, la consolidación nocturna de mi segundo cerebro en Obsidian. - 03:17 y 03:32 del lunes — El EEAT se reprograma dos veces y vuelve a morir. Mismo error.
Quince errores Insufficient Balance registrados en dos días, y decenas de respuestas vacías (response.choices is None) mientras el sistema intentaba pensar con un proveedor que no le dejaba.
Lo interesante no es el 402. Es lo que pasó cuando el sistema intentó salvarse solo.
El fallback también estaba herido
Mi configuración tiene un proveedor de respaldo: cuando DeepSeek falla, los crons saltan a OpenRouter con un modelo gratuito. Sobre el papel, la caída habría sido invisible para el usuario.
En la práctica, OpenRouter devolvía 500s upstream y el health check lo marcó como unhealthy por "payment/credit error". Es decir: mi cuenta principal estaba en negativo y mi respaldo tenía sus propios créditos agotados. Dos billeteras vacías la misma semana, y yo sin mirar ninguna de las dos.
Ya había habido un aviso. El 27 de julio, OpenRouter me devolvió un 402 con un mensaje que ahora me da vergüenza no haber leído despacio: "can only afford 11310 tokens". Me quedaban once mil tokens. Lo traté como ruido transitorio porque el sistema se recuperó. El sistema no se recuperó: yo no me enteré de que la billetera estaba casi vacía.
Lo que el auto-reparador hizo bien
Tengo un cron de auto-reparación que corre cada hora, revisa logs, diagnostica y aplica fixes. La semana pasada escribí sobre él, y me hace gracia contar que esta vez se portó mejor que yo.
Primero: identificó la causa raíz como evento de billing, no como fallo técnico. Verificó el saldo por API directa y reportó el número exacto: -$0.04.
Segundo: no reintentó los crons muertos. Un 402 por saldo negativo no es un error transitorio. Reintentar solo habría quemado tokens del fallback para obtener el mismo fallo. El auto-reparador lo tiene ahora como regla documentada: 402 Insufficient Balance = notificar al humano, nunca re-run ni migración automática de provider.
Tercero: aprovechó la caída para arreglar cosas que sí podía arreglar. Encontró que el módulo de visión mandaba una clave de Z.ai a api.openai.com (401 garantizado), que una línea sin comillas en mi .env rompía el parseo de variables, y que el prompt del EEAT Publisher apuntaba a un script con una ruta rota. Tres fixes reales mientras el proveedor principal seguía caído.
Lo que el auto-reparador no puede hacer
Pagar.
Hay una frontera que ningún sistema autónomo cruza: la capa de dinero. El agente puede diagnosticar, reparar, degradar, avisar. Pero recargar saldo en DeepSeek requiere una tarjeta, una cuenta, una decisión humana. Así que el sistema entero quedó en pausa a la espera de que yo hiciera un clic en platform.deepseek.com.
Y eso está bien. Yo no quiero un agente con acceso libre a mi tarjeta para auto-recargar APIs a las 3 de la mañana. Pero entonces la responsabilidad es mía: si el dinero es el single point of failure, el monitoreo del dinero tiene que ser mejor que el de cualquier otra cosa.
Y no lo era. Yo monitoreaba disco, DNS, caché de Cloudflare, cookies de sesión, sitemap. Tenía siete watchdogs distintos. Ninguno miraba el saldo de las APIs. El recurso que más veces me dejó tirado era el único que nadie vigilaba.
El watchdog que construí después
Ahora hay un octavo. Se llama deepseek-balance-watchdog.py, corre cada 6 horas, no usa ningún LLM, y hace exactamente una cosa:
GET https://api.deepseek.com/user/balance Authorization: Bearer $DEEPSEEK_API_KEY saldo < 0 → alerta roja: "TODOS los crons LLM van a fallar" saldo < $1.00 → aviso: "recargar pronto" saldo >= $1.00 → silencio total
Cuarenta líneas de Python. Sin dependencias raras, sin reintentos agresivos, sin LLM. Guarda el último saldo en un archivo de estado para poder decir "ayer tenías $X, hoy tienes $Y" y detectar el drenaje antes de llegar a cero.
El umbral de un dólar no es arbitrario. Con mi consumo actual (unos $5 al mes para 25 crons con LLM), un dólar da para seis días. Suficiente para que me llegue el aviso mientras duermo, me despierte, recargue, y ningún cron diario se pierda.
Lo que me llevo de esta caída
Uno. El billing se monitorea igual que el disco. Un watchdog de saldo es más barato que un solo cron muerto, y el mío costó cuarenta líneas de código. Si tu sistema depende de una API de pago y no consultas su saldo al menos una vez al día, tu sistema tiene un fallo garantizado con fecha: la fecha en que se agote el saldo.
Dos. Los fallbacks también necesitan salud propia. Un proveedor de respaldo que nadie comprueba no es un respaldo, es decoración. Mi OpenRouter llevaba días diciendo que no tenía créditos y yo lo trataba como si fuera infinito.
Tres. Un 402 es una señal para humanos, no para máquinas. La respuesta correcta no es reintentar ni cambiar de proveedor en caliente: es avisar al dueño. Cualquier otra cosa solo gasta más.
El sistema ya está corriendo de nuevo, esta vez sobre un proveedor distinto mientras recargo DeepSeek. Los crons de esta noche deberían salir limpios. Y si el saldo alguna vez vuelve a acercarse a cero, el nuevo watchdog avisará seis horas antes de que pase nada. Esta vez sí.