Skip to main content
Continuum can drive more than one account per provider on the same machine. Sign in a personal Claude plan and a work Claude plan, or two separate Codex subscriptions, and keep them cleanly apart: each account gets its own isolated config, its own gauge, and its own entry in the account picker. Spend stays on the account you chose — it is never silently billed to the wrong one. Accounts are configured on a host and then travel with it. Add one on your Mac and it shows up in the pickers and gauges on your iPhone and in the web app, because account identity rides along with model selection, session creation, execution and quota rather than being a local-only setting.
Two different things in Continuum are called “account”. This page is about provider accounts — your Claude, Codex, Cursor or Z.ai subscriptions. Your Continuum account is the email you sign in with to sync devices and buy hosted inference; see Remote Devices and Hosted inference for that one.

​
Why you would want this

  • Separate personal and work quotas. A personal Claude plan for side projects and a work plan for the day job, each metering against its own rolling window and weekly cap.
  • Two Codex subscriptions — a Pro and a Team plan, say — without logging out of one to use the other.
  • Pick the billing account per task. Start a coding session and choose which account pays for it.
Your existing single account keeps working untouched. It is always present as the default account for its provider; adding accounts only puts peers next to it.

​
Which providers support it

Every provider Continuum ships can hold more than one account, but the mechanism differs by how the provider authenticates:
Not every provider reports quota per account. Subscription providers (Claude, Codex) meter each account independently. Several API-key providers expose no independently attributable quota, so their secondary accounts get a picker entry but no separate gauge — the add-account sheet says so on the last step.

​
Adding an account

Open Settings → Providers. Under each provider you’ll find an Accounts list with a button to add another account.
1

Name the account

Give it a short slug — work, personal, team. The name becomes part of the account’s isolated config path and its terminal shim, so it can’t contain /, \, or any whitespace, and can’t start with a dot. The sheet rejects a name that already exists for that provider.
2

Authenticate

What happens next depends on how the provider signs in:
  • Claude runs claude setup-token in an embedded terminal. Continuum watches the output, captures the sk-ant-oat01-… token automatically, and stores it in a per-account Keychain partition. If the capture misses, a paste field below the terminal takes it manually.
  • Codex runs codex login --device-auth. A Use CLI login button falls back to the older browser-callback codex login when device-code auth isn’t available for that account.
  • API-key providers (Cursor, Grok, OpenRouter, Z.ai, OpenCode) just take the key in a secure field.
  • Continuum hosted inference signs in through your browser with a device code.
Only one sign-in runs at a time — the CLI OAuth callback binds a fixed localhost port, so two concurrent logins would collide. Starting a second one tells you to finish the first.
3

Done

The account starts polling its gauge (where the provider reports one) and appears in the Code account picker. For Claude, Codex and Antigravity, Continuum also installs a terminal shim at ~/.local/bin/<provider>-<name> — claude-work, codex-team — so you can use the isolated account from any shell. API-key accounts get no shim and are marked In-app only: their credential lives in the Keychain and is handed only to sessions Continuum spawns.
Continuum never re-runs claude setup-token against your default Claude account. Claude Code stores its credential in a single per-OS-user Keychain item, so a second login there would clobber your primary sign-in. Secondaries get their own Keychain partition; the default account is re-authenticated through Claude Code itself.

​
How isolation works

Each secondary account is a configured instance: a provider plus a stable name (claude/work, codex/team). When Continuum spawns a CLI for that instance it points the provider at the account’s own config root and leaves the rest of your environment alone. Isolated config roots live under ~/Library/Application Support/Clawdmeter/Instances/<provider>/<name>/. That layout never crosses the wire — your other clients only ever see a stable id and a label.

​
What’s stored, and where

Secondary accounts are persisted to ~/Library/Application Support/Clawdmeter/provider-instances.json, next to sessions.json and workspaces.json. The file records only a provider, a name, a config root and a creation date — no secrets. Tokens and API keys live in Keychain partitions; Codex’s own auth.json lives inside the account’s config root. Your default account for each provider is never written to that file. It is synthesized in memory at launch, so a corrupted or deleted provider-instances.json can never take your default account away — secondaries vanish, the default stays.

​
Pinning a session to an account

When a provider has two or more accounts, an account picker appears where you choose that provider:
  • The Code composer on the Mac — a compact pill on the bottom bar that opens a Default / work / personal menu.
  • The new-session sheet on iPhone.
  • The Usage surfaces, as account toggles that switch which account the gauges are reading.
Pick default or a named account; the choice rides on the request as the account to bill, and Continuum remembers your last pick per provider. If you pinned an account that was later removed, the picker degrades cleanly to the default instead of erroring. A provider with a single account shows no picker at all. In Settings → Providers you can also mark which account is the default Code account, rename any account (including the default), and disconnect a secondary — with a choice between keeping and deleting its local sign-in and history. When a stored credential is actually rejected, the row turns red and offers a one-click Re-log in; healthy accounts and transient network blips don’t trigger it. The web and desktop apps manage accounts from Settings → Providers too, with per-account model, effort and permission defaults. They do not currently offer an account picker inside the Code screen itself.

​
Gauges and analytics

On the Mac Usage tab, a provider with more than one account renders as a single card with account toggle pills in its header — tap a pill to switch which account’s live limits the meters below are showing. A single-account provider renders exactly as before, with no pills.The menu-bar popover has the same account sub-toggle, shown only when the selected provider actually has a secondary. There is no separate menu-bar status item per account — the menu-bar gauge itself stays on one account at a time.On iPhone, secondary accounts surface under the active provider’s hero gauge, and the newer Usage screen uses account pills like the Mac. Account renames travel with the usage data, so a rename on the Mac shows up on your other clients without a second round-trip.
If you upload usage to an organization, that upload has no per-account dimension either: two Claude subscriptions on one Mac arrive at the org as one undifferentiated Claude stream.

​
Limitations

  • No per-account analytics breakdown. Historical totals aggregate across accounts, on the device and in org uploads alike.
  • No per-account menu-bar gauge. The menu bar shows one account at a time; there’s no second status item.
  • Spawn-mode terminal tiles always use the default account. The batch terminal grid has no per-tile account pin.
  • Not every provider reports per-account quota. API-key providers that don’t expose attributable usage get a picker entry but no independent gauge.
  • Older paired hosts degrade to the default. A client paired to a host too old to advertise the account list simply shows no picker and uses the default account — nothing fails, you just don’t get the choice. Update the host to get it back.
For how account isolation fits the broader credential and privacy model, see Privacy and Security. For connecting subscriptions in the first place, see the Providers overview.