Skip to main content
llm.chat can send its reply piece by piece, so your screen shows the text as it is written. Add one header to the usual call: Accept: text/event-stream. The request body is the same. Send that type alone. A request that lists application/json beside it without ranking it lower (Accept: application/json, text/event-stream) gets the plain JSON reply, so a client that never asked for a stream never receives one. Always read the response’s Content-Type before you parse: text/event-stream is a stream, application/json is the whole answer.

With the SDK

A failure throws a PramaanError, before or during the stream. Leaving the loop early stops the call.

Events

The stream ends after done or error. Keep done.result: it is the checked reply. The pieces are for display. A line that starts with : (: ping) is a keep-alive sent every 15 seconds; skip it. The SDK does.

What to know

  • Tools and JSON output work the same. Tool arguments and JSON-schema output are checked when the reply is complete. If the check fails (the JSON does not match, or the reply was cut off at maxTokens) you get an error event after the pieces, and the reply is charged: you received it. The plain call makes the same failure free because it returns nothing.
  • Errors before the first piece are plain JSON with the usual status (400, 402, 429 and so on), not an event stream. Check the status before you read events.
  • Price. A finished reply costs what the plain call costs; the price is price_micro in done (there is no price header on a stream). If the reply breaks after pieces were sent, or you disconnect, you pay for what was generated, never more than the estimate. When the break leaves no token count, the charge is a ceiling: your input at the estimate’s bound and one token per byte sent. That can be more than the finished reply would have cost, so let a reply finish when you can. A call that sent nothing costs nothing. The estimate is held from your credit while the stream is open.
  • Idempotency. A repeated Idempotency-Key returns the stored reply as plain JSON, not a stream; while the first is still running it answers 409. A reply that broke is not stored, so the same key runs, and is charged, again.
  • Limits. A stream is stopped after 120 seconds, or after 50 seconds when the call carries an Idempotency-Key. An organisation may have 20 streams open at once; one more answers 429. Nothing is sent until the first piece is ready, which can take several seconds.
  • Disconnecting stops the reply.
  • MCP returns the whole reply; it does not stream.