Oak, an open source Rust project in public beta at v0.99.0, treats one agent coding session as one branch and pairs with Claude Code, Codex, and Cursor without code changes. The pitch is the substrate slot, not the speed benchmark.
The version control system underneath AI coding agents is the same one that has tracked human commits since 2005. Three AI labs ship harness updates on a weekly release cadence; the substrate that stores and shares the code those harnesses write has not been meaningfully re-architected for the agent workload in over a decade. Oak, a Rust-based open-source version control system that hit public beta at v0.99.0, is the most concrete bid yet to occupy that slot before any of the three labs builds its own.
The category is developer infrastructure, specifically version control: software that tracks changes to source code and lets multiple writers collaborate without overwriting each other. The audience for this story is the teams wiring AI coding assistants into real codebases, and the question is whether the storage and branching layer that sits beneath those assistants has been designed for how the assistants actually work.
Oak is built around one substitution: a session is the unit of work, not a commit. In git, the human commit is the atomic primitive, and a coding session is a string of commits accumulated on a feature branch. In Oak, an agent run is its own branch, complete with a description of what the session tried to do, and there are no per-commit messages to maintain. The project's framing of this design choice is captured in founder Zach Geier's blog post title: "Git is forever." That line is Oak's positioning, not field consensus: the project is aiming to be substrate, not replacement.
The second design move is content-addressed storage with lazy hydration. Oak uses BLAKE3 hashing and content-defined chunking, which means a repository's contents are identified by what they contain rather than by where they sit on disk. A new agent session can check out a large codebase in seconds because the mount materializes only the files the session actually reads, not the whole tree. The project publishes a reproducible benchmark harness showing roughly 95% p50 latency reductions against git on identical repos across four scenarios, including a 50,000-file initial snapshot. Treat that number as project-published, not independently validated; the harness is open, and the substance of the design is the lazy hydration, not the headline figure.
The third move is interoperability rather than displacement. Oak ships as a Cargo workspace: oakvcs-core is a library that custom clients can embed, with SQLite and read-only git backends included, and oakvcs-cli is the oak binary that agents call. Agents that already wrap a command-line interface, including Claude Code, Codex, and Cursor, drop Oak in by changing the binary the agent shells out to. No model swap, no harness rewrite, no IDE plugin.
That drop-in shape is what turns Oak into a substrate bid rather than a feature pitch. The labs that ship Claude Code, Codex, and Cursor are the only three organizations that know the agent workload's true shape: how many sessions a single developer kicks off in a day, how often those sessions branch and get discarded, how much of a monorepo any one session actually touches. None of them has announced a proprietary storage layer for that workload, and none of them needs to until a community substrate proves it can carry the load. If Oak or something like it holds up under real agent traffic, the labs have an off-the-shelf answer. If it does not, the labs will build their own, and the substrate slot will close.
There are real reasons that outcome is not yet settled. Oak is at v0.99.0 public beta, not general availability. On macOS (Apple Silicon) and Linux (x86_64) the install path is a single shell line, curl -fsSL oak.space/install | sh; on Windows, the mount feature requires Projected File System (ProjFS) to be enabled once per machine from an elevated PowerShell, and everything except mount works on Windows without ProjFS. There is no third-party adoption data, no security audit, and no interoperability matrix with production CI systems in the public material. The speed claim is reproducible but project-run, and the backstory behind Oak rests on a single author-attributed blog post describing Geier's prior project, Jam, which was sold to a company that shut down within roughly a year.
The watch item is whether any of the three agent vendors ships a proprietary branch-pool, sandboxed storage layer, or session-shaped version control of its own. If that announcement lands before Oak or a peer reaches general availability, the substrate race closes inside the labs, and Oak becomes a community curiosity. If it does not, the layer beneath AI coding agents starts to look less like a 2005-vintage commit log and more like the session log it always should have been.