Oak VCS: The Git Alternative Built for AI Agents (And Why It Changes How You Think About Version Control)

Git was not designed for agents. You can see the seams everywhere once you start looking.

Detached HEAD state when a process checks out a specific commit. Shared .git lock files that corrupt when two parallel agents touch the same repo at the same time. Commit messages required for every intermediate save — even the ones that are just noise. A status output designed to be read by a human, not parsed by a program. SHA-1 hashing that's older than most of the developers using it.

None of that was a problem when one developer was one keyboard. It becomes a problem when dozens of AI coding agents are running concurrently, each doing a separate task in the same codebase, each needing to branch, commit, push, and report back without stepping on each other.

Oak is a new version control system built from scratch for exactly that scenario. It's at v0.99.0 public beta, Apache-2.0 licensed, built in Rust, and designed around one core insight: the unit of work for an agent is a session, not a commit.

---

What Oak Actually Is

Oak is both a library (oakvcs-core) and a command-line client (oak) for version control. The library handles BLAKE3 content hashing, content-defined chunking, diff and merge algorithms, and the core data models (Blob, Manifest, Commit, Tree). The CLI is what agents and humans interact with day-to-day.

The project is built by Zach Geier, with product and visual design from Adam Morse. The team is small — and notably, they've published this in the repo header: "This repo was written almost entirely using AI with human oversight." Oak is dogfooding its own workflow. The entire repository is versioned in Oak itself.

That's not a PR stunt. It tells you the design decisions came from real daily use, not from theorizing about what agents might need.

The $10/month Pro plan gives you 100GB of included storage. There's no tracking of your code for model training — Oak makes zero AI calls and explicitly does not train on your content.

---

The Problem With Git for Agents

Before Oak makes sense, it helps to understand what breaks.

Git assumes a single developer per working tree. When you introduce parallelism — multiple agents, each running its own session — you hit problems that weren't visible before:

• Lock contention. Git's .git/index.lock file is single-threaded. Two concurrent git operations in the same repo will fight over it.
• Commit message overhead. Every intermediate save needs a commit message. Agents don't have anything meaningful to say at every micro-checkpoint.
• Clone cost. Spinning up a new agent means cloning the entire repo, even if it only needs three files.
• Unstructured output. Git's CLI was designed for terminal displays. Parsing git status with a regex in 2026 is still embarrassingly common.
• No session concept. Git's fundamental unit is a commit. An agent's fundamental unit is a task — which might have dozens of commits, or none.

Some of these are patched with tooling (worktrees help with isolation, --json flags exist in some git commands). But patches compound complexity. Oak's bet is that starting clean is worth more than patching an existing system.

If you've been using Claude Code's subagent system for parallel development (covered in detail in Claude Code Subagents and Agent Teams), you've already hit some of these walls — the worktree-per-agent pattern exists precisely because base git wasn't enough.

---

How Oak Works

Branch-Per-Session as the Primitive

In Oak, branches aren't just organization — they're the fundamental unit of agent work. Every task gets a branch. Every parallel agent gets a mount (its own isolated working tree) pointing to its own branch.

This eliminates the shared .git corruption problem structurally. There's no contention because there's no sharing.

Branch creation on a 50,000-entry repository: 7.5ms median. Git's equivalent: 10.5ms median. That 28% speedup compounds across thousands of agent operations. More importantly, you're not mounting full clones — Oak mounts are lazy.

Lazy Mounting

oak mount creates a virtual working tree without cloning the repository. File contents stream on first read. An agent that only touches three files in a 10,000-file codebase never downloads the other 9,997.

This is implemented via FSKit on macOS (no kernel extension required, replacing the legacy macFUSE approach) and FUSE on Linux. Windows gets ProjFS (Projected File System) support. The effect: agents can begin working on large codebases in seconds, not minutes.

BLAKE3 Content Addressing with Chunking

Content is stored and referenced by BLAKE3 hash — faster than SHA-256, naturally parallelizable, structured internally as a Merkle tree. This is the same hashing choice Lore (Epic Games' new open-source VCS for game assets) made, and for the same reason: correctness proofs, deduplication, and cache-friendliness across distributed systems.

Large files get content-defined chunking. Push a 4GB file, modify one tensor in it — only the changed chunks transfer. That's not new as a concept, but it's not something Git does natively, and it matters the moment agents start working with model weights, datasets, or large binaries.

oak finish Instead of git commit -m "wip"

The standard Git agent loop is littered with meaningless commit messages. Oak collapses that into oak finish, which handles commit + push + describe in one command. The branch description functions as the squash-commit message when the work is done — written once, by the agent, summarizing the whole session rather than narrating every intermediate save.

Intermediate commits in Oak don't require messages at all. They're checkpoints. The description is the artifact that matters.

Structured Output for Machines

Every Oak command that produces data supports --json. Not as an afterthought — as the designed-first interface.

Exit codes are typed: 2 = usage error, 3 = repo locked, 4 = dirty working tree, 5 = merge conflict, 6 = network error. An agent doesn't need to parse stderr to know what happened. It reads the exit code.

oak agent state returns structured JSON with repository state and recommendations — Oak's way of giving agents a decision-making primitive, not just a status dump. When output is piped (non-interactive), Oak removes redundant metadata automatically, reducing token overhead for agents that are paying per token to process the output.

Escape Hatch: Git Compatibility

oak export replays full branch history into a standard Git repository, preserving author, email, and timestamp on every commit. There's also a read-only Git Smart-HTTP endpoint, so git clone works against an Oak remote.

You don't have to bet your entire workflow on Oak never failing. The exit ramp is built in.

---

The Numbers

Oak benchmarks at up to 95% faster snapshots than Git on large repositories. The specific numbers from the repository:

Operation	Oak	Git
Branch creation (50k-entry repo)	7.5ms p50	10.5ms p50
Large-file diff	Chunked, incremental	Full-file diff
Initial mount on large repo	Seconds (lazy hydration)	Minutes (full clone)

The 95% snapshot improvement figure is against Git's standard snapshot approach on large repos — the combination of lazy hydration, pre-sized allocations, and content addressing eliminates the redundant work Git does on every status check.

---

Safety That Actually Matters for Production

Oak's safety features read like a list of things that have gone wrong in production agent systems:

• Crash-atomic pulls and clones. State is verified before publishing. A killed agent mid-clone doesn't leave a corrupt working tree.
• SQLite transaction semantics. Multi-operation sequences are consistent. No partial writes.
• Flock-based advisory locks. Cross-process race conditions can't silently corrupt state.
• Content hash verification on download. What you requested is what you got.
• Symlink safety. Directory traversal attacks via symlinks are rejected.
• Control character rejection. Branch names, author fields, and filenames are validated at ingest — no injection via stored data.

The last two matter more than they might look. When agents create branch names programmatically from user input, they're doing it millions of times at scale. A single unvalidated string can become a stored exploit.

---

List Your Developer Tool on SaaSCity

Building an Oak integration — a CI plugin, an IDE extension, a dashboard for agent branch management? This is exactly the kind of tooling that early adopters are looking for right now, before the ecosystem gets crowded.

SaaSCity.io is the premier directory for developer tools and modern software products. List your project and it's not just a static page — your product gets visualized as a building in our interactive 3D digital city.

• Free to list. Submit in under 2 minutes with no catch.
• Dofollow backlinks. Real SEO value, not directory spam.
• 3D city visibility. Stand out in an experience developers actually browse.

Submit your project today and start building your early user base before the Oak ecosystem gets competitive.

---

What This Means If You're Building AI-Native Products

Oak isn't just a tool for teams that have agent fleets today. It's a signal about where the tooling stack is going.

The branch-per-task model is conceptually the right answer for parallel AI work. If you're building a SaaS product that lets customers spin up AI agents — a coding assistant, an autonomous code reviewer, a deployment pipeline — your backend needs to handle dozens to thousands of concurrent agent sessions per customer. Git's locking model wasn't designed for that. Oak's was.

The advanced Claude Code workflow already recommends git worktrees for parallel agent streams as the "clean way to scale beyond one thing at a time." Oak makes the worktree-per-session pattern the default, not the advanced configuration.

For indie hackers and SaaS builders:

• If you're building dev tooling, an Oak integration puts you early in a growing ecosystem
• If you're building AI-native apps with agent backends, Oak's lazy mounting and JSON output reduce infrastructure complexity
• If you're evaluating alternatives to Git for internal tooling, the Apache-2.0 license means zero licensing friction

For teams already running agentic pipelines:

• Test Oak's lazy mounting against your current clone time on large repos
• The typed exit codes alone might justify the migration for anything doing programmatic git parsing today
• oak agent state's recommendation output is worth experimenting with as an agent decision-making primitive

The $10/month Pro pricing is remarkably low for infrastructure that competes with solutions charging per-seat at an order of magnitude more. That price point won't last forever once adoption scales.

---

The Honest Status Check

Oak is at v0.99.0 — one step short of 1.0, and they're being deliberate about it. That means interfaces and on-disk formats could still change before the stable release.

The platform support picture is solid for macOS Apple Silicon and Linux x86_64. Windows gets ProjFS support but it's listed as an optional feature. If your agent fleet runs on Windows, verify your specific setup before committing.

Installation is clean:

curl -fsSL oak.space/install | sh

Or via Cargo:

cargo install oakvcs-cli

The contact for contributions and issues is [email protected]. This is a small team and the project is genuinely open-source — Apache-2.0, published on crates.io, no proprietary dependencies.

---

The Bigger Picture

Git is 21 years old. It was designed in a week by Linus Torvalds to solve a specific problem for a specific team. It has accumulated an enormous amount of tooling, habit, and institutional inertia since then — and it still works well for what it was designed for: humans, committing code, one at a time.

AI agents aren't humans committing code one at a time. They're parallel processes with structured outputs, session-scoped tasks, and zero patience for interactive prompts. The workflow assumptions baked into Git — sequential commits, meaningful messages, single working trees — don't map cleanly.

Oak is the first serious attempt to start over with those constraints as first principles, not afterthoughts. It's a small team, a v0.99 public beta, and an Apache-2.0 license. That combination is either the beginning of something important or a tool that gets absorbed into something larger.

Either way, the problem it's solving is real, the timing is right, and the design decisions are sound. If you're building anything with AI agents and version control in the same sentence, it deserves more than a passing glance.

---

SaaSCity.io covers developer tools, AI infrastructure, and the software products being built by founders who ship. Explore the SaaSCity directory to discover what's shipping right now — or list your own product.