Oak

title
Oak
type
toolbox
summary
Version control for coding agents β€” lazy mounts, messageless commits, chunk-deduped large files
tags
version-control, ai-agents, rust, developer-tools, watchlist
language
Rust
license
not stated
created
2026-07-23
updated
2026-07-23

Oak is a version control system built on the premise that git's shape is wrong for agents. The concepts survive β€” repos, branches, commits, push and pull β€” but the storage is content-addressed with content-defined chunking, working trees are lazy mounts instead of clones, and intermediate commits carry no message at all. The pitch to an agent operator is that you change nothing about your model, agent, or editor; you just tell the agent to run oak where it used to run git.

The four complaints

Each design decision answers a specific friction the site names. Cloning a large repo to read one file costs minutes of wall clock and tokens spent watching a progress bar, so oak mount pulls down a manifest and hydrates file contents on first read. Parallel tasks in git share one .git that any bad index can wedge, so every Oak mount gets its own working tree on its own branch and tearing one down leaves the others alone. Git demands prose on every commit, which turns into agents generating "wip" and "fix" that nobody reads, so Oak checkpoints carry no message and the branch description is the single string that becomes the squash-commit message on main. Large binaries push git to LFS with its separate quota and its habit of re-uploading a whole file for a one-tensor change, so Oak chunks and dedupes natively and moves only the changed chunks.

The branch model follows from that last point about descriptions. oak init puts you on a feature branch parented onto main, and main exists only on the server, so there is no local mainline to drift. Merging is a server-side squash. Direct pushes to main are refused except for the very first push into an empty repo, which is a guardrail aimed squarely at a misconfigured agent fast-forwarding something it shouldn't.

Mounts live inside an oak space, which is one working area for a whole organization rather than a single repo. Each task is a subdirectory of the space; inside it you mount whichever repos that task touches, so a change spanning three repos keeps its three branches side by side.

$ oak space new acme
$ oak mount acme/app ./fix-auth
$ oak switch -c feat/oauth
$ oak desc "Replace REST auth with OAuth + PKCE"
$ oak merge          # squashed onto main, description becomes the message

The numbers, and who produced them

The headline claim is p50 latency up to 95% lower than git, with a snapshot of 50k files going from 29.7s to 1.4s. These are vendor-published figures, but the benchmark code is public at oak.space/oak/benchmarks and the site invites you to re-run it, which is more than most such comparisons offer. The honest part of the same page is where git still wins: cold repo init and process startup, where Oak pays fixed costs it hasn't eliminated. The argument is that those costs amortize across a long agent session made of constant snapshots and status checks.

Limits

The CLI runs on macOS (Apple Silicon) and Linux (x86_64) only, because lazy mounts need FSKit on macOS and FUSE on Linux. Linux ARM64 and Windows are on the roadmap. There is no issue tracker, no code review, no CI, and none of the decade of tooling built around GitHub β€” the site concedes this directly and says bring your own.

oak export ./dest replays branch history into a standard git repository with author, email, and timestamp preserved, and a read-only git Smart-HTTP endpoint lets a stock git clone fetch the current main. That escape hatch matters more than usual here, because main living server-side means the hosted service is not optional. Oak states that it makes no LLM calls on your behalf and trains no models on user code; whatever agent you run alongside it is a separate integration with its own posture.

One detail worth noting for anyone who adopts it: Oak asks you to paste a prompt into CLAUDE.md or AGENTS.md instructing the agent to file oak feedback -m "..." --json whenever it hits friction. It is a clever way to get bug reports from the party that actually experiences the latency, and it is also a standing instruction for your agent to send text to a vendor. Read what it sends before enabling it.

Tracked on watchlist: no stated license, a hosted server in the critical path, two platforms, and a young project competing against the most entrenched tool in software.

Related: jujutsu takes the other route, keeping git as the backend while replacing the workflow model; billjings-git-not-fine catalogs the git primitives that break under stacked and async work. For what agents actually do with a version control system all day, see claude-code and log-is-the-agent, which makes a similar bet on cheap forking from a different direction.

Source at oak.space/oak/oak; install with curl -fsSL oak.space/install | sh. License is not stated on the site.