A few months ago, running one AI coding agent in the terminal felt like the edge of the workflow. Now some developers are running three. The typical stack looks like this: Claude Code for interactive work, Aider for git-native pair programming, and OpenCode as the model-agnostic fallback or local-LLM option.
The problem is not running the agents. It is keeping their changes from stepping on each other. We spent a week running all three against the same repository to find a coordination pattern that actually works.
Why Multiple Agents at All
No single agent is best at everything. Claude Code has the tightest tool loop for Anthropic models. Aider treats git as a first-class citizen and makes every change a reversible commit. OpenCode lets you switch providers and run local models. Each has a sweet spot.
The wrong reason to use multiple agents is speed. Running three agents in parallel on the same task multiplies token cost and review burden. The right reason is specialization. Different agents handle different stages of the same workflow better than one agent handles all stages.
If you are not already comfortable with one terminal agent, adding a second will not help. Master the single-agent loop first. Multi-agent workflows add coordination overhead that only pays back once the single-agent loop is already smooth.
The Branch-per-Agent Pattern
The workflow that held up best was simple: each agent gets its own git branch. No agent touches main or another agent's branch.
-
OpenCode ran on a
feat/opencode-refactorbranch for model-agnostic or local-model tasks. -
Claude Code ran on a
feat/claude-featurebranch for tasks where Anthropic's tuned harness saved turns. -
Aider ran on a
feat/aider-testsbranch for test generation, where git-native commits made review easy.
Each branch started from the same base commit. Agents did not merge between branches. A human reviewed each branch, picked the best parts, and rebased or cherry-picked into a clean integration branch.
This sounds slower than letting one agent do everything, and it is. The payoff is quality. Each agent stayed in its lane, and the final code was easier to review than any single-agent output we compared it against.
Cost Visibility Becomes Critical
The biggest surprise was cost. Running three agents across a workday burned through API budget faster than expected, not because any single task was expensive, but because the agents were always on. A Claude Code session left running, an OpenCode session retrying a flaky test, and an Aider session generating tests added up.
We added two rules:
- Close the session when the task is done. Agents left idle still consume context on the next prompt. A clean exit saves tokens.
- Set a per-session token budget. OpenCode and Aider both expose model choice, so cheap tasks ran on cheap models. Claude Code stayed on Sonnet for interactive work.
Never auto-merge output from multiple agents. The risk is not that the agents conflict; it is that they agree on the wrong approach. A human review is the only reliable merge gate.
When This Workflow Is Worth It
Multi-agent terminal workflows make sense for two groups:
- Teams with a multi-provider policy who need model fallback and cannot standardize on one vendor.
- Power users who already know the strengths of each agent and want to route tasks accordingly.
For everyone else, one agent is enough. The coordination cost is real, and the gains are marginal until you are running enough agent-assisted work for specialization to matter.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)