Summary
MiniMax Code Desktop created an unusually large number of mvs_* session records during a parallel verifier/review-style coding task, then continued retrying after the Token Plan usage limit was reached.
This report is not about exact credit prediction. The concern is that related agent/SSE work appeared to keep retrying after Token Plan usage limit reached, instead of stopping cleanly or requiring explicit user confirmation.
Environment
- App: MiniMax Code Desktop
- Version: 3.0.47
- Platform: Windows
- Timezone: Asia/Tokyo
- Date observed: 2026-07-03
- Main affected session:
mvs_e603...0764
- Upload ID:
414502851952903
What happened
I was running a coding task that involved parallel verifier/review-style work. Local logs show a sharp burst of mvs_* session creation, followed by repeated usage-limit errors across multiple SSE streams.
Local evidence
- 72
mvs_* sessions were created on 2026-07-03.
- Recent previous daily counts were much lower: 2026-07-02=5, 2026-07-01=4, 2026-06-30=8, 2026-06-29=17, 2026-06-28=17, 2026-06-27=5.
- 22
mvs_* sessions were created between 15:03 and 15:22 JST.
- In the 15:00 hour, completed tool events included approximately:
read: 332 completions / ~2.9 MB output
bash: 1036 completions / ~1.6 MB output
grep: 128 completions / ~245 KB output
- Repeated 45,394-byte
read outputs appeared across multiple verifier-like sessions.
- From 15:27:27 to 15:31:58 JST, local logs recorded 80
Token Plan usage limit reached errors across 10 SSE streams.
- One stream reached retry attempt 8.
- At 15:33:01 JST, a verifier-like session attempted another
sendMessage, then hit the same usage-limit error and stopped around 15:33:03-15:33:08.
Expected behavior
After USAGE_LIMIT_EXCEEDED / code 2056, related active agent/SSE streams should stop cleanly, or retry only after explicit user confirmation.
Parallel verifier/sub-agent work should also have a visible cap, warning, or confirmation step before creating enough sessions to rapidly consume the token plan.
Actual behavior
Multiple related SSE streams appeared to keep retrying after the usage limit was reached. A verifier-like session also attempted work again after the limit errors had already occurred.
Why this seems like a bug
I understand that MiniMax Agent uses multiple agents/sub-tasks and cannot predict exact credit usage. The issue here is narrower: once the usage limit was reached, related agent/SSE activity appeared to continue retrying instead of cancelling the active fan-out.
Privacy note
The raw local logs contain sensitive auth headers/tokens, so I am not pasting them into this public issue. I will provide the official Upload ID generated from Settings -> General -> Upload logs.
Requested investigation / safeguards
- Check whether all related active SSE/agent streams are cancelled after
USAGE_LIMIT_EXCEEDED / code 2056.
- Avoid automatic retries for usage-limit failures unless the user explicitly confirms.
- Add a visible cap, warning, or confirmation step for verifier/sub-agent fan-out.
- Check whether repeated session-history hydration or repeated identical tool outputs contributed to the runaway activity.
Summary
MiniMax Code Desktop created an unusually large number of
mvs_*session records during a parallel verifier/review-style coding task, then continued retrying after the Token Plan usage limit was reached.This report is not about exact credit prediction. The concern is that related agent/SSE work appeared to keep retrying after
Token Plan usage limit reached, instead of stopping cleanly or requiring explicit user confirmation.Environment
mvs_e603...0764414502851952903What happened
I was running a coding task that involved parallel verifier/review-style work. Local logs show a sharp burst of
mvs_*session creation, followed by repeated usage-limit errors across multiple SSE streams.Local evidence
mvs_*sessions were created on 2026-07-03.mvs_*sessions were created between 15:03 and 15:22 JST.read: 332 completions / ~2.9 MB outputbash: 1036 completions / ~1.6 MB outputgrep: 128 completions / ~245 KB outputreadoutputs appeared across multiple verifier-like sessions.Token Plan usage limit reachederrors across 10 SSE streams.sendMessage, then hit the same usage-limit error and stopped around 15:33:03-15:33:08.Expected behavior
After
USAGE_LIMIT_EXCEEDED/ code 2056, related active agent/SSE streams should stop cleanly, or retry only after explicit user confirmation.Parallel verifier/sub-agent work should also have a visible cap, warning, or confirmation step before creating enough sessions to rapidly consume the token plan.
Actual behavior
Multiple related SSE streams appeared to keep retrying after the usage limit was reached. A verifier-like session also attempted work again after the limit errors had already occurred.
Why this seems like a bug
I understand that MiniMax Agent uses multiple agents/sub-tasks and cannot predict exact credit usage. The issue here is narrower: once the usage limit was reached, related agent/SSE activity appeared to continue retrying instead of cancelling the active fan-out.
Privacy note
The raw local logs contain sensitive auth headers/tokens, so I am not pasting them into this public issue. I will provide the official Upload ID generated from Settings -> General -> Upload logs.
Requested investigation / safeguards
USAGE_LIMIT_EXCEEDED/ code 2056.