Anthropic hit 30,000+ merges a day. Git couldn't keep up.

Git was built for humans. Kudzu is built for agents.

Version control infrastructure for the agent era

Every engineer is about to run a hundred agents. They clone, commit and merge around the clock, all at once, and git is the first thing to break. Kudzu rebuilds version control as infrastructure: agents fetch only what they touch, history is an API, and thousands of changes land without a lock.

Star on GitHub Try it in 60 s Watch demo

Open source, MIT · one Go binary · 16 MCP tools built in

# Fetch just the slice of the monorepo this task touches. No history, no packfile.
$ kudzu clone --sparse services/api $KUDZU_REMOTE wc && cd wc
# History and blame are answered by the server, from derived data.
$ kudzu log services/api/handler.go
$ kudzu blame services/api/handler.go
# The server creates the changeset, rebases it onto main and lands it. No push, no queue.
$ kudzu commit -m "api: retry on 503" --land main
created 3f9c2a71b0de (1 file)
landed 8a41d07e5c22 on main (rebased, 2 attempts)

01 The problem

The agent era breaks git in four places.

Git gives every clone a full replica of history, so one person on a laptop can work offline. Agents are never offline, and there are about to be thousands of them per repo. Every one of git's assumptions turns into a bottleneck.

Clone storm

GitEvery agent sandbox and CI job pulls the entire repo and all of its history.

KudzuClients fetch only the objects they touch, through tiered caches. 50 identical cold requests become 1 upstream request.

Merge jam

GitThousands of agents race for main. Merge queues lock, pushes bounce, everyone rebases and retries.

KudzuThe server rebases and lands with a compare-and-swap on the ref. No lock, no queue, no push.

History trapped in clones

GitTo ask “who changed this line?”, an agent has to check out the repo first.

KudzuLog, blame and diff are server APIs, and 16 MCP tools your agent can call.

Mirror sprawl

GitHundreds of mirrors, each a full copy, each needing repack and gc.

KudzuImmutable, content-addressed objects behind cache tiers. No packfiles, no maintenance.

Not hypothetical: it already happened at Anthropic

Figures from Anthropic's article “Redesigning source control at Anthropic” (Oct 2026), about Scion, the system they built to replace git. Kudzu builds that architecture in the open.

Merges per day

~2,500 May 2026

30,000+ Sept 2026

~12× in four months

~100 GB

of main-branch history

25+ GB

compressed working copy

~25M

CI checkouts per day

Hundreds

of git mirrors at peak

After moving to Scion, the article reports

200×smaller infrastructure footprint
Secondsper checkout, instead of minutes
>99%cache hit rate at each tier

Kudzu flips git's defaults

Always online

No full clone. The client asks the server for exactly the trees and blobs it wants, when it wants them.

Thin client, smart server

History, blame, diff, merge, rebase and commit run on the server. Clients cache objects, lay out files and notice edits.

A real source-control API

/api/log, /api/blame, /api/diff, /api/cat… CI and tools get answers without a checkout.

Scales out by caching

Objects are immutable and content-addressed, so any tier can answer. No packfiles, no repo maintenance.

Cheap, lock-free commits

A changeset is one append to a log. The ref moves separately, by a single-row compare-and-swap.

Sparse by default

The protocol is built around sparse checkout, and many reads and writes need no working copy at all.

02 How it flows

Ask for what you want. Every tier answers the same question.

Server, regional cache and node daemon all speak the same object RPC. Objects never change, so any tier can answer, and a miss travels upstream once, no matter how many agents asked.

1 Want the root tree

kudzu server authoritative

changeset log · refs · derived data — SQLite + object store

served 0

kudzu cache regional · memory

coalesces misses · ≤32 upstream in flight

hits 0 · up 0

kudzu daemon node A · disk

hits 0 · up 0

A1agent

A2agent

A3CI

kudzu daemon node B · disk

hits 0 · up 0

B1agent

B2agent

B3CI

Agent A1 runs kudzu clone --sparse services/api. It resolves main to a root tree ID, then asks for exactly that one object. Every tier misses, so the want travels all the way up.
From the root, A1 wants services/, and simply never asks for docs/ or tools/. Sparse checkout needs no special protocol: it's just not asking.
services/api/ comes down; services/web/ is never requested. Each tier keeps a copy of what passes through it.
With the trees in hand, A1 asks for every file it needs at once. Objects stream back one by one, so a dropped connection re-asks only for what's still missing. No multi-GB packfile.
A2 on the same machine checks out the same path. Every object is a hit in node A's on-disk daemon. Nothing leaves the machine.
B1 starts on a fresh machine. Its daemon misses, but the regional cache already has everything, so the server never sees the request.
A change lands and all six agents want the new objects at the same moment. Each tier merges identical in-flight misses: six wants, one request to the server. In Kudzu's tests, 50 simultaneous cold requests reach upstream as 1.

A1's working copy--sparse services/api

/
README.md
docs/
tools/
services/
web/
api/
handler.go
routes.go
api_test.go

03 Git vs Kudzu

Same job. Opposite assumptions.

Git puts a whole repository on every client and asks each one to do the work. Kudzu keeps the repository on the server and sends clients only what they ask for.

Comparison of git and Kudzu
Task	git	Kudzu
Getting the code	`git clone` copies a packfile with the full history to every client.	The client asks for exactly the trees and blobs it wants, level by level. Sparse is just not asking.
History, blame, diff	Computed on every client, from its own full copy.	A server API backed by derived data. Works with no checkout at all.
Committing	Commit locally, then push objects and history.	Upload only the blobs the server is missing; the server creates the changeset. There is no push.
Landing	A merge queue serializes landings behind a global lock.	The server rebases onto the current tip and compare-and-swaps the ref. Lost the race? Retry.
Maintenance	`repack` and `gc` on every mirror and replica.	None. Immutable, content-addressed objects are served as-is by any cache.

What lands on the client

Columns are files and directories; rows are versions, newest on top.

git clone

Every version of every file, as one packfile

kudzu clone --sparse services/api

Only the objects you asked for, at one revision

Git has shallow and partial clones too; Kudzu's protocol is built around wanting individual objects from the start.

Two agents land at the same moment

Both changes are based on c3, the current tip of main.

Merge queue · global lock

kudzu land · lock-free

Conflicts come back as HTTP 409 with the conflicting paths, for the agent to resolve. In Kudzu's tests, 40 concurrent lands all succeed and main stays linear.

04 Demo

See it run, end to end.

Import a git repository, start the three tiers, check out a slice, and land changes from more than one agent.

Prefer the terminal? scripts/demo.sh in the repo runs the walkthrough against any git repository you point it at.

05 Under the hood

A log of changesets. Everything else is derived.

A changeset doesn't point at a full tree. It lists the files it changed relative to its first parent, and becomes one entry in an append-only log. Root trees, path history, ancestry and blame are computed from that log by one recursive engine.

Append-only changeset log

1041web: fix nav focus ring2 files
1042api: tweak handler2 files
1043docs: add runbook1 file

{
  "parents": ["9e03d1f2…"],
  "author": "Alice <a@example.com>",
  "message": "api: tweak handler",
  "changes": [
    { "path": "services/api/handler.go",
      "mode": 33188, "blob": "<sha256>" },
    { "path": "services/api/old.go", "mode": 0 }
  ]
}

Creating a changeset is a single insert: no lock, no ref update. mode: 0 is a delete. Moving main is a separate compare-and-swap on one row.

root treeeager

Checkout, diff, cat. Computed when the changeset is created, which also validates it.
generation + skip listeager

Ancestry checks and main~N in O(log n) along the first-parent chain.
unodeeager · or lazy

Path history. kudzu log <path> follows one chain, however much unrelated history is in between.
blamelazy

Line ownership, computed on first query and cached for everyone after.

A new index is one more Deriver: a parents function and a compute function. The engine handles caching, computes missing ancestors oldest-first, and merges concurrent computations of the same key. Clients never see these structures, so they can change freely.

06 Numbers

Fast where it matters. Honest about the cost.

The last 529 commits of a real-world repository (3,613 files), imported and served by Kudzu.

Illustrative only. Measured in a single container with all three tiers on one machine. Not a benchmark.

Time to a working copy

Seconds, lower is better

kudzu clone --sparse src/1,838 files · cold daemon

0.30 s

kudzu clonefull, 3,613 files · warm daemon

0.46 s

kudzu clonefull, second machine · warm regional cache

0.49 s

git clone --no-localsame repository

2.07 s

≈5 s

to import 529 commits (3,613 files) from git, derived data included

50 → 1

simultaneous cold requests for the same objects reach upstream as one request (tests)

40 / 40

concurrent lands succeed, with main kept linear (tests)

The trade-off: storage

No packfiles and no delta compression. Each object is stored and shipped as-is, so any tier can cache it, resume it and serve it independently, with no repository maintenance. The price is about three times the server storage on this repository.

Kudzu object store 79 MB

git packfile 26 MB

07 Quick start

Point it at any git repo. One command.

kudzu up imports a repository's history and runs the server, a regional cache and a node daemon in one process. Re-running it imports only new commits. No Go toolchain needed.

1
Install
One binary for macOS and Linux runs the server, the caches and the client. Windows builds and go install work too.
```
curl -fsSL https://raw.githubusercontent.com/garyships/kudzu/main/install.sh | sh
```
2
Bring it up on any git repo
Every commit becomes a changeset; the three tiers start on your machine, with the node daemon on a unix socket.
```
cd your-repo && kudzu up
# in another terminal:
export KUDZU_REMOTE=unix:///tmp/kudzu.sock
```
3
Plug in your agent
Sixteen MCP tools for history, blame, diffs, file reads and lock-free writes.
```
claude mcp add kudzu -e KUDZU_REMOTE=unix:///tmp/kudzu.sock -- kudzu mcp
```
4
Check out a slice, change it, land it
commit --land creates the changeset on the server and lands it in the same call. -A also picks up new files.
```
kudzu clone --sparse services/api $KUDZU_REMOTE wc
cd wc  # edit files…
kudzu status
kudzu commit -m "api: tweak handler" --land main
```

Ask the server, no checkout needed

History, path history, blame and diffs come straight from the API.

kudzu log -n 5 --oneline
kudzu log services/api/handler.go
kudzu blame services/api/handler.go
kudzu diff --from main~3 --to main --stat

6
Commit without a checkout
Write files straight through the API and land them in one call.
```
kudzu write -r main -m "bump version" --land main VERSION=@./VERSION
```

08 Built for AI agents

Version control your agents can just call.

kudzu mcp runs a Model Context Protocol server over stdio. Agents can query history, blame and diffs, and write and land changes, without a checkout. Add --read-only to let an agent look but not land.

16 MCP tools11 read5 write--read-only

More in Kudzu for AI agents, the Agent Skill, and llms.txt.

claude mcp add kudzu \
  -e KUDZU_REMOTE=unix:///tmp/kudzu.sock \
  -- kudzu mcp

{
  "mcpServers": {
    "kudzu": {
      "command": "kudzu",
      "args": ["mcp"],
      "env": { "KUDZU_REMOTE": "unix:///tmp/kudzu.sock" }
    }
  }
}

Then just ask

“Who last changed the retry logic in services/api/handler.go, and what else did that changeset touch?”

“What landed under services/api today?”

“Bump the version in VERSION and land it on main.” No checkout, no push.

Ask, don't clone. History, blame and diffs are answered by the server from derived data.
Write and land in one step. Changes go straight to the server, which rebases and lands them lock-free.
Conflicts are data. A conflicting land returns the conflicting paths, so the agent can fix them and retry.

09 Roadmap

What’s next. Come build it.

Kudzu is a working prototype with tests end to end. Access control, multi-server backends, GC, git export and lazy FUSE checkouts have landed; these pieces are next.

Writable virtualized checkouts
kudzu mount fetches files on first read but is read-only. Next: an overlay that kudzu commit reads.
Spanner & CockroachDB
Metadata runs on SQLite or Postgres today; the store.Meta interface and its conformance tests are ready for more.

The agent era needs new infrastructure.

Kudzu is MIT licensed. Star it, try it on your repo, and send issues, ideas and pull requests.

Star on GitHub Read the design doc

Git was built for humans. Kudzu is built for agents.

🌪️Clone storm

🚦Merge jam

🔒History trapped in clones

🪞Mirror sprawl

Not hypothetical: it already happened at Anthropic

Kudzu flips git's defaults

Always online

Thin client, smart server

A real source-control API

Scales out by caching

Cheap, lock-free commits

Sparse by default

What lands on the client

Two agents land at the same moment

Time to a working copy

The trade-off: storage

Install

Bring it up on any git repo

Plug in your agent

Check out a slice, change it, land it

Ask the server, no checkout needed

Commit without a checkout

Writable virtualized checkouts

Spanner & CockroachDB

Clone storm

Merge jam

History trapped in clones

Mirror sprawl