[FEATURE] Let individual subscribers gift or pool unused usage limits

Preflight Checklist

• [x] I have searched existing requests. The closest matches are #75063 (a Claude Family plan — a new household tier) and #81554 (reserving a % of quota within one account). Neither covers moving already-purchased capacity between existing accounts, which is what this asks for. See "Related issues" at the bottom.
• [x] This is a single feature request (not multiple features)

Problem Statement

Usage limits are strictly per-account, and unused capacity expires at the end of each window. On a team where everyone holds their own individual subscription — separate personal accounts, no Team/Enterprise org, no admin console — that creates a wasteful asymmetry:

• One heavy user exhausts their Fable 5 limit and is hard-blocked mid-work.
• Several colleagues on identical individual Max x20 plans finish the same window having used a small fraction of theirs.
• The idle capacity is already paid for. It simply evaporates.

There is no mechanism — gift, transfer, pool, or lend — to move any of it. Buying credits doesn't close the gap either, because credits are also per-account: a teammate topping up their own balance does nothing for the person who is blocked.

The result is a team paying for N subscriptions where the aggregate capacity is plentiful, but the distribution is wrong and cannot be corrected.

Proposed Solution

Two options, either of which solves it. (A) is the smaller change.

A. Giftable usage credits

/usage-credits already turns usage into a purchasable balance. A balance, unlike a rate-limit window, is inherently transferable. Add a transfer:

/usage-credits gift 500000 --to teammate@example.com

The recipient's balance increases; the sender's decreases. No change to how limits themselves work.

B. Voluntary account linking ("group", family-plan style)

Several individual subscribers opt into a shared group with a pooled extra-usage balance. No Team contract, no seat migration, no admin console — subscribers stay on their own personal plans and simply agree to share a pool.

Org- and seat-level pooling for Team/Enterprise would be valuable too, but it is explicitly the secondary case here. The gap that has no workaround today is the one between individual accounts.

Alternative Solutions

Considered and rejected:

• Sharing credentials — violates the usage policy and risks every account involved. Not a workaround, and shouldn't be treated as one.
• Everyone buys credits — doesn't help; credits are per-account.
• Move the team to Team/Enterprise — a billing and procurement change to solve a capacity-distribution problem, and it still doesn't pool per-model limits.
• Switch models when capped — what people do today. It's a downgrade, not a fix.
• Company-card API key / Bedrock / Vertex — works, but abandons the subscription that was already paid for.

Priority

High - Significant impact on productivity

Feature Category

Other (billing / usage limits)

Use Case Example

1. Several engineers at the same company each buy their own Max x20 subscription.
2. One of them drives the majority of the team's Claude Code work — in a recent month, claude-fable-5 accounted for roughly 78% of their model spend.
3. Mid-week, that engineer hits the wall:

``
429 rate_limit_error
You've reached your Fable 5 limit. Run /usage-credits to continue or switch models with /model.
``

1. Their colleagues are at a fraction of their own limits for the same window, and want to help.
2. With this feature: a colleague gifts part of their balance, or the group's shared pool absorbs the overflow. Work continues on the model the task actually needs.
3. Without it: paid capacity expires unused on several accounts while one person is blocked.

Additional Context

Anticipated objection — abuse. Transferable usage invites a resale market, ban evasion, and account sharing. Worth constraining from day one:

• Transfers only between email-verified accounts on the same domain.
• A monthly transfer cap per account.
• Non-refundable, non-resellable, no cash-out — usage only, never convertible back to money.
• Audit trail on both sides of every transfer.

Under those constraints the feature reallocates capacity within a team that already paid for it, and creates no secondary market.

On feasibility — the pieces already exist. Anthropic already sells giftable subscriptions: there is an active stream of issues about redeeming gifted Pro and Max plans (#88792, #86472, #83118, #83757, #90006, #66259). So transferring paid entitlement between accounts is an established concept in the billing stack, not a new one.

More directly, #89106 reports that "Multiple Claude Max Gift Cards converted to flat credit instead of stacking" — meaning gifted entitlement already converts into a credit balance today. Both halves of Option A therefore exist: a gifting flow, and gift-to-credit conversion. What's missing is letting an existing subscriber gift from their own balance rather than only by purchasing a new gift.

Transferring a rate-limit window is genuinely hard — it's time-boxed capacity, not a currency. Transferring a credit balance is not. Option A is deliberately scoped to the part that's already built.

Related issues

• #75063 — [FEATURE] Claude Family plan (household tier). Related, not a duplicate: it proposes a new plan tier with shared billing and per-member entitlement. This request leaves plans untouched and moves capacity between accounts that already have their own. The two compose.
• #81554 — reserve % of quota for specific tasks. Allocation within a single account; complementary, different scope.
• #60607 — multi-account / multi-profile support (closed). Adjacent.
• Gift-subscription billing reports establishing the existing primitive: #89106, #88792, #86472, #83118, #83757, #90006, #66259.