A CI job that only needs a diff can ask Anthropic's new Scion system for it without downloading a repository. That removes a familiar pipeline expense: copying code before deciding what to do with it, as Anthropic's engineering report explains.
Published October 13, the report describes a five-month migration from Git. Anthropic says daily merged changes rose from roughly 2,500 in May to more than 30,000 in September, with CI performing around 25 million checkouts daily. Those are company-reported figures, not an industry benchmark.
Anthropic reports a 25% gain in available CI CPU capacity after the switch. Its in-house system assumes clients can reach the server. Adopting Scion also requires different review, search and CI systems, so Anthropic rules it out as a general Git replacement.
Ask for the answer before fetching the files
GitHub already provides a smaller version of this approach. Its commit comparison API returns commits and information about changed files, including rename details and patches. A service that routes a change to the appropriate reviewer can use that response without creating a working directory. For that narrow task, the API supplies the information the service needs.
The response has limits that matter for automation. Without pagination parameters, GitHub caps the returned commit list at 250. With pagination, changed files appear only on the first page, with up to 300 files for the whole comparison. Paging through commits doesn't make that file list unlimited. A job using the endpoint to choose tests needs a fallback when the change exceeds what the response can describe. Otherwise, the saved download can come at the cost of missed tests.
GitLab's repository comparison API exposes a different boundary. Its compare_timeout field signals that a comparison timed out or exceeded size limits. The documentation says the commit array remains complete, while diffs may be incomplete. Individual diff contents can also be absent. An automation system must check those conditions before treating a response as the full change.
There is a choice about the comparison itself, too. GitLab defaults to comparing through the merge base, the common ancestor of the two revisions. Setting straight=true requests a direct comparison between the endpoints. Those answer different questions when branches have diverged. For a developer moving a local script to the server API, preserving the intended comparison is part of the job. Moving computation off the runner doesn't remove the need to define what result counts as correct.
An API-based job also has a request budget. GitHub's rate-limit documentation gives the standard GitHub Actions GITHUB_TOKEN allowance as 1,000 requests per hour per repository, with a higher allowance for resources belonging to an Enterprise Cloud account. Secondary limits can also restrict bursts. Replacing every local operation with a request can therefore introduce another queue. For a busy pipeline, include rate-limit responses in the measurement and follow the documented reset or retry headers. A job waiting for permission to ask its next question has merely moved the delay.
Download less, and know what you left behind
For work that needs repository objects locally, Git's partial-clone design already allows a client to omit unwanted objects and fetch them later. A repository object can hold file contents or describe a directory tree. Filtering can avoid downloading historical binary files or parts of a repository outside the task's work area.
That creates a dependency you can plan around. A promisor remote is a server that agrees to supply objects omitted from the clone. If a command needs one of those objects, the remote must be reachable. Git's documentation suggests fetching anticipated objects before going offline. The consequence for CI is straightforward: an initially cheap setup can still incur network work during the job. Measure the whole run, including later fetches, before counting the saving. The partial-clone documentation also separates this mechanism from shallow history, so the two shouldn't be treated as interchangeable settings.
The clone command's reference makes the distinction concrete. --depth truncates commit history. --filter=blob:none delays downloading file contents until Git needs them. --no-checkout skips creating the initial working tree. A job can reduce one kind of work while still paying for another: skipping checkout alone doesn't mean it skipped the repository transfer.
Choose those options around the operation the job performs. A build needs its input files. A history inspection needs the relevant revisions. Treating every task as a build can copy files unnecessarily, while treating every task as a shallow snapshot can leave a history query without its inputs. The documented clone options give you separate controls for different parts of repository setup. The useful experiment is to compare identical jobs and record both setup time and total runtime. A faster first step is only helpful if the rest of the job still has what it needs.
A sparse directory still needs the right inputs
Git's sparse-checkout command controls which tracked files appear in the working tree. Its default cone mode takes directory names. Selecting a directory also includes files alongside it or its ancestors, so the resulting tree isn't necessarily limited to the exact directory you named.
That behavior matters when a team estimates what an isolated task will see. Sparse checkout changes the visible files, while partial clone controls which repository objects arrive. You can use the concepts together, but shrinking a working directory doesn't by itself establish how much data crossed the network. A test of the setup should inspect both, following the sparse-checkout rules.
Git also documents behavior changes around sparse paths: switching branches doesn't update excluded paths, and git commit -a doesn't record excluded files as deleted. The manual labels the command experimental. Before giving an agent a sparse workspace, check that its build and editing workflow tolerate the missing paths. A smaller tree is useful only if the task's actual dependencies fit inside it.
The precedent predates coding agents
Meta's Sapling scale overview records years of work on these same costs. It dates on-demand historical file fetching to 2013 and sparse working-copy profiles to 2015. Later entries include historical tree fetching in 2017 and EdenFS, a virtualized working copy that fetches current files or trees on demand, in 2018. These techniques existed well before today's coding-agent workloads.
The chronology helps explain why source-control performance can't be reduced to clone speed. Sapling's list also includes filesystem monitoring for status checks and faster commit-graph algorithms. Those address different operations after the initial setup. For a team investigating slow automation, the documented history suggests measuring the command that's expensive. If repeated status scans dominate runtime, a smaller network transfer won't address the whole delay. If old file contents dominate transfer, a faster status command won't solve that either.
Public availability needs its own check. Sapling's introduction says its CLI can clone Git repositories and work with GitHub. It also says the server and virtual filesystem used for its largest deployments aren't publicly available. Installing the client doesn't give a team Meta's entire repository service. That distinction is useful when evaluating any account of an internal migration: identify which parts you can adopt and which require infrastructure you would have to operate yourself.
Anthropic points toward better server APIs for Git. Watch whether those interfaces let more jobs finish without a checkout, with complete answers and measured savings.