Skip to main content
After receiving a question, the Kimi large language model first performs inference and then generates the answer one Token at a time. Streaming sends Tokens to the client as soon as a certain number of them (usually 1 Token) is generated, instead of waiting until the full response is complete. Waiting for the complete response usually takes several seconds — for complex questions and long replies it can stretch to 10 or even 20 seconds; with streaming, users see the first Token immediately, which significantly reduces wait time. When you chat with Kimi AI Assistant, the reply appears character by character — that is streaming in action.

Enable Streaming Output

Set stream=True in the request to enable streaming. The SDK then returns an iterable — loop over it to read data chunks one by one. Each chunk has a structure similar to a completion, except the message field is replaced by a delta field:
The examples on this page use the latest model kimi-k3 by default. K3 configures reasoning effort with the top-level reasoning_effort request field (supports "low" / "high" / "max", default "max"). To use another model such as kimi-k2.6 or kimi-k2.5, just replace the model field — parameter configurations differ across models. See the Model Parameter Reference.

Parse the SSE Response Body

With streaming enabled, the API no longer returns a JSON response (Content-Type: application/json); it returns Content-Type: text/event-stream (SSE) instead, which lets the server continuously push Tokens to the client. An SSE response body looks like this:
In the response body, each data chunk starts with the data: prefix, followed by a valid JSON object, and ends with two newline characters \n\n. Once all chunks are transmitted, the server sends data: [DONE] to mark completion, at which point you can close the connection. Note: always use data: [DONE] to determine whether the data has been fully transmitted, not finish_reason or any other means. If you have not received data: [DONE], do not consider the transmission complete even if finish_reason=stop was received; in other words, until data: [DONE] arrives, the message should be considered incomplete. During streaming, the content field is delivered chunk by chunk; role and usage are not repeated in every chunk — role appears only in the first chunk, and usage only in the last one.

Count Token Usage

There are two ways to count tokens. The most direct and accurate one is to wait until all chunks have been transmitted, then read the usage field of the last chunk to see the request’s prompt_tokens/completion_tokens/total_tokens:
Note that usage is nested inside choices[0] of the last chunk (choices[0].usage), not at the top level of the chunk. With the OpenAI SDK, chunk.usage is None — read chunk.choices[0].usage instead, or parse the raw SSE chunks directly.
However, a stream can be interrupted by uncontrollable factors such as a network drop or a client-side error, in which case the last chunk never arrives and the request’s token consumption cannot be determined. To avoid this, save the content of every chunk you receive and, once the request ends (whether successfully or not), call the token-count endpoint to compute the actual consumption:

Stop Streaming Output

To terminate the output early, simply close the HTTP connection or discard subsequent chunks — for example, break out of the loop:

Handle SSE Without an SDK

In a language without an SDK, or when the SDK cannot accommodate your business logic, you can interface with the HTTP API directly to handle streaming output. The following examples show how to read and parse the SSE response body line by line; see the code comments for details:
Whatever the language, the basic steps for handling streaming output are the same:
  1. Send an HTTP request with the stream parameter set to true in the request body;
  2. Check the Content-Type in the response Headers — text/event-stream means the response is a streaming output;
  3. Read the response line by line and parse the data chunks (in JSON format), locating chunk boundaries via the data: prefix and newline characters \n;
  4. A chunk whose content is [DONE] marks the end of the transmission.

Multiple Responses (n Parameter)

Current models (kimi-k3, kimi-k2.7-code, kimi-k2.6) fix n at 1 and do not support returning multiple responses in a single request. Passing an n greater than 1 returns a 400 error (invalid n: only 1 is allowed for this model) for both streaming and non-streaming requests. See the Model Parameter Reference for per-model parameter constraints.