Clone Is the New Bottleneck for Agents

Agents increasingly work in ephemeral sandboxes. AI app builders, code execution, parallel cloud agents — and none of them can do anything until the repo is present.

ComputeSDK measured the median time-to-interactivity (TTI) across the top 10 sandbox providers: 690ms.

But TTI only measures the time until the sandbox can run a command. It doesn’t count getting the code in. For many repositories, cloning from scratch takes seconds. That’s several sandbox boots.

Improving git clone

For small repos, Corigin materializes a full clone faster than the sandbox itself boots: median 184–646ms, against the 690ms median TTI.

I’m working on corigin.dev, a programmatic git server. I rebuilt the read path for the 2026 workload — agents in sandboxes — to see how fast a clone could get.

Clone times vary run to run. Whiskers span min–max; black line is the median; n=10 per lane; speedups are vs. GitHub’s median.

Methodology

I tested four repositories, mirrored to our own GitHub, GitLab, and Corigin accounts. I ran the benchmark locally with hyperfine; it’s public and runnable at r2d4/corigin-benchmarks.

• hello-world — minimal: 1 commit, 3 objects, 1 head, 0 tags, 1 file, 4 KiB.

• nanoid — small: 1,232 commits, 5,756 objects, 3 heads, 118 tags, 49 files, 0.4 MiB.

• claude-code — small: 787 commits, 3,027 objects, 162 heads, 141 tags, 203 files, 12.6 MiB.

• vite — medium: 10,245 commits, 114,514 objects, 61 heads, 1,020 tags, 2,663 files, 25.0 MiB.

I timed stock git clone against GitHub and GitLab, 10 runs each after a discarded warmup.

For Corigin, I tested two lanes.

• Corigin lane uses a precomputed clone plan (corigin clone --plan), so the timed command is only the materialization — the plan can exist before the sandbox does.

• Corigin (plan in clone) lane runs corigin clone with only a token, so the plan fetch happens inside the timed run — one extra roundtrip.

In both lanes, the short-lived read token is minted outside the benchmark.

The tradeoffs

What are we giving up?

1. We compute the clone plan outside the sandbox, saving one roundtrip and about 155–370ms — the gap between the two Corigin lanes in the chart. You pass the token and plan to the sandbox, which still gets short-lived, scoped credentials.

2. We use a custom clone protocol instead of git. The end artifact is exactly the same git repository. The Corigin API accepts a normal git push for writes, but only supports clones through corigin clone.

3. git push gets slightly slower: that’s when we precompute the artifacts that make clones fast (I have ideas to reduce this).

4. The benchmark only measures full clone. Corigin does not support shallow, blobless, treeless, single-branch, or any other clone optimizations.

You might not need this

The simplest alternative is to skip the clone: attach a persistent disk or network filesystem from your sandbox provider and keep the repo on it. Mount time is effectively zero, and for one sandbox on one task at a time, it’s hard to beat.

But a disk is shared, mutable state. Even when caching makes file operations fast, every sandbox works against the same filesystem. Parallel agents need isolation. Once your provider’s answer is snapshots or “branching” disks, you’re rebuilding version control by hand — branches, merges, history. Git already solved distributed state across every provider. A fast clone keeps the repo a real Git remote: each sandbox materializes its own isolated copy on local disk, does its work, and pushes back with a normal git push.