> ## Documentation Index
> Fetch the complete documentation index at: https://continuum-three-olive.vercel.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Multiple Accounts

> Run two or more subscriptions for the same provider side by side — add, pin, isolate, and meter each account separately.

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.

<Note>
  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](/docs/features/remote-devices) and [Hosted inference](/docs/features/hosted-inference) for that one.
</Note>

## 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:

| Provider                   | How accounts are kept apart                                                           |
| -------------------------- | ------------------------------------------------------------------------------------- |
| Claude                     | Its own config directory (`CLAUDE_CONFIG_DIR`) plus a per-account Keychain partition. |
| Codex                      | Its own config directory (`CODEX_HOME`).                                              |
| Antigravity (Gemini)       | An isolated mini-`HOME`, because the CLI ignores a config-dir variable.               |
| OpenCode, OpenRouter, Z.ai | Their own data directory (`XDG_DATA_HOME`) plus a per-account API key.                |
| Grok                       | Its own config directory (`GROK_HOME`) plus a per-account API key.                    |
| Cursor                     | Per-account API key only — no config directory.                                       |
| Continuum hosted inference | A per-account member session and inference key, each in its own Keychain partition.   |

<Note>
  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.
</Note>

## Adding an account

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Warning>
  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.
</Warning>

## 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.

| Mechanism                 | What it does                                                                                                                                                                                                                                                                                                                          |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Config-dir isolation**  | Sets the provider's config-directory variable to the account's isolated root so auth, history and settings resolve there. Your real `HOME` is **not** swapped — a full `HOME` override would break `git`, `ssh`, `gh` and `node` in your worktrees.                                                                                   |
| **Env scrubbing**         | Strips inherited provider variables (`CLAUDE_*`, `ANTHROPIC_*`, `CODEX_*`, `OPENAI_*`, `ZAI_*`, `GROK_*` and more) from the spawned child, then injects only that account's secrets — so a stray key from one account can't leak into another's process. Third-party agents additionally never see your Anthropic credentials at all. |
| **Keychain partitioning** | Each account's token or API key lives in its own Keychain item, separate from the default and from every other account.                                                                                                                                                                                                               |
| **Fail-closed spawn**     | A session pinned to an account that was removed, that has no stored credential, or that can't be isolated **refuses to spawn** with a re-authenticate error. It never silently falls back to the default subscription. Wrong-account billing under a "work" label is the failure mode being defended against.                         |

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

<Tabs>
  <Tab title="Usage gauges">
    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.
  </Tab>

  <Tab title="Historical analytics">
    The token and cost **Analytics** roll **every account's history into the aggregate totals**. Continuum reads each secondary's history directory under its isolated config root in addition to the default locations, and the directory list is re-read on each refresh — so an account you add in Settings joins the totals on the next refresh without a relaunch.

    There is still **no per-account analytics breakdown**. Totals are aggregated across all accounts for a provider.
  </Tab>
</Tabs>

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](/docs/privacy) and [Security](/docs/security). For connecting subscriptions in the first place, see the [Providers overview](/docs/providers/overview).