Several accounts per agent: two subscriptions, one Termic

Most people who run agents all day end up with more than one login: a work subscription and a personal one, or two accounts for two clients. Termic lets an agent hold several named credential sets, lets each task choose which one it runs as, and can move a task from one to the other when the first runs out.

This shipped in 1.3.0 and is off until you name a second account.

Termic never handles your credential

Termic does not read, copy, store, export or back up a credential. Adding an account creates an empty directory and points the agent’s own configuration variable at it. You then run the agent’s own login, in its own terminal, exactly as you would have anyway, and the agent writes its own credential into that directory.

So there is nothing to import or migrate, and no credential vault. A new account is signed out until you sign in, and the interface shows it as signed out.

The first name is the login you already have

Naming your first credential set does not create one. You already had a login; this is the name you are giving it.

So the first step asks for two names at once: one for the account the agent is using right now, and one for the new account. Naming only what you already have leaves you with one account and no second, and Termic would then have to tell someone whose agent works perfectly that they are “not signed in”.

The account you already had relocates nothing. It keeps using the agent’s ordinary configuration directory, so an install that adopts a name and stops there is byte-for-byte what it was.

Which agents can do this

This table comes from testing each CLI, because a failure here is silent. Several agents keep the token in the OS keyring and only the settings in the configuration directory. Whether moving that directory separates two logins depends entirely on how the keyring item is keyed.

Termic refuses agents with a fixed keyring name, because the override looks like it worked. Point one at a new directory and it finds no settings and asks you to sign in. Sign in, and the token lands back in the same shared slot, and your two “accounts” are now one account. Those agents get no account control, only a sentence explaining why.

What a second account shares

An account owns its credential and nothing else. Everything that is not a credential is shared back to your main configuration by symbolic link, at the moment the account is created:

• your settings and permissions,
• your instructions file (CLAUDE.md, AGENTS.md),
• your skills, commands and prompts,
• your conversation history and transcripts.

Switching accounts changes only the login. Without the shared links, a second account would be a blank agent with no instructions, permissions or history, and switching to it mid-task would lose the conversation.

Where to find it

It shows up in three places:

• Settings, Agents. The canonical place. Each agent’s card lists its credential sets at the top, above its command and args.
• The task footer. Once an agent has more than one account, the footer chip names the one the task is running as. Click it for the switcher, the plan usage and the automatic-switch option, all in one panel.
• The usage popover, which offers to add a second set at the point where you are looking at a number that is nearly spent.

The footer chip’s panel shows usage, the account it belongs to, and the manual and automatic switch.

Each agent’s card carries its credential sets at the top, before the fields that say how it runs.

Scoping: which profile offers what

The account list and the default live on the agent’s entry in settings, so they are per profile automatically. A work profile can default to a work account while a personal one defaults to yours.

The logins themselves are machine-wide, keyed by the name you gave them. Two profiles that both offer an account called “Work” address the same login, so signing in once covers both. A profile does not own logins; it owns which names it offers and which is default.

The same rule means names are frozen once created. For Claude the store path is hashed into the keychain item’s name, so renaming would move the directory, change the hash, and log that account out of a credential that is still perfectly good. Remove and add instead; that costs one sign-in.

Signing a new account in

A new account starts signed out. Only the agent’s own login can fill it.

The catch is that the agent in front of you is still running on the old account, so running /login there signs the old one in again. Picking an account you have not signed into yet therefore opens a tab in the same task, titled Sign in: <name>, where the agent runs as the new account. Run its login there, close the tab, then pick the account again to move the task over.

It opens a tab instead of restarting, so the running conversation isn’t interrupted.

Switching a task that is already running

A running process cannot have its environment changed underneath it, so a switch writes a setting and the new login takes effect on the agent’s next start.

That doesn’t help mid-session, so Termic offers a restart. Accept it and the agent restarts on the other account and resumes the same conversation, which works because history is shared across accounts. Decline it and the change stays staged for the next start. The confirmation can be turned off once you have seen it, and re-enabled in Settings, Tasks.

While a switch is staged, the footer shows both: the account the process is running as, whose numbers are on screen, and the one it will move to.

Switching when an account runs out

For Claude and Codex, Termic can read how much of a subscription’s rolling limits the current account has spent. That makes an automatic switch possible.

It is off by default, and it is one checkbox per agent, in the panel behind the footer chip. When it is on and the account in use passes 95% of a rolling window, Termic:

1. moves the task to an account it has seen headroom on,
2. restarts the agent there, resuming the conversation,
3. sends it “continue”, because the turn that hit the wall still has to be asked for again and nobody is at the keyboard,
4. and says what it did, so the change is not something you discover by wondering why a number moved.

It will never move to an account nobody has signed into. An empty store cannot start the agent at all, so switching to it would be a downgrade from merely being near a limit. It also only moves one task: the agent’s default is untouched, exactly like a manual switch.

Docker needs its own sign-in

Termic’s Docker sandbox never reads the host’s configuration directory, so a login performed on your Mac is invisible inside a container. You sign in once on the host and once in Docker, and each login is shared across every profile.

A container that could read the host’s credential store would defeat the point of the container.

Sandboxed agents

An account’s store sits outside the agent’s usual configuration directory, so the Seatbelt sandbox has to be told about it explicitly. Termic does that for you: the account in use is allowed for read and write, and only that one. A sandboxed agent can sign in and refresh its own token on the account it is running as, and cannot reach the others.

What about the terms of service

Holding several subscriptions is not a terms violation. What draws suspensions is routing subscription tokens through third-party clients and relay servers that impersonate the official one.

Termic runs the real CLI and never speaks to any provider’s API itself. Isolating an account with the CLI’s own documented configuration variable is the pattern vendors have publicly accepted, and it is the only mechanism Termic uses: no token is lifted out of a keychain and planted elsewhere.

Related

• Profiles: separate windows, and how they pick which account to use.
• Agents & the registry: the built-in agents and what each one supports.
• Docker sandbox: why it needs its own sign-in.
• Sandbox overview: what an agent can reach when it is caged.