Every agent on one podium. You hold the baton.
Baton conducts Claude Code, Codex and six more coding agents from a single desk. It reads your repo, drafts the score, and nothing plays until you raise the baton β you approve the plan first, every time.
curl -fsSL https://baton.sh/install | sh
macOS & Linux Β· one binary, no Node.js Β· Windows via npm Β· Apache 2.0 Β· no extra API key if you already run a coding agent
State the goal in plain words. Baton studies the repo, asks about anything still ambiguous, and returns a plan of tasks you can rewrite line by line. Each change works on its own branch, and you read the diff before anything merges. Try the planner below β
Say what you want
Baton reads your repo first and asks about anything you left open β before a single task exists.
Arrange the score
Swap any task, agent or model before anything runs. The plan is a draft on the stand, not a contract.
Read the diff, then merge
Change tasks play side by side on their own branches. The combined diff waits for you at the end.
Feel how a goal becomes a plan.
Pick a goal or write your own, rearrange who plays what, then approve and watch the run. Build tasks stay parked until you approve β here, exactly as in the real tool.
You see the score before a single note plays.
Every task is written out with the agent, model and effort that will run it. You can change any of it before the downbeat.
It reads, then asks
The planner reads your repo without changing it, asks about anything unclear, and writes the plan: ordered tasks, each naming the agent and model that will run it.
Many players, one score
Each change task gets its own branch and worktree. Independent tasks play at the same time; a dependent task waits until its inputs land on the run's integration branch.
Done means reported
A task is done when its agent reports completion through Baton's own tools, or a check script's exit status says so. No second model judges the work. A task that never reports fails where you can see it.
Four things Baton does on purpose.
Build tasks wait for the downbeat
The plan is yours to rewrite before anything builds: prompts, agent, model, effort, mode and dependencies. Approval is a step in the workflow, not a settings page.
Done means reported
No second model is asked whether the work looks done. The agent's own completion report decides, and a script's exit status decides for scripts.
Several agents, one plan
Eight supported agents can share a plan. Each task picks its agent, model, effort and mode β and a task can move to another agent mid-performance.
Limits pause the music, they don't end it
A task that hits its agent's usage limit pauses and resumes in its saved session when the limit resets. Move a paused task to another agent and its unfinished work comes with it.
Eight players. Bring the ones you already pay for.
Baton doesn't sell you another model subscription. It conducts the coding agents already installed on your machine β each with its own login, its own models and its own usage limits β mixed in one plan, per task.
Claude Code
Anthropic's terminal agent. Sonnet and Haiku families, high / medium / low effort.
Codex
OpenAI's coding agent. Strong on self-contained refactors and test repair.
OpenCode
Open-source runner with the widest model catalog β DeepSeek, Qwen, GLM, Kimi and more.
Gemini CLI
Google's agent for long-context research: whole-repo audits, doc sweeps, migration inventories.
Aider
Pair-programming veteran. A good fit for small, tightly-scoped edits on a branch you watch closely.
Cursor Agent
Drives Cursor's agent from the plan when your team already lives in the editor. Tasks land as branches, not chat threads.
Goose
Block's open-source agent, extensible with MCP tools. Your Goose extensions work inside Baton tasks unchanged.
Amp
Sourcegraph's agent for fast, parallel exploration. Useful as the research leg before a heavier model builds.
Detection is automatic β and honest
On first run Baton scans for installed agents and lists only the ones it can actually start. A player that isn't signed in, or whose binary is missing, never appears in a plan's picker β so a task can't be assigned to an agent that will fail at launch. Add an agent later and run /players (terminal) or refresh the panel (editor); it joins the ensemble without restarting the plan.
Every task carries its full assignment.
Nothing about a task is implied. Before you approve, each card spells out exactly what will run, where, and in what order β and every field is editable.
The instruction, in plain words. Generated from your goal and the planner's research. Rewrite any line; the player gets your version, not the draft.
Who plays it, and how hard they think. Picked per task from that player's real catalog. A rename doesn't need high effort; a data migration does.
What the player is allowed to touch. Build edits files and runs commands. Research is read-only. Manual tasks are never given to an agent at all β they're yours.
The ordering, made explicit. Independent tasks run in parallel on separate worktrees. A dependent task starts only when its inputs are on the integration branch.
Your team's habits, attached by name. Built-in or repo skills the planner matched to the task. Shown on the card before approval β remove one and it doesn't run.
One branch per change. Every build task works in its own worktree and branch, so two agents never write the same file at the same time.
Two podiums: your editor, and your terminal.
The same loop β goal, question, plan, branches, diff β beside your code in the editor, or over SSH in the terminal.
Editor extension
Live thinking, every research step, and the plan itself, pinned above the composer in VS Code, Cursor and compatible editors. The extension bundles its own core β nothing to install from npm.
- Open a project folder.
- Open the Baton panel from the activity bar.
- Type a goal. Build tasks wait until you approve the plan.
Choose an installed coding agent to plan for you β read-only, using its own credentials. Model names and interface details may change between releases.
Terminal UI
Conversation on the left, live plan on the right. Single keys drive the plan: no menus, no mouse. The terminal UI runs inside tmux β on Windows, that means WSL; planning, the CLI and the editor extension run natively everywhere.
You decide how far it goes without you.
Three supervision levels, set per plan and changeable mid-run. Guarded is the default, and no level ever merges to your branch without a handoff you accept.
Guarded
A Baton task can pause before the step that can't be undone and hand you the decision with the evidence it gathered β a dry run reporting exactly what would change.
- Plan approved by you before anything builds
- Checkpoints on risky tasks β migrations, deletions, dependency changes
- Diff review before merge, always
Watch
The plan plays end to end while a supervisor keeps an eye on the stream.
- No per-task pauses; checkpoints collapse into one review at the end
- Supervisor flags stalls, loops and off-plan edits as they happen
- You can grab any running task and take it over
Autopilot
For plans you've run before and trust: overnight batches, codemod sweeps, test repair.
- Runs to completion or to a stated stop condition
- Failed tasks retry once, then park with a full report
- Merge still waits for your handoff β autopilot never pushes
When a limit hits
- Usage cap reached β the task pauses in its saved session, not in a failed state.
- Limit resets β the same session resumes where it stopped, context intact.
- Can't wait? β reassign the paused task to another player; its brief and progress travel with it.
- Budget guard β set a per-plan token or time ceiling and Baton stops starting new tasks when it's reached.
When something goes wrong
- Agent goes silent β no completion report means not done. The task fails visibly, branch preserved.
- Tests fail β the failure output is attached to the task card, not buried in a log.
- Off-plan edit β a player touching files outside its brief is flagged before merge.
- You disagree β discard one task's branch without touching the rest of the plan.
How your team works, written down once.
Baton shows every dial before a task runs: which skills are switched on, and how hard the model thinks. Per task, and yours to change. Drop a Markdown file in .baton/skills/, commit it, and every teammate's Baton picks it up on the next plan β no plugin, no install. Skills shape prompts and checks; they never grant a player new permissions.
Interrogate the goal before planning: surfaces hidden constraints, edge cases and the questions a senior engineer would ask first.
Turns a loose goal into a written spec β scope, non-goals, acceptance checks β that the plan is then built against.
Tests first, then the change, then the refactor. Done means the new tests pass and the old ones still do.
A second pass over a finished task's diff: correctness, naming, dead code, and anything the brief asked for that's missing.
Runs the project's own checks β test suite, linter, typecheck, build β and attaches the real output to the task.
Reproduce first, form a hypothesis, instrument, then fix. No speculative patches stacked on a guess.
Three plans, end to end.
The same loop β goal, questions, plan, branches, diff β shaped by three very different kinds of work.
- Research β planner maps the middleware chain and finds the shared Redis client.
- One question β reuse that connection, or open a new one?
- 5 tasks, 3 players β limiter, wiring and 429 contract in parallel; tests depend on all three.
- Handoff β one combined diff, 429 behaviour behind a flag you flip.
- Reproduce β a research task runs the suite in a loop and captures the failing seed.
- Hypothesis β planner attributes it to a shared fixture, asks you to confirm the scope.
- Fix + proof β one build task isolates the fixture; a verify task runs the suite 20Γ clean.
- Handoff β diff shows the fixture change and nothing else.
- Inventory β every read and write of the session cookie, across services.
- Checkpoint β Guarded mode pauses before the dual-write task for your sign-off.
- Staged tasks β dual-write, backfill (manual β yours to run), cut-over behind a flag.
- Handoff β rollback is one task branch you simply don't merge.
For a pipeline instead of a person.
The full loop from the command line, with exit codes CI can gate on: 0 plan complete, 1 a task failed or never reported, 2 plan not approved.
| Command | What it does | Notes |
|---|---|---|
| baton plan --goal "β¦" | Research the repo and draft a plan without running anything | Plan on stdout as JSON with --json |
| baton task-player N agent | Reassign task N to another player | Model and effort reset to that player's sane defaults |
| baton task-model N model | Change one task's model before it runs | Only models that player can start are accepted |
| baton task-mode N mode | Set a task to build, research or manual | Manual tasks are skipped by run and left for you |
| baton run | Execute the approved plan | Parallel where dependencies allow; streams status lines |
| baton status | Show every task's state, branch and last report | Safe to run from a second terminal mid-run |
| baton resume | Resume paused tasks β after a limit reset or a Ctrl-C | Sessions are restored, not restarted |
| baton handoff review | Print the combined diff of all finished task branches | Per-task diffs with --task N |
| baton handoff merge | Merge finished branches onto yours, in plan order | Stops on the first conflict, leaves the rest untouched |
| baton discard N | Throw away one task's branch and mark it discarded | The rest of the plan is unaffected |
Project config β baton.toml
One file at the repo root sets the planner, default players, autonomy level and limits for everyone on the project. Personal overrides live in ~/.config/baton/config.toml and win for your machine only; environment variables override both for a single pipeline run.
Questions, answered straight.
Do I need an API key?
No β not if you already run a coding agent. Baton plans and runs through your installed agents using their own sign-in, so there is no extra key to buy or paste. If you'd rather plan on a direct API provider, set AI_PROVIDER and that provider's key instead.
What does Baton cost?
Baton itself is free and open source under Apache 2.0. You pay only for the agents and models you already use, under your own subscriptions and limits β Baton adds no markup and holds no billing relationship with you.
Which agents are supported?
Eight: Claude Code, Codex, OpenCode, Gemini CLI, Aider, Cursor Agent, Goose and Amp. A plan can mix any of them per task, and only agents Baton can actually start on your machine appear as options.
Does my code leave my machine?
Baton runs locally and sends nothing anywhere itself. Each task runs inside the agent you assigned, so your code goes wherever that agent already sends it β under that agent's own terms, with your own account.
What happens when an agent hits its usage limit?
The task pauses in its saved session instead of failing. When the limit resets, it resumes with context intact β or you reassign it to another player and the unfinished work moves with it.
Do I need git?
No. Without git, tasks work directly in the folder, one at a time. With git 2.38 or newer you get the full model: a worktree and branch per task, parallel runs, and merge-all at handoff.
Can two tasks edit the same file?
Not at the same time. Each build task works in its own worktree; if two tasks genuinely need the same file, the planner makes one depend on the other so the edits land in order on the integration branch.
How is "done" decided?
By evidence, not vibes: the player reports completion through Baton's own tools, or a check script's exit status says so. No second model grades the work. A task that never reports is shown as failed, with its branch preserved for inspection.
Can I use it in CI?
Yes β that's what the CLI is for. Draft with baton plan, execute with baton run, and gate on the exit code: 0 complete, 1 a task failed, 2 the plan was never approved. Guarded checkpoints become a required --approve flag in pipelines.
Windows?
Supported via npm: npm install -g baton. The CLI and editor extension run natively; the terminal UI runs inside tmux, which on Windows means WSL. The one-binary installer is macOS and Linux only.
Troubleshooting, quickly
A player is missing from the picker β it isn't installed or isn't signed in; Baton only lists players it can start. A task is stuck on RUNNING β check baton status; a player that never reports is failed visibly, never silently. Merge stops halfway β the first conflicting branch halted the handoff; resolve it, re-run baton handoff merge, and the remaining branches continue in plan order.
One install, one goal.
Terminal β one binary
curl -fsSL https://baton.sh/install | shInstalls to ~/.local/bin on macOS and Linux, with no Node.js. Then run baton in your project. On Windows, use npm install -g baton.
Editor β the extension
code --install-extension baton.batonOr search Baton in the Extensions view. It bundles its own core, so there is nothing to install from npm.
What you need
- One coding agent, installed and signed in: Claude Code, Codex or one of six more. It runs tasks β and it can plan too.
- No Node.js on macOS and Linux: the terminal UI and CLI are one binary. Windows installs with npm.
- git is optional. Without git, every task works directly in the folder. With git 2.38+, each task gets its own worktree and branch.
Pre-1.0 software can change between minor releases, so read the changelog before you upgrade.