Docs / Set up accounts

Set up the accounts that do the work

Two things, once: tell Oga which accounts it may hand work to, then point the coding agent you already use at Oga.

Let your coding agent reach Oga

Connect tools in Settings → Connections connects the coding agents Oga finds on your Mac. Existing connections are backed up first.

Setting one up by hand instead? Point it at http://127.0.0.1:7331/mcp. Your agent can then hand work to Oga like any other connected tool.

Add an account

On first open, Oga directs you to connect your AI before you delegate. You can also open Settings → Workers to add an account you already use. Every worker holds:

• Which provider tool it runs.
• The model it uses when nothing else is named.
• Any environment values it needs. Anything that looks like a key, token, secret, or password is hidden everywhere Oga shows it.

Each worker can use its own sign-in. Add environment values in the worker settings when a provider needs them.

How Oga talks to a worker

Oga talks to a worker's tool over the Agent Client Protocol (ACP) when it can run that tool this way, and through the tool's own command line otherwise. Either way the work runs on the same account, with the same limits on what it may touch.

• Claude, Codex, OpenCode, OpenCode 2, Antigravity, Pi, fx, and Cursor workers connect over ACP.
• Claude needs one extra install to connect this way: npm install -g @agentclientprotocol/claude-agent-acp. Without it, Claude workers use their command line.
• Codex needs one too: npm install -g @agentclientprotocol/codex-acp@1.12. It brings its own copy of Codex and leaves the one you already have alone. Without it, or with a different version, Codex workers use their command line.
• A Codex worker that signs in with CODEX_API_KEY always uses its command line.
• OpenCode workers run OpenCode 1.x. Oga picks the first opencode that reports version 1, looking on your PATH and in the usual install folders such as /opt/homebrew/bin, so an OpenCode 2 install that took over the name is passed over. If every opencode it finds is another version, the task stops before it starts and says which one it found. To use a specific install, set OPENCODE_BIN in the worker's environment to its full path.
• OpenCode 2 workers connect this way on OpenCode 2.0.x. On any other version, they use their command line. Oga runs opencode2, or an opencode that reports version 2, and never an OpenCode 1 install. To use a specific install, set OPENCODE2_BIN in the worker's environment to its full path.
• Antigravity needs Google's Antigravity ACP server, version 1.1.1, from the ACP registry. Unzip it and add that folder to your PATH. Google doesn't publish it for Intel Macs. Without it, or with a different version, Antigravity workers use their command line.
• That server has its own sign-in, separate from agy's. Sign in to it once from an editor that uses it, such as Zed. Until then, Antigravity workers use their command line.
• Antigravity tasks that connect over ACP can't be continued in a terminal and don't show token counts or cost.
• Pi needs one extra install to connect this way: npm install -g pi-acp@0.0.33. Without it, or with a different version, Pi workers use their command line.
• Pi workers never load a project's own Pi settings, extensions, or skills, such as a .pi or .agents/skills folder. In a project that has them, Pi workers use their command line.
• If a Pi extension stops to ask a question, Oga answers no, because nobody is there to reply.
• Pi tasks that connect over ACP don't show token counts or cost.
• Cursor connects over ACP and nothing else. There's no command line to fall back to, so a Cursor task that can't start says why and stops.
• Cursor needs the cursor-agent command on your PATH. Sign in once with cursor-agent login; until then, Cursor tasks stop and say so.
• Each Cursor model name carries its own thinking, context, and speed choice, so the effort you pick is ignored.
• Cursor tasks can't be continued in a terminal and don't show token counts or cost.
• A task keeps the connection it started on, so resuming it picks up the same conversation.
• If ACP can't start or can't use the model and effort you picked, Oga switches the task to the command line before it begins and notes why. A worker set to use only ACP stops the task and says why.
• A task's details show whether it connects over ACP or uses its command line, and why. When ACP wasn't available, you can copy what it reported.
• A sign-in problem is never worked around: the task stops so you can sign in again.
• If a worker stops partway through, Oga never starts the work over on its own. Resume the task when you're ready.
• Tasks from before ACP keep running through the command line.
• You see the same activity either way: what the worker said, what it was thinking, every file and command it touched, and its plan.
• Continue in terminal appears when the worker's own tool can reopen the task's conversation. Not every worker can, and Oga doesn't offer it then.

Choose who gets work that names nobody

Settings controls which workers and models can receive work. A model has to be turned on before Oga can select it.

oga love pins the worker and model that runs work nobody named an account for. Set it once, and every piece of work that leaves worker and model blank lands there instead of wherever Oga would otherwise guess.

Pin a default

Mark one account and model as loved to make it the default for work that names nothing. From the terminal:

oga love claude:opus

Give it a reasoning effort too, as a third part of the name:

oga love claude:opus:high

Name more than one destination and Oga tries them in order, moving on the moment one can't take the work — out of quota, unreachable, or not offering that model:

oga love opencode:muse claude:opus

Pin a kind of work

Send one kind of work somewhere else with --when, leaving everything else on the default:

oga love opencode:muse --when ui
oga love codex:beast --when backend,database

A kind is a subject — ui, ux, backend, database, docs, tests, review, research, refactor — or a class of work: context, mechanical, build, reasoning, general. Oga reads the kind off the task itself by default. A coding agent that already knows it's handing off a UI change, say, can name the kind directly instead — with --kind from the terminal, or its own kind option — rather than leave Oga to guess from the wording. When a task fits two rules, the one naming its subject wins over one naming only how demanding the work is.

general is the catch-all: a rule pinned to it takes everything no other rule claimed, not only the work that reads as nothing in particular. Pin general and one subject, and everything outside that subject still lands on the general rule:

oga love opencode:muse --when ui
oga love claude:opus --when general

See what's set, and clear it

Run oga love on its own to see what this project sends where today, listed in the order the rules take work:

oga love

oga love --clear drops every rule and goes back to choosing per piece of work. Add --when to drop only the rule for those kinds:

oga love --clear --when ui

Project or every project

Every command above applies to the project you're standing in. Add --global to set it for every project instead. That's the fallback: a project's own rules, once it has any, replace the global list whole rather than add to it.

oga love claude:opus --global

Match the worker to the brief

Rules pin work by kind. Turn this on instead and Oga reads the brief before the work goes out, so a task lands on the worker whose strengths fit what it actually asks for.

Open Settings, find Choosing a worker, paste your TypeSafe key, and switch it on. It applies only to work that names neither worker nor model — name one and the task still goes straight there.

Your rules stay underneath. When no answer comes back, or one comes back too close to call, or the worker it picked can't take the job, the work falls to your rules and starts as usual. Either way the task records which worker was suggested, how sure the suggestion was, and whether the work went there.