[FEATURE] Sell a Max tier above 20x (50x/100x) - the ceiling is what forces the multi-account workarounds

Preflight

I searched the enhancement requests for an existing ask for a tier above 20x and did not find one. The nearest are #85590 (make the Max five-hour hard stop configurable) and #90479 (surface plan usage limits to the agent), which are about the shape of the existing limits rather than the ceiling on them.

On scope, said plainly. Subscription tiers are a pricing decision, not a CLI feature, so this may be the wrong tracker. I am filing it here because the consequences land in this tracker: #89993, #87954, #92135, #55621, #74662 and #36151 are all multi-account issues, and multi-account exists mostly because 20x is the ceiling. If this belongs elsewhere, please route it rather than close it, and tell me where to send it.

Problem Statement

Max 20x is the largest subscription sold. When one account is not enough, the only way to buy more capacity is to buy more accounts.

More accounts is what breaks everything else. I hold five Max 20x subscriptions on five accounts on one machine, and the costs are structural:

1. Sessions on different accounts cannot address each other. The session map is per-login, so a session on another config root is never registered in it and cannot be listed or messaged. My work is split across five app instances that cannot coordinate. Filed as #92135.
2. Load does not spread evenly. The permission to spawn a session lives in one account's settings, so every launch bills to that account whatever work the child does. One account runs hot while the others idle.
3. I cannot see remaining headroom to route around it. Checked today, all five accounts return UNKNOWN on the usage read with refresh HTTP 429. Rate limiting, not an expired token, so re-authenticating does not clear it. The instrument that would let me swap before hitting a cap is least available when a cap is close. See #89993 point 5.
4. Five of everything to keep in sync. Five logins, five config roots, five settings files, and a five-way edit for every permission or hook change. A root that drifts fails quietly.

None of these are problems I would have on one account. They are all consequences of the ceiling.

Proposed Solution

Sell a Max 50x, and ideally a Max 100x above it.

• Roughly linear pricing against 20x. I already pay for five subscriptions, so the comparison I care about is one bill against five at similar total spend.
• Nothing else has to change. Every mechanism in Claude Code already works correctly within a single login. Session messaging, config, permissions, usage reporting. Putting my sessions back on one login is the entire fix.

That last point is why I think this is worth filing despite being a pricing question. Most of the multi-account feature requests in this tracker are asking Anthropic to build machinery that a larger tier would make unnecessary.

Alternative Solutions

What I do today. Five accounts, five launcher scripts, five config roots, and a file-based mailbox inside .git to pass messages between sessions that cannot see each other. It works and I maintain it, which is the point.

Cross-account session messaging (#92135). This solves the sharpest cost, cost 1 above, and leaves costs 2 through 4 in place. It also needs a trust model that a single account does not: pairing, permission intersection, cross-account audit. Useful, and strictly more to build than a pricing tier.

Rate-limit failover between accounts (#89993). Same shape. Real machinery to work around a ceiling that could instead be raised.

I would take any of the three. I am pointing out that this one is the cheapest to ship and removes the need for the other two.

Priority

High. Significant impact on productivity.

Feature Category

Other. Subscription and capacity.

Use Case Example

1. I run multi-agent orchestration against a single Python repository, most days, across roughly 125 git worktrees with several sessions live at once.
2. One 20x account cannot sustain that, so the work is spread over five accounts.
3. A coordinating session finishes scoping a task and needs to hand it to a worker with quota headroom. It cannot see the worker, because the worker is on another login, and it cannot read the worker's remaining quota, because the usage endpoint is returning 429.
4. On a single 50x account, both problems disappear without a line of new code. ListAgents sees every session, SendMessage reaches it, and there is one quota to reason about.

What this would not fix

Capacity is not always my bottleneck, and I would rather say so than oversell this. In a recent burst, 39 pull requests merged in one repository in about a day and 36 of them touched the same file. That contention is mine to solve in how I decompose work. A larger tier would not have helped there.

I am asking because of coordination cost, not because more quota alone makes the work faster.

Environment

Claude Code on Windows 11, Desktop app and CLI. Five config roots, five distinct account emails, five separate pools.