Skip to main content
One agent runs as one account. Point two agents at two different logins for the same provider and they draw on two separate quotas, so the one that runs dry does not stop the other. The account is selected by an environment variable on the agent, which is why this is a per-agent setting rather than a global one. Every provider spells that variable differently, and a few have no way to express it at all.

​
What Works Today

“Maestro attributes it” means the Usage Dashboard account filter, the per-card account badge, and the Context Window tooltip name the account. For providers outside that column, Maestro sees one profile no matter how many logins you juggle. Copilot CLI is the odd one out. It has no account selector - the login is machine-wide - but COPILOT_HOME does move the transcripts, so Maestro reads every home it finds and files each as its own profile. Those profiles are separate transcript trees, not separate logins: they all bill the same GitHub account, and the split is a workspace split rather than a quota split.
Stay on one provider, different accounts. Mixing providers on the same work is a roadmap item, not a supported workflow - see Switching Providers at the bottom of this page.

​
Setting the Variable in Maestro

The steps are the same whichever variable your provider uses. Only the variable name and its value change.

​
When Creating a New Agent

  1. Click + in the sidebar to create a new agent
  2. Select the provider
  3. Expand the Environment Variables section
  4. Click + Add Variable
  5. Set the provider’s account variable to that account’s path

​
When Editing an Existing Agent

  1. Right-click an agent in the sidebar → Edit Agent, or use Alt+Cmd+, / Alt+Ctrl+,
  2. Scroll to the Environment Variables (optional) section
  3. Add the variable
Claude Code agent settings showing CLAUDE_CONFIG_DIR environment variable
Or from the CLI, without opening the app:
Per-agent variables replace the provider-level set rather than layering over it. An agent that carries any variable of its own loses every provider-level default, including keys it never set. If an agent needs both an account directory and an API key, set both on the agent. See Environment Variable Precedence.

​
Confirming Which Account a Tab Runs As

Agent names are a convention, not a guarantee - a renamed agent, or a variable edited after the fact, leaves the two out of step. To read the account off the tab itself, hover the Context Window gauge in the Main Window header: The profile resolves the same way the Usage Dashboard attributes an agent, so the account named here and the quota bars beneath it are the same account. Hover the profile name for the full path. Providers with no per-account config directory show only the Provider row.

​
Claude Code

Claude Code reads its configuration and OAuth credentials from ~/.claude. CLAUDE_CONFIG_DIR moves that directory. Because Claude stores sessions as plain JSONL files, you can give each account its own credentials while symlinking the shared parts back to one canonical source - which means sessions resume across accounts.

​
1. Authenticate Each Account

Start Claude Code normally and complete OAuth for your first account:
Copy the authenticated config to a named directory:
Then authenticate your second account:
The main ~/.claude/ directory does not need its own .claude.json. It serves as the canonical source for shared resources.
For each account directory, replace local copies with symlinks back to ~/.claude so settings, plugins, and sessions stay in sync:

​
What Is Shared vs. Account-Specific

One agent per account, named so you can read the split at a glance:

​
Notes

  • Session resume works cross-account because projects/ is symlinked.
  • Do not run both on the same project at once. Two Claude instances writing the same session files contend with each other. One at a time per project.
  • Symlinks may break after a Claude Code update. If an update recreates a directory, re-run the symlink commands.
  • Maestro samples each account’s remaining quota separately, so the Usage Dashboard’s quota panels show one set of bars per account.

​
Codex

Codex reads its configuration, auth.json, and session state from ~/.codex. CODEX_HOME moves the whole directory.
Then set CODEX_HOME=/Users/you/.codex-work on the agent.

​
What Does Not Carry Over

Codex keeps sessions, memories, and queue state in SQLite databases (thread_history_*.sqlite, memories_*.sqlite, state_*.sqlite), each with a write-ahead log. Do not symlink those between accounts - two Codex processes sharing one database file will corrupt it. That means an account switch is a clean break: conversations, memories, and history stay with the home they were created in. What is safe to share is the static configuration. Symlink only these:
Maestro’s Agent Sessions browser reads Codex sessions from ~/.codex/sessions only. Sessions created under a non-default CODEX_HOME are still resumable by the agent that made them, but they do not appear in that browser. Quota sampling and the Usage Dashboard’s account attribution do honor CODEX_HOME.

​
OpenCode

OpenCode stores credentials and sessions under its data directory, not its config directory. XDG_DATA_HOME is what moves the login:
Then set XDG_DATA_HOME=/Users/you/.opencode-work on the agent. Confirm with:
OPENCODE_CONFIG_DIR exists too, but it moves only the config file - it does not separate logins, so it is not the variable you want here.
Maestro does not attribute OpenCode accounts. Every OpenCode agent shows as one profile in the Usage Dashboard regardless of which data directory it runs against, and Maestro discovers OpenCode sessions from its own data directory, so sessions written under a per-agent XDG_DATA_HOME are invisible to the session browser. Name the agents clearly - that is the only signal you get.

​
Copilot CLI

Copilot CLI has no per-agent account switch. Its login lives in ~/.config/github-copilot/hosts.json, which is shared with every other Copilot client on the machine and is not relocatable.
  • COPILOT_HOME moves sessions and configuration, but not the login.
  • COPILOT_GITHUB_TOKEN, GH_TOKEN, and GITHUB_TOKEN are consulted only when there is no stored login. Once you have signed in interactively, the stored credential wins and those variables are ignored.
To change accounts, sign out and sign back in - which changes it for every agent at once. Maestro still honors COPILOT_HOME when it reads transcripts, from <home>/session-state rather than ~/.copilot/session-state only. That matters for the Usage Dashboard: an agent given its own home would otherwise have all of its spend go uncounted. Each home shows as its own profile there, which reads like two accounts and is not - see the note under the table at the top of this page.

​
Local Models

There is no account to split. A local runtime such as Ollama or LM Studio has no login and no quota, so a second “account” buys you nothing. What you can vary per agent is the endpoint and the model, by pointing a provider’s base-URL variable at your local server:
The endpoint must speak the API the provider’s CLI expects. See Using a Different Token Backend for the per-provider variables and the limits of that approach.

​
Other Providers

Factory Droid, Grok, Qwen3 Coder, Antigravity, Hermes, Oh My Pi, and Pi have no account-selecting variable that Maestro knows about. Their agents each show a single profile. If one of them grows a config-directory variable, it belongs in the table at the top of this page.

​
Switching Providers

Everything above is about one provider, several accounts. That is the seamless case: the agents speak the same session format, so a conversation started on one account is intelligible to the other, and in Claude Code’s case directly resumable. Pointing a single agent at a different provider is not that. Session history and memories live in each provider’s own store and in its own format, so they do not follow the switch - the agent comes back with no idea what it was working on. Moving an agent smoothly between providers, with its session history and memories carried across, is on the roadmap. Until it lands, use a separate agent per provider.