A practical guide to running three coding agents on one repository at the same time: installing each CLI, giving every agent its own git worktree so they cannot overwrite each other, splitting work by what each model is good at, handing context between them as files, watching the combined token spend, and reviewing the result branch by branch.
the short version
Running Claude Code, Codex and Grok on the same repository at the same time is not hard, but it fails in one specific way if you do it naively: they share a working directory, they overwrite each other, and you find out at commit time. The fix is one command per agent.
Give each agent its own git worktree and its own branch. Split the work along file boundaries you can name out loud. Hand context between agents as committed files rather than pasted text. Watch the combined token spend, because three agents burn roughly three times as fast and nothing in a terminal will tell you. Then review and merge in dependency order.
Everything below works with nothing but the four CLIs, git and a terminal. If you want the conceptual background first, read what AI agent orchestration means.
1. install the CLIs and sign each one in
Each agent is a separate CLI from a separate vendor with its own auth. Install what you will actually use rather than all four: an agent you have not signed in to is an agent that will sit at a login prompt while you assume it is working.
Claude Code
npm install -g @anthropic-ai/claude-code
claude # first run walks you through sign-in
claude --versionClaude Code authenticates either against a Claude subscription or an Anthropic API key. Which one you pick changes what the spend numbers mean later: on a subscription you are not billed per token, so a meter is showing you headroom rather than dollars.
Codex CLI
npm install -g @openai/codex
codex # sign in with ChatGPT, or export OPENAI_API_KEY
codex --versionGemini CLI
npm install -g @google/gemini-cli
gemini # sign in with a Google account, or set GEMINI_API_KEY
gemini --versionGrok
xAI's command line tooling has moved around more than the other three, so check the current install instructions in xAI's own docs rather than trusting a package name in a blog post, including this one. What matters for everything below is only that you end up with an executable on your PATH and an API key in your environment:
# whatever the vendor's current install path is, verify it lands on PATH
which grok
export XAI_API_KEY="..." # put this in your shell profile, not your repoSanity check before you go parallel
Run each one alone in the repo, ask it something trivial, and confirm it answers. Three agents debugging is three times the confusion of one, and every setup problem is easier to see in isolation.
2. give every agent its own git worktree
This is the step that makes the rest possible. A git worktree is a second checkout of the same repository, on its own branch, in its own directory, sharing one object database. It is much cheaper than a clone and, unlike a clone, everything you commit is already in the same repo.
cd ~/code/myapp
# one worktree and one branch per agent
git worktree add ../myapp-claude -b agent/claude-api
git worktree add ../myapp-codex -b agent/codex-schema
git worktree add ../myapp-grok -b agent/grok-ui
git worktree list
# /Users/you/code/myapp 9f1c2ab [main]
# /Users/you/code/myapp-claude 9f1c2ab [agent/claude-api]
# /Users/you/code/myapp-codex 9f1c2ab [agent/codex-schema]
# /Users/you/code/myapp-grok 9f1c2ab [agent/grok-ui]Now start each agent inside its own worktree. The working directory is the isolation boundary, so this is the part that must not be skipped:
# terminal 1
cd ../myapp-claude && claude
# terminal 2
cd ../myapp-codex && codex
# terminal 3
cd ../myapp-grok && grokWhat worktrees do not copy
Only tracked files come across. Gitignored things do not, and that catches everyone once. Expect to redo these in each worktree:
cd ../myapp-claude
cp ../myapp/.env.local . # gitignored, so it did not come with you
npm install # node_modules is per worktree
If reinstalling dependencies three times is painful in your stack, that pain is worth fixing once: a bootstrap script in the repo that any worktree can run is a small investment that pays every time you fan out.
Keep the main checkout empty
Leave your original checkout on main and do not run an agent in it. It is where you read diffs, run the full test suite and merge. Having one directory that is always clean is what lets you tell whether anything is actually broken.
3. split the work by boundary first, strength second
The instinct is to divide work by which model is best at what. Do the other thing first: divide by file boundary, then assign the resulting pieces to models. A perfect model-to-task match still produces a mess if two agents need the same file.
A boundary is good if you can finish this sentence for each agent without a comma: "this agent touches only ___." Directory, package, layer, and route group are all good answers. "The refactor" is not.
agent/codex-schema -> db/, migrations/, and nothing else
agent/claude-api -> server/api/, server/lib/
agent/grok-ui -> app/components/, app/styles/Then match strengths, empirically
Which model to point at which slice is genuinely a matter of taste and of the week you are asking in. Rather than repeating rankings that will be stale by the time you read them, do this: for the first few days, give two agents the same task in two worktrees and read both diffs. It costs one extra run and it tells you more about your codebase and your prompting than any public comparison will.
Some structural differences do hold and are worth knowing. The CLIs differ in how they handle long autonomous runs, in their permission and approval models, and in how much of a large repository they will read before answering. Those differences matter more for which agent you leave unattended than for which one writes prettier code.
Write the plan down where the agents can read it
Commit the split to main before you start, so all three worktrees have it:
cat > PLAN.md <<'EOF'
# Payments provider
## agent/codex-schema (db/, migrations/)
Add customers, subscriptions, invoices. Write the migration. Do not touch server/.
## agent/claude-api (server/api/, server/lib/)
Provider client + webhook handler. Import types from db/types.ts once it exists.
## agent/grok-ui (app/components/, app/styles/)
Checkout form + status page. Call the API routes by name; do not edit them.
## merge order
schema -> api -> ui
EOF
git add PLAN.md && git commit -m "plan: payments provider split"
git worktree list | awk 'NR>1 {print $1}' | xargs -I{} git -C {} merge --ff-only mainThat last line pulls the plan into every worktree in one go. Now each agent's first instruction can be short: read PLAN.md, do your section, stay inside your directories.
4. hand context between agents as files, not paste
No agent can see another agent's context window. When the schema agent finishes, the API agent knows nothing about what it built. There are two ways to fix that and one of them scales.
The way that does not scale
Copy the useful part of one transcript and paste it into the other agent's prompt. It works, it is what everyone does at first, and it is lossy, unversioned and unrepeatable. Fine for one handoff. Bad as a habit.
The way that does
Make the handoff an artefact in the repository. Have the finishing agent write down what the next one needs, commit it, and let git move it:
# in the schema worktree, when the agent is done.
# ask it to leave HANDOFF-schema.md behind: what exists, the names,
# what it left undone, and what the next agent must not change.
cd ../myapp-codex
git add -A && git commit -m "schema: customers, subscriptions, invoices"
git push -u origin agent/codex-schema # optional, if you use a remote
# in the API worktree, pick it up
cd ../myapp-claude
git merge agent/codex-schemaNow the API agent can simply read db/types.ts and HANDOFF-schema.md. It is not being told about the schema, it is looking at it, which is both cheaper in tokens and impossible to get out of date.
A good handoff note is short and factual: what exists now, what the names are, what was deliberately left undone, and what the next agent must not change. Ask for it explicitly in the prompt, because an agent asked to "summarise" will write prose and an agent asked for those four headings will write something usable.
Shared instruction files
Each CLI reads its own conventions file from the working directory. If your repository has house rules, put them somewhere every agent will see, and keep the per-agent files thin pointers rather than three diverging copies of the same rules. One source of truth that three agents read beats three files that were identical last Tuesday.
5. watch the combined spend
One agent gives you no running total. Three give you three times no running total, and the burn is genuinely additive: three agents working for an hour is roughly three agent-hours of tokens, not one.
After the fact, you can read what Claude Code actually spent straight from its transcripts, which are JSONL files under ~/.claude/projects/:
npx claude-code-spend # spend by day, by model, by projectThat is an open-source CLI we wrote; it reads only local files and sends nothing anywhere. The counting is less obvious than it looks, and if you are writing your own you will want the three mistakes we documented: cache reads are a small fraction of an input token, cache writes come in two differently priced kinds, and more than half the transcript lines are duplicates of the same billed call.
Three habits that keep the number down
Scope the prompt to the boundary. An agent told to work in db/ reads far less of the repository than one told to "add payments", and reading the repository is where the tokens go.
Do not leave an idle agent in a loop. An agent that has finished but has not been told so is the most expensive thing on your machine.
Check before you walk away, not after you come back. The moment the meter matters most is the moment nobody is watching it, which is the argument for a display that is always visible rather than a command you have to remember to run.
6. review and merge in dependency order
You now have three branches. Read them in the main checkout, where nothing is running:
cd ~/code/myapp
git fetch --all
git diff main...agent/codex-schema --stat
git diff main...agent/claude-api --stat
git diff main...agent/grok-ui --statRead the --stat output first, before any code. It is the cheapest possible check on whether the boundaries held. A UI branch that touched migrations/ is a boundary violation, and you want to know that in one line rather than three hundred.
Then merge in the order the plan named, testing after each step:
git merge --no-ff agent/codex-schema && npm test
git merge --no-ff agent/claude-api && npm test
git merge --no-ff agent/grok-ui && npm test--no-ff keeps each agent's work as a distinguishable merge commit, which is worth it here: when something breaks a week later, "which agent wrote this" is a question you will actually ask.
When there is a conflict anyway
Boundaries leak. Two agents both edit a shared type file, or both add a dependency to the same manifest. Resolve it yourself, in the main checkout, by hand. Handing a conflict back to one of the two agents that caused it is tempting and usually wrong: it has no context on the other branch, so it will resolve in its own favour, confidently.
Review the diff, not the transcript
It is easy to substitute reading an agent's explanation for reading its code. The explanation is a summary written by the thing being reviewed. Read the diff. If the diffs are too big to read, that is the signal to run fewer agents, not to read faster.
7. clean up
Worktrees are cheap but they are not free, and stale ones are confusing. Remove each one once its branch has landed:
git worktree remove ../myapp-codex
git worktree remove ../myapp-claude
git worktree remove ../myapp-grok
git worktree prune # clears records of directories you deleted by hand
git branch -d agent/codex-schema agent/claude-api agent/grok-uiIf remove refuses, it is because that worktree has uncommitted changes, which is exactly the check you want. Go and look before you force it.
doing this on a canvas
Everything above works in a terminal, and if it is working for you, keep doing it. What gets tedious is not any single step but the bookkeeping: which pane is which worktree, which agent is blocked on a permission prompt, and what all of them have spent so far.
Skribbl is one way to fold that bookkeeping into the workspace itself. Agents are nodes on an infinite canvas, each one a real terminal, so the commands in this post are still the commands. Spawning a fleet creates the worktrees for you rather than leaving it as step two. Sessions survive a restart. A link drawn from one agent to another is what grants the first the authority to instruct the second, and rubbing it out revokes it, so the picture of who commands whom cannot fall out of date with the reality. The combined spend sits in the top bar while the agents are still running rather than in a command you have to remember.