Multiple Claude accounts in Claude Code

Why does anyone hold two Claude accounts?

Two reasons, and they are usually both true at once. A subscription belongs to one person on one plan, so a work seat and a personal seat are separate logins by construction. And the seat has a ceiling that a long day can reach. Anthropic says a Team or Enterprise member's Claude Code usage draws from a per-seat allowance that resets on a rolling five-hour window and a weekly window, and that the allowance is shared with Claude chat and Cowork. On a Pro, Max, Team or Enterprise plan, /usage shows the bars for what counts against those limits.

The ceilings announce themselves in Claude Code with two messages: You've hit your session limit and You've hit your weekly limit. Anthropic is explicit that these are seat-based windows shared across all models, so changing model inside the same account does not restore access. The message shows when the window resets. /usage prints the plan bars and a breakdown of what has been counting against them.

So the second account is capacity, not curiosity. The question is how a terminal program that holds one login at a time gets to use two.

How do you use multiple Claude accounts side by side?

Anthropic documents one arrangement for staying signed in to several accounts at once, and it is a directory rather than a feature. Give each account its own configuration directory, and tell Claude Code which directory this launch should use with the CLAUDE_CONFIG_DIR environment variable. Each directory keeps its own settings, its own session history, and its own claude.ai login or API key. Anthropic's own example is a shell alias:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

Open a new terminal, run claude-work for the first time, and Claude Code walks you through login and setup for that directory. After that, claude is your personal login and claude-work is the other one, each with its own history and settings.

A configuration directory is more than a token. On the machine this page was written on, the default ~/.claude holds settings, project state, session transcripts, plugins, skills and task state, so a second directory means a genuinely separate working identity rather than a swapped credential.

Anthropic names one limit on the arrangement: separate directories do not keep two Claude Console sign-ins without an API key apart, because Claude Code stores that kind of sign-in outside the configuration directory. If both of your accounts are claude.ai subscriptions, the directories are enough.

By hand the alternative is logging out and back in. /logout also resets first-launch setup state, so the next claude walks you through login and setup again. Neither route knows anything about remaining capacity, so the choice is yours to make from /usage or from memory.

What do the account switcher tools actually do?

Several open-source projects exist because the directory trick is manual and the usage numbers live in another command. Every fact below comes from the project's own README, read in October 2026.

claude-swap

A Python package installed with uv or pipx. You log in with an account and run cswap add to store it; cswap switch makes one of them the machine's active login; cswap list is a dashboard of every account's five-hour and seven-day usage and reset times. cswap auto watches usage and switches before a threshold, 90% by default, with separate lines available for the weekly window and for one model's weekly limit. It quarantines an account whose refresh token has died, and it will not rotate onto API-key accounts unless you pass --include-api-key-accounts.

tagteam

A Rust rewrite of claude-swap, and it keeps that project's JSON field names so scripts written for it can read tagteam's output. One binary for macOS and Linux, statically linked on Linux. Its README states that Windows is not supported. A switch changes the account identity only: memory, instruction files, history, projects, settings, skills, agents and MCP configuration are left alone by design. tagteam run starts Claude Code as a second account beside your default one, and a daemon does the automatic switching in the background. The README is candid about the trade: it relies on Claude Code internals that Anthropic does not document or guarantee, so a Claude Code update can break it.

claude-code-switcher

A different approach to the same problem: each profile runs in its own Podman container, with its own authentication, its own MCP servers and its own settings, so no configuration is shared between profiles. You launch one with ccs <profile> [path]. It buys clean separation and asks you to run Podman.

Altero

altero list, switch, add and run work on macOS, Windows and Linux, as does the terminal dashboard, so the switching half is not Mac-only. What is Mac-only is the passive half: the menu bar app and the desktop widget are macOS-only, and its README is explicit that the auto-switch engine runs as a background service only on macOS while Windows and Linux get it in the foreground, with altero auto --once from cron or a systemd timer for anything unattended. It says it is not affiliated with Anthropic.

aicli-switch

The narrowest pitch of the set: switch accounts without re-authenticating, so that when one login reaches its usage limit you name another instead of signing in again. One Go binary, installed from npm or downloaded per platform for Windows, macOS and Linux, driven by a single command at the moment you need it.

cc-switch

A different scope: a cross-platform desktop application that manages Claude Code and several other coding CLIs in one place, rather than a switcher for Claude Code alone. Its README lists Claude Code, Codex, OpenCode and others as the tools it covers. If the thing you want is one desktop window over every agent CLI on your machine, this is the shape to look at; if you want only your Claude logins rotated, it is more than you asked for.

The group shares a shape. They manage which login the machine or the process uses, and you drive the choice or set a threshold. That fits a person working in one terminal at a time. It fits less well once several sessions are running at once and each of them wants an account at the same moment.

How does Omniscio handle multiple Claude accounts?

Omniscio keeps the logins itself and chooses one for each session as it starts. You add each subscription in Settings → Accounts with the same OAuth sign-in Claude Code uses, and from then on the pick is silent: you start a session and it lands on an account with room.

The default pick is a tier list

With one exception noted below, a spawn walks four tiers and takes the first that has capacity: your pinned account, then logins with primary capacity, ordered by the one with the most headroom first, then logins that can draw on extra-usage credits, then API-key accounts, which only count at all if you have allowed sessions to spawn on a key. Utilization is scored as the worse of the five-hour and seven-day numbers, so an account at 99% of its five-hour window loses to one at 80% of its weekly window.

Spreading is the opt-in, and pinning is its opposite

The setting Distribute sessions across accounts is off by default on a new install. With it on, the pick becomes a load balancer that spreads new sessions across the logins that have capacity, weighing how many sessions each is already carrying and which accounts have a reset coming. The library page for that setting has the full list of what it weighs, and the Omniscio library covers the rest of the account features. The load balancer never pins, which is why pinning applies only while distributing is off: the two are opposite instructions.

What happens at a limit

A login that Anthropic rate-limits leaves the picker immediately, so a session lands on another one that has room. It parks only when every login is limited, rather than being pushed back onto the account that just refused it, and once a window clears it resumes on its own — which can be on a different account than it started on. A running session never moves mid-turn: the pick happens at spawn and on the Continue after a rate-limit recovery.

Two kinds of limit are treated differently. An account whose meters are genuinely full sits out until its real reset. A short burst throttle, meaning a 429 on an account that still has headroom, benches it for about a minute and returns it early once a usage reading confirms the headroom is still there. That distinction matters when a subagent fan-out trips the request limit while the weekly allowance is barely touched.

When every login is spent

Omniscio raises an amber banner at the top of the sessions sidebar reading All accounts are at their usage limit, with a toast that offers View Accounts and one OS notification per 30 minutes. The banner cannot be muted, because its subject is that no new session can start.

A dead login is quarantined, not retried

Capacity is one failure and an invalid credential is another. When a token refresh is rejected twice on the same token, that login is marked dead and every account picker skips it, so new sessions never start against a credential that can only fail. Sessions that were on it move to a healthy login and resume. If Omniscio notices an idle login has gone dead, it asks you to sign it in before the next session fails.

Signing several back in is the tedious part, so Settings → Accounts offers Sign them back in: it drives the sign-in in your own Chrome, reads Anthropic's sign-in email from the Google account you have connected, and captures each account back into the pool. It runs on the Chrome bridge that feature needs, and the panel offers a button that opens the setting. It clicks through for you and asks only when its own click does not register; the last Authorize window is the one it hands you unless you have turned on drive any tab for that bridge.

Sessions on another machine can use the same pool

If some of your sessions run on your own Linux or Mac box over SSH, that machine normally uses its own Claude login. In Managed accounts mode you can switch it onto this pool in Settings → SSH Remotes with Use this computer's Claude accounts. Its sessions then draw from the same chooser and move to another account at a usage limit, while your sign-in stays on this computer and the remote holds a pass for one run.

What still needs a person?

Four things, and none of them is a session starting.

• Each subscription gets added once, with its own sign-in through Anthropic. No pool can sign itself into an account it has never seen.
• The automated re-login needs your connected Google account to read the sign-in email, and it hands you the page when its own click does not land.
• Capacity is not creatable. When every login is out, the options are another account, waiting for a reset, or turning on usage credits for the plan.
• A running turn stays where it is. Moving work between accounts happens between turns, not during one.