Oak — the agentic substrate · oak

🌳">

What are the odds Git is the fastest and most efficient way for agents to work? We’re building a new type of version control designed for how humans and agents build software together. We’re finding every millisecond of latency and eliminating it. Fewer tokens. Less time. Right out of the box. No need to change your model, your harness, or your IDE. Just tell your agents to use Oak.

Welcome to the agentic substrate

Get started

curl -fsSL oak.space/install | sh<br>Copy

Source code: oak.space/oak/oak

Numbers you can verify.

Median p50 latency from the same benchmark harness, comparing git and Oak<br>on identical repositories. The delta column shows how much Oak changes<br>the wait for each operation.<br>Run the harness yourself if you're curious<br>oak.space/oak/benchmarks. If you find anything wrong, please let us know.

Where Oak shines most p50, standard & large profiles

scenario / operation<br>delta<br>p50 time

many small files · 50kinitial snapshot−95%git29,723 msoak1,412 ms

many small filesinitial snapshot−95%git2,073 msoak99.6 ms

many large binariestask snapshot−95%git443 msoak23.2 ms

wide dirty treeinitial snapshot−94%git849 msoak50.9 ms

multi-GB binariestask snapshot−94%git5,218 msoak321 ms

multi-GB binariesfull diff (info recall)−93%git3,945 msoak271 ms

many large binariesdirty snapshot−93%git362 msoak25.4 ms

multi-GB binariesdirty status−90%git1,343 msoak128 ms

Inner-loop wins the devloop you live in

scenario / operation<br>delta<br>p50 time

wide config refactoragent setup (clone + checkout)−89%git540 msoak58.6 ms

large asset manifestagent setup−88%git319 msoak37.7 ms

few large binariestask snapshot−82%git77.7 msoak13.9 ms

shared checkout · 8 workersparallel worker−72%git419 msoak116 ms

Where Oak has the most room to improve git-faster work

scenario / operation<br>delta<br>p50 time

repo init · 50k filesone-time cost+188%git14.8 msoak42.6 ms

process spawncold start+143%git22.3 msoak54.2 ms

cold dirty status · 50k filesuncached+82%git89.4 msoak163 ms

dirty status · many small filesuncached+43%git16.3 msoak23.3 ms

Oak still pays small fixed costs for cold init and process startup. The<br>reason to use it is the loop that follows: snapshots, status checks, and<br>large-file work can be dramatically faster across a long-running agent<br>session.

Git is awesome, but it wasn't built for agents.

Every developer knows Git. We think it's awesome, but it's not perfect.<br>Oak is also not perfect, but we think there's value in exploring something<br>new. Oak is solving problems developers have had with Git for decades,<br>along with fitting it to current agentic workflows. Making an agent native<br>substrate allows us to improve these workflows directly rather than trying<br>to build something on top.

You wait minutes to read one file.

Git makes you clone the entire history before you can open a single path. On a big repo that's minutes of dead time, with tokens spent watching a progress bar, before you've done any work.

oak mounts without a full clone · files stream in on first read

Worktrees fight you back.

Running tasks in parallel means one shared, corruptible .git, detached-HEAD foot-guns, and half-applied state bleeding between worktrees. One bad index and every session stalls.

oak gives every task its own mount + branch · tear one down, the rest are untouched

The commit-message tax.

Git demands prose on every commit. You burn tokens writing "wip", "fix", and "address review", messages no human will ever read, just to checkpoint your own progress.

oak checkpoints carry no message · describe the branch once, at the end

Big files break it.

A 4GB checkpoint chokes git. LFS is a separate quota, extra config, and another thing to get wrong; it still re-uploads the whole file when one tensor changes.

oak chunks + dedupes natively · change one tensor, only that chunk travels

Familiar surface, improved internals.

Anyone coming to Oak is going to be familiar with the concepts. Your<br>mental model of commits, branches, and repos still apply. Likewise,<br>your agents already know the flow.

One branch, one description.

Iterate freely on a feature branch with any number of intermediate commits and no messages required. Land a single squash on main with the branch description as the message.

$ oak switch -c feat/oauth<br>$ oak desc "Replace REST auth with OAuth + PKCE"<br>$ oak mergesquashed onto main

Mount remote repos as filesystems.

oak mount projects a repo into a working tree without a full clone. Files hydrate on first access, so large repos become usable before git clone finishes counting objects.

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

Built to feel instant.

Speed is the feature. A Rust core, content-addressed storage, and lazy hydration keep the CLI snappy: no re-hashing the whole tree, no waiting on a clone, no spinners between you and the code.

snapshot 50k files 29.7s → 1.4s −95%<br>mount large repo no full clone...