Streaming
Consume Qufas Chat Completions as OpenAI-compatible Server-Sent Events.
SSE protocol
Set stream: true. Qufas responds with Content-Type: text/event-stream. Each event uses a data: line and a successful stream ends with data: [DONE].
1data: {"id":"chatcmpl_...","object":"chat.completion.chunk","model":"kimi-k2.7-code","choices":[{"index":0,"delta":{"content":"Hello"},"finish_reason":null}]}2 3data: {"id":"chatcmpl_...","object":"chat.completion.chunk","model":"kimi-k2.7-code","choices":[],"usage":{"prompt_tokens":10,"completion_tokens":4,"total_tokens":14},"metadata":{"request_id":"req_abc123"}}4 5data: [DONE]Examples
1curl -N https://qufas-ai.vercel.app/v1/chat/completions \2 -H "Authorization: Bearer $QUFAS_API_KEY" \3 -H "Content-Type: application/json" \4 -d '{5 "model": "kimi-k2.7-code",6 "messages": [{"role": "user", "content": "Write a short checklist."}],7 "stream": true,8 "stream_options": {"include_usage": true}9 }'Usage, request ID, and billing
With stream_options.include_usage: true, the terminal usage chunk includes token usage and metadata.request_id. The canonical transport identifier is also returned in x-qufas-request-id.
Setting include_usage: false hides the client-facing usage chunk only. Qufas still uses provider usage to complete billing.
Omitting stream_options or setting it to null retains the legacy behavior of exposing usage. With an object, omittedinclude_usage defaults to false. A disconnected client may never receive the final usage chunk, even when it requested one. Receiving usage is not itself a receipt that billing has committed.
Text and tool-call deltas
Text arrives in choices[].delta.content. Tool calls can arrive in multiple choices[].delta.tool_calls fragments; accumulate function names and argument text by tool-call index until completion.
In-band streaming errors
Provider errors, timeouts, billing finalization failures, or malformed upstream streams that occur after HTTP headers may be returned as an SSE error event. Handle the same stable error object used by JSON responses and record its request ID. Do not parse provider raw messages.
1data: {"error":{"message":"Upstream provider timed out.","type":"provider_error","param":null,"code":"provider_timeout","request_id":"req_abc123"}}2 3data: [DONE]Qufas closes the stream after a terminal error. Clients must not assume every failed stream has a normal completion chunk. An error may also be followed by[DONE]: that marker means the SSE stream ended, not that the operation succeeded or that no charge occurred. Normal completion finalizes available provider usage before Qufas sends its one terminal marker. Provider/transport errors before final usage may leave accounting incomplete; a later accounting error can occur after a charge has committed. Check usage and billing records with the request ID.
Stop and disconnects
Chat Stop or aborting your client stops receiving and displaying further output. Upstream provider cancellation is not guaranteed. The provider request may keep running, and final billable usage may include tokens generated after you stopped receiving it.
When the provider completes and final usage reaches accounting, Qufas settles that logical operation once using tenant-scoped idempotency. Stop is not a refund or a zero-charge boundary. Disconnect detection depends on the deployment; request status may remain in progress or become completed, failed, or cancelled. A cancelled status records Qufas's local handling, not confirmation that the provider stopped.
A disconnected client need not receive [DONE] or an error event. Missing final usage or interrupted server execution can leave settlement unverified; do not interpret an incomplete stream as free usage. Reconcile usage and billing by request ID before retrying, and reuse the same Idempotency-Keyfor the same logical operation. Idempotency prevents duplicate settlement, not duplicate provider execution.
Was this page helpful?