[M3 Bug] Token Plan quota exhausts in long sessions — cache_read inflates monotonically per turn (regression since 2026-06-08, see #16)

[mvallebr]

M3 Token Plan quota exhausts in long sessions — cache_read inflates monotonically per turn

Cross-reference: this duplicates the observation filed in #16 (Chinese). I'm opening this new English-language issue for two reasons:

1. I cannot read Chinese well enough to subscribe to [Bug]: Plus 订阅额度消耗异常 (周总 + 5h) + 消耗数据查询延迟一天 #16's discussion or add my own data points to it.
2. A search in English for similar reports — Reddit (r/MiniMax_AI), Twitter/X, GitHub Discussions on pi-mono and opencode, Hacker News — turns up essentially nothing on the GitHub-hosted MiniMax-M3 repo except issue [Bug]: Plus 订阅额度消耗异常 (周总 + 5h) + 消耗数据查询延迟一天 #16 above. Other paying users will hit this and need a thread they can find.

If a maintainer prefers to translate this and merge into #16, that's fine too.

Reproduction environment

Plan	MiniMax Token Plan (Plus tier)
Model	MiniMax-M3
Provider route	Anthropic-Messages via built-in minimax provider in Pi
Base URL	https://api.minimax.io/anthropic
Client	Pi 0.80.6
Default thinking level (my config)	medium — lowered from high to reduce burn
contextWindow cap (my config)	300000 via models.json modelOverrides

Symptom — exactly 17 minutes of normal agent work

This is one window I instrumented from a real session (Python refactor on a separate project). The session did normal agent things: bash, read, edit on a project source tree. No multimodal, no audio, no video. 40 assistant turns total. Elapsed wall-clock time ≈ 17 minutes.

Category	Tokens	Cost (USD)	% of window
cache_read	7,964,672	$0.478	97.3%
input (uncached)	207,540	$0.062	2.5%
output	9,899	$0.012	0.1%
cache_write	0	$0.000	0.0%
Total	8,182,111	$0.55	100%

Per-turn averages (40 turns):

	tokens/turn
input (uncached)	5,189
cache_read	199,117
output	247

The cache_read is growing monotonically turn after turn, even though the per-turn new input is just ~5k. A sample of the growth over the window:

20:08:50  cR =      128   in = 195,161   cold start (a single big `ctx_search` tool result)
20:09:00  cR =  195,712   in =     383
20:09:50  cR =  201,472   in =     391
20:10:22  cR =  204,032   in =     451
20:11:19  cR =  209,408   in =     576
20:12:09  cR =  211,072   in =     140
20:17:04  cR =  212,224   in =     300   end of window

Two consecutive turns will report very different cache_read values because the prefix accumulates. At this rate (≈481k tokens/min ≈ 8.18M tokens in 17 min), roughly 8% of the 5h rolling quota is consumed in 17 min. If the 5h bucket fills with tokens (the FAQ says "5-hour rolling and weekly quota windows" but does not specify the denominator), the math implies the ceiling is ~102M tokens / 5h, and the current pace would hit it well before the 5h window closes.

Why I think this is a regression (matches #16)

Issue #16 was opened 2026-06-08 with the title "Plus 订阅额度消耗异常 (周总 + 5h)". The author notes:

这种"不耐用"是从今天（2026-06-08）突然开始的，之前没有这么夸张。

Translated: "This 'running out too fast' started suddenly on 2026-06-08. Before that it wasn't this extreme."

That timestamp is the start of the regression as observed by a paying Plus-tier user on the web client. My own session data shows the same pattern continuing in mid-July. The two together bracket the regression to a window around early June.

Hypothesised mechanism (not authoritatively confirmed by MiniMax)

The most plausible mechanism I have for this is that the Anthropic-Messages route on api.minimax.io/anthropic is including the model's thinking blocks (with their opaque base64 signature) in the cached prefix on every turn — and re-emitting them as cache_read to subsequent requests. With thinking on, every turn pays for all prior turns' thinking content at the cache_read rate. The growth I observed (~2-3k new cache_read per turn) is consistent with the size of a single batch of model thinking text plus its base64 signature.

Supporting observations:

1. There is an open issue on the OpenCode repo describing a similar pattern: anomalyco/opencode#31755 — "MiniMax direct API caching may be broken or affected by new thinking toggle, while OpenRouter BYOK still caches correctly."
2. There is an unofficial community workaround extension that targets specifically this: rwese/pi-minimax-m3-caching-fix — described as "Standalone pi extension that fixes MiniMax-M3 over-billing by routing to /v1/chat/completions for passive caching and stripping duplicated thinking."
3. A Reddit thread on r/MiniMax_AI (/comments/1twel9b/m327_token_consumption_is_insane_346m_cachereads/) — which I could not fully read due to bot protection — suggests other users see the same shape, with hundreds of millions of cumulative cache_read tokens.
4. Switching the running session's defaultThinkingLevel from high to medium did not stop the growth — it only slowed it. That is consistent with the cost driver being "thinking bytes re-emitted per turn" rather than "thinking mode on at all."
5. The OpenAI-compatible endpoint at https://api.minimax.io/v1 (recommended in MiniMax docs as the secondary option "for tools that ask for both") likely doesn't have the same problem, because it doesn't emit Anthropic-style thinking signatures — but switching to it would bill outside the Token Plan quota, so it is not a budget-neutral workaround.

What's missing from public docs

The Token Plan FAQ:

• States the quota is "5-hour rolling and weekly quota windows" but does not specify whether the bucket fills with input, output, cache_read, cache_write, or some weighted combination.
• States "long-context, multi-turn reasoning, multimodal tasks, and complex agent workflows deduct according to actual resource usage" — consistent with a heavy agent workload burning quota fast, but again no statement of what changed between the periods when this worked and when it became a regression.
• The other-tools page recommends for Pi literally just export MINIMAX_API_KEY=…; pi --provider minimax --model MiniMax-M3 — no mention of thinking-level settings, no warning about long sessions, no fallback recommendation.

Asks (in priority order)

1. Acknowledge the issue publicly — ideally in this thread or [Bug]: Plus 订阅额度消耗异常 (周总 + 5h) + 消耗数据查询延迟一天 #16. Issue [Bug]: Plus 订阅额度消耗异常 (周总 + 5h) + 消耗数据查询延迟一天 #16 has been open since 2026-06-08; it now has 1 community reply and zero official comment. Five-plus weeks of silence on an open billing-bug ticket is itself a problem.
2. Publish the 5h/weekly quota denominator — tokens, cost, or requests. Without it, users cannot reason about burn rate, test workarounds, or decide when to switch tools.
3. Confirm or refute whether the Anthropic-Messages route on api.minimax.io/anthropic is emitting thinking-block signatures in cache_read. If yes, ship an API-side fix — don't require users to install a third-party patch.
4. Publish a sanctioned workaround in the docs while a fix is being shipped — e.g. an explicit "for long agent sessions, set thinking.type=disabled" recommendation, or a per-tier cache policy that disables prefix caching for affected usage shapes.
5. Reduce the consumption-data latency from T+1 to T+0 / real-time. This was the highest-rated ask in [Bug]: Plus 订阅额度消耗异常 (周总 + 5h) + 消耗数据查询延迟一天 #16 and remains the biggest blocker to self-support on any billing question.

Why I'm filing this

I want M3 to keep being the model I reach for. The work this team is shipping is clearly visible. A small data dump like this should help move the conversation on a regression that has been visibly bothering paying users since early June. Thanks for reading.