Type a goal in your repo. Walk away. Come back to a pull request.
No babysitting. No copy-paste. No "now do the next file." A fleet of coding agents planned the work, built it in parallel across isolated branches, reviewed each other, and opened the PR — from a single sentence.
▸ See what happened — 33-story DAG, 64 test suites, 83.5% branch coverage, +13,606 lines, zero phantom bugs filed.
npm install -g baro-ai
cd your-repo
baro "Add JWT authentication with role-based access control"No machine, or no Claude/Codex subscription? Run the same fleet on baro's cloud — nothing to install, each run in an isolated sandbox, pay as you go. → app.baro.jigjoy.ai
baro at the end of an actual run — one prompt → 33-story DAG → 32 files modified → PR opened. The summary panel shows wall time, parallel speedup (2.2×), token usage, and the PR URL.
flowchart LR
G([your goal]) --> C[Conversation<br/><sub>asks only what matters</sub>]
C --> A[Architect<br/><sub>pins the design</sub>]
A --> P[Planner<br/><sub>splits into a story DAG</sub>]
P --> S[Story agents<br/><sub>parallel, isolated worktrees</sub>]
S --> V[Critic + Verifier<br/><sub>reviews, repairs, tests</sub>]
V --> PR([Pull Request])
- You describe the goal. A conversation agent confirms the scope, or asks only the questions that would change it.
- The Architect pins the design — file paths, schemas, API shapes, library choices — so dozens of agents don't each invent their own.
- The Planner splits it into a DAG of stories, with dependencies, so independent work can run at the same time.
- A fleet of agents builds it, each in its own git worktree — not one chat agent typing for an hour.
- It reviews and repairs itself. A tool-less Critic gates each story; a Surgeon replans the ones that get stuck.
- You get a pull request, build-verified, with a stories table and run stats.
The speedup scales with the width of your DAG, not the patience of a single session.
npm install -g baro-ai
baro "Migrate the hardcoded category data to a backend dictionary"
baro --quick "fix the typo on line 42 of README.md" # skip Architect/Critic/Surgeon
baro --parallel 3 "Add unit tests for the auth module"
baro --local-only "Your goal" # no pushes, no PR
baro --resume # pick up an existing prd.json
baro --continue "…and add refresh tokens" # follow-up onto the same PR
baro --doctor # self-diagnosticFull options, .barorc config and per-phase overrides: docs.baro.rs.
--mode decides how much runs at once. The default asks the intake to propose one and
lets you confirm it.
| mode | what it does |
|---|---|
auto (default) |
intake proposes a mode from the goal; you confirm |
focused |
a single story, start to finish |
sequential |
one story at a time, in dependency order |
parallel |
every ready story at once, up to --parallel |
Same orchestration, same DAG, same prompts. The only thing that moves is which provider each agent talks to. Auth inherits from whichever CLI you already have signed in — no API key plumbing for the subscription backends.
baro --llm claude "Your goal" # default — Claude Code on an Anthropic Max subscription
baro --llm codex "Your goal" # Codex CLI on a ChatGPT Plus/Pro subscription
baro --llm opencode "Your goal" # OpenCode CLI — multi-provider agent shell
baro --llm openai "Your goal" # native OpenAI-compatible API (per-call billing)
baro --llm hybrid "Your goal" # Claude plans and reviews, Codex writes
baro --llm jigjoy "Your goal" # hosted baro gateway — we hold the upstream keys--llm hybrid is the recommendation for serious runs. --llm jigjoy needs no provider
account at all — run baro login once and phases route through the hosted gateway.
Every phase also has its own override:
baro --architect-llm claude --planner-llm claude \
--story-llm opencode --critic-llm claude --surgeon-llm claude \
"Your goal"Anything speaking OpenAI Chat Completions works with --llm openai. Point
OPENAI_BASE_URL at it and pass any model name:
OPENAI_API_KEY=your-key OPENAI_BASE_URL=https://openrouter.ai/api/v1 \
baro --llm openai --story-model anthropic/claude-3.5-sonnet "Your goal"
OPENAI_API_KEY=not-needed OPENAI_BASE_URL=http://localhost:11434/v1 \
baro --llm openai --story-model llama3 "Your goal"--openai-base-url does the same and wins over the env var.
Gotcha. Model names matching
gpt-*,o1–o9,chatgpt-*,text-*ordavinci*are treated as native OpenAI and go to the Responses API (POST /v1/responses), not Chat Completions (POST /v1/chat/completions) — two different wire protocols. SettingOPENAI_BASE_URLalone does not change that. Pass--openai-base-urlexplicitly and you get Chat Completions regardless of the model name.
--llm picks a backend per phase. --tier-map tiers per story instead: the Planner
tags each story by blast radius — light (mechanical), standard (one module), heavy
(cross-cutting, schema, a DAG hub) — and the map binds each tier to a backend:model.
# Cheap single-concern stories on MiniMax, cross-cutting stories on Claude Opus
baro --openai-endpoint minimax=https://api.minimax.io/v1 \
--tier-map "light=openai:MiniMax-M3@minimax,standard=openai:MiniMax-M3@minimax,heavy=claude:opus" \
"Your goal"A route can name any backend (claude:opus, openai:MiniMax-M3, codex:gpt-5.5), and an
OpenAI route can name its own endpoint with @ — so one run can hit several endpoints at
once. Keys never go on the command line: each endpoint reads BARO_OPENAI_KEY_<NAME>,
falling back to OPENAI_API_KEY.
Provider economics and a side-by-side benchmark across three real tasks: Claude Code vs OpenAI Codex in my parallel agent setup.
Most multi-agent setups put one orchestrator function in the middle driving N agents. That orchestrator becomes the bottleneck the moment you go past a handful of concurrent agents, and every new behaviour means editing its control flow.
baro has no such function. Every role is a participant on a shared event bus (Mozaik), reacting to typed events:
flowchart LR
subgraph A["Typical orchestrator"]
direction TB
C{{Coordinator}}
C --> A1[Agent 1]
C --> A2[Agent 2]
C --> A3[Agent N]
end
subgraph B["baro on Mozaik"]
direction TB
Bus[(shared event bus)]
P1[Board + Broker] -.-> Bus
P2[Story Agent 1] -.-> Bus
P3[Story Agent N] -.-> Bus
P4[Critic / Surgeon / …] -.-> Bus
end
| Participant | Role |
|---|---|
| Conversation | Sole user-facing intake; turns a sentence into one accepted goal, and survives restarts |
| RepoScout | Read-only researcher that investigates the repo before planning; cannot run code or write |
| Architect | One strong-model design pass; its decisions are pinned for every story |
| Planner | Decomposes the goal into a story DAG |
| Board + Broker | Scheduling and ownership: the Board arbitrates the graph, the Broker auctions and grants leases |
| StoryAgent | One isolated worker per story, in its own git worktree |
| Critic + AcceptanceGate | Evaluates each story against its acceptance criteria and blocks or corrects |
| GoalGuardian | Independent goal authority — attests completion from evidence; cannot schedule or merge |
| Surgeon | Replans a failed story: split, add a prerequisite, rewire, or escalate |
| Librarian + Sentry | Share findings between siblings; flag overlapping edits across concurrent stories |
| RunVerifier / Finalizer | Produces build/test evidence and opens the PR from it |
Because it's a bus, adding a participant — a CI deployer, a Slack notifier, a ticket trigger — changes no existing code. Workers can also message each other and propose changes to not-yet-started parts of the DAG; the Board stays the only thing allowed to mutate it.
Details: collective runtime architecture covers the execution guarantees, lease and authority fencing, failure policy, runtime DAG changes, progressive planning, and the provider-free verification contract. The local collective experiment is the hands-on guide.
Parallel agents share what they discover. When one reads a file or greps a pattern, the finding is embedded locally (CPU-only ONNX, no API calls) and indexed, so siblings don't redo the same exploration — only semantically relevant findings get injected.
baro "your goal" # on by default
baro --no-memory "goal" # off
BARO_DEBUG=memory baro … # debug to stderr + ~/.baro/runs/memory-*.logWorth it on large codebases with overlapping exploration and DAGs where later stories build on earlier ones. Adds ~1s of startup and little else on 1–3 file tasks.
baro can run as a remote runner: fire a goal from a web dashboard, a teammate, or a
GitHub issue labeled baro, and it executes here on your machine over your own
subscription. baro-cloud orchestrates and never sees your source — only metadata and diffs.
curl -fsSL https://api.baro.jigjoy.ai/install.sh | sh -s -- --token rt_…That installs baro and registers a background service that survives terminal close, logout and reboot — launchd, systemd, or a Windows logon task. By hand:
baro connect --install-service --token rt_… # persistent background service
baro connect --token rt_… # foreground, this terminal only
baro connect --uninstall-service # remove itGet a pairing token from baro-cloud → Runners. A mid-run network blip won't kill a run: the runner reconnects and resumes streaming where it left off.
No machine or subscription? baro-cloud can run the goal entirely on our infrastructure, billed from prepaid credits — pick ☁ baro's cloud at app.baro.jigjoy.ai.
- Node.js 20+, and at least one of:
- Claude CLI signed in — for
--llm claude(default) - Codex CLI signed in — for
--llm codex - OpenCode CLI with a provider — for
--llm opencode OPENAI_API_KEY(optionallyOPENAI_BASE_URL) — for--llm openai- nothing at all —
baro login, then--llm jigjoy
- Claude CLI signed in — for
- macOS (arm64/x64), Linux (x64/arm64), Windows (x64)
ghCLI, optional, for automatic PR creation
baro is a work in progress. If a run explodes, the audit log at ~/.baro/runs/<run-id>.jsonl
is the fastest way to get it fixed — open an issue
with that file attached.
Discord: discord.gg/dvxY9J2kWX · Twitter: @lotus_sbc
MIT — JigJoy team