Git has carried software development for more than twenty years. Anthropic decided it could not carry Claude.
Seven engineers spent five months building a version control system called Scion and migrating the company’s core repository onto it. In May, Anthropic was merging about 2,500 code changes a day. By September the figure had passed 30,000. The continuous integration system alone runs roughly 25 million code checkouts every day.
Writing code got faster. Preparing repositories, synchronising objects and querying history got heavier, and the cost landed on machines rather than people.
Offline capability became overhead
Git’s distributed design lets an engineer clone a repository and keep committing, merging and reading history with no network. The workloads now arriving at the repository are the opposite. They are CI jobs and agent sandboxes that are always online, that live for a few minutes and are destroyed, and that may need three files, one diff, or confirmation that one commit is an ancestor of another.
Preparing a local repository for each of those requests is repeated work. Anthropic’s main branch history is close to 100 gigabytes, and a compressed working copy exceeds 25 gigabytes. Fetching a full copy for 25 million daily checkouts would imply more than 600 petabytes of traffic. The company used shallow clones, sparse checkouts, snapshots and hundreds of Git mirrors. The mirrors still have to synchronise, the snapshots expire, and history queries still need objects fetched into place. The busier the repository, the more the maintenance costs.
Scion shrinks the client to a thin entry point. Commit creation, merging, rebasing and history queries move to a central service. Locally it watches for file changes and keeps a small cache, expanding a working directory on demand. If CI only needs a diff, it calls an API instead of checking anything out. Offline autonomy is gone. Repeated initialisation goes with it.
A changeset is not a commit
The storage format changed too. A Git commit points at a tree describing the state of the repository. A Scion changeset records, as a write-ahead log entry, the files that differ from the first parent, referencing data through content-addressed pointers.
Creating a changeset requires no packfile and no immediate movement of a shared branch. When a reference like main does move, the system performs a compare-and-swap on a single row in Spanner. Agents can generate changes concurrently, and contention concentrates at the moment the branch reference moves.
History queries remain the difficult part. Incremental records cannot answer who last touched a line or what happened to a file. Scion maintains derived data for blame, path history and a skip list of the commit graph, precomputed against parent relationships or generated when a query arrives. Writes and history analysis then scale independently.
On checkout the client starts from the target tree and requests only the trees and blobs it lacks. Requests pass through a daemon on the node, a regional cache, then a server that falls back to Spanner or object storage. Objects are immutable once written, so caches can be reused across jobs and the negotiation, compression and retransmission mostly disappear. Anthropic reports a cache hit rate above 99 per cent and caps origin traffic during failures.
The migration result is a CPU and memory footprint roughly 200 times smaller than the old Git mirror system, checkouts that moved from minutes to seconds, and about 25 per cent of CI compute capacity released. That 200 times refers to infrastructure resource use, not to Git operations becoming 200 times faster. Anthropic also had to build code review, source search, identity and access management and batch merge tooling around the new protocol, and running an online service became a new cost of its own.
The same problem in chip verification
Chip verification hits the same wall from a different direction. Simulation produces waveform files recording every signal over time, and a complex design can dump tens or hundreds of gigabytes. An engineer scrolls a viewer looking for the anomaly. An agent that converts the raw waveform to text fills its context with timestamps, signal names and repeated transitions before it finds anything.
BTTF, from Columbia University and Google DeepMind among others, moves the data into SQLite. One table holds signal names, types and hierarchy, another holds signal identifier, timestamp and new value, joined on identifier. Asking for the state of a signal at a moment becomes a lookup of the most recent change before that moment. Between two transitions the state is unchanged, and treating a missing row as unknown would be a bug.
The model then handles the question and a small set of returned events. In a handshake timeout, an agent can look up changes in request and response signals, narrow to the anomalous interval, and check timing relationships. The database retrieves, the model decides what to retrieve next.
Importing does not remove the pressure. High-frequency clocks generate dense records, and row-by-row inserts carry transaction cost. BTTF maps waveform identifiers to database identifiers at ingestion, counts transitions, filters clocks, drops signals that never toggle and batches inserts. An unpruned database took 1,420 megabytes and answered queries in about 410 milliseconds. After filtering clocks and static signals it fell to 395 megabytes and 94.8 milliseconds. Pruning further to signals with below-average toggle rates reached 185 megabytes but covered only 64.23 per cent of activity.
That last trade is the danger. A rare fault often sits on a control signal that almost never changes. Data deleted at import cannot be recovered later by the agent, so pruning has to follow assertion and debugging requirements rather than size targets.
With the SQL interface in place, BTTF splits the work across agents: one decomposes the task, one writes queries, one checks assertions against RTL source, one audits time ranges, field relationships and completeness. On a 4.2 gigabyte waveform with 18,450 signals and 150 expert-annotated queries, the system reached 95.33 per cent execution accuracy. Multi-agent scoring improved 17.3 per cent over a single agent while average latency rose about 1.96 times, and static assertion checking reached 84.62 per cent.
Why secret scanning went back to a classifier
High-entropy strings may be live credentials, test fixtures, placeholders or checksums. Regex finds candidates quickly but reads no context. A general-purpose model can judge context, and the cost of that judgement accumulates with every candidate, which matters badly for push protection, where the answer has to arrive before a commit is accepted.
GitHub kept the regex as a candidate filter and moved the judgement to a fine-tuned ModernBERT. The encoder reads the candidate string, the secret type, the variable name, the file path and nearby code, and returns a risk score that a threshold turns into an alert. A forward pass returns a class in one shot instead of generating tokens one at a time, which suits bulk processing of similar requests.
The hard part is hard negatives, the strings that look exactly like keys and are harmless. GitHub combined product feedback and human labels, high-recall candidates from real repositories, and deliberately synthesised difficult negatives, then split training and evaluation by repository, candidate value and association to avoid the model memorising file names instead of learning what a credential looks like in an unfamiliar project.
The model ships as ONNX with 8-bit quantisation, and the threshold has to be calibrated against precision, recall and live traffic. Too loose and the alerts become noise. Too tight and real keys pass. Against the old language model pipeline, offline precision rose 13 per cent and recall 19 per cent. In production A/B tests the median post-push scan time fell 86 per cent, model serving cost fell more than 98 per cent, and the owner-weighted alert acceptance metric rose 11.5 per cent. The 98 per cent refers to model serving, not the total cost of the security system.
The bottleneck moved
Fixing checkout did not finish the job at Anthropic. A test round can still be running while hundreds or thousands of changes land on main. A global lock lets a backlog build. Releasing concurrency creates a different problem, because a test that passed may correspond to a code state that no longer matches what is about to deploy.
What CI has to solve next is how a verification result stays valid under continuous change. Build caches must detect changes in source and dependencies. Test records must be tied to specific commits and artefacts. The system has to decide which results can be reused and which edits invalidate earlier verification. For a monorepo with deep dependency graphs, adding test machines does not resolve version consistency under concurrent edits.
Anthropic has started strengthening post-merge testing and pre-deployment verification. For most teams the practical order is dependency analysis, incremental testing and build caching before rebuilding the version control system. But the direction is clear. As agents raise code output, the constraint travels down the delivery chain, from how fast code can be written to whether the build, test and deploy stages can still prove that what ships is what was tested.
Editor’s note: This is an adapted translation of the original Leiphone report. It has been trimmed and restructured for readability for an international business audience. The full original (in Chinese) is at https://www.leiphone.com/category/ai/wHcf2tZUiQkXGM0i.html.