Kimi Code ate 18% of my weekly quota in 3 hours — Here is the log audit comparing it to Claude
热度趋势
百分比基于当前可用热度信号，而非评论数或独立用户人数。
一位开发者报告称，Kimi Code 在短短三小时内消耗了其每周配额的 18%，引发了对其配额计算与 Claude Code 和 Codex 相比是否准确的担忧。审计显示，Kimi Code 处理了约 30 条消息和 110 次 API 请求，共计 10.2M tokens，导致每周配额的约 90% 被用尽。相比之下，Claude Code 在更便宜的套餐下处理了 51 条消息和 3,544 次 API 请求，共计 677M tokens，却没有出现类似的配额问题，这表明 Kimi Code 的计量方式可能存在差异。
Is Kimi Code's quota math broken? I compared it with Claude Code and Codex — the numbers don't add up
TL;DR: A single 3-hour session with Kimi Code consumed 18% of my entire weekly quota. On the exact same day, Claude Code processed 66x more tokens on a cheaper subscription without breaking a sweat. Support claims this is "standard product behavior." I ran a forensic audit on the local logs—using Kimi itself to write the parser and measure the data—and the results raise serious questions about how cache tokens are billed.
What happened
I'm an annual subscriber to Kimi Code (Moderato tier). I also use Claude Code and Codex CLI on the same machine for my daily dev workflow.
My Kimi weekly quota kept dying within hours of normal use. When I opened a ticket, support responded:
"All charges are normal. This is standard product behavior based on dialogue turns and historical context."
To see if this was actually "standard," I audited the local session logs across all three agents. I actually had Kimi Code itself write the log parsing script and extract the exact measurement data from the raw session files:
- Kimi: ~/.kimi/sessions/*/wire.jsonl
- Claude: ~/.claude/projects/*/*.jsonl
- Codex: ~/.codex/sessions/*/*.jsonl
Same day, same machine, same user (2026-08-29)
Agent API requests My messages Tokens processed Quota result Kimi Code 110 ~30 10.2M ~90% of WEEKLY quota gone Claude Code 3,544 ~51 677M Fine (cheaper plan)
Over 5 weeks (Jul 24 – Aug 29)
Agent Total tokens processed Claude Code 13.3 BILLION Codex CLI 56M Kimi Code 52M Claude processed 256x more token volume than Kimi over 5 weeks on a cheaper subscription, with much heavier use, and never ran dry.
The Root Cause: Cache Billing & Amplification
Looking at context amplification (how many times the agent re-reads conversation context per turn):
- Kimi: ~10–20x amplification
- Claude: ~300x daily amplification (e.g., Aug 22: 180K new input tokens generated 1.3 Billion processed tokens in agent loops)
Technically, Kimi's agent implementation is more efficient with prompt context than Claude's. So why does Kimi's quota evaporate?
- Unrealistically Small Quota: Kimi's Moderato weekly quota measures out to roughly 11.3M tokens per week (measured: 565,819 tokens = exactly 5% of weekly limit).
- Full-Weight Cache Billing: Kimi appears to bill cache_read tokens at 100% full weight against the subscription allowance. In industry practice, prompt cache reads carry a ~90% discount (~0.1x weight).
Charging cache_read at 1:1 full weight against an 11.3M weekly quota means a standard 3-hour agentic session burns nearly a fifth of your weekly limit just re-reading context.
Support Response
- "Session involved numerous dialogue turns... each request carries full historical context. This is standard product behaviour."