Abnormal quota consumption: cache_read billed every turn with cache_creation always 0 (>10x amplification)

[ahmadyaseen35-coder]

Subject: Abnormal quota consumption — cache_read billed with zero cache_creation across all sessions (2026-08-28)

Hello Moonshot support,

I am a paying Kimi Code subscriber (annual plan). On 2026-08-28 (evening, +03:00) my 5-hour quota window lost 40% within minutes of light use. I pulled the CLI's own per-turn token telemetry from my local session logs (/.kimi/sessions/*/wire.jsonl). The numbers show the problem is in metering, not in my workload.

EVIDENCE — three independent sessions on the same evening, same account, same machine:

Session A (id 6a96f8a3, started ~19:50):
turns=75 · new_input=521,668 · output=38,127 · cache_read=5,652,480 · cache_creation=0 · total_billed=6,212,275

Session B (id ead41565, ~19:03):
turns=43 · new_input=58,711 · output=17,921 · cache_read=1,938,176 · cache_creation=0 · total_billed=2,014,808

Session C (id b1efd4b0, spawned 23:10, tiny task):
turns=5 · new_input=20,979 · output=2,183 · cache_read=104,448 · cache_creation=0 · total_billed=127,610

THE ANOMALY:

1. cache_creation is ZERO on every turn of every session. A healthy cache shows a write once, then cheap reads. Here the entire conversation context (~138K tokens by end of Session A) is re-read and re-billed on EVERY turn — 75 times — with no creation ever recorded.
2. Result: a session whose real new content is ~560K tokens bills 6.2M tokens — a >10x amplification. Two short user messages near the end of a long session each cost ~139K billed tokens. This is exactly the "5% of the 5-hour window in seconds" behavior I observed via /usage.
3. This is not workload-driven: Session C proves it — a 5-turn trivial task billed 127K tokens.

WHAT I AM ASKING:

1. A per-request billing breakdown for my account for 2026-08-28 (prompt/cache/completion tokens and their price weight per request).
2. Whether cache_read tokens are counted at full weight against the 5-hour quota window. If yes, that is the defect: with cache_creation always 0, every session's quota is consumed at ~10x the real rate.
3. A credit correction for the mis-metered consumption.

I can provide the raw wire.jsonl excerpts on request. My account is the email tied to this subscription.

Thank you.

[ahmadyaseen35-coder]

Follow-up: cross-provider forensic comparison (same user, same machine, same days)

I accept the support team's finding that metering is internally consistent. However, I audited all three coding agents installed on this machine using identical methodology on their local session logs (~/.kimi/sessions/*/wire.jsonl, ~/.claude/projects/*/*.jsonl, ~/.codex/sessions/**/*.jsonl). The results show the real defect is quota sizing, not metering.

Same-day head-to-head (2026-08-29)

Agent	API requests	Real user msgs	New input	Output	Cache re-read	Total processed
Kimi Code	110	~30	630,577	56,020	9,477,856	10,164,453
Claude Code	3,544	~51	7,752	3,115,517	673,965,534	677,088,803

Claude Code processed 66x more tokens than Kimi on the same day, on a cheaper subscription — and its quota was not exhausted. Kimi's weekly quota was ~90% consumed.

Period totals (Jul 24 – Aug 29)

Agent	Total tokens processed	Peak day
Kimi Code	51,859,761	17.3M
Codex CLI	55,951,949	47.1M
Claude Code	13,294,896,165	963M

Claude Code processed 256x Kimi's total volume over the same period, with heavier use, on a cheaper plan.

Amplification — Kimi is not the aggressive one

Agent	Context amplification (total ÷ real new tokens)
Kimi Code	~10–20x per session
Claude Code	~220–330x per day (Aug 22: 180K new tokens → 1.3B processed)

My measured Moderato weekly quota is ~11.3M tokens (565,819 tokens registered as exactly 5% of weekly). That equals 1.6% of one normal Claude Code day for me.

Conclusion

1. Metering is consistent — no over-billing.
2. The Moderato weekly quota covers ~15 minutes of normal agentic use. For a coding agent, that is mis-sized by roughly two orders of magnitude.
3. Kimi's own amplification (10–20x) is 15–30x lower than Claude's (~300x). The workload is not the problem.
4. Root cause of the fast drain: cache_read appears to be billed at full weight against a very small quota. Industry norm is ~0.1x for cache reads.

Ask

1. Re-size the Moderato weekly quota for agentic workflows, or bill cache_read at reduced weight.
2. A credit correction for the current cycle.

Full audit report with raw session IDs and per-day breakdowns for all three agents available on request.