Comparative tables of artificial intelligence models describe capacity, speed, maximum context, and price per million tokens. These data are useful, but they do not always show how many steps an agent needs to complete a real task.
On July 25, 2026, we examined the local logs produced by Kimi Code CLI 0.29.1. The data show a rapid accumulation of recorded tokens and allow us to distinguish normal input, input retrieved from the cache, and output.
Dossier Summary
- The real case: Monitoring local logs of Kimi Code CLI during real development on July 25, 2026.
- Recorded data: 1,449,154 tokens and 30 internal calls in about 9 minutes.
- The necessary distinction: Recorded tokens, billed cost, and deducted quota are not the same. Cache and service type change the calculation.
- The key lesson: The nominal price per million tokens is not enough to describe the cost of an agent making multiple calls to complete a task.
The Token Explosion in Autonomous Agents
The first gap between theory and practice lies in how programming agents interact with the server. In a standard test, the model answers an isolated question. In development work:
- The agent reads files from the local computer to analyze the context.
- Subsequent calls include instructions, history, tool results, and parts of files already read.
- The already processed context can be retrieved from the cache: it costs less than new input but still appears in the recorded consumption.
Detail of Recorded Tokens
Between 22:38 and 22:47 on July 25, a single session with Kimi K3 recorded: 64,311 normal input tokens, 1,372,416 retrieved from the cache, and 12,427 output tokens.
The session contained 11 user requests: on average 2.7 internal calls for each visible request. Across the examined local sessions, 3,516,457 tokens were recorded.
These values come from local logs. They do not automatically correspond to the billed cost or deducted quota, which depend on the service and cache handling.
The Weight of Mandatory Reasoning
Kimi K3 allows choosing the reasoning effort between low, high, and maximum. To use Kimi K2.7 Code, however, it is necessary to keep the Thinking mode active. In local tests, a request with an incompatible setting was rejected by the API with the error:
invalid thinking: only type=enabled is allowed for this model
The choice of model, reasoning level, and context window can change consumption. Kimi's documentation indicates that K3 with a context of one million tokens uses about twice the quota compared to the K3 version with 256,000 tokens. The calculation varies between providers and services, so it must be measured on the same task.
Saturation and Blocks: The Payment Paradox
Kimi Code and Kimi Platform do not use the same commercial system. Kimi Code applies quotas on five-hour, weekly, and monthly windows linked to the subscription. Kimi Platform instead bills the APIs based on usage and applies separate limits.
The subscription maintains its periodic quotas. Kimi Code also offers Extra Usage: if activated, at the end of the available quota, requests can continue using a separate balance, with a configurable spending limit. Therefore, convenience cannot be evaluated solely by comparing the nominal price per million tokens.
The observed problem is not just the model's rate, but the difficulty in predicting how many calls and tokens will be needed to complete a task with an agent. To compare different tools, real sessions, distinct counters, and the same starting assignment are needed.
What to Do with This Information
- Measure real sessions: count input, output, cache, and calls separately for the same type of activity.
- Reduce context: send only the necessary files and code parts.
- Choose the model based on the task: a lower reasoning level can reduce consumption, but it must be verified while keeping the assignment unchanged.
- Control reasoning: where the model allows, use the minimum level that produces a correct result.
- Compare under equal conditions: use the same files, the same goal, and the same verification criteria.