In this article
A transport chunk is not an SSE event, and receiving HTTP headers does not establish successful completion of the answer.
OpenRouter streaming lets an application display an answer while it is generated. The client requests streaming and reads events for the chosen API. This changes more than text display: the application must handle event boundaries, normal completion and failures after transmission begins. Chat Completions and Responses need protocol-appropriate parsing.
Choose one event protocol
Record which operation the application actually sends. Chat Completions delivers content through its response structure, while Responses uses its own event types. Do not combine parsers merely because both deliver data incrementally. Begin with a short synchronous request to confirm access and the model before testing the stream.
Use the documented streaming interface and keep a raw, non-sensitive example for development. A library may already provide compatible event handling; verify its behavior rather than adding a second parser that interprets the same bytes differently.
Buffer incomplete events correctly
A network read can contain part of an event or several events together. Splitting each received byte chunk as if it were complete JSON is unreliable. Follow Server-Sent Events rules, including event separators and service comments, and retain incomplete data between reads.
UTF-8 decoding also needs to preserve a character split across byte chunks. Test text containing non-ASCII characters, several small reads and a final partial buffer. These are protocol checks, not performance benchmarks. A robust client should distinguish an incomplete event from a malformed completed event without silently losing text.
Measure the relevant milestones
| Milestone | What it establishes |
|---|---|
| HTTP headers received | The response has started |
| First useful content | The user can begin reading |
| Protocol-defined completion | The answer ended normally |
| Usage information | Data is available for cost reconciliation |
The first comment or service event is not necessarily the first meaningful answer. Capture timestamps at the same points when comparing configurations. Proxy buffering can make an incremental upstream response appear all at once, so test the direct authorized route and the intended application route separately.
Handle partial answers explicitly
A failure can occur after useful text has appeared. Preserve the distinction between complete output, interrupted output and a deliberate user cancellation. Do not label every response with initial HTTP 200 as successful, and do not replace a partial answer silently with a second attempt.
Test disconnection, timeout and an error event using a controlled setup. Keep request identifiers and safe usage details to reconcile attempts. For infrastructure planning, distinguish network delivery, model waiting time and GPU execution.
Official references: openrouter.ai — streaming, html.spec.whatwg.org — server sent events.
Related guides: Errors inside an OpenRouter stream: why HTTP 200 is insufficient, Calling OpenRouter from Node.js without exposing the key.