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

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.

No source file, entry point, or test is named; the evidence is in ~/.kimi/sessions/*/wire.jsonl and the reported /usage behavior. Start by reviewing the telemetry from Sessions A–C and the requested per-request billing details; the issue is done only when the discrepancy has a documented explanation and an account correction path is established.