Una ejecución de OpenAI Codex puede terminar con mensajes distintos:
textexceeded retry limit, last status: 429 Too Many Requests stream disconnected before completion exceeded retry limit, last status: 401 Unauthorized
No describen una única incidencia. Un 401 indica que una ruta concreta rechazó la autenticación. Un 429 indica que algún servicio aplicó un límite de solicitudes, crédito, gasto o uso. stream disconnected solo confirma que la respuesta no terminó. “Exceeded retry limit” explica por qué el cliente dejó de intentarlo, no cuál fue la causa.
Antes de borrar credenciales, rotar una clave, ampliar timeouts o lanzar de nuevo la tarea completa, fija la ruta efectiva y conserva el primer error útil.
Dos comprobaciones antes de modificar nada
En Codex CLI, empieza con comandos de solo lectura:
bashcodex --version codex login status
Guarda el mensaje exacto, la hora y zona horaria, la superficie de Codex, el modelo y el request ID si aparece. codex login status identifica el método de autenticación; no demuestra que todos los permisos posteriores sean válidos. Si utilizas un provider personalizado, confirma también el provider y la base URL efectivos sin imprimir credenciales ni el fichero de configuración completo.
La clasificación oficial de errores de Codex App Server separa Unauthorized, fallos HTTP del upstream, ResponseStreamConnectionFailed, ResponseStreamDisconnected y ResponseTooManyFailedAttempts. Cuando existe un estado HTTP upstream, puede llegar como httpStatusCode. Aunque tu interfaz solo muestre la última línea, conviene conservar esas categorías por separado.
Qué cuenta y qué provider son responsables
| Ruta activa | Evidencia que manda | Evidencia que no la sustituye |
|---|---|---|
| Codex iniciado con ChatGPT | cuenta/workspace activos, uso de Codex, reproducción en una sesión nueva | saldo o RPM/TPM de Platform API |
| OpenAI API key | error estructurado, organización/proyecto, billing y limits, cabeceras | estado de ChatGPT Plus/Pro |
| Provider o gateway externo | endpoint efectivo, cuenta del provider, logs gateway/upstream, trace ID | un panel de OpenAI que no recibió la petición |
Un panel puede mostrar correctamente “uso disponible” y seguir siendo irrelevante si pertenece a otra ruta. Alinea el método de autenticación, el provider y la consola que estás consultando.
Error 401: cambia el estado de autenticación, no el número de reintentos
En OpenAI Platform API, un 401 puede significar autenticación inválida, API key incorrecta, falta de pertenencia a la organización o una IP que no coincide con la allowlist. La referencia oficial de errores distingue estas causas. Lee error.code y confirma el mismo proyecto antes de actuar.
En la ruta de ChatGPT, comprueba si codex login status muestra el método y la cuenta esperados. Volver a autenticarse tiene sentido cuando la sesión guardada está realmente invalidada o se ha seleccionado otra cuenta. No es una primera prueba inocua: codex logout elimina credenciales guardadas. La guía oficial de autenticación también diferencia workload identity, que depende del entorno del proceso.
Con una API key, confirma que el proceso utiliza una clave del mismo endpoint, organización, proyecto y política de IP que estás revisando. No muestres la clave, todo el entorno ni auth.json. Corrige el invalid_api_key, membership o IP authorization que indique el error y después realiza una sola solicitud corta. Un 401 estable no mejora con backoff.
En un gateway externo, el 401 puede ser del acceso al gateway o un rechazo del upstream. Cruza el request ID con los logs de la misma hora. Si el gateway aceptó la credencial del cliente pero falló al autenticarse aguas arriba, rotar la clave del cliente apunta a la capa equivocada.
Error 429: identifica el owner antes de esperar
En OpenAI Platform API, 429 no significa únicamente “demasiadas solicitudes”. La documentación actual también separa crédito agotado, límite de gasto de organización o proyecto y límite de uso de la organización. Los errores de billing, spend o quota no se recuperan repitiendo la petición.
- Si existe un
Retry-Afterválido o un código explícito de request rate, reduce concurrencia, espera como mínimo ese intervalo y limita los intentos. - Si aparece
credit_balance_exhausted, detente hasta que cambie el saldo de la organización afectada. - Si aparece un spend limit, revisa el mismo proyecto y organización que enviaron la solicitud.
- Si la cuenta ChatGPT/Codex muestra una ventana de uso, sigue la condición de recuperación de esa cuenta; no la conviertas en throughput de API.
- Si el 429 viene de otro provider, sus límites, facturación, concurrencia y logs son la fuente correcta.
- Si solo tienes la última línea 429, conserva hora, ruta y request ID; todavía no hay base para inventar un tiempo fijo de espera.
Si una solicitud corta y serial funciona, pero la carga concurrente falla, reduce la concurrencia y registra el umbral. Es evidencia sobre la forma de la carga, no una prueba completa de la causa. Si el resultado sigue siendo irregular, deja de sondear y consulta los logs del provider o gateway.
Stream disconnected: averigua cuándo se interrumpió
Un stream puede cortarse en el cliente, proxy o inspección TLS, red gestionada, gateway, servicio upstream o durante un cambio de red local. El texto no demuestra por sí solo que una VPN sea la causa ni que OpenAI esté caído.
Haz una única comparación pequeña:
- Abre una sesión nueva con la misma cuenta, provider, modelo y una petición breve sin datos sensibles.
- Anota si falla antes de cualquier salida, después de una respuesta parcial o con un estado HTTP explícito.
- Solo si la política lo permite, repite esa misma petición una vez en otra red de confianza.
- Cruza hora y request ID con los logs de gateway/provider.
- Si solo falla un cliente o versión, registra la diferencia y no cambies varias variables a la vez.
Que otra red funcione acota el problema a la ruta; no autoriza a desactivar controles de seguridad corporativos. Si ambas redes fallan a la vez, pesan más las evidencias de cuenta, provider, gateway y servicio actual.
No amplíes automáticamente stream_idle_timeout_ms. Un timeout solo cambia cuánto espera el cliente. No corrige una base URL equivocada, un 401, créditos agotados ni una conexión cerrada deliberadamente por el gateway.
Aumentar retries no cambia el upstream
Codex incluye configuración para request retries, stream retries y stream idle timeout. La referencia oficial de configuración también explica que model_providers y las claves de provider/auth son ajustes de usuario; un .codex/config.toml del proyecto no puede sustituir esa ruta de máquina.
Subir los valores puede alargar un fallo determinista, multiplicar tráfico si el gateway también reintenta y ocultar el primer error útil. Solo tiene sentido cuando ya has demostrado una condición temporal de rate o transporte, el upstream permite reintentar y has fijado un máximo de intentos y tiempo total.
Después de cambiar la condición responsable, valida con una petición corta. Si vuelve el mismo primer fallo, detén el bucle.
Qué incluir al escalar el problema
Prepara un informe si la petición mínima falla en sesiones nuevas, la cuenta contradice el error o solo una combinación de versión/provider reproduce el fallo:
- versión de Codex, CLI/App/IDE y sistema operativo;
- método de autenticación y provider, sin credenciales;
- primera y última hora del fallo con zona horaria;
- si ocurrió antes de la primera salida o tras una respuesta parcial;
- categoría de error, estado HTTP,
error.codey request ID; - alcance entre sesiones y modelos;
- resultado de una única prueba comparativa;
- fragmento mínimo de log saneado que conserve el primer fallo.
No envíes API keys, tokens, cabeceras de autorización, ficheros auth/config completos, volcados de entorno, prompts privados ni código propietario.
La recuperación se valida en la ruta original: misma cuenta, provider, cliente y una petición corta que termine por completo sin el primer error. Cambiar de cuenta, modelo o red puede servir como rodeo, pero no demuestra que la ruta original esté reparada.
