· reAPI Team
stream disconnected before completion: stream closed before response.completed
Codex llegó al final del flujo sin aceptar su finalización. Antes de reintentar, comprueba el error completo, el evento final, el tiempo de espera y el protocolo.
«stream disconnected before completion: stream closed before response.completed» significa que Codex llegó al final de un flujo de respuesta sin aceptar un evento de finalización. Identifica dónde se detuvo el procesamiento, no qué máquina lo provocó. En el lector SSE de Codex inspeccionado el 22 de octubre de 2026, este mensaje es la salida de reserva al terminar el flujo; los fallos de transporte, las esperas por inactividad y los errores previos del servidor siguen rutas distintas.[1]
Lee el sufijo completo antes de cambiar ajustes. Un flujo cerrado requiere una traza de eventos; un tiempo de espera por inactividad, mediciones; un límite de uso, identificar qué recurso limita el servicio. Si evalúas reAPI, consulta primero la documentación de solicitudes de GPT-6 Astra: describe Chat Completions. Una solicitud correcta de Chat Completions no demuestra compatibilidad con el protocolo Responses de Codex.[2][3]
Empieza aquí
- Guarda el error completo, la versión del cliente, la fecha y hora y el identificador de solicitud antes de reintentar. Excluye credenciales y prompts privados de los informes compartidos.
- Ante un cierre anticipado, comprueba si los datos SSE recibidos incluyen un evento terminal válido y aceptado; no te bases solo en el éxito HTTP o el texto visible.[1]
- Ante
idle timeout waiting for SSE, mide el intervalo entre eventos. El control de inactividad documentado es independiente del número de reintentos de solicitudes y flujos.[2] - Ante un límite temporal, sigue la indicación de reintento del servicio y reduce la carga correspondiente. Los errores de cuota o facturación exigen actuar sobre la cuenta.[4]
stream disconnected before completion: stream closed before response.completed
El código fuente permite una respuesta más precisa que «tu conexión a Internet falla». El bucle SSE lee eventos, deserializa su JSON y envía los reconocidos al manejador de Responses. Cuando este devuelve una respuesta completada, el bucle termina correctamente. Si la entrada termina antes, devuelve un error de respuesta guardado, si existe; de lo contrario emite el mensaje de flujo cerrado.[1]
Esto permite distinguir varias situaciones al revisar una traza:
| Observación | Qué demuestra | Siguiente paso de diagnóstico |
|---|---|---|
| Llegó texto y después terminó el flujo | Parte de la salida llegó al cliente | Buscar el evento terminal y su cuerpo JSON |
| Éxito HTTP sin finalización aceptada | La solicitud HTTP tuvo éxito en esa capa | Examinar la secuencia de eventos en vez de dar la tarea por terminada |
| Hay datos que parecen indicar finalización | Llegaron bytes con apariencia de evento terminal | Comprobar el tipo de evento, los campos obligatorios y el parser del cliente instalado |
| Se guardó un fallo del servidor antes del EOF | El servicio proporcionó un error | Diagnosticarlo antes de tratar el cierre como otro fallo de red |
Son interpretaciones del parser revisado, no resultados de una llamada real a reAPI. El artículo usa la revisión inmutable c2d5ea52, para que puedas comparar su comportamiento con el cliente instalado sin asumir que todas las versiones de Codex funcionan igual.[1]
Los datos mal formados requieren una comprobación específica. En esta revisión, los eventos cuya deserialización JSON inicial falla se registran y se omiten. Un evento de finalización reconocido con un objeto de respuesta inválido sigue otra ruta de error. Por tanto, encontrar response.completed en un registro no demuestra que Codex lo aceptara. A la inversa, un flujo cerrado no prueba por sí solo que el servidor omitiera el evento: compara lo enviado por el servidor con lo recibido por el cliente.[1]
Para un endpoint personalizado, revisa el protocolo documentado antes de aumentar los reintentos. La referencia de configuración actual indica responses como valor admitido de wire_api y describe WebSocket como una capacidad independiente del proveedor. Aceptar JSON de Chat Completions con formato OpenAI no convierte por sí solo un endpoint en un endpoint Responses funcional.[2]
Proponemos una secuencia de reproducción pequeña: una solicitud solo de texto, después la misma solicitud con streaming y, por último, la interacción con herramientas que falló. Mantén constantes endpoint, clave y modelo. Registra qué cambia en cada paso: es un método de diagnóstico, no una garantía de que todos los proveedores admitan las tres pruebas. Si generan cargos por uso, ejecuta únicamente las pruebas autorizadas para esa cuenta.
stream disconnected before completion: transport error: network error: error decoding response body
Esta consulta describe un fallo de transporte o de lectura del cuerpo de respuesta. El lector SSE de Codex puede propagar un error del flujo entrante antes de recibir el siguiente evento utilizable. Es una ruta distinta de la finalización normal del flujo descrita arriba.[1]
Trata cada componente como un punto de investigación, no como una causa demostrada. Registra el host final del endpoint, la versión del cliente, el estado HTTP si está disponible, el tiempo transcurrido y si llegó algún evento. Después compara un solo cambio controlado cada vez, como otra ruta de red autorizada o el mismo endpoint fuera del cliente afectado. Abrir correctamente un sitio web en el navegador no comprueba el flujo autenticado concreto que falló.
La guía de errores de OpenAI recomienda revisar ajustes de red, configuración del proxy, certificados SSL y reglas del cortafuegos ante errores de conexión API. Son comprobaciones que realizar, no un diagnóstico de esa cadena exacta en tu entorno.[5] Mantén activada la verificación de certificados. Si una organización administra la red, usa su configuración autorizada en lugar de aplicar una solución de proxy ajena al problema.
Al comunicar el fallo al operador de una pasarela, incluye una estructura de solicitud sin datos sensibles y el último tipo de evento recibido. Una captura que solo muestra «disconnected» elimina la distinción necesaria. Conserva la traza original localmente y comparte una versión reducida sin cabeceras de autorización, entradas privadas ni salidas de herramientas.
stream disconnected before completion: idle timeout waiting for sse
Un tiempo de espera por inactividad significa que la espera del siguiente evento SSE superó el intervalo configurado. No equivale a que la respuesta tarde mucho en total: una respuesta larga que sigue generando eventos tiene un patrón temporal distinto de un flujo silencioso.[1]
La referencia de configuración consultada el 22 de octubre de 2026 separa tres controles:[2]
| Ajuste del proveedor | Alcance documentado |
|---|---|
stream_idle_timeout_ms | Espera inactiva de eventos SSE, en milisegundos |
stream_max_retries | Número de reintentos ante interrupciones SSE |
request_max_retries | Número de reintentos de solicitudes HTTP |
Aumentar el intervalo de inactividad cambia cuánto espera el cliente. No hace que un endpoint incompatible emita eventos Responses ni recupera bytes perdidos. Aumentar los reintentos cambia el número de intentos, no la causa del primer fallo.
Mide antes de ajustar valores. Registra cuándo empieza la respuesta, cuándo llega cada evento y cuándo se informa del error. Si el timeout del cliente es el límite observado, revísalo junto con el comportamiento documentado del servicio. Si la conexión se cierra antes, investiga ese cierre. No asignes un timeout universal a todos los modelos, redes y pasarelas basándote en un único turno fallido.
rate limit exceeded: upstream rate limit exceeded, please retry later
Este mensaje informa de un límite en algún punto del recorrido de la solicitud, pero su texto no identifica la cuenta, el recurso limitado ni la hora de restablecimiento. No deduzcas un proveedor concreto de «upstream», ni supongas que comprar más créditos resuelve cualquier respuesta de límite de uso.
La documentación de la API directa de OpenAI distingue límites de solicitudes y tokens, sobrecarga temporal y condiciones de cuota o gasto. Documenta las cabeceras de respuesta de límites y establece que Retry-After, cuando acompaña una condición temporal, indica una espera mínima. También advierte que los estados de cuenta que requieren una acción no se arreglan con reintentos.[4] Esa es la semántica documentada de OpenAI; utiliza la documentación y las cabeceras del endpoint al que realmente llamas.
| Evidencia del endpoint real | Respuesta adecuada |
|---|---|
| Límite temporal con indicación de reintento | Esperar al menos el tiempo indicado y reintentar con una política acotada |
| Límite de solicitudes agotado | Reducir la tasa entre los procesos que comparten ese límite |
| Límite de tokens agotado | Revisar la demanda de tokens además del número de solicitudes |
| Condición de cuota, facturación o tope de gasto | Resolverla en la cuenta antes de reenviar el trabajo |
| Mensaje genérico sin recurso limitado | Recopilar el identificador de solicitud y pedir al operador que identifique la restricción |
OpenAI recomienda espera exponencial con aleatoriedad si no hay una indicación de reintento adecuada, y señala que las solicitudes fallidas pueden contar para los límites. Ten en cuenta los reintentos del SDK antes de añadir otro bucle en la aplicación.[4] Una política necesita una condición de parada; no debe transformar una tarea rechazada en solicitudes nuevas sin límite.
En una tarea de agente, revisa además lo que ya ocurrió. Lee el diff del árbol de trabajo y el historial de herramientas antes de pedir al agente que repita una operación interrumpida. Que falle la respuesta final no demuestra que hayan fallado todas las acciones anteriores. Esta conciliación es un consejo operativo para evitar duplicados, no una afirmación de que Codex revierta automáticamente acciones externas.
Why does my Codex stream disconnect before completion and the stream closed before the response is completed?
En la ruta SSE inspeccionada, el cliente llegó al final de la entrada sin devolver correctamente la finalización y sin un error guardado más específico. Compara la traza recibida con la del servicio para saber si el evento terminal faltaba, era inválido o se perdió por el camino. El mensaje por sí solo no distingue esas explicaciones.[1]
Why does Codex keep disconnecting?
Los fallos repetidos requieren una comparación reproducible: mantén constantes versión del cliente, modelo y endpoint, captura el error completo y cambia una condición cada vez. Primero distingue cierre anticipado, fallo de transporte, timeout por inactividad y rechazo del servicio. Aumentar los reintentos antes puede repetir el fallo sin aportar pruebas útiles.
codex request timed out
Determina qué componente notificó el timeout. La configuración del proveedor de Codex expone un intervalo de inactividad SSE, mientras que un cliente API también puede informar de un timeout de solicitud. La guía API de OpenAI enumera factores de red y servidor que investigar, pero no convierte un timeout en prueba de una causa concreta.[2][5]
resume stream unavailable
No lo interpretes como garantía de que la respuesta puede reanudarse ni como prueba de que se perdió todo el trabajo terminado. Guarda versión y error completo, conserva la conversación e inspecciona las acciones de herramientas ya completadas. Las fuentes revisadas no establecen un comando universal de recuperación para esta cadena exacta, por lo que aquí no se prescribe ninguno.
Si vas a cambiar de modelo o endpoint, la guía de migración de GPT-6 Astra explica cómo separar descubrimiento de modelos, cambios de protocolo y validación de herramientas. La página del modelo muestra la oferta actual de reAPI. Ni el nombre de un modelo ni una tarifa sustituyen una comprobación completa y satisfactoria de compatibilidad con Codex.
Fuentes consultadas el 22 de octubre de 2026
- OpenAI. Codex Responses SSE implementation, revisión
c2d5ea52e1b7ab11ee2d71dc44ea1ef00f9c8eb3. Código y pruebas correspondientes. - OpenAI. Configuration Reference, protocolo del proveedor, tiempos de espera y reintentos. Referencia de configuración.
- reAPI. Documentación de solicitudes de GPT-6 Astra. Contrato de solicitud publicado; documentación de implementación inspeccionada localmente, no una prueba real de generación.
- OpenAI. Rate limits, cabeceras de respuesta y recomendaciones de reintento. Límites de la API.
- OpenAI. Error codes, errores de conexión API y timeout. Guía de errores API.