vesper

Vesper

A git server layer for AI agents. Put Vesper in front of your GitHub repo, and many agents can commit and land on main at once: no clones, no merge queue, no local rebasing.

Agents send only the files they changed. Vesper builds the commit on the server, rebases it onto the latest main (merging line by line when two agents touched the same file), groups landings that arrive together into one push, and retries when someone pushes to GitHub directly. Everything stays ordinary git: GitHub, pull requests, your deploys and every git tool keep working, and nobody's commits are ever overwritten.

It is inspired by Anthropic's Redesigning source control, which describes Scion, the system Anthropic built for its own monorepo. Vesper takes the same ideas (history owned by the server, lock-free landing, source control as an API) and builds them on git instead of replacing it. It is independent and not affiliated with Anthropic.

Status: early. The server, API and landing are tested, including against a real application's history. See the roadmap.

How it works

agents ──HTTP──▶ Vesper ──git push──▶ GitHub ◀── humans, CI, deploys
                (mirror)  ◀──fetch──

• Mirror. Vesper keeps a bare git mirror of the upstream and fetches every 30 seconds, plus whenever it needs to.
• Commit on the server. An agent uploads the changed files and names the commit it started from. Vesper rewrites only the directories on those paths and writes an ordinary git commit.
• Land without locks. Landings on a branch queue for the few milliseconds each takes. Each commit is replayed on the newest tip: in memory when the files don't overlap, with git's three-way merge when they do. Only lines changed two different ways are a conflict.
• Push as compare-and-swap. The batch goes upstream in one push. If someone pushed first, the push is refused; Vesper fetches, rebases and pushes again.

DESIGN.md has the details.

Numbers

Measured on an Apple Silicon Mac, with a local copy of a real application repository (3,562 commits, 418 branches) standing in for GitHub:

• Mirroring the repository took 1.5 seconds.
• 100 agents landing at once, all starting from the same stale main: 300 of 300 landed, 48 a second, up to 86 landings in a single push.
• Humans pushing directly to the upstream three times a second while 20 agents landed: 100 of 100 landings succeeded, no human commit was lost, and git fsck --strict stayed clean.

A push to real GitHub takes around a second instead of milliseconds. Batching is what keeps throughput up there: the agents that arrive during one push all go out in the next.

Quick start

Requires Go 1.26+ and git 2.40+.

go install github.com/ImLukeF/vesper/cmd/vesper@latest

vesper serve --data ./vesper-data &                   # listens on 127.0.0.1:7420
vesper repo create my-app --upstream https://github.com/you/my-app.git
export VESPER_REPO=my-app
vesper log -n 5
vesper ls main src
vesper cat main~3 README.md
vesper diff main~1 main

Vesper pushes with the machine's own git credentials, so the user running vesper serve must be able to git push to the upstream (for example after gh auth setup-git, or with a deploy key). A repo created without --upstream stands alone.

Commit and land through the API

API=http://127.0.0.1:7420/v1/repos/my-app
BASE=$(curl -s $API/commits/main | jq -r .id)
BLOB=$(vesper upload src/fix.go)          # prints the git blob id

ID=$(curl -s -X POST $API/commits -d '{
  "parents": ["'$BASE'"],
  "changes": [{"path": "src/fix.go", "mode": "file", "blob": "'$BLOB'"}],
  "author": "agent-7 <agent@example.com>",
  "message": "Fix the parser"
}' | jq -r .id)

vesper land main $ID                      # or POST $API/land {"branch": "main", "commit": "..."}

If main moved since BASE, Vesper rebases the commit onto it. A real conflict comes back as 409 with the paths:

{"error": "conflicts with main at 3f2a…", "code": "conflict", "conflict": {"branch": "main", "tip": "…", "paths": ["src/fix.go"]}}

If the upstream refuses the push for another reason, such as branch protection that requires pull requests, land returns 502 upstream_rejected with the remote's message.

Running a shared server

Set VESPER_TOKEN and the server requires Authorization: Bearer <token> for writes (and for reads with --private). It refuses to listen beyond localhost without a token. Put it behind HTTPS.

VESPER_TOKEN=$(openssl rand -hex 32) vesper serve --addr 0.0.0.0:7420 --data /var/lib/vesper

Clients read VESPER_SERVER, VESPER_REPO and VESPER_TOKEN from the environment.

Load testing

go run ./cmd/vesper-loadtest --repo my-app --agents 50 --rounds 4

Point it at a repo whose upstream is a scratch copy: it really lands every commit.

Roadmap

1. Pull-request mode: land as a pull request when main is protected.
2. Webhooks from GitHub instead of polling.
3. An agent client: vesper checkout as a git partial clone with sparse checkout, for agents that want files on disk.
4. Several server processes sharing repositories (already safe, since the upstream is the compare-and-swap).
5. Caches in front of reads, code review, code search, permissions.

Contributing

Issues and pull requests are welcome. go test -race ./... must pass.

License

MIT