Kimi Code Made Crystal Clear · chapter 2: Core Concepts: Models, Membership, and the Agentic Loop
The three quota timers, nested
2026-09-02
A request must clear the rolling 5-hour window, the weekly Kimi Code quota, and the monthly membership pool; any one of them can stop you. The prepaid Extra Usage wallet sits outside the timers and is deducted last.
Below: the paragraph from the book that builds this idea, then the diagram itself (Figure 2.2), and a recap. About a minute of reading.
Now the precise version. The weekly quota is the main allowance: "Kimi Code's quota refreshes automatically every 7 days from your subscription date; unused quota does not roll over." Inside it sits the rolling 5-hour window, a burst limiter: too many requests in a short time trigger rate limiting even with weekly quota left, recovering as the window rolls over. The docs publish only a range, approximately 300 to 1,200 requests per window depending on tier, with up to 30 concurrent requests; no per-tier table exists anywhere, so your real meter is /usage and the Console. Around both sits the monthly membership total, shared with every other Kimi benefit: when it is spent, Kimi Code freezes until the monthly reset or an upgrade. Figure 2.2 nests the three.
Recap
- The idea: A request must clear the rolling 5-hour window, the weekly Kimi Code quota, and the monthly membership pool; any one of them can stop you.
- The picture: Figure 2.2, from chapter 2 ("Core Concepts: Models, Membership, and the Agentic Loop") of Kimi Code Made Crystal Clear.
- Go deeper: the chapter builds this step by step, with recipes and sources at the end.
This diagram is one of many in Kimi Code Made Crystal Clear.
Every chapter opens with the gist, draws the hard ideas, and ends with recipes and sources.
Get the book
