Your own subscription

Your own subscription is a provider like any other — you'll find it under the vendor grid when you add one. The difference is where it runs: through a CLI signed into a plan you already pay for, on your own computer or on a small cloud machine we run for you. Either way the login is made with the vendor's own sign-in and stays on the machine that does the work.

Supported runtimes

A local machine provider needs a runtime — the CLI that actually does the work. Which subscription pays follows from which runtime you pick.

One machine can hold logins for more than one runtime, and each provider is pinned to exactly one. A Codex login is never handed to a provider that runs Claude Code, so there's no risk of the wrong subscription being spent.

Which one should you pick?

• Claude Code if you have a Claude Pro, Max or Team plan — the most complete experience here: edits, git, pull requests and the app's web tools all work.
• Cursor if a Cursor subscription is what you already pay for — same full coding treatment, and its catalogue includes Cursor's own Composer models.
• Codex CLI if you have a ChatGPT plan — full coding treatment, including the pull-request tools.
• Antigravity if you want to spend nothing: it signs in with a plain Google account, free tier included. Google moved its consumer plans here from Gemini CLI in June 2026 — if you were using Gemini CLI on a Google AI Pro or Ultra plan, this is where that plan now works. Repository sessions edit files; the machine pushes for them, and pull requests go through the Repo panel.
• Gemini CLI only if you hold a Gemini Code Assist license (or use an API key) — Google no longer serves its consumer plans through it. Sessions edit files, the machine pushes, and the app's pull-request and web tools work in the run.
• CodeWhale if you use DeepSeek: an open-source terminal agent that spends the DeepSeek API key (or local model) you configure inside it — full coding treatment, pull-request tools included. Nothing about it is stored here.
• Ollama for chat that never leaves your hardware — see below.

Setting up each one, step by step

Every runtime here is a client you install and sign into yourself — the same one you would use in your own terminal. Configure My AI never sees the login; the companion runs the CLI next to it. Three steps each, and the second one is where they genuinely differ.

Claude Code

Spends: Your Claude Pro, Max or Team plan.

1. Install the client on that machine.

# npm (any platform, Node 18+)
npm install -g @anthropic-ai/claude-code

Check it landed with claude --version. Other install routes are on Claude Code's own page.

2. Sign in to Claude Code itself.

claude

Type `/login` at the prompt. It opens a browser; approve it with the Anthropic account your Claude plan is on. Claude Code is not available on the free plan.

3. Tell this account about it.

cma-agent runtimes:scan

A Claude Code provider then appears in your provider list. The scan is usually unnecessary — a paired machine re-checks itself every thirty seconds — but it is the thing to run when you have just signed in and would rather not wait.

Cursor

Spends: Your Cursor Pro, Ultra or Teams subscription.

1. Install the client on that machine.

# macOS, Linux, WSL
curl https://cursor.com/install -fsS | bash

Check it landed with cursor-agent --version. Other install routes are on Cursor's own page.

2. Sign in through the companion.

cma-agent runtimes:login --runtime cursor

Opens Cursor in your browser. Approve it with the account your Cursor subscription is on — the same login the editor uses.

3. Tell this account about it.

Nothing more to run — the sign-in above reports itself, and a Cursor provider appears in your provider list within seconds.

Gemini CLI

Spends: A Gemini Code Assist Standard or Enterprise license.

1. Install the client on that machine.

# npm (any platform, Node 18+)
npm install -g @google/gemini-cli

Check it landed with gemini --version. Other install routes are on Gemini CLI's own page.

2. Sign in to Gemini CLI itself.

gemini

Complete the Google sign-in in the browser it opens. Google stopped serving its consumer plans here on 2026-06-18 — a free, Pro or Ultra account belongs on Antigravity now.

3. Tell this account about it.

cma-agent runtimes:scan

A Gemini CLI provider then appears in your provider list. The scan is usually unnecessary — a paired machine re-checks itself every thirty seconds — but it is the thing to run when you have just signed in and would rather not wait.

Antigravity

Spends: A plain Google account — free tier included — or Google AI Pro / Ultra.

1. Install the client on that machine.

# macOS, Linux, WSL
curl -fsSL https://antigravity.google/cli/install.sh | bash

Check it landed with agy --version. Other install routes are on Antigravity's own page.

2. Sign in to Antigravity itself.

agy

The first run starts a Google sign-in and opens your browser. Over SSH it prints a URL and a one-time code instead.

3. Tell this account about it.

cma-agent runtimes:scan

A Antigravity provider then appears in your provider list. The scan is usually unnecessary — a paired machine re-checks itself every thirty seconds — but it is the thing to run when you have just signed in and would rather not wait.

Codex CLI

Spends: Your ChatGPT Plus, Pro, Business or Enterprise plan.

1. Install the client on that machine.

# npm (any platform)
npm install -g @openai/codex

Check it landed with codex --version. Other install routes are on Codex CLI's own page.

2. Sign in through the companion.

cma-agent runtimes:login --runtime codex

Choose "Sign in with ChatGPT" and approve it in the browser with the account your plan is on.

3. Tell this account about it.

Nothing more to run — the sign-in above reports itself, and a Codex CLI provider appears in your provider list within seconds.

Grok Build

Spends: Your SuperGrok, SuperGrok Plus or X Premium+ plan.

1. Install the client on that machine.

# macOS, Linux, WSL, Git Bash
curl -fsSL https://x.ai/cli/install.sh | bash
# Windows PowerShell
irm https://x.ai/cli/install.ps1 | iex
# npm (any platform)
npm i -g @xai-official/grok

Check it landed with grok --version. Other install routes are on Grok Build's own page.

2. Sign in through the companion.

cma-agent runtimes:login --runtime grok

Opens grok.com in your browser. Approve it with the account your SuperGrok or X Premium+ plan is on. The credential is written to that profile on your machine and never leaves it.

No browser on that machine? cma-agent runtimes:login --runtime grok --device-auth — On a machine with no browser — a server, or an SSH session — this prints a URL and a code to enter on any other device.

3. Tell this account about it.

Nothing more to run — the sign-in above reports itself, and a Grok Build provider appears in your provider list within seconds.

CodeWhale

Spends: Whatever you configure inside CodeWhale — usually a DeepSeek API key, billed per token rather than monthly, or a local model for nothing.

1. Install the client on that machine.

# Homebrew
brew tap Hmbown/deepseek-tui && brew install codewhale
# npm
npm install -g codewhale
# Cargo
cargo install codewhale-cli --locked

Check it landed with codewhale --version. Other install routes are on CodeWhale's own page.

2. Sign in to CodeWhale itself.

codewhale

Its own onboarding asks for a provider and a key. Nothing you enter there is stored here, or ever sent to us.

3. Tell this account about it.

cma-agent runtimes:scan

A CodeWhale provider then appears in your provider list. The scan is usually unnecessary — a paired machine re-checks itself every thirty seconds — but it is the thing to run when you have just signed in and would rather not wait.

Ollama

Spends: Nothing. Your own hardware runs it and the prompt never leaves the machine. It answers in text only — no files, no git, no pull requests.

1. Install the client on that machine.

# macOS, Linux
curl -fsSL https://ollama.com/install.sh | sh

Check it landed with ollama --version. Other install routes are on Ollama's own page.

2. Get a model onto the machine. There is no account to connect.

ollama pull llama3.2

There is no account. Pull at least one model and it appears in this app's model list after the next check-in, about thirty seconds later.

3. Tell this account about it.

cma-agent runtimes:scan

A Ollama provider then appears in your provider list. The scan is usually unnecessary — a paired machine re-checks itself every thirty seconds — but it is the thing to run when you have just signed in and would rather not wait.

Bringing your own model

Ollama is the odd one out in that table, and worth understanding on its own terms. It is not a subscription — it is a model already sitting on your disk. Nothing is spent when it runs, and the prompt never leaves the machine it runs on.

The reason it works here at all is the companion. Ollama listens on 127.0.0.1:11434, which is unreachable from our servers no matter what we do — but the companion is already on the right computer, so it simply asks the model next door. There is no tunnel to open, no port to forward, and nothing to expose to the internet.

The three steps are in Setting up each one above. What is worth adding here is what happens afterwards: an Ollama provider appears in your provider list, and its model dropdown holds exactly what that machine has pulled — grouped by family, so qwen2.5-coder:7b and :14b sit together rather than as two unrelated rows.

Pull another model later and it shows up after the next check-in, within about thirty seconds. Remove one with ollama rm and it disappears — the machine's library is the whole truth, and nothing here keeps a stale copy of it.

If Ollama listens somewhere other than the default — in a container, or on another box on your network — point the companion at it with CMA_OLLAMA_URL:

CMA_OLLAMA_URL=http://192.168.1.20:11434 cma-agent start

What it cannot do. An Ollama run answers with text. It has no tools, so it cannot read or edit files, run git, or open pull requests — a coding session pointed at it will describe a change rather than make one. Use a Claude Code, Cursor, Codex CLI or CodeWhale provider for work that has to change a repository, and Ollama for chat, drafting, summarising and anything you would rather keep entirely on your own hardware.

How it works

You install a small program called the companion on your Mac or Linux machine and pair it with your account. From then on, a configuration on a Local machine provider runs like this:

1. You send a message in Configure My AI, exactly as you would with any other provider.
2. We put the prompt in a short queue for your machine.
3. The companion — which is polling us, not the other way round — picks it up.
4. It runs the runtime you chose — your own Claude Code, Cursor, Codex, Antigravity, Gemini CLI or CodeWhale — which spends that subscription (or, for Ollama, your own model).
5. The answer comes back and appears in your chat.

The companion only makes outbound connections. Nothing on your machine is exposed to the internet, there are no ports to open, and no firewall rules to add.

What we store, and what we never see

This is the part worth reading twice. Setting this up does not mean handing us your Claude account.

There is no credential on our side to leak, and nothing stored here could be replayed against Anthropic. If you look at a device in Configure My AI you will notice there is no “reveal secret” button anywhere — that is not an oversight.

Prompts and answers pass through us in transit, and are held only long enough for your machine to pick them up. The lasting copy of a conversation lives with the chat or code session it belongs to, the same as every other provider.

What you need

• A Mac or Linux machine you can leave running when you want to use it. It does not have to be unlocked, or even in front of you — see Running while locked or in sleep mode. Or no machine at all: a cloud machine we run needs nothing installed anywhere.
• A supported runtime installed and signed in, with the plan you want to spend — Claude Code, Cursor, Gemini CLI, Antigravity, Codex CLI, Grok Build, CodeWhale, Ollama. Each one links to its own commands in Setting up each one.
• The companion: brew install 9thdesigns/tap/cma-agent
  Or, if you'd rather not install Homebrew, npm install -g https://github.com/9thdesigns/cma-agent — that one needs Node 20 or newer already on the machine, where Homebrew installs it for you.

Running it

Three commands, in this order. The third is the one people miss — a machine that paired and reported its logins still shows as Offline until something is listening, and nothing runs on it while it is stopped.

cma-agent pair                                        # once, with the code from the setup page
cma-agent runtimes:add --runtime claude_code --label "Work"
cma-agent start                                       # leave this running

cma-agent status answers "is this actually working?" at any point. It reports both what the machine can see and what Configure My AI can see, then lists what to do about any difference — a login that resolves locally but was never reported, a session that lapsed, a companion that isn't running. If a login is signed in but the web app hasn't heard about it, cma-agent runtimes:scan pushes it.

Then choose Local machine when adding a provider, pick the runtime, the machine and the login. In practice you rarely need to: each usable login becomes a provider by itself as soon as the machine reports it.

Several sessions at once

One machine runs up to three sessions at the same time. Each one works in its own checkout of the repository, so two sessions on the same project have separate files and separate branches rather than editing over each other — the clone is shared, the working tree is not.

Set it on Devices: press Edit next to a machine and choose Jobs at once, from one to 5. The machine picks the change up within seconds — nothing to restart, and no terminal.

Start more sessions than that and the extra ones queue rather than fail, and the session tells you the machine is busy — not offline. A folder you shared yourself with repos:add is the exception: that directory is yours, so two sessions pointed at it share it, exactly as two terminals would.

Running while locked or in sleep mode

You do not have to sit in front of the machine. A locked screen and a dark display change nothing about whether work runs — sleep is the only state that stops it, and sleep is something you can switch off. Keep the machine plugged in and on Wi-Fi and it will keep taking work while you are somewhere else entirely.

The distinction is worth being precise about, because “asleep” gets used for several states that behave nothing alike:

On a Mac

caffeinate is built into macOS and holds sleep off for exactly as long as the command it wraps is running. Start the companion through it and the assertion goes away by itself when you stop the companion — there is no setting left switched on afterwards:

caffeinate -is cma-agent start

Two flags, because they cover different halves of the problem. -s blocks system sleep outright, and macOS only honours it while the machine is on the power adapter — which is the charged-and-plugged-in case, and the one to design around. -i blocks idle sleep, the kind that arrives after a stretch of no keyboard and no mouse, and it holds on battery too. Together they cover a machine you walked away from, whether or not it is on the charger at that moment.

If you would rather set it once and stop thinking about it, do the same thing in System Settings → Battery → Options on a laptop (“Prevent automatic sleeping on power adapter when the display is off”), or System Settings → Energy Saver on a desktop. Then plain cma-agent start is enough. Lock the screen with Control+⌘+Q and walk away; the machine stays Online and keeps picking up work.

On Linux

Most Linux servers never sleep to begin with. A desktop or a laptop might, and systemd-inhibit is the same idea as caffeinate — scoped to the process it wraps, gone when that process exits:

systemd-inhibit --what=idle:sleep --why="cma-agent" cma-agent start

Wi-Fi, and what happens when it drops

The companion polls us; we never connect to it. That means a network it can reach is the whole requirement — no port forwarding, no static address, and nothing that stops working when you move the machine to a different Wi-Fi network.

A drop is not a failure state. The companion retries on its own with a widening backoff, and picks work up again as soon as the connection is back. The machine flips to Offline in the web app while it is out of touch and back to Online on the next heartbeat, thirty seconds apart. Nothing needs re-pairing, and nothing needs restarting.

One thing a lock screen does not survive

A restart. After a reboot the machine sits at the login window with FileVault holding the disk closed, and nothing of yours is running yet — the companion included. Locked after you logged in is fine; rebooted and never logged into is not. If the machine is going to be away from you for days rather than hours, start the companion as a launchd or systemd service so a restart brings it back without you, and make sure the runtime's login is one you have signed in recently — see When a login expires.

cma-agent cheat sheet

Every command the companion takes, in one place. cma-agent on its own prints the same list, and cma-agent status is the one to reach for when you are not sure which of these you need — it names the next step rather than making you guess.

Setup and state

Running work

Logins

Local repositories

Using more than one Claude account

Plenty of people have a work Claude account and a personal one. The companion keeps each login in its own place on your machine, so they never mix, and you choose per provider which one pays. Below is the whole thing end to end — six commands, and a check after each one.

1. Pair the machine, once

Skip this if cma-agent status already says Paired: yes.

cma-agent pair          # paste the code from the setup page
cma-agent status        # → Paired: yes

2. Add the first login and sign into it

The label is yours to choose — it becomes the provider's name in the web app. Each command opens Claude's own sign-in in your browser; Configure My AI never sees it.

cma-agent runtimes:add --runtime claude_code --label "Work"

Sign in as the work account in the browser window that opens. When it finishes, the companion re-checks the login it just created and tells you whether it resolved — “you signed in” and “this login works” are genuinely different claims, so it does not take your word for it.

3. Add the second login and sign into it

cma-agent runtimes:add --runtime claude_code --label "Personal"

Sign in as the personal account this time. If the browser sends you straight through without asking which account — because you are already signed in to claude.ai as the first one — sign out there first, or use a private window, then run the command again.

4. Check which account each login actually signs in as

This is the command to remember. It reads each login's own config directory and reports the account it resolves to — not the label you typed, which is the one fact that cannot be wrong and also says nothing about which subscription pays.

cma-agent accounts

Claude Code  [claude_code]  2.1.220
  ✓ Default  [default]
      account:   [email protected]
      folder:    this machine's own Claude Code login (no CLAUDE_CONFIG_DIR override)
      provider:  "Claude Code on MacBookPro"
  ✓ Work  [work]
      account:   [email protected]
      folder:    ~/.configure-my-ai/claude-profiles/work
      provider:  "Claude Code · Work"
  ✓ Personal  [personal]
      account:   [email protected]
      folder:    ~/.configure-my-ai/claude-profiles/personal
      provider:  "Claude Code · Personal"

Confirming which plan pays
  1. The account above is read from the login's own config directory,
     not from the label — so it is what the CLI will actually sign in as.
  2. `cma-agent start` prints the same account on the line that opens
     every run: → Claude Code (account: [email protected]): claude-opus-5 …
  3. The web app shows it too, in the first line of a session's thinking log.
  4. Anthropic's own record is the last word: check claude.ai/settings/usage
     while signed in as that account.

Three things to look at, in this order:

• Each account: line is the address you expect. If “Work” shows your personal address, sign that login in again — see the warning below.
• No two logins show the same address. If they do, they are one subscription wearing two labels, and the command says so outright.
• Each has a provider:. That is the name to pick in the web app. “none yet” means the login has not reached us — run cma-agent runtimes:scan.

5. Start the companion

cma-agent start

One process serves every login on the machine. It prints what it is holding as it starts, so the accounts are on screen before any work runs:

cma-agent 0.11.1 · Claude Code 2.1.220
Host: MacBookPro
  · Claude Code · Default [default] — account: [email protected]
  · Claude Code · Work [work] — account: [email protected]
  · Claude Code · Personal [personal] — account: [email protected]
Waiting for work — up to 3 at a time. Leave this running.

And every run opens with the account that is about to be spent:

→ Claude Code (account: [email protected]): claude-opus-5 on "work" in ~/code/site…
[0034]   · Starting up
[0034]   · Reading app/models/user.rb

6. Point each provider where you want it

You do not create the providers — each usable login becomes one on its own, and they appear in the provider list of every configuration alongside your API keys:

• Claude Code · Work — spends the work plan;
• Claude Code · Personal — spends the personal one;
• Claude Code on MacBookPro — the machine's ambient login, if it has one.

Open a configuration, use the Provider switcher to pick one, and everything that uses that configuration — chats, code sessions, the composer — spends that account from then on. The dropdown shows the resolved address next to each login, so you are picking an account rather than a name.

Providers you already had may name no login at all — anything created before your second login existed. Those run on whichever account this machine treats as its default, which is yours to set with cma-agent use.

Choosing which account runs the work

Two things decide this, and they answer different questions. They cannot contradict each other, because only one of them is ever consulted for a given piece of work.

So if a machine holds two Claude accounts and work keeps coming out of the wrong one, the fix is whichever of those two applies. To see where you stand, ask the machine — it lists every login with the account each would actually spend:

cma-agent use

Claude Code: work that names no login runs on
  Default [default] — account: [email protected]

Change it to any of:
  · cma-agent use default     Default — account: [email protected]
    cma-agent use 9th         9th — account: [email protected]

Then choose:

cma-agent use 9th
cma-agent start

The restart is not optional — cma-agent start reads the choice once, when it starts. Its opening banner then marks the login that unnamed work lands on, so the confirmation is in front of you every time you run it. cma-agent use default puts it back.

It is per runtime: cma-agent use --runtime cursor is a separate decision, because a login called “work” under Claude Code and one under Cursor are different logins that share a word. And a choice pointing at a login you later delete falls back to the ambient one rather than running against a directory with no credential in it.

Being sure which plan paid

Four independent checks, cheapest first. They should all say the same thing; if two disagree, believe Anthropic's.

Switching between logins in Configure My AI

There is nothing to configure for this. Each login the machine reports becomes an ordinary provider, so switching between two Claude accounts is the same action as switching from Anthropic to OpenAI — pick a different provider.

The naming follows the label you gave the login:

• a labelled login becomes Claude Code · Work, Claude Code · Personal;
• the machine's ambient login — the one that was already signed in — becomes Claude Code on MacBookPro, named after the machine.

Then, wherever you want to change which one pays:

• A configuration. Open it and use the Provider switcher: choose the login, then the model. Your system prompt, rules, training data and model settings are untouched, so everything that uses that configuration — chats, endpoints, widgets, code sessions — moves with it.
• One code session. The session's own switcher changes the provider for that session without touching the configuration behind it, which is what you want when a single piece of work should go on the work account.
• The dashboard composer. The same switcher, on the box you type the first message into.

When a login expires

Claude sign-ins do not last forever. When one lapses, a run on it stops with “That Claude login needs signing in again”, and cma-agent status shows the login as logged out — on this machine and in Configure My AI both. Nothing is broken and nothing needs re-pairing; the login just needs renewing.

Sign-in opens your browser and takes over the terminal, so stop the companion first with Ctrl+C — the sign-in starts it again when it finishes. Then, per login:

cma-agent runtimes:login --runtime claude_code            # the login unnamed work runs on
cma-agent runtimes:login --runtime claude_code --profile work
cma-agent runtimes:login --runtime claude_code --profile default   # the ambient one, by name

The sign-in hands the terminal to Claude Code's own console. Sign in there, leave it with exit (or Ctrl+D), and the companion starts back up in the same window — there is no second command to remember. Add --no-start when you would rather it stopped at the sign-in.

runtimes:scan is usually unnecessary — signing in reports the new state by itself — but it costs nothing and it is what to reach for when the machine says a login works and the web app still shows it signed out.

cma-agent start also says so on the way up, so an expired login is something you read in the terminal rather than discover from a failed run minutes later:

! The Claude Code login "9th" is signed out — work sent to it will fail.
    Sign it in with: cma-agent runtimes:login --runtime claude_code --profile 9th

Working on repositories already on your machine

A code session running on one of your machines can work against a git repository that already exists there — its real branches, its real history, its real uncommitted changes — instead of a copy fetched from GitHub. The turn runs inside that directory, so it reads and edits the actual files.

Nothing on your computer is visible to Configure My AI until you name a folder. There is no default location and no “scan my home directory” option. Share one, on the machine:

cma-agent repos:add ~/code      # a folder of projects
cma-agent repos:add ~/work/api  # or a single repository
cma-agent repos:list            # what's shared, and what was found
cma-agent repos:remove ~/code   # stop sharing

Then open a code session whose provider is that machine, and choose a repository under Repo → Local repository. From there the session can read the commit history and branches. While the checkout is clean the panel says so and stops there — there is nothing to commit and nothing has been branched. Once there are changes it shows them, names the branch it will create for the pull request, and Commit, push & open PR commits the working tree onto that branch, pushes it using the git credentials that machine already has, and opens the pull request with your GitHub connection. Your git credentials are never sent to us, and we never need them.

Every path we ask about is checked against the folders you shared — symlinks resolved, parent traversal rejected — and anything outside them is refused by the companion rather than honoured. Claude Code is allowed to edit files in that directory and is not given free rein over the machine.

This needs cma-agent 0.3.0 or newer — check with cma-agent --version. If you're behind, upgrade it the same way you installed it (brew update && brew upgrade cma-agent for Homebrew — the refresh first, or Homebrew upgrades against a formula it may not have re-read for a day), then run cma-agent start again so the new build is the one picking up work.

Using it day to day

There is nothing new to learn. You use Configure My AI in your browser exactly as you do now — open a chat, pick a configuration, send a message. If that configuration's provider is one of your device's, the answer is generated by Claude Code on your machine and appears in the browser like any other reply.

The companion is background plumbing. Once it's installed you never open it again; it starts with your machine and waits. The only time you'll think about it is when a device is asleep, and the app will tell you that before you type rather than after you send.

Only the label is sent to us. We do not store which Claude account a login belongs to, beyond an optional masked hint like d•••@acme.com that exists purely so you can tell two logins apart in a dropdown.

Sessions and the two-week rule

A paired machine stays authorised as long as it keeps checking in. Every check-in extends its session by two weeks, so a machine you use regularly never asks you for anything again.

If a machine goes quiet for more than two weeks — you switched laptops, or uninstalled the companion — its session lapses. Providers pointing at it will say Needs re-verify rather than silently failing. To bring it back:

cma-agent verify

That re-checks your Claude logins are still valid and restores the session. It deliberately will not restore a machine whose Claude logins have all expired — that would just move the failure to your next message.

What it can and can't run

Your Claude plan can only pay for work while your machine is awake. That makes this a great fit for anything you are present for, and the wrong fit for anything that has to run without you.

So this is an addition to your setup, not a replacement for it. Most people keep an API key or managed credits for the always-on surfaces and use their Claude plan for day-to-day work.

Costs and limits

Runs on your Claude plan draw on that plan's usage limits, not on your Configure My AI credits. Nothing is charged to your wallet, and the Usage page marks these runs as having happened on your machine so you can tell them apart.

Hitting your Claude plan's rate limit looks like exactly that — a clear message saying your plan is rate limited, not a generic failure. Waiting or switching that configuration to another provider both work.

Four ways people set this up

One Mac, one Claude plan

The common case, and the whole of the setup. Nothing to label and no profile to think about — the Claude Code login already on the machine is picked up and becomes a provider named after it.

cma-agent pair          # once, with the code from the setup page
cma-agent start         # leave this running

Open a chat, pick Claude Code on your-machine as the provider, and every turn is paid for by the plan you already have. Close the laptop and work stops until you open it again — which is the trade this makes.

Work and personal on the same machine

Two logins, two providers, and the client work never lands on your personal plan.

cma-agent runtimes:add --runtime claude_code --label "Work" --account [email protected]
cma-agent runtimes:add --runtime claude_code --label "Personal"
cma-agent accounts        # check each one resolved to the account you meant

Keep two configurations — one pinned to Claude Code · Work, one to Claude Code · Personal — and choose between them by choosing the configuration. See Switching between logins, and Using more than one Claude account for the whole thing step by step with the checks after each one.

A repository that only exists on your machine

A client project with uncommitted work in it, or a repo that is not on GitHub at all. Share the folder it lives in and a code session can work in the real checkout — real branches, real history, real uncommitted changes.

cma-agent repos:add ~/code       # the folder your projects live in
cma-agent repos:list             # confirm what it found

Then start a code session, choose Repo → Local repository, and pick it. Nothing outside the folders you shared is reachable — see Working on repositories already on your machine.

A laptop for you, a key for everything else

The setup most people end up with. Your own plan pays for the work you are present for; something that does not depend on a laptop being awake pays for the rest.

• Chats and code sessions → the Local machine provider.
• Chat widgets, API endpoints and scheduled bots → an API key or managed credits.

If you have a Linux box or a Mac mini that is always on, pair that instead of your laptop and the first half of that split stops depending on whether you closed the lid. On a laptop, caffeinate -is cma-agent start gets most of the way there — a locked machine keeps working, as long as the lid stays open. See Running while locked or in sleep mode.

Running on a cloud machine instead

Everything above assumes a computer you own. If you would rather not leave one on — or want scheduled bots to run on your plan while your laptop is shut — pick Devices → Use your own subscription → A cloud machine we run. We stand up a small machine with the CLI and the companion already installed, and it behaves exactly like a paired laptop from then on: the same provider, the same queue, the same runs.

What happens when you create one

1. You pick the plan it should run (Claude Code, Cursor, Antigravity, Codex CLI, and Grok Build), a region and a size.
2. A one-CPU machine with a small persistent disk is created for you. The disk is what holds the sign-in and the tools, so they survive every stop and start.
3. The runtime and the companion are installed onto it, and it pairs with your account by itself — the same single-use code a laptop redeems, handed straight to the machine.
4. It hands you the vendor's sign-in link. The machine has no browser, so you open the link on any device, approve it with the account your plan is on and, for Claude Code, paste back the code it shows you. The credential the vendor issues is written on the machine and never reaches us.
5. The provider appears on your configurations, and the machine goes to sleep until something sends it work.

It sleeps, and it wakes itself

A cloud machine stops 10 minutes after its last job. When a chat message, a code session or a scheduled bot sends it work, we start it again and the queued run is picked up within seconds — well inside the queue's own clock. The pill on the Devices page reads Sleeping or Awake, and neither is a problem.

This is also what makes it cheap. About 3¢ an hour from your credits while it is awake, and nothing while it sleeps. The minutes are settled to your credits as they accrue, and a machine cannot be woken when your credits are at zero — it says so on the machine's page rather than running up a bill.

Knowing what the subscription is doing

On a laptop you would see the vendor's error in your terminal. A cloud machine reports it instead, as a status next to the machine:

The verdict comes from the machine: every run that fails is classified there, in the vendor's own words, and every scan of the login reports the same way. A rate limit shows the vendor's reset time when it gives one. Sign in needed has a button beside it that starts the sign-in again from the machine's page.

Kept up to date

The machine checks for a newer companion and a newer Claude Code and Cursor (whichever it runs) when it boots and every 24 hours while it stays awake. When either is behind, it installs the update the next time it is idle and restarts itself. A machine asleep for a week checks on the boot that wakes it, so nothing runs stale for more than a day of use.

What stays on the laptop

• Gemini CLI needs a Gemini Code Assist license or an API key rather than a plan — run it on your own computer, or use a Google provider with a key.
• CodeWhale spends a DeepSeek API key you configure inside it, not a subscription — a DeepSeek provider with that key does the same job here.
• Ollama runs a model on your own hardware, which is the whole point of it. A small cloud machine has no GPU and no room for a model.
• Repositories already on your disk. A cloud machine clones from GitHub, the way a session on an API key does; it cannot see a folder on your computer.

What we store for a cloud machine

The same as for a laptop — a name, which plan it runs, when it last checked in — plus where it lives at the provider and the log of what setting it up did. The sign-in link the vendor prints passes through us on its way to your browser, and for Claude Code so does the single-use code you paste back, which is useless without the verifier the machine kept. The token the vendor issues is written on the machine's disk and is never read by us. Removing the machine deletes that disk.

When something isn't working

When updating says “already installed”

brew upgrade cma-agent compares what you have installed against the copy of our formula in Homebrew’s local clone of the tap — and Homebrew refreshes that clone on a schedule of its own, roughly daily, not when a release comes out. Update shortly after a new version lands and Homebrew has not seen it yet: it prints already installed, changes nothing, and reads exactly like being up to date. Refresh first — which is why the update instructions are two lines, not one:

brew update && brew upgrade cma-agent

If it still says already installed, the clone is not merely stale — it is stuck, or no longer there. These two commands say which:

brew tap | grep 9thdesigns/tap
git -C "$(brew --repo 9thdesigns/tap)" log --oneline -3

Nothing listed, or no such directory, means the tap is gone and Homebrew is falling back to the formula stored inside your installed copy — which can only ever name the version you already have. A commit older than the current release means the clone stopped fetching. Either way, re-tapping fixes it, and it does not uninstall anything:

brew untap 9thdesigns/tap
brew tap 9thdesigns/tap
brew upgrade cma-agent
cma-agent start

And if even that reports the old version, replace the installed copy outright:

brew uninstall cma-agent
brew install 9thdesigns/tap/cma-agent
cma-agent start

Confirm it took with cma-agent --version. The version each machine last reported is also on Devices, which updates on the next heartbeat — every 30 seconds — so you can check without a terminal.

Turning it off

On Devices you can:

• Revoke — the machine stops running work immediately. Providers pointing at it pause with an explanation, and pairing it again restores them.
• Remove — deletes it entirely. Any provider using it will need a different one.

Uninstalling the companion (brew uninstall cma-agent, or npm uninstall -g @configuremyai/cma-agent if you installed it that way) has the same effect from the other side: it stops checking in, and its session lapses within two weeks.