Repository navigation
[Feature]: Add per-project and per-worktree account assignment for token and credit management #7782
Description
Problem or use case
Orca’s account switching is very useful, especially when working across multiple Claude, OpenAI, or other coding-agent accounts. However, account selection currently operates as a global application-level setting.
The main limitation is not simply that switching accounts affects multiple projects but rather resource allocation. When working across several projects/teams, and on multiple worktrees, or agentic sessions, different tasks may have different levels of priority, cost sensitivity, token demand, or account availability.
For example, a user may want to allocate:
- Claude account 1 (with more credits) to a high-priority production project
- Claude account 2 (with less credits) to a large exploratory or research project
- Claude account 3 to lower-priority background work
This would make it possible to use the right account for the right project, rather than having all active work inherit the same global account. It would also help users manage credit consumption, subscription limits, rate limits, team usage, and token-heavy workflows more deliberately.
At the moment, if account selection is only global, users cannot reliably assign accounts to specific projects or worktrees. This makes it harder to optimize token usage across larger projects, parallel agentic workflows, and teams with different priorities.
Proposed solution
Add support for scoped account assignment, ideally at the project level and, if feasible, at the worktree level.
A possible hierarchy could be:
- Worktree-specific account, if set
- Project-specific account, if set
- Global default account
This would preserve the current global account selector while allowing users to override it where more granular account control is needed.
Example behavior:
- Project A uses Claude account 1 because it is high priority
- Project B uses Claude account 2 because it is token-heavy exploratory work
- Project C uses OpenAI account 1 for a specific workflow
- Project D inherits the global default account
Suggested UI behavior:
- Keep the existing global account selector as the default.
- Add an account selector in project settings.
- Optionally add an account selector in worktree settings.
- Clearly display which account is active for each project or worktree.
- Prevent global account changes from overriding projects or worktrees with explicit account assignments.
This would give users more control over how credits, tokens, rate limits, and subscriptions are allocated across active work.
Alternatives or additional context
The current workaround is to manually switch accounts depending on which project is active. This is easy to get wrong when multiple projects, worktrees, or agents are running in parallel.
Another workaround would be to run separate Orca instances, separate operating-system profiles, or separate environments. However, that adds operational overhead and reduces the benefit of managing multiple agentic workflows inside one interface.
This feature would be especially useful for users who:
- Run multiple agentic coding sessions in parallel
- Use multiple Claude or OpenAI accounts
- Need to prioritize token and credit usage across projects
- Work with larger teams or multiple collaborators
- Need to separate high-priority work from exploratory or background work
- Want predictable account usage across projects and worktrees
- Need better rate-limit, subscription, and usage management
The main request is to make account selection assignable per project, and ideally per worktree, so users can allocate the right account to the right work rather than relying only on a global application-wide account setting.
Activity
juandl commentedon Jul 21, 2026
Hello any ETA?
metheoryt commentedon Aug 1, 2026
A project group tier would slot between project and global in your proposed hierarchy — groups already carry
executionHostId/connectionIdwith repo-then-group precedence and a cycle-guardedparentGroupIdwalk, so the resolver shape exists. Proposed in detail on #6921 (answering its open question about where the binding lives): worktree → repo → group chain → global.nwparker commentedon Aug 23, 2026
Closing as a duplicate of #6921.
Disagree? Please respond! I will re-visit this ticket in 5 days. If you respond, I will re-open it 🙏.
nwparker commentedon Oct 9, 2026
Reopening to retain the broader account-assignment request. #6921 describes Claude-specific worktree binding; this report also explicitly includes OpenAI/other agents and project/worktree/global precedence for resource allocation. The Claude-only issue does not establish completion or coverage of the whole request.
AlexanderAbramovPav commentedon Oct 25, 2026
Adding a use case and a proposal for one shared shape, since this is the issue kept open for the broader request (Claude and Codex, project and worktree precedence).
Use case. One person, two subscriptions per provider: a work Claude plan and a personal one, plus Codex on both sides. A fleet of agents runs across many repos at once, started from the UI and by a coordinator agent through the CLI. The split is fixed by repo, not by task:
Today the selected Claude and Codex account is one setting per runtime (host or WSL distro), and
orca account selectonly accepts OpenCode and Devin, so neither a project nor a CLI launch can choose its account.Proposal: one binding, read by every launch path. Most of the pieces are already in flight. This is an attempt to line them up so they share one setting.
Repo.agentAccounts.claude, next to the per-project GitHub account from feat(github): bind projects to a specific gh account #13664. Keeping that shape and addingcodexcovers the Codex half. Precedence: explicit launch flag → the session's recorded account (resume/restore) → worktree override → project binding → global selection.orca account select --agent claude --account work --repo <selector>writes the project binding. Without--repoit is the global switch from feat(cli): select the Claude or Codex account fromorca account select#26870.--account <id|email>onorca worktree create,orca agent launchandorca orchestration worker-start, for one launch (feat(claude-accounts): launch a Claude agent on a specific managed account with --account #22691 has the Claude half).Since each Claude account now has its own folder (#24434, #26801), a launch can be pointed at one account without copying credentials. The remaining work is mostly where the account is chosen, not how credentials are handled.
Would the maintainers accept #23228's
agentAccountsshape as the shared binding, with Codex and the CLI flags added on top of it in small follow-ups?capoyeti commentedon Nov 1, 2026
+1 to @AlexanderAbramovPav's proposal to reuse #23228's
Repo.agentAccountswith acodexkey. My case is the same split: company repos on a company ChatGPT account for billing, everything else on personal. Today I route it with a wrapper set as the Codex Command (picksCODEX_HOMEfrom the repo's git common dir). One addition to that proposal: the usage chip and account indicator should reflect the account a session actually launched with. With externally routedCODEX_HOMEit currently shows "System default", which hides exactly the mis-route the binding is meant to prevent. Details in #9496.