«Streaming interrumpido. Esperando el mensaje completo» aparece cuando la conexión que transmite la respuesta de ChatGPT a tu navegador se cae antes de que termine. Casi nunca lo causa lo que escribiste: las causas habituales son carga en el lado de OpenAI, un enlace inestable, una extensión del navegador o un hilo que ha crecido demasiado. Regenerar soluciona la mayoría de los casos; cuando no lo hace, una comprobación de estado indica si el problema es realmente tuyo.
El error
Streaming interrupted. Waiting for the complete message...
(related wording for the same failure: "Error in message stream",
"Hmm...something seems to have gone wrong." The symptom is the same —
the answer stops partway and never completes.)Causas y soluciones de un vistazo
| Causa | Solución |
|---|---|
| Carga o una incidencia en el lado de OpenAI. Afecta a todos los planes a la vez, incluidos Plus y Pro, y es la causa más común cuando el error se repite cada pocos minutos. | Comprueba status.openai.com. Durante una incidencia, nada de tu lado cambia el resultado: la solución es esperar. |
| Una conexión inestable: un cambio de Wi-Fi, una VPN o un proxy corporativo, o una señal móvil débil. El streaming mantiene abierta una conexión de larga duración, por lo que se rompe donde las cargas normales de páginas sobreviven. | Desactiva la VPN o el proxy y vuelve a intentarlo con otro enlace (de Wi-Fi a móvil o al revés). |
| Entorno del navegador: una extensión que se inyecta en la página, una caché obsoleta o una sesión caducada. | Vuelve a intentarlo en una ventana privada. Si allí funciona, la causa es una extensión o la caché: desactiva las extensiones, borra los datos del sitio e inicia sesión de nuevo. |
| El hilo es demasiado largo o los archivos adjuntos son demasiado pesados. Una conversación muy larga se reenvía con cada turno, por lo que las respuestas tardan más y es más probable que se corten. | Traslada los puntos clave a un chat nuevo. Divide los archivos grandes en lugar de adjuntarlos completos. |
Los tres de 90 segundos
Regenera la respuesta, recarga la página (cierra por completo y vuelve a abrir la aplicación si estás en el móvil) y, después, cierra sesión y vuelve a iniciarla. Una conexión caída puntual se soluciona con una de estas tres acciones, y la mayoría de los casos son puntuales. Si se detiene exactamente en el mismo punto cada vez, es señal de que la causa es una de las específicas que aparecen a continuación y no una caída temporal.
Determina si realmente es culpa tuya
Este es el paso que omiten las demás listas de soluciones y el que más tiempo ahorra. Abre status.openai.com. Si aparece una incidencia, ninguna configuración de tu equipo cambiará nada y la única solución es esperar. Si no aparece nada, la causa es local y el siguiente paso la aislará. Hacer esto antes de empezar a cambiar configuraciones evita que pases veinte minutos borrando cachés por una interrupción del servicio.
Aísla la causa local desde fuera hacia dentro
Revisa las capas en este orden, porque cada una descarta todo lo anterior: (1) desactiva la VPN y el proxy; (2) abre una ventana privada, que elimina las extensiones y la caché de una sola vez; (3) prueba otro navegador o dispositivo; (4) cambia de red. La capa en la que empieza a funcionar es la causa. Si el error solo aparece en hilos largos, ninguna de las cuatro es el problema: traslada los puntos clave a un chat nuevo.
Para desarrolladores: el mismo corte en la API
Al llamar a la API con stream: true, este fallo aparece como una conexión de Server-Sent Events que termina sin un finish_reason. El estado HTTP es 200 —todo estaba bien cuando se enviaron las cabeceras—, por lo que las comprobaciones basadas únicamente en el código de estado no lo detectarán; bajo carga también verás 429 y 529 overloaded_error. Tres cosas lo hacen tolerable: (1) trata un stream terminado sin finish_reason como reintentable, no como una respuesta completa; (2) reintenta 429, 500 y 529 con backoff exponencial más jitter; (3) si estás detrás de un proxy, comprueba su tiempo de espera por inactividad y desactiva el buffering de respuestas: un proxy con buffering convierte un stream funcional en una espera prolongada. Reprodúcelo primero sin el proxy:
# Stream directly, no proxy in the path, and watch where it stops.
curl -N https://api.kunavo.com/v1/chat/completions \
-H "Authorization: Bearer $KUNAVO_API_KEY" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","stream":true,
"max_tokens":300,
"messages":[{"role":"user","content":"count slowly from 1 to 20"}]}'Si llamas a través de Kunavo
Kunavo es una pasarela de API de IA, y los streams interrumpidos son una condición que está diseñada para absorber, no una excepción. Cuando un modelo tiene configurado más de un canal upstream y el primer intento falla, la solicitud se reintenta en otro canal dentro de la misma llamada, de modo que un problema upstream temporal aparece como un éxito ligeramente más lento en lugar de un error. Las solicitudes fallidas nunca se facturan. Como GPT y Claude son accesibles mediante una sola clave, un modelo sobrecargado puede evitarse cambiando el nombre del modelo en lugar de modificar la integración. El patrón de reintento y backoff para el caso de streaming está explicado en Errores de transmisión de la API de LLM.
Preguntas frecuentes
¿«Streaming interrumpido, esperando el mensaje completo» es culpa mía?
Casi nunca. El mensaje significa que la conexión que transportaba la respuesta se cortó antes de que terminara. Lo que escribiste no lo causa. Las causas son carga en el lado de OpenAI, una red inestable, una extensión del navegador o una sesión obsoleta, o un hilo que ha crecido lo suficiente como para provocar tiempos de espera en las respuestas.
¿Qué ocurre si regenerar no lo soluciona?
Comprueba primero status.openai.com: durante una incidencia nada local ayuda. Si no hay ninguna incidencia, abre una ventana privada usando otra red: esa única prueba elimina a la vez las extensiones, la caché y tu enlace habitual. Si allí funciona, vuelve a añadirlos uno a uno hasta que vuelva a fallar. Si falla en todas partes y solo en una conversación larga, traslada los puntos clave a un chat nuevo.
¿Ocurre esto en otros chats de IA?
La redacción es propia de ChatGPT, pero cualquier asistente que transmita respuestas puede fallar de la misma forma. Claude muestra un mensaje sobre la imposibilidad de completar la respuesta; en una llamada directa a la API aparece como un stream de Server-Sent Events que termina sin un finish_reason, o como un 529 overloaded_error bajo carga.
¿Por qué aparece el error con más frecuencia en conversaciones largas?
Cada turno reenvía todo el hilo, por lo que una conversación larga implica una generación más prolongada mantenida en una sola conexión. Cuanto más tiempo permanece abierta esa conexión, más posibilidades hay de que un tiempo de espera del proxy, un cambio de red o un problema del upstream la interrumpan. Empezar un chat nuevo con un resumen de lo importante suele mejorar más la situación que cualquier configuración del navegador.
¿Me cobran cuando se interrumpe un stream?
En las suscripciones de ChatGPT no existe un cargo por mensaje, así que no se pierde nada más allá del tiempo. En la API, la facturación sigue los tokens que el proveedor produjo realmente, por lo que un stream que muere pronto cuesta menos que uno completo; además, en Kunavo una solicitud que falla por completo no se factura.
Guías relacionadas
- Errores de streaming de LLM: cortes SSE, streams bloqueados y uso no informado
- Claude API 529 overloaded_error — qué es y cómo superarlo
- Tiempos de espera de las solicitudes de la API de Claude y «se recomienda encarecidamente el streaming»: la regla de los 10 minutos
Encontrarás más detalles sobre el significado de los errores en referencia de errores; obtener una clave lleva un minuto mediante registro y la guía de autenticación.