[Bug] Subscription quota billed on full cache-read input + CLI defaults to a model the plan cannot access (burns quota)

[Bug] Subscription quota billed on full cache-read input + CLI defaults to a model the plan cannot access (burns quota)

What version of Kimi Code is running?

0.43.1

Debug zip session: kimi-debug-session_-20260918-091613.zip — Kimi Code CLI 0.43.1, OS linux x64, Node.js 26.3.1, session title "Xin chào" (collected 2026-09-18)

Which open platform/subscription were you using?

Kimi Code subscription (OAuth login, kimi.com managed service) — Plus plan (new-plan tier: Kimi Code access, K3/K2.8 access, no HighSpeed access)

Which model were you using?

kimi-code/kimi-for-coding (after an initial 401 fallback, see below)

What platform is your computer?

Linux x86_64

What issue are you seeing?

Two related quota-consumption problems, backed by per-request usage records from the session wire.jsonl:

1. Cache-read input tokens are billed at full value against the subscription quota

The session consisted of a handful of short conversational messages (greetings, questions about plans/quota, drafting feedback text). No code work, no large files, minimal tool activity. Per-request usage (usage.record entries, model kimi-code/kimi-for-coding, 12 requests):

#	Time (UTC+7)	Uncached input	Cache-read input	Output
1	15:44:02	33,581	512	102
2	15:46:05	279	34,048	347
3	15:46:17	1,223	34,304	342
4	15:46:34	5,125	35,328	448
5	15:46:51	6,041	40,448	338
6	15:48:26	1,956	46,336	3,322
7	15:51:04	3,616	48,128	1,532
8	15:51:41	1,607	51,712	543
9	15:55:50	681	53,248	1,010
10	15:58:02	1,221	53,760	939
11	15:59:52	1,211	54,784	1,630
12	16:02:03	1,868	55,808	821
	Total	58,409	508,416	11,374

Totals: ~578,200 billed tokens. The subscription page showed 15.77% of the monthly Code quota at 15:58 and 18.85% of the 5-hour window at 16:02 — these line up exactly with the cumulative request totals above, so the wire-log usage and server-side quota deduction are consistent.

Prompt caching is working (90% of input tokens were inputCacheRead), but cache-read tokens appear to be deducted from quota at full value. Implication: the effective 5-hour window on the Plus plan is only on the order of ~3M tokens total input+output, i.e. roughly 50–80 agentic turns at the baseline context size of this session, most of which is fixed overhead (21.5k-char system prompt + 39 tool definitions ≈ 34k tokens on the very first "hello" turn).

At competitor pricing models — e.g. Claude Code bills cache reads at ~10% of the input price — the same session would consume roughly a third of the quota it currently does. The membership docs mention cache hit rate as a billing factor for Extra Usage, but for subscription quota the observed behavior is full-price billing of cached prefixes.

2. The CLI defaults to a model the plan cannot access and burns requests on 401s

Session start (2026-09-18 15:41:52 UTC+7), the client's default profile was kimi-code/kimi-for-coding-highspeed. Two requests were sent and both failed:

2026-09-18T08:41:53.711Z WARN llm request failed model=kimi-code/kimi-for-coding-highspeed
  errorName=APIStatusError statusCode=401
  errorMessage="401 Your current subscription does not have access to kimi-for-coding-highspeed. Upgrade to higher-tier Kimi Code plans. ..."

2026-09-18T08:41:55.410Z WARN llm request failed model=kimi-code/kimi-for-coding-highspeed
  errorName=APIStatusError statusCode=401
  errorMessage="401 Your current subscription does not have access to kimi-for-coding-highspeed. Upgrade to higher-tier Kimi Code plans. ..."

The client then fell back to kimi-for-coding after ~2 minutes. The client (or the profile resolution) should never select a model the active subscription tier is known not to include — on a quota-billed product, each wasted attempt is real quota and real latency. This also surfaced as a UX problem: the Plus plan has no path to the HighSpeed model at all, so offering it as the default profile guarantees this failure for every Plus user on first launch.

Steps to reproduce

1. Subscribe to the Plus plan; launch a fresh Kimi Code CLI session (OAuth login). Observe the two 401s against kimi-for-coding-highspeed before fallback (check logs/kimi-code.log / wire.jsonl turn.step.interrupted).
2. Exchange a few short conversational messages (no tools, no large files).
3. Run /usage and compare with the subscription page; export the debug zip and sum usage.record entries for the session — cache-read input dominates and is deducted at full value.

Expected behavior

• Cache-read input tokens should be excluded from, or discounted within, subscription quota deduction — consistent with the cache-hit billing factor the docs already describe for Extra Usage.
• The client should not default to (or attempt) a model excluded by the user's plan tier.
• Quota-consumption estimates should be surfaced per turn (or at least per session) so users can see what a session actually costs.

Actual behavior

• Cache-read tokens are billed at full value against the 5-hour window; a few short messages consumed ~19% of the window.
• Two 401 requests were spent on a model the plan cannot access before falling back.

Additional information

• The session transcript is only a handful of short messages; the visible content cannot account for the billed volume — the bulk is fixed agent overhead re-sent each turn (correctly cache-hit, but still fully billed).
• A full debug zip is available and can be attached on request (contains per-request usage records and the two 401 warnings quoted above).
• Related context: membership docs state quota is shared across all devices and API keys, and the 5-hour window applies to all logged-in usage.

Contribution

• Happy to attach the unredacted debug zip to this issue or to support (code@moonshot.ai) with the Feedback ID if preferred.

Start with the reported logs/kimi-code.log, wire.jsonl usage.record entries, and the /usage entry point to reproduce both failures on a Plus plan. Trace model selection and quota reporting from those records; done means an inaccessible default is not attempted and cache-read usage is handled according to the documented subscription quota behavior.