axis vs claude code agent teams
by the people who build axis
if you are one developer running agents on one machine, use agent teams. it ships inside claude code, costs nothing, needs no account, and it is better at that job than axis is. we would rather you learn that here than after an install.
axis is for the next problem along: two or more people, often on different agent tools, editing one repo at the same time. nothing that only sees your machine can see that collision, so this page is about where the line falls and where axis is still thin.
which one you should use
use agent teams if
- you are the only person whose agents touch this repo right now
- every agent you run is claude code
- you want zero setup: no account, no server, no config file to commit
- your agents run on one machine, launched by you
- you do not need the task list to outlive the session
use axis if
- more than one person on the repo is running agents
- your team is split across claude code, cursor, codex and windsurf
- you want a board that survives the session, so tomorrow’s agent sees what yesterday’s finished
- you want humans on the same board: post a job, release a stale claim, read the notepad, from a browser
- you want to know whether a locked file changed under you before you overwrite it
- you need the coordination layer to be readable, forkable and self-hostable
what each one is
agent teams: anthropic's native multi-agent coordination inside claude code, shipped as a research preview in february 2026. several claude instances share one task list and take file locks across processes. it is free, it is in the client, and there is nothing to set up.
axis: an mcp server plus a shared board. clients connect over http with oauth, or over stdio with a key. the coordination half (jobs, per-file locks, live notepad, presence, sessions) is agpl-3.0 and free forever. the hosted search layer is the part that costs money, because embeddings and reranking cost money.
where the line falls
both coordinate agents on one codebase. they are scoped at different boundaries, and the boundary is the whole difference.
teamsthe agents you launched, on your machine.
axisevery agent on the repo, across people and machines.
teamsclaude code.
axisany mcp client: claude code, cursor, codex, windsurf, antigravity.
teamswith the session, on the machine that started it.
axispostgres, scoped to your org. the board outlives every session.
teamsyou, driving claude code.
axisanyone on the team can post, cancel and release jobs from the live board while agents work.
teamsnone. it is already in the client.
axisone command to add the mcp server, plus an org pin committed at .axis/axis.json.
teamsfree.
axiscoordination free forever. hosted search is $20 per seat per month.
teamsships as part of claude code.
axisagpl-3.0 core. read it, fork it, run it on your own postgres.
what axis adds
six things, all of them shipped. everything else axis does, agent teams also does, and does closer to the metal.
boards are org-scoped, not process-scoped. your teammate's agent claims from the same job list yours does and contends for the same file locks, so a denial names the person and the intent behind it. the live view is /team/board.
axis is a standard mcp server over http with oauth. nothing about it is claude-specific, so one person’s cursor agent and another’s codex agent queue behind the same lock on the same file.
commit .axis/axis.json with a project and an org id, and every clone of that repo lands on the same board. no per-machine setup drift, no teammate quietly coordinating with themselves.
jobs, locks, the shared notepad and the archived session are rows in postgres. an agent starting tomorrow morning can read what an agent finished last night, on a different machine, in a different client.
pass a content hash when you take a lock and verify_file_lock compares the file's current hash against the fingerprint recorded at grant. it tells you the file moved under you before you overwrite it. it does not prevent the write. on the local stdio server, AXIS_ENFORCE_LOCKS=1 additionally chmods held files read-only.
the mcp server, the cli, the sdk and the protocol are agpl-3.0. point it at your own postgres and the hosted side never sees your repo.
what agent teams does better
- nothing to install and nothing to sign into. it is there the moment you open claude code.
- no network hop in the coordination loop, and no account that can be down.
- built by the people who build the client, so it moves with claude code instead of chasing it.
- free, with no tier above it that we would like to sell you.
- for one person on one machine it is simply the right tool. axis would add a board, an account and a round trip you do not need.
what axis does not do well yet
the honest list. if one of these is disqualifying for you, it should be.
local search is not semantic: the stdio server answers search_codebase with ripgrep plus a keyword ranker: coverage scoring, path and proximity bonuses. useful, but it is lexical. the semantic pipeline (vector, full text and trigram fused, then llm reranked) exists only on the hosted side, which is the paid tier.
the code chunker is regex based: it splits files by pattern matching rather than parsing, and caps a chunk at 2800 characters, so long function bodies are cut off in the index. a pass over axis's own two repos put that at roughly one function chunk in ten. a real parser is the fix and it is not written yet.
there is no scale evidence: axis has no users yet. job claims are atomic (SELECT ... FOR UPDATE SKIP LOCKED) and lock grants are atomic (INSERT ... ON CONFLICT), and 536 tests across the two repos gate every push. tests are not a production track record, and we are not going to dress them up as one.
locks are advisory: the protocol cannot stop an agent that never asks. read-only hardening is opt-in, local only, and a process running under your own account can chmod it back. it stops accidental clobbering and tools that have never heard of axis. it is not a security boundary.
why not just use git worktrees?
worktrees are the right tool and we use them. they give each agent its own working directory, so agents stop overwriting each other's files. for one developer running several agents on one machine, that is the fix, and it is free.
they do not reach across machines. your worktrees are on your disk and your teammate's clone is on theirs, and the only state they share is the remote. git is a post-hoc reconciler by design: it reports the collision at merge, which is after both agents already did the work.
they also isolate files rather than intent. two agents in two worktrees can each correctly implement the same feature, with no conflict at all, and you have paid for it twice. a shared job board stops the second one from starting. isolation cannot do that, because it works by making the agents blind to each other.
so they compose rather than compete: worktrees for isolation, a shared board for awareness.
you can run both
axis is an mcp server, so it runs inside claude code alongside whatever the client does natively. the split that makes sense: let the client coordinate the agents you launched, and let axis carry the boundary between you and everyone else on the repo.
setup is one command and an org pin, both in the docs. the coordination layer is free forever, so trying it costs you a config file.