Cuando una llamada en streaming se porta mal, lo que tienes es un muro de líneas de evento y datos, y las tres cosas que quieres saber están repartidas por él: qué dijo realmente el modelo, por qué paró y qué consumió. El texto llega en fragmentos, los argumentos de herramienta llegan como JSON parcial que solo analiza cuando cae la última pieza, y el uso está repartido entre el primer evento y el último. Esto lo recompone todo. Se admiten las dos formas de stream habituales, porque en la práctica la gente pega ambas, y los eventos que no analizan se informan en vez de saltarse en silencio.
Características
Texto recompuesto desde sus deltas, en orden
Argumentos de herramienta reconstruidos desde JSON parcial y formateados
Motivo de parada, modelo y uso extraídos
Admite tanto la forma de bloques como la de choices/delta
Líneas data repetidas unidas como exige la especificación
Los comentarios de keep-alive se ignoran en vez de contarse como eventos
Los eventos de error se muestran en lugar de saltarse
Cada evento desplegable, con un recuento por nombre
Cómo usar Visor de streams SSE
Pega el stream en bruto
Lee el texto recompuesto
Comprueba el motivo de parada y el uso
Despliega eventos concretos si algo sigue sin explicarse
Ejemplo
Entrada
delta: {"type":"text_delta","text":"Order 4471 "}
Salida
Order 4471 shipped on 30 August.
Fragmentos repartidos en seis eventos, recompuestos en orden.
Errores comunes y solución de problemas
No sale texto. — Puede que el stream terminara antes de haber contenido: mira la lista de eventos y el motivo de parada. Un rechazo o un evento de error producen un stream válido y vacío.
Los argumentos de herramienta salen truncados. — Llegan como JSON parcial en varios eventos. Si el stream se cortó, el JSON nunca cierra y se muestra el fragmento en bruto en vez de un análisis.
Algunos eventos no analizan. — Suele ser un stream cortado a mitad de evento al copiarlo. Esos se informan con su índice en vez de descartarse.
Los números de uso parecen incompletos. — Están repartidos por el stream: los tokens de entrada al principio y los de salida al final. A un stream sin sus eventos finales le falta la mitad.
Preguntas frecuentes
¿Qué son los server-sent events?
Un formato de streaming sencillo: líneas de campo y valor, con los eventos separados por líneas en blanco. Es lo que usan las respuestas de API en streaming, y por eso una llamada fallida te deja con un muro de ellos.
¿Qué formas de stream se admiten?
La de bloques, donde el texto llega como deltas tipados dentro de bloques de contenido, y la de choices/delta. Ambas se reconocen automáticamente, porque la gente pega la que registró su cliente.
¿Por qué los argumentos llegan a trozos?
Se transmiten como JSON parcial para que el cliente pueda empezar a dibujar antes de que la llamada esté completa. Eso significa que los fragmentos solo analizan cuando llega el último, y por eso un stream truncado deja JSON inválido.
¿Puedo ver lo que costó?
El bloque de uso se extrae cuando está presente, lecturas de caché incluidas. Te dice qué consumió la llamada; a partir de ahí entran las herramientas de coste.
¿Se sube el stream a algún sitio?
No. Un stream contiene la respuesta entera y a menudo el prompt que la produjo, y todo el análisis ocurre en el navegador.