Usage-limit retry loop after rapid verifier/session fan-out

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.

Start by tracing the agent/SSE retry path for USAGE_LIMIT_EXCEEDED (code 2056), using the reported Upload ID and local logs to follow related streams after the first limit error. Check whether the fan-out continues creating sessions or sending messages, and consider the investigation complete when active streams stop cleanly or require explicit confirmation before retrying.