exceeded retry limit, last status: 429 Too Many Requests significa que Codex recibió 429 en varios reintentos automáticos y finalmente detuvo el trabajo. No significa por sí solo que se haya agotado tu porcentaje semanal, que falte dinero en la API o que exista una caída general de OpenAI.
Antes de pulsar otra vez, conserva los archivos ya modificados y detén nuevos subagents o tareas paralelas. Anota el error completo, hora y zona horaria, y el request ID si aparece. La pregunta que permite recuperar el trabajo no es “¿cuántos minutos espero?”, sino “¿qué cuenta, proyecto, workspace o proveedor era dueño de esta petición?”.
El límite de reintentos pertenece al cliente
Las dos partes del mensaje proceden de capas distintas:
retry limites el máximo de intentos automáticos que hizo el cliente Codex;last status: 429es el último estado HTTP devuelto por un servidor o gateway.
El 429 todavía no identifica una causa única. La guía vigente de errores de OpenAI API separa límite de velocidad de peticiones, créditos prepago agotados, spend limit de organization/project y organization usage limit. En ramas de facturación, error.code es más específico que el error.type amplio y cambia la acción necesaria.
Si Codex utiliza un base_url personalizado, proxy empresarial, router de modelos o proveedor externo, ese intermediario puede originar o transformar el 429. Que el panel de ChatGPT muestre saldo no demuestra capacidad en ese gateway.
Congela el estado y localiza al propietario
No cierres sesión, cambies de red, modelo, clave y proveedor a la vez. Tal combinación puede ocultar el síntoma, pero no ofrece una causa reutilizable.
| Ruta activa | Propietario que debes comprobar | Evidencia útil |
|---|---|---|
| Codex con inicio de sesión ChatGPT | cuenta o workspace en Codex Usage | ventanas de cinco horas y semanal, reset, credits, /status en CLI |
| Codex con API key directa de OpenAI | organization/project de API | cuerpo del error, error.code, Retry-After, Limits y Billing |
| Business, Enterprise o Edu | workspace gestionado | seat, créditos compartidos/comprados, política y administrador |
| Gateway o proveedor externo | contrato del proveedor | base URL real, headers, request ID, saldo, concurrencia, model pool y status |
La documentación actual de uso de Codex dirige al Usage Dashboard para consultar los límites de la cuenta y señala /status para ver los límites restantes desde Codex CLI. Los campos cambian según cliente, versión, autenticación, plan y rollout. Registra lo visible; no conviertas un campo ausente en “sin límite”.
Si dos cuentas parecen heredar el mismo estado, utiliza la comprobación de cuenta, workspace, API y sesión local. Esa rama busca una sesión antigua, workspace común u organización API compartida; repetir 429 no puede separarlos.
Aclara qué “saldo” sigue disponible
El valor positivo puede ser porcentaje semanal, ventana de cinco horas, ChatGPT credits, crédito prepago de API, margen del project spend limit o cartera del proveedor. No son el mismo contador.
La explicación oficial de tokens y créditos indica que el coste cambia con modelo, contexto, razonamiento y herramientas. En planes compatibles, los créditos disponibles pueden extender el trabajo después del volumen incluido. La misma página explica que los mensajes locales y tareas cloud de planes ChatGPT comparten una ventana de cinco horas y pueden tener límites semanales adicionales. Por eso contar mensajes no permite prever consumo, y conservar saldo en una ventana no descarta el límite de otra.
Guarda una ficha breve antes de cambiar la configuración:
- superficie de Codex y versión del cliente;
- login de ChatGPT, API key o proveedor personalizado;
- cuenta/workspace ocultando datos; organization/project para API;
- modelo, razonamiento, Fast y uso de subagents;
- usage, reset, credits o saldo del proveedor visibles;
- tareas local, cloud, scheduled, delegated y background activas;
- error exacto, timestamp, zona horaria y request ID.
No adjuntes API keys, access tokens, OTP, correo completo, archivos de credenciales, código privado ni una captura completa de facturación.
Aplica una condición de recuperación, no un reintento genérico
Límite de velocidad o throttling temporal
Para un request-rate 429 de OpenAI API directa, la documentación oficial pide reducir el ritmo y respetar Retry-After cuando exista. En un cliente HTTP propio sin ese header, utiliza exponential backoff con jitter y limita tanto los intentos como el tiempo total. Los SDK oficiales de OpenAI ya reintentan errores de rate limit compatibles y respetan Retry-After cuando está presente; cuenta esos intentos antes de añadir otra capa. Las peticiones fallidas también pueden consumir el límite por minuto.
Cuando Codex muestra el error terminal, su ciclo acotado ya terminó. No lances copias del mismo trabajo desde varias sesiones. Detén concurrencia, espera el reset visible o la indicación del proveedor y prueba una operación pequeña con final claro. Si funciona, aumenta la carga gradualmente.
Ventana de uso de ChatGPT/Codex
Con autenticación ChatGPT, revisa Usage en la misma cuenta o workspace. Mantén separadas las ventanas de cinco horas y semanal; registra el reset mostrado, los credits disponibles y cualquier trabajo agentic que aún se ejecute.
Si la ventana que gobierna la petición está agotada, espera su reset real o usa créditos legítimos cuando la cuenta los ofrezca y aceptes el coste. Un modelo más ligero, menos contexto y menos herramientas ayudan tras recuperar acceso, pero no reabren una ventana ya cerrada.
Crédito, gasto o cuota de API
En la ruta API directa, lee error.code. credit_balance_exhausted, organization_spend_limit_exceeded, project_spend_limit_exceeded y organization_usage_limit_exceeded pueden compartir 429, pero no dueño ni solución.
OpenAI afirma que reintentar errores de crédito, gasto o cuota no restaura el acceso. Debe producirse el reset real o un owner con permisos debe ajustar el balance/límite correcto. Rotar una key dentro del mismo proyecto no crea una cuota nueva.
Gateway de terceros
Si el endpoint no es el directo de OpenAI, consulta headers de rate limit, saldo, concurrencia, modelo, request ID y status del proveedor. Un gateway puede mapear un fallo upstream a su propio 429. Sin respuesta original solo puedes afirmar que “esta ruta devolvió 429”.
Mantén credenciales y modelo, cambia una sola condición—espera el intervalo indicado o baja concurrencia—y prueba una petición pequeña. El porcentaje de ChatGPT no explica un contrato externo.
Posible incidencia del servicio
Compara producto, hora y región con OpenAI Status. Una incidencia coincidente permite seguir su cronología oficial. Que no exista aviso público significa solo que no hay confirmación pública coincidente; no demuestra que cada cuenta, región o gateway esté sano.
La primera prueba de vuelta debe ser pequeña
Después de un reset, cambio de límite o recuperación del proveedor, confirma que no continúan procesos antiguos ni cloud jobs duplicados. Mantén cuenta, ruta, modelo, razonamiento y Fast. Ejecuta una tarea que termine en pocos minutos y registra el mismo medidor antes y después.
Si la tarea pequeña funciona y la grande vuelve a 429, carga, concurrencia, contexto o una ventana corta ganan fuerza como explicación. Si la petición mínima falla de inmediato con el mismo 429, reenviar el trabajo grande no aporta información: vuelve a cuota, proveedor y status.
La comparación también sirve cuando el porcentaje semanal baja más rápido de lo esperado. No ofrece una factura perfecta por tarea, pero separa cambio asociado al trabajo visible, actividad en otra superficie y movimiento todavía sin explicar.
Si el fallo se reproduce después de cumplir la condición adecuada, prepara una cronología corta: cliente y versión, autenticación, proveedor, modelo/modo, error exacto, timestamp y zona horaria, request ID, usage/reset visible, actividad paralela y reproducción mínima. Para API añade error.code y headers relevantes ya ocultos, nunca Authorization ni el cuerpo privado.
El orden seguro es detener demanda duplicada, identificar al propietario, leer el subtipo disponible, cambiar la condición que falló y ejecutar una prueba pequeña. Así esperar, comprar créditos, pedir ayuda al administrador o abrir un ticket al proveedor deja de ser una apuesta y se convierte en el siguiente paso respaldado por evidencia.
