Oak: the version control system built for AI agents, not 2005

Git turned 21 this year. It won. Every developer uses it. Every agent tries to. And the friction is starting to show.

A project called Oak just hit the front page of Hacker News with a pitch that sounds almost heretical: what if version control was not designed around a single human typing carefully crafted commit messages by hand, but around agents that make hundreds of small changes per minute and need to move fast without breaking each other?

I spent an evening reading their docs and benchmark harness. Here is what I found.

What Oak actually is

Oak is a version control system written in Rust. It shares DNA with Git: commits, branches, repos. Your mental model transfers over. But the internals are different enough that calling it "Git but faster" misses the point.

The core idea is the agentic substrate. In Git, every operation assumes a human is sitting there, waiting, reading output, deciding what to do next. In Oak, the design assumption is that a program is driving, and it needs answers fast, without ceremony.

Three things stood out.

No more full clones

Git makes you clone the entire history before you can open a single file. On a big repo, that is minutes of dead time. For an agent burning tokens while it waits, that is real money wasted on watching a progress bar.

Oak has oak mount. It projects a repo into a working tree without a full clone. Files hydrate on first access. You get a usable directory immediately, and the content streams in as you read it.

$ oak mount acme/app
fetched manifest · 2.4MB · 0 blobs
mount ready at ./app (lazy) · files hydrate on read

For agents that only need to touch a few files in a large monorepo, this is a substantial improvement. Instead of downloading 4GB of history to change one config file, you download the file you asked for.

One task, one branch, no bleed

Git worktrees exist, but they are fragile. One shared .git directory, detached-HEAD footguns, state bleeding between trees when the index gets confused. If you have ever watched two agent sessions corrupt each other's working tree, you know the pain.

Oak gives every task its own mount and branch. Tear one down, the rest are untouched. The isolation is structural, not convention-based.

$ oak switch -c feat/oauth
$ oak desc "Replace REST auth with OAuth + PKCE"
# ... make changes, run tests ...
$ oak merge squashed onto main

You describe the branch once at the end. Not per-commit. More on that next.

Commit messages are optional

This one felt weird at first. Git has drilled into me that every commit needs a message. But think about what agents actually do: they checkpoint progress dozens of times per task with messages like "wip", "fix", "address feedback". Messages no human will read. Tokens burned for ritual compliance.

Oak checkpoints carry no message. You iterate freely on a feature branch with any number of intermediate commits. Then you land a single squash on main with the branch description as the commit message.

I was skeptical, but the logic is sound. Commit messages are for humans reading history. If the only reader is the agent that wrote them, the message is a tax, not documentation.

The benchmarks

Oak published a benchmark harness (oak.space/oak/benchmarks) with numbers you can reproduce yourself. I like that they included scenarios where Oak is slower than Git, because that builds trust.

Here are the highlights from their standard profile, median p50 latency:

Operations that matter most in an agent loop (snapshot, status, diff, clone) are where Oak wins big. The operations where Git is faster, cold start and process spawn, happen once per session.

Oak is honest about where it is still slower. Repo init takes 42.6 ms vs Git's 14.8 ms. Cold process spawn is 54.6 ms vs 22.3 ms. These are the fixed costs of Oak's architecture, and they are trivial for a long-running session.

Big files without LFS

Git Large File Storage is one of those things that works until it does not. It is a separate quota, extra config, and another thing to get wrong. When you change one tensor in a 4GB file, LFS re-uploads the whole thing.

Oak chunks and deduplicates natively. Change one chunk of a large binary, and only that chunk travels over the network. No separate system, no extra config. It just works the same way for every file type.

For teams working with ML models, game assets, or embedded firmware images, this alone could justify the switch from LFS.

What I am not sure about

Oak is clearly early. The repo shows active development with multiple merges per day. The team (zdgeier, mrmrs) is small. The documentation is good but the ecosystem is tiny compared to Git. No GitHub integration, no CI pipeline support, no editor plugins beyond the CLI.

The "agentic substrate" framing makes me wonder if Oak is trying to be two things: a better Git for humans and a better Git for agents. Those goals can conflict. What is good for an agent (optional messages, auto-merge behavior, lazy hydration) might confuse a human contributor who expects explicit, verbose operations.

Migration worries me too. Git has 20 years of tooling. Moving a team to Oak means rewriting CI scripts, updating documentation, retraining muscle memory. The mount feature helps (you can work in Oak and push to a Git remote), but the full value only kicks in when everyone is on Oak.

When to try it

If you are running coding agents against large repos and watching them burn time on clones and status checks, Oak is worth a spin. The benchmarks are not theoretical. You can run the harness yourself.

If you are a solo developer on a small repo, Git is fine. The pain points Oak addresses scale with repo size and agent count. Below a certain threshold, the switching cost is not worth it.

If you are building agent infrastructure (tools, harnesses, CI systems), Oak is worth watching even if you do not adopt it now. The design decisions around lazy mounts and checkpoint-based workflows will probably show up in other tools.

Installing

curl -fsSL oak.space/install | sh

Source code is at oak.space/oak/oak. The CLI builds on Windows, macOS, and Linux. There is also a hosted version at oak.space.