In this article
Anthropic says its monorepo went from about 2,500 merged changes per day in May to more than 30,000 in September. Its main-branch history approached 100 GB, a compressed working copy exceeded 25 GB, and CI performed about 25 million checkouts each day. A naive fetch model would have generated more than 600 PB of daily traffic. (Anthropic engineering)
The company responded by replacing Git for that monorepo with Scion, an internal source-control service built and migrated in five months. The important signal is not that Git has stopped working for ordinary teams. Anthropic says the opposite. Its workload is unusually large, its agent and CI clients are almost always online, and Scion requires a bespoke review, search, and CI stack.
The signal is where the bottleneck moved. Faster code generation did not remove software delivery constraints. It pushed pressure into repository transfer, history queries, review, integration, and validation.
Source control became a service
Git gives every clone enough state to work offline. Scion assumes that clients can reach an authoritative server. The server creates commits, performs rebases and merges, computes diffs and merge bases, and answers history and blame queries. Clients maintain a bounded object cache and request only the trees and blobs they need.
That asymmetry changes the unit of work. A Scion changeset is an entry in a write-ahead log. It stores the files changed relative to a parent plus content-addressed pointers to compressed blobs. Derived structures for path history, blame, and commit ancestry can be computed eagerly or on demand. Creating a changeset does not require a packfile, a repository-wide lock, or a ref update. Moving the main ref is a separate compare-and-swap operation.
For checkout traffic, immutable content-addressed objects pass through regional cache tiers. Anthropic reports a hit rate above 99 percent at each tier, a CPU and memory footprint 200 times smaller than its former Git mirror fleet, and checkouts that fell from minutes to seconds. It attributes a 25 percent CPU capacity gain in CI to the change. These are internal measurements from the system’s builder, not an independent comparison.
Teams should resist copying the architecture before reproducing the constraint. Start with four measurements:
- Split source-control latency into metadata queries, object transfer, working-copy materialization, and merge coordination.
- Count bytes and CPU per checkout by consumer class, including CI, agents, developer environments, and research jobs.
- Measure how far caches or repository seeds lag behind the authoritative head as the merge rate rises.
- Track the number and age of changes waiting for review, integration, tests, and deployment.
If clone traffic dominates, better server APIs, shared node caches, sparse checkout, or virtual filesystems may buy enough headroom without a migration. If review or test capacity dominates, a new repository format merely makes work arrive at the real queue faster.
Review intent, not generated volume
Seven people built Scion, its Antique review interface, and related systems over five months, according to Anthropic. The same account says engineers still review every change request, but focus on intent and design constraints rather than reading every generated line. Reviewers repeatedly had to reject agent implementations that satisfied a local pattern while violating a system-level rule, such as scanning commit history instead of calling the review service.
That distinction matters because 30,000 merged changes is a workload measure, not a productivity measure. It does not reveal defect escape, rollback frequency, customer impact, or the amount of follow-up work. A credible agent-scale delivery scorecard needs those outcomes beside throughput.
Semantic approval rules are one useful response. Anthropic’s review system can distinguish simple comment edits from sensitive logical changes and route human attention accordingly. A more portable implementation is a policy gate that classifies a change by affected capability, privilege, data boundary, and rollback difficulty, then requires the appropriate reviewer and tests. The agent can produce more patches; it should not lower the evidence required for a risky patch.
Migration clock: GPT-4 snapshots get a January deadline
OpenAI’s deprecations page now dates a new notice to October 14. GPT-4o snapshots gpt-4o-2024-08-06 and gpt-4o-2024-11-20, GPT-4o mini gpt-4o-mini-2024-07-18, and GPT-4.1 and GPT-4.1 mini snapshots will be removed on January 14, 2027. Fine-tuned versions follow the same schedule, and OpenAI recommends gpt-6-luna as the replacement. (OpenAI deprecations)
This is not a model-string edit for systems with fine-tunes, structured outputs, tool policies, or latency budgets. Inventory the exact snapshot behind every endpoint, replay production-shaped cases against the replacement, compare schema validity and tool-call behavior, and keep rollback independent of the retiring model. An earlier OpenAI deadline also remains close: a separate group of legacy snapshots shuts down on October 23, 2026.
Application watch: retrieve behavior by failure cost
Fin’s September 25 engineering account describes a related scaling problem inside customer-service agents. As customer rules, connectors, and procedures grew, passing the entire configuration on every turn increased cost and made relevant instructions harder to isolate. Fin trained separate cross-encoder selectors from production decisions, then gave each surface a different retrieval contract. (Fin research)
Guidance uses a top-10 shortlist and fails open to the full rule set. Connectors use a high-recall gate because several tools may be needed together. Procedures use an absolute threshold so that “none” remains a valid answer. On a held-out week of production traffic, Fin reports recall of 0.97, 0.95, and 0.95 respectively, with filter rates from 0.44 to 0.74. Live tests kept resolution stable for connectors and procedures, while guidance showed a small decrease alongside higher rule adherence. Exact online effect sizes were not disclosed, and the evaluation is vendor-authored.
The reusable principle is to choose retrieval semantics from the cost of a miss. Instructions, tools, and procedures should not share one top-k policy merely because they share an embedding index.
Stay Sharp: use Little’s Law on the delivery queue
John D. C. Little’s 1961 result states that, for a stable system under its assumptions, the average number of items in the system equals arrival rate multiplied by average time in the system: L = λW. (Little, 1961)
Applied to software delivery, define the boundary before using the formula. If “in the system” means accepted for review through merged, then arrival rate, work in progress, and elapsed time must all use that same boundary. At 30,000 changes per day, one minute of average residence time corresponds to about 20.8 changes in flight. Ten minutes corresponds to about 208. That calculation does not describe Anthropic’s actual queue because its residence time is undisclosed. It shows why small delays become large inventories at high arrival rates.
Measure the queue by risk class and stage. A falling merge latency can coexist with a growing pre-deploy test queue or rollback queue. Little’s Law helps expose the displaced bottleneck, but only after the team defines arrivals and departures consistently and checks that the period is stable enough for the averages to mean something.
Watch next
- Defect escape, rollback, and deployment-frequency data from agent-heavy development environments, not only merged-change counts.
- Whether standard Git servers add cheaper history, diff, and sparse-object APIs for always-online agent clients.
- Replacement-model evidence for the January 14 OpenAI deadline, especially fine-tune behavior and tool-call regressions.
- Independent evaluation of behavior retrieval under changing policies, rare procedures, and linked tool sequences.