Skip to main content
Unlike the Kimi intelligent assistant, the Kimi API is stateless and has no memory of its own: across multiple requests, the model doesn’t know what you asked in a previous request and won’t remember any context—if you tell it you are 27 years old in one request, it won’t know that in the next. To enable multi-turn conversations, manually maintain the context for each request by sending the conversation history along with the next request, so the model can see what has been discussed before.
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.

Give the model memory with the messages list

The following example modifies the one from the previous chapter to show how maintaining a messages list gives the model memory: each turn appends both the user’s new message (role=user) and the model’s reply (role=assistant) to the list, then sends the whole list with the request. The key points are annotated as comments in the code:
Key points:
  • The Kimi API has no built-in context memory; use the messages parameter to manually tell the model what has been discussed before;
  • The messages list must store both the user’s questions (role=user) and the model’s replies (role=assistant).

Truncate history to control context length

As the number of chat calls grows, the messages list keeps getting longer, so each request consumes more Tokens—eventually the messages in the list will exceed the context window supported by the model. Use a strategy to keep the messages list within a manageable range, for example by keeping only the latest 20 messages as the context for each request. The following example shows how the make_messages function controls the number of messages in each request (keeping the latest 20 by default)—note how it ensures the System Messages remain in the list even when truncating:

What else to consider in production

The examples above only cover the simplest invocation scenario. In real business logic, you may need to handle more scenarios and edge cases:
  • In concurrent scenarios, additional read-write locks may be needed;
  • For multi-user scenarios, maintain a separate messages list for each user;
  • Persist the messages list;
  • Use a more precise way to determine how many messages to retain in the messages list;
  • Summarize the discarded messages and add the summary as a new message to the messages list;
  • ……