Feature request: pool usage across accounts and share session context so several people can work one project together

Summary

Two related capabilities for small teams that share a codebase but each run Claude Code under their own subscription:

1. Pooled usage. Let a group of accounts contribute their plan limits to a shared pool attached to a project, so work on that project draws from the pool rather than from whichever individual happens to be driving.
2. Shared context. Let a session, its memory and its accumulated project knowledge be handed between accounts, so a collaborator can pick up exactly where another left off instead of being handed a written brief.

The problem today

I run a few small open-source and non-profit projects with a handful of collaborators. Each of us has our own Claude subscription. In practice this means:

• Work stalls on one person's cap while everyone else's capacity sits idle. When I hit the session or weekly limit mid-build, the only options are to wait for the reset or to have a collaborator start over on their own account. Their allowance is unused; mine is exhausted; the project is blocked either way.
• Context does not travel between accounts. Sessions, resume history and auto-memory are per user. If a collaborator continues the work, the new session knows nothing about the decisions, traps and half-finished state the previous one had built up. We currently work around this by writing a hand-off ledger to a shared network drive and telling the next session to read it, which is fragile and loses everything that was not written down.
• Long-running agent teams cannot survive a hand-off at all. A multi-agent build with warm implementer, reviewer and verification agents is tied to one account's session. If that account runs out, every agent's context is lost and the next person rebuilds it from scratch. This is the dominant cost of a long build, far more than the tokens themselves.

The result is that a team of three with three subscriptions gets roughly the throughput of one, plus the overhead of reconstructing context at every boundary.

What I am asking for

A project-scoped team with pooled usage

• A way to define a project workspace with member accounts (personal plans or a mix of personal and Team/Enterprise seats).
• Members opt in to contribute some or all of their plan allowance to the pool. Usage on that project is drawn from the pool first.
• Clear accounting: each member can see what they contributed and what the project consumed. Rate limits still apply per account for abuse control, but the budget is shared.
• Nothing changes for members who do not opt in.

Shared session context

• A session started by one member can be resumed by another member of the same project, with explicit permission from the originator (or a project setting that allows it by default).
• Auto-memory directories can be project-scoped and shared, not only per user, so lessons learned on a project accumulate for everyone working on it.
• Running sessions can be handed off live: if my account hits its cap, a collaborator can attach to the same session and its subagents and continue, rather than the session dying with my quota.
• The transcript records which account was driving at each point, for attribution and audit.

Why this is worth doing

• It turns individual subscriptions into team capacity without requiring an Enterprise contract. Small teams, open-source maintainers and volunteer organisations are exactly the people who cannot justify per-seat enterprise pricing but who already pay for several individual plans.
• It removes the single worst failure mode in long builds: context loss at an account boundary. Everything else about a hand-off (the code, the branch, the tests) already lives in git. The one thing that does not is the session's understanding, and that is the expensive part.
• It aligns with how the product already works. Agent teams, resume, auto-memory and CLAUDE.md all exist. This request is to let those cross an account boundary within a defined project, not to invent a new primitive.

Related

• #91953 describes a different cause of the same symptom: work that has to be split across sessions, with all the context for why it was safe discarded in between. Shared session hand-off would soften that too.
• #36151 and #18435 ask for multi-account switching in the apps. This is the complementary case: not one person with several accounts, but several people on one project.

Environment

Claude Code CLI on Linux (Raspberry Pi, aarch64) and macOS, individual Max subscriptions, projects on a shared network drive.