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. If you need token usage in a streaming response, also pass stream_options: {"include_usage": true} (write {"include_usage": True} in the Python SDK):
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, 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 is not repeated in every chunk and appears only in the first one. When you pass stream_options: {"include_usage": true}, the server sends a final statistics chunk before [DONE]. This chunk has an empty choices array, and the total usage for the request is in the top-level usage field.

Count Token Usage

There are two ways to count tokens. We recommend passing stream_options: {"include_usage": true}, waiting until all chunks have been transmitted, and reading the top-level usage field of the final statistics chunk to see the request’s prompt_tokens/completion_tokens/total_tokens:
The final statistics chunk does not contain model output, so its choices array is empty. When parsing a stream, do not assume that every chunk has choices[0]; read the total usage from chunk.usage on the final statistics chunk.
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.