«Error en el flujo de mensajes» aparece cuando la conexión por la que ChatGPT entrega su respuesta poco a poco se corta antes de que la respuesta termine. Casi nunca se debe a lo que escribiste: las causas habituales son saturación en el lado de OpenAI, un enlace inestable, una extensión del navegador o un hilo que se ha hecho demasiado largo. Regenerar la respuesta resuelve la mayoría de los casos; cuando no basta, una sola comprobación te dice si el problema es tuyo siquiera.
El error
Error en el flujo de mensajes
(La misma avería con otras redacciones: «Transmisión interrumpida.
Esperando el mensaje completo», «Vaya...parece que algo ha salido
mal.» El síntoma es idéntico — la respuesta se detiene a medias
y nunca se completa.)Causas y soluciones de un vistazo
| Causa | Solución |
|---|---|
| Saturación o incidencia en el lado de OpenAI. Afecta a todos los planes a la vez, incluidos Plus y Pro, y es la causa más probable cuando el error se repite cada pocos minutos. | Consulta status.openai.com. Durante una incidencia nada de lo que cambies en tu equipo altera el resultado — esperar es la solución. |
| Conexión inestable: salto entre Wi-Fi y datos, VPN o proxy corporativo, cobertura móvil débil. El streaming mantiene una única conexión abierta mucho tiempo, así que se rompe donde una carga de página normal sí pasaría. | Desactiva la VPN o el proxy y reintenta por otro enlace (Wi-Fi ⇄ datos móviles). |
| Entorno del navegador: una extensión que se inyecta en la página, una caché caducada o una sesión expirada. | Reintenta en una ventana privada. Si ahí funciona, la causa es una extensión o la caché — desactiva extensiones, borra los datos del sitio, vuelve a iniciar sesión. |
| El hilo es demasiado largo o los adjuntos demasiado pesados. Cada turno reenvía toda la conversación, así que la generación tarda más y se corta con más facilidad. | Lleva los puntos clave a un chat nuevo. Divide los archivos grandes en vez de adjuntarlos enteros. |
Los tres gestos de los primeros 90 segundos
Regenerar la respuesta → recargar la página (en el móvil, cerrar la aplicación por completo y volver a abrirla) → cerrar sesión y volver a entrar. Un corte puntual se resuelve con uno de estos tres, y puntual es el caso normal. Si en cambio se detiene exactamente en el mismo punto siempre, es señal de que actúa una de las causas concretas de abajo y no un imprevisto.
Decidir primero si el problema es tuyo
Este es el paso que se saltan las demás listas de soluciones, y el que más tiempo ahorra. Abre status.openai.com. Si hay una incidencia en curso, ningún ajuste local la arregla y esperar es la única opción. Si no figura nada, la causa es local y el paso siguiente la acota. Hacer esta comprobación antes de tocar ajustes evita pasar veinte minutos vaciando cachés durante una caída.
Aislar la causa local de fuera hacia dentro
Ve en este orden, porque cada capa descarta todo lo anterior: (1) apagar VPN y proxy; (2) abrir una ventana privada — eso quita extensiones y caché de una sola vez; (3) probar otro navegador u otro dispositivo; (4) cambiar de red. La capa a partir de la cual vuelve a funcionar es la causa. Si el error solo aparece en hilos largos, ninguna de las cuatro tiene la culpa: lleva lo esencial a un chat nuevo.
Para desarrolladores: el mismo corte en la API
Al llamar a la API con stream: true, esta misma avería llega como una conexión Server-Sent Events que termina sin finish_reason. El estado HTTP es 200 — todo iba bien cuando se enviaron las cabeceras —, así que comprobar solo el código de estado no la detecta; bajo carga aparecen además 429 y 529 overloaded_error. Tres cosas la hacen sobrellevable: (1) tratar un stream que acabó sin finish_reason como reintentable, no como una respuesta completa; (2) reintentar 429, 500 y 529 con backoff exponencial más jitter; (3) si hay un proxy por medio, revisar su idle timeout y desactivar el buffering de respuestas — un proxy que almacena convierte un stream que funciona en un bloqueo largo. Para acotar, transmite primero sin proxy:
# Transmitir directamente, sin proxy por medio, y ver dónde se detiene.
curl -N https://api.kunavo.com/v1/chat/completions \
-H "Authorization: Bearer $KUNAVO_API_KEY" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-4-6","stream":true,
"max_tokens":300,
"messages":[{"role":"user","content":"cuenta despacio del 1 al 20"}]}'Si llamas a través de Kunavo
Kunavo es una pasarela de API de IA, y un stream interrumpido es allí un estado previsto de funcionamiento, no una excepción. Cuando un modelo tiene configurados varios canales de origen y el primer intento falla, la petición se reintenta por otro canal dentro de la misma llamada, así que un problema pasajero arriba se convierte en un éxito algo más lento en lugar de un error. Las peticiones fallidas nunca se facturan. Como GPT, Claude y Gemini son accesibles con una sola clave, esquivar un modelo saturado es cambiar el nombre del modelo, no la integración. El patrón de reintentos y backoff para el caso del streaming está desarrollado en LLM API streaming errors.
Preguntas frecuentes
«Error en el flujo de mensajes», ¿es culpa mía?
Casi nunca. El mensaje indica que la conexión que transportaba la respuesta se cortó antes de terminar. Lo que escribiste no lo provoca. Las causas son carga en el lado de OpenAI, una red inestable, una extensión del navegador o una sesión caducada, o un hilo que ha crecido lo bastante como para que las respuestas expiren.
¿Qué hago si regenerar no lo arregla?
Consulta primero status.openai.com — durante una incidencia nada local ayuda. Si no hay incidencia, abre una ventana privada en otra red: esa única prueba retira extensiones, caché y tu enlace habitual a la vez. Si ahí funciona, ve devolviendo cada pieza hasta que vuelva a romperse. Si falla en todas partes y solo en una conversación larga, lleva lo esencial a un chat nuevo.
¿Pasa también en otras IA?
La redacción es de ChatGPT, pero cualquier asistente que entregue respuestas en streaming puede cortarse igual. Claude muestra un mensaje sobre no haber podido generar la respuesta completa; en una llamada directa a la API aparece como un flujo SSE que termina sin finish_reason, o bajo carga como un 529 overloaded_error.
¿Por qué ocurre más en conversaciones largas?
Cada turno reenvía el hilo entero, así que una conversación larga significa una generación más larga sostenida sobre una sola conexión abierta. Cuanto más tiempo permanece abierta, más ocasiones tienen un timeout de proxy, un salto de red o un tropiezo arriba de romperla. Empezar un chat nuevo con un resumen de lo que importa suele mejorar más que cualquier ajuste del navegador.
Guías relacionadas
- LLM streaming errors — SSE cutoffs, hanging streams and missing usage
- Error 529 overloaded_error de la API de Claude — qué es y cómo absorberlo
- Precios de Claude en 2026: Pro, Max, la API por tokens y cuál sale más barato
La semántica completa de los errores está en la referencia de errores; conseguir una clave lleva un minuto con crear una cuenta y la documentación de autenticación.