QWE AI Academy Key takeaway: Codex didn’t break the git binary. It broke the assumptions behind hosted monorepos. OpenAI’s Scaling Git at OpenAI post (Nov 2, 2026) shows Pando keeping the Git protocol, cutting median push latency nearly 5× (about 80% lower), and moving nearly a petabyte of Git data per day. You can’t install their backend. You can copy the bets that removed contention.
If agents already open lots of branches, hammer CI, and collide on the same refs, treat this as a fork in the road: rebuild the server path while keeping Git, or replace Git. Most product teams should take the first road – and ship workflow changes before reliability slides the way OpenAI described (at times below 90% by late 2025, per their write-up).
Why this dropped – and why you should care
Aaron Friel, Taylor Blau, and Ted Nyman’s official engineering post is the source for the chart everyone screenshotted: commits landed on master up 1,378% by Q3 2026 vs Q1 2024, with a Q4 2026 estimate at 2,442%. One engineer ships several changes at once; each push fans out fetches across CI and research jobs.
HN and X split on cue – praise for the numbers, side-eye at “agent slop” as a growth strategy. Fair fight. Shared systems still fail first when you multiply writers and readers.
Think of classic Git hosting like a single checkout lane that demands every cart finish in global order. Fine for humans. Miserable when a thousand agents each need a lane.
Method A vs Method B: keep Git or leave it?
Two serious answers showed up in 2026.
| Dimension | Method A – OpenAI Pando | Method B – Anthropic Scion (and similar) |
|---|---|---|
| Client | Standard Git (+ OpenAI’s patches) | New client (e.g. scn) |
| Write model | Per-branch causal consistency | Server-centric changesets / CAS-style refs |
| Read path | Reuse stored packs via packfile-uri + regional cache | Tiered caches; often no full pack model |
| Tooling tax | Low – agents already speak Git | High – new habits, new forge integrations |
| Public availability | Backend internal; client work public | Internal; ideas shared, not a general product |
| Headline pressure (self-reported) | ~5× faster median push; ~1 PB/day Git data | Merges from ~2,500/day to 30,000+/day; new client/server path |
Method B fits if your monorepo is already a fake distributed system – always-online agents, server-side merge, almost no offline work. Anthropic’s direction matches that shape (GitLab’s write-up on the agentic forge path sketches the pressure).
Method A is what I’d pick for most product orgs I’ve worked with. Hooks, IDEs, review bots, coding agents: they already know git push. OpenAI’s wager was blunt – the protocol wasn’t the cliff; server assumptions were. Unless you’ve deliberately outgrown Git’s object model, don’t pay a forge rewrite tax first.
Detailed walkthrough: apply Pando’s winner moves without Pando
No Express tier. No their metadata store. Still three principles that drain contention.
1. Design agent work around per-ref serializability
Same ref? Serialized. Different branches? Parallel. So stop aiming ten agents at main.
- Unique branch per agent or task (embed the run id).
- One merger path to trunk – bot or human – not N parallel force-pushes.
- Teach agents that “tips of many branches” are eventually consistent, not one frozen repo picture.
- Prefer
--force-with-leasewhen rewriting a topic branch.
Why this matters: clients only truly serialize on the same ref under Pando’s model. A script that reads branch A, then branch B, then acts as if it saw one atomic clone is lying to itself – and will flake harder as agent counts climb.
OpenAI’s public Git work on “explicit haves” helps a server advertise trunk while a client still packs a side branch cleanly. On stock GitHub/GitLab the habit still beats the flag: isolate writes, merge once.
2. Make fetches cacheable, not bespoke
Classic hosts burn CPU on a custom pack per client. Pando keeps push packs and hands out URIs so readers share bytes. As of the Nov 2026 post: Express-layer hits over 99%; more than 57 TB of packs in a peak hour; clones/fetches able to saturate 10 Gbps on ordinary cloud VMs once generation isn’t the bottleneck.
# Agent sandboxes: partial + sparse
git clone --filter=blob:none --sparse <url> repo
cd repo
git sparse-checkout set path/you/need
# CI: one ref, shallow when history doesn't matter
git fetch --depth=50 origin "$BRANCH"
git checkout --force FETCH_HEAD
Turn on whatever pack reuse or regional mirrors your host already offers before you buy fatter runners. Bandwidth should become the ceiling – not pack generation.
Pro tip: Pin CI jobs to a commit SHA, not a moving branch name, so CDN/runner caches see identical objects. Agents love “latest main.” Caches don’t.
3. Steal client-side fixes that already shipped publicly
Pando the backend stays closed. The public trail is client/packfile-uri work and related fixes under github.com/openai/git – parallel pack download/indexing, interrupted download cleanup, and friends.
Pilot idea: their build in agent images first (fetch-heavy), system Git on laptops if you want a slower rollout. Measure fetch wall time and server pack CPU. Ignore vanity commit charts.
4. Roll out like they did: proxy, don’t big-bang
They fronted a read/write-through proxy, shifted traffic gradually, even leaned on Codex skills so devs could ask an agent to migrate checkouts. Copy the discipline, not the brand names: shadow traffic, dual-write metrics (push latency, merge failure rate, fetch TTFB), cut over by workload class – CI before laptops.
Edge cases agents will hit first
Cross-branch scripts that want one frozen view of every ref break under causal consistency. Read one ref, act, read the next. Don’t pretend clone/fetch negotiation gave you a repo-wide point-in-time snapshot.
The catch is advertisement size. With millions of branches, full ref lists can top 100 MiB, so Pando-style setups lean on trunk-heavy ads. Side-branch pushes resend non-trunk history. OpenAI still reported median push packs under 20 KiB and p99 under 3 MiB – annoying, not fatal – until stacked agent branches drag huge binaries along. LFS or keep blobs out.
Your host isn’t Pando. Those latency and PB/day figures are self-reported on their monorepo with custom caches plus a tuned client. Stock Git hosts won’t match them.
Release tooling that updates several refs in one go should verify atomic multi-ref behavior on your forge. Public Pando material does not fully spell out that contract under the relaxed consistency model – treat it as unspecified, not identical to classic Git.
And the gap nobody can close from the blog alone: no public cost model, no deploy guide, no independent benchmark. Hot-cache serving path ≠ cold enterprise mirror.
Is unbounded commit volume even the goal? Answer that on the roadmap before you scale the forge to match the slop.
FAQ
Can I run Pando on my monorepo today?
No. As of the November 2026 post it’s internal. They’re exploring ways to share the technology. Public pieces are Git client improvements and upstream patches – not the backend.
Should my coding agents keep using plain Git?
Yes for most teams. Picture five Codex-style agents pushing agent/job-$ID, a merger bot opening PRs to main, CI fetching by SHA with blob filters. Parallel writes, zero new VCS training. That’s why “replace the client” was the wrong first move for OpenAI – and likely for you.
Isn’t Anthropic’s replace-Git approach just better at this scale?
Only if you’re already centralized, always online, and ready to rewrite forge integrations. Scion answers a different constraint set after merge volume jumped from roughly 2,500/day to 30,000+/day. Pando’s narrower claim: drop repo-wide consistency and per-client unique packs – guarantees most agent workflows never relied on – and Git gains headroom. Cargo-culting either write-up is how you inherit the wrong tax.
Next action: one hot repo. Chart push p50/p95 and fetch CPU for a week. Force agents onto unique branches with SHA-pinned CI. If those curves flatten, you already captured what Scaling Git at OpenAI teaches – without waiting on a product launch.