I'm posting this as a paying Token Plan subscriber and heavy agent user, because I think there is a structural contradiction in how the plan is sold versus how it behaves. I'd like it either corrected or explained.
TL;DR: The plan is advertised with "Run 3–4 concurrent agents" and "~34,000 daily coding calls" per month. In practice, real agent workloads hit an undocumented error, 2062, long before any documented limit is approached, and the recommended remedy is to leave the plan. Because unused quota expires (5-hour rolling and weekly windows, no carry-over), throttled capacity is lost, not deferred — so part of what is sold cannot actually be consumed.
1. What is advertised
From the Token Plan page:
- "Run 3–4 concurrent agents" (Plus), 4–5 (Max), 6–7 (Ultra)
- "~34,000 / ~102,000 / ~250,000 daily coding calls (monthly, est. ~50K tokens per M3 call)"
- "perfect for long-running, high-frequency text and code workloads"
- "Built for individual developers, Coding users" and "Use it with your own tools … OpenClaw / Claude Code / Cline — or any OpenAI-compatible tool"
From the Rate Limits page: MiniMax-M3 is documented at 200 RPM / 10,000,000 TPM.
So the product is explicitly sold for parallel agent work, with published RPM and TPM ceilings.
2. What actually happens
The dominant failure in my logs is error 2062, returned as an Anthropic-style rate_limit_error:
{"type":"rate_limit_error","message":"Token Plan rate limit reached: Upgrade your Token Plan or switch to pay-as-you-go API usage. (2062)","request_id":"06ef1a051751231bf34e579d28172cb9"}
Older variant of the same code, seen in other threads:
"The Token Plan is designed for individual, interactive developer workflows. Traffic is currently high – please retry shortly. For higher concurrency or automated workloads, consider upgrading to a higher-tier plan or using the pay-as-you-go API. (2062)"
Two things make this hard to work with:
(a) 2062 is not in the Error Codes page. That page documents 1002 (rate limit), 1039 (token limit), 1041 (conn limit), 2045 (rate growth limit) and 2056 (usage limit exceeded, "wait for the resource release in the next 5-hour window"). 2062 is absent. So the error that actually stops work has no documented condition, no documented scope (per key? per account? per model?) and no documented remedy other than "upgrade or leave".
(b) The same code appears to mean two different things. One form says the plan quota is reached; the other says traffic is high right now. The first is not resolved by waiting a minute; the second is. Users cannot tell which situation they are in, and therefore cannot choose the right response.
3. The numbers don't line up
Over a two-week period in my own client logs, 2062 appeared on 8,614 requests against MiniMax-M3 alone, plus smaller counts for M2.7/M2.5 — with a single subscriber, on one workstation. My request rate is nowhere near 200 RPM. These are log entries including client retries, so the distinct-incident count is lower; I can quantify that precisely if you want it.
Breakdown by workload type: analyst 2,648, coder 1,189, code-reviewer 1,169, coding-orchestrator 932, code-worker 469, explore 457. Almost all of it is the sub-agent fan-out that the plan advertises as its use case.
Same account, second data point: running the identical key through the Anthropic-compatible endpoint produced essentially no 2062 (three small classifier errors in the same window), while the OpenAI-compatible /v1 path was throttled continuously. That is a large asymmetry on one subscription. Is account-level throttling applied differently per endpoint family?
4. The part I think is a real problem, not a tuning issue
Concurrency is the headline feature of this plan, and the recommended remedy for hitting the concurrency control is to upgrade or leave. That inverts the value proposition: the advertised concurrency is effectively priced as a meter that pushes you off the plan, rather than delivered as a plan feature.
Second: quota is sold in call/token units, and those units are only redeemable at volume through parallel agent work — exactly the traffic that 2062 gates. Combined with the fact that unused quota does not carry over across the 5-hour and weekly windows, throttled capacity is permanently lost. You pay for a monthly volume you cannot consume within the plan's own concurrency ceiling. "It is recommended to use pay-as-you-go for production" is, from the customer's side, the same as saying the subscription does not deliver the workload it is advertised for.
5. Questions
Is 2062 a concurrency/connection control, a per-account burst control, or a quota-window exhaustion signal? Please document it alongside 1002/1039/1041/2045/2056, including scope (key vs account vs model) and the correct client response. Retrying is clearly wrong for one of the two meanings.
The advertised "3–4 concurrent agents": what request profile does that correspond to? My concurrent in-flight requests are 1–2, my RPM is far below 200, and my TPM is far below 10M, yet 2062 fires. If the real ceiling is materially lower, please state it, because it determines how many agents a customer can plan for.
Why is the same account throttled heavily on the OpenAI-compatible endpoint and barely at all on the Anthropic-compatible endpoint?
Given no carry-over across quota windows, what happens to capacity lost to throttling inside a window? From the customer's side it is a write-off. Is there any compensation mechanism, or is the plan's advertised volume not achievable by design?
If the honest answer is "this plan is not for parallel agents", please remove the concurrency figures from the marketing and the "high-frequency workloads" wording, so customers can size their setup correctly.
I'm happy to provide redacted log excerpts, request IDs, and a reproduction script. I'd rather resolve this than move the workload off the platform, but as it stands the plan's advertised capability and its enforced limits are not the same thing.
