Developers increasingly run two or three AI coding tools at once and split work to save money and quota — plan and reason on a powerful (often plan-included) agent, then do the bulk editing on a cheaper one. But the agents don't know about each other:

• They clobber the same files with no warning.
• Switching tools loses all the context — the plan, the diff, the remaining tasks die with the session.
• Each one re-reads the whole repo to orient, burning tokens.

Baton coordinates them on one repo: every task runs in its own git worktree, a local daemon streams who's editing what in realtime, a queryable knowledge graph lets agents navigate instead of grepping, shared memory carries verified facts between sessions, and a single HANDOFF.md carries a curated, execution-ready brief — with a cost estimate — from one agent to the next.

One file (HANDOFF.md). No server lock-in. No database. Open source.

Claude Code (plan / think)                 Cursor · Codex · Gemini (edit cheap)
──────────────────────────                 ─────────────────────────────────────
  baton pass my-task --to cursor ─────────▶  HANDOFF.md  ─────────▶  baton take my-task
  (curated brief + est_cost_usd)            (objective · plan ·      (prints the execution
                                             files · git state ·      prompt, marks in-progress)
                                             graph excerpt)                  …agent edits…
                                                                            baton done

Do the expensive thinking where it's powerful (or included in your plan); do the bulk editing where it's cheap. Baton emits a minimal, cheap-to-execute brief with a token/cost estimate — not a raw history dump.

Prefer to have an agent do this for you? Paste this repo into Cursor or Claude Code and say "set this up for me" — it'll follow AGENTS.md, ask what it needs to know (which project to wire up, which agents you use, which port), run every command itself, and leave you a personalized GETTING_STARTED.md in your project when it's done.

Requires Node ≥ 24 and git. Run this in any repo:

npx batonhq setup

It scans the folder, then asks a handful of arrow-key questions — one repo or a hub over several, which agents you use, whether to turn on the knowledge graph. Each option carries a note explaining it, and Enter takes the recommendation. Then:

baton serve --write  # daemon + dashboard → http://localhost:7077

npm install -g batonhq     # `baton` on your PATH (setup offers this at the end)

uv tool install graphifyy  # or pipx install graphifyy

Then create an isolated session and point an agent at it:

baton new "refactor the auth middleware"   # → branch baton/… + worktree under .baton/wt/
cd .baton/wt/refactor-the-auth-middleware  # start claude / cursor / codex here

Working across several repos? Run baton setup on the folder that holds them to create one hub — a single dashboard + merged knowledge graph over all of them. baton serve runs from the hub root (which needn't be a git repo); each task just names its sub-project, and the worktree branches off that repo:

baton new "fix the checkout crash" --project api-server   # or pick it in the dashboard

Five situations Baton is built for. Each is one command.

Your good agent is rate-limited, and you still have work to do. Plan on the agent that reasons well, execute on the one that's cheap or still has quota. The brief carries the objective, plan, checklist, touched files, git state and a cost estimate — not a transcript dump.

baton pass fix-checkout --to cursor     # → HANDOFF.md
baton take fix-checkout                 # on the other agent

Two agents just edited the same file. Every task gets its own worktree and branch, so they physically cannot collide. Before an agent touches a shared file, it asks — and gets told who's in there and what they're doing.

baton new "refactor auth"               # isolated worktree + branch
baton signals                           # who is editing what, right now

A session died mid-task — context ran out, the window closed, you went home. The next session picks up from a written brief instead of re-deriving everything.

baton resume fix-checkout

An agent is new to the repo and starts grepping. It reads a queryable graph and a CODEBASE.md map instead — roughly 300× cheaper than reading the files it would otherwise open to orient.

baton kb init && baton orient

One product, several repos (api, web, mobile, infra). Point setup at the folder holding them: one merged graph, one dashboard, tasks that name their sub-project.

npx batonhq setup                       # detects the repos, offers the hub
baton new "fix the checkout crash" --project api

Bonus — "didn't we already fix this?" Composes recorded fixes with commit history to name the commits that likely re-broke it.

baton bugs "checkout 500s on empty cart"

Baton is a local tool. It is worth being precise about this rather than asking you to take it on faith:

• No telemetry, no analytics, no account. There is no tracking code in the source — nothing to opt out of, because there is nothing to opt into.
• Solo mode makes zero outbound requests. The daemon binds 127.0.0.1 and is unreachable from outside your machine. Your code, graph, memory and tasks live in .baton/ in your own repo.
• No install scripts. npm i -g batonhq runs no postinstall, so nothing executes on install. It works fine under npm i --ignore-scripts.
• Team mode is opt-in and metadata-only. Networking happens only after you run baton host set <url> to link machines. Even then, what crosses the wire is coordination metadata — task slug, agent name, which paths are being edited — never file contents. baton serve --host likewise binds a public interface only when you explicitly ask it to.
• Two commands fetch a URL, and both are ones you typed. baton join <url> reads a workspace manifest from a host you name, and baton skills import <url> downloads a skill you point it at. Neither runs on its own, and neither uploads anything.
• Your agents still talk to their own vendors. Claude Code, Cursor and the rest send your code to Anthropic, OpenAI and so on exactly as they always did. Baton neither adds to that nor can prevent it — it coordinates the agents, it does not sit between them and their APIs.

Everything above is checkable: the outbound calls are in src/host-link.ts, src/pipeline-claims.ts and src/remote-claims.ts, all gated on a host link you configured. See docs/security.md.

baton serve serves a realtime React dashboard at http://localhost:7077 — a Command Center board, live Activity, Conflicts, the Knowledge Graph, Memory, History, an Agents roster (with one-click MCP wiring), and the Skills catalog. It binds to 127.0.0.1 only and is read-only until you pass --write. See docs/dashboard.md.

No — Baton is terminal-first. You open your own terminals, run claude / cursor / codex yourself, and coordination happens through hooks + MCP tools + a local SQLite file. Start the dashboard only when you want to look:

History, memory, and reports are plain files + git — so when you do open the dashboard later, the past is all there; only live uncommitted-edit activity from hook-less agents needs the daemon watching at the time.

The same docs also live in this repo under docs/:

• Installation · Quickstart · CLI reference
• Dashboard · Knowledge base · Session handoff
• Skills · Project memory · MCP tools · Agent routing
• Configuration · Security model · Architecture · Troubleshooting & FAQ

• Zero-dependency daemon — src/server.ts is raw node:http. No express, no fastify.
• Realtime is SSE, not socket.io — every live event flows through one bus.
• Git-native — no external database; a small local SQLite index over your real git history. All git runs shell-free through a hardened wrapper.
• Loopback-only + write-gated — the daemon binds 127.0.0.1, and every mutating request requires a loopback origin and (mostly) --write. See the security model.
• Strict TypeScript in two workspaces (root + web/).

Baton is open source (AGPL-3.0) and contributions are welcome — the project is deliberately easy to hack on:

• Orient first: STATUS.md is the living map — what's built, what's pending, and where every module lives. docs/architecture.md explains the shape; CLAUDE.md lists the conventions that must not break (zero-dependency daemon, SSE-only realtime, shell-free git).
• How changes land: every feature is TDD'd (the test exists and fails before the code), and non-negotiable behaviors are guarded by invariant tests — if a future edit drops a safety rule from a bundled skill, the suite fails loudly.
• Good first contributions: an agent adapter (add your CLI to src/agents/registry.ts), a bundled skill (src/skills/bundled/<id>/SKILL.md — the loader auto-discovers it), a language check against your stack, or a docs fix.

npm install && npm install --prefix web
npm run build && npx vitest run        # backend build + full test suite
npm run build --prefix web             # dashboard build
node dist/cli.js serve --write         # run it locally on :7077
npm run dev --prefix web               # UI dev server :5173 (demo data ON)

Open a PR against main with tests. If you're changing coordination behavior, run the suite a few times — flaky is treated as broken here.

AGPL-3.0-or-later © Rakshan Shetty. See LICENSE.

Use it, change it, run it commercially — all fine. The one condition: if you distribute Baton or run a modified version as a network service, the people using it get the source under the same terms. That second clause is the reason this is AGPL and not GPL — Baton is a daemon with a web dashboard, so hosting it without ever shipping a binary would otherwise be a way around the license.

Baton was MIT until 2026-08-07. Copies taken before then keep their MIT grant — relicensing does not reach backwards. Contributions are accepted under the terms in CONTRIBUTING.md.