Cloudflare’s Artifacts Turns Agent Git Into a Repo-Per-Task Bet and Leaves Merging to a Contest

Cloudflare moved Artifacts, its Git-compatible storage service, into open beta on October 1 and paired the launch with a contest to build “the next Git platform” on top of it. Read side by side, the documentation, the two launch posts and the contest’s official rules describe one clear design bet: give every agent task its own small repository, and leave the question of how all those repositories get reviewed and merged back to someone else.

This piece lines those documents up, checks Cloudflare’s limits and prices against Git’s own protocol documentation and GitHub’s published guidance, and points out where Cloudflare’s pages disagree or go quiet. It reflects the pages as they stood on October 1, 2026. We did not test the service itself, which requires a paid Workers plan.

What shipped on October 1

Artifacts is, in Cloudflare’s words, “a versioned filesystem that speaks Git and can scale to millions of repositories.” It first appeared on April 16 as a private beta, and the launch post said Cloudflare was “aiming to open this up as a public beta by early May.” The changelog dates the open beta to October 1, about five months after that target. Access requires the Workers Paid plan.

The open beta announcement lists five capabilities, some of which, such as the Workers binding, were already available in the private beta:

• Deploy on push. A repository can be connected to a Worker through Workers Builds. Pushes to the production branch deploy the Worker, and pushes to other branches create or update Worker Previews.
• A Workers binding. A Worker can create or fork repositories, inspect files and commits, and issue repo-scoped Git tokens.
• Events. Artifacts publishes events when a repository is created, imported, forked, deleted, pushed to, cloned or fetched, and the event guide adds token changes to that list.
• Data jurisdiction. A namespace can be pinned to the US or the EU. The changelog’s August 13 entry says a jurisdiction cannot be changed after the namespace is created.
• Metrics. Per-repository operations, pulls, pushes, errors and error rate appear in the dashboard and through an API.

The April post said more features would “land over the next few weeks.” Metrics and event subscriptions are on the changelog’s open beta list. The post also planned “Native TypeScript, Go and Python client SDKs” and search APIs for questions like “find all the repos with a package.json file.” The documentation index lists no SDK pages, and the only search parameter we found is on the list-repositories route, so those items do not appear to have shipped.

How it is built, and what the limits look like

The launch post explains that each repository is a Durable Object. Files live in the object’s SQLite database, and “Durable Object storage has a 2MB max row size, so large Git objects are chunked and stored across multiple rows.” Durable Objects also carry “~128MB memory limits,” which is why, in the post’s telling, the platform can spawn tens of millions of them but has to work within those limits. Cloudflare wrote the Git server itself in Zig and compiled it to Wasm. The How Artifacts works page adds that a repo is “a single logical instance that Cloudflare can route to from any region,” and that a fork “creates a new repo that starts from an existing repo’s history, then diverges independently with its own tokens, routing, and lifecycle.”

Sources: the limits and pricing pages.

For scale, GitHub’s repository limits page recommends keeping a repository’s on-disk size, meaning its .git folder, within 10 GB, and warns that “Large repositories can slow down fetch operations and increase clone times for developers and CI.” Artifacts’ 1 GB is a documented maximum rather than a recommendation, and a tenth of GitHub’s figure, although the two pages do not say they measure the same thing. The launch post motivates its ArtifactFS tool with the question of “a multi-GB repository,” and adds that “ArtifactFS works with any Git remote, not just our own Artifacts.” With a 1 GB cap, the multi-GB case presumably lives on other remotes.

Protocol support is narrower than a full Git host as well. The Git protocol page says Artifacts supports protocol v1 and v2 for clone and fetch, but push uses v1 only: “Artifacts does not support v2 receive-pack.” It also says “Some optional v1 capabilities, such as filter and include-tag, are not supported.”

Cloudflare’s own advice: one repository per unit of work

The best practices page is the most telling document in the set. It says “Create one repo for each unit of autonomous work. If you have 10,000 agents, create 10,000 repos,” and gives the reason: separate repositories avoid “turning one shared repo into a hot spot for conflicts, large diffs, and accidental overwrites.” Branches are for narrower cases: “Use branches only when collaborators share the same lifecycle and need to work on the same repository. Do not use one shared repo as a queue for many autonomous agents.”

What the rate limits imply

The rate limits show why Cloudflare steers people this way. The two calculations below are our estimates, built from Cloudflare’s numbers and Git’s protocol documentation, not figures Cloudflare publishes.

• Creating repositories. A limit of 2,000 control-plane requests per 10 seconds per namespace is 200 per second. If each create or fork is one request, creating 100,000 task repositories through a single namespace takes at least 500 seconds, a little over eight minutes. The best practices page anticipates this: “When one namespace becomes hot, shard new repos into additional namespaces instead of continuing to grow a single shared namespace.”
• Cloning one shared repository. Git’s protocol v2 documentation describes a session that opens with an info/refs request and then says “Only a single command can be requested at a time.” A clone needs at least the ls-refs and fetch commands after that opening request, so three requests. Against 2,000 requests per 10 seconds, that is at most about 666 complete clones per ten-second window for one repository, and 1,000 agents cloning the same baseline at the same moment would need about 3,000 requests. Cloudflare’s docs do not define what counts as a request, so treat this as an estimate.

Both numbers point the same direction. Many small, isolated repositories are cheap to create, easy to hand a narrow credential, and easy to throw away. Forking from a baseline is a control-plane call rather than a clone against the baseline’s Git endpoint, so it draws on the namespace limit instead. What the architecture cannot do for you is bring the results back together.

Tokens follow the same logic

Tokens are repo-scoped and come in two levels: read for clone, fetch, pull, indexing and review, and write for push and other mutations. Their format is art_v1_<40 hex>?expires=<unix_seconds>, so the expiry travels inside the token string. The best practices page says “Give tokens short lifetimes, and re-issue a fresh token for each agent session,” and its examples mint a 15-minute read token and, in the sandbox example, a one-hour write token. It is the same idea of scoping what an agent can do that we covered in NVIDIA’s OpenShell launch and in Docker’s explainer on YOLO modes, applied to source control.

The half Cloudflare did not build

Cloudflare is explicit about where Artifacts stops. The October 1 post says it designed Artifacts “as a set of programmable primitives that developers could use to build their own products, workflows, and abstractions,” and then names the open layer: “how agents coordinate their work, how changes are reviewed and merged, and what the developer experience should look like when hundreds or thousands of agents are working on the same codebase.” The next sentence is “That is the layer we want you to build.”

The documentation matches that description. The Workers binding’s repository methods are info, createToken, listTokens, revokeToken, fork, log, readCommit, readTree, readBlob and readFile. We searched the 25 pages in Artifacts’ own documentation index on October 1: “pull request” appears nowhere, and “merge” and “diffs” appear only on the best practices page, in prose about what separate repositories let you do, such as “review, merge, archive, or delete work independently.” The October 1 post’s review example is a few lines of glue. A Worker consumes the cf.artifacts.repo.pushed event and starts a review Workflow, passing it the repository, branch and new commit. Everything after that is yours to write.

None of this means merging is impossible. Artifacts speaks standard Git, so any Git client can fetch from one task repository, merge locally and push to another. What the documentation does not describe is the machinery a Git host normally wraps around that act: an object that marks a change as proposed, a record of who reviewed it, a rule about what may land on which branch, and a policy for two agents that touched the same file. Token scopes are described at the level of the whole repository, read or write, and the pages say nothing about branch-level rules.

That matters more because of deploy-on-push. For a repository connected through Workers Builds, the changelog says: “Pushes to the production branch deploy the updated Worker, while other branches create or update Worker Previews.” A write token for such a repository is therefore, in effect, also a deploy credential. Our reading of the best practices page, not a statement from Cloudflare, is that the safe pattern is for agents to write only to their own forks while a single merge service holds the write token for the canonical repository.

The layer is hard for a reason GitHub’s documentation states in one sentence. A merge queue exists for “automating pull request merges into a busy branch and ensuring the branch is never broken by incompatible changes,” according to the merge queue documentation. The contest asks what that problem looks like when the authors are, in the launch post’s phrase, “agents who never sleep, can work on several issues at once, and never tire.” We have covered the verification side of that pressure in our look at Red Hat’s argument that faster coding is not making delivery faster and in a tutorial on reviewing AI-generated Python code before you merge it. Anthropic’s relaunched Claude Code Projects tackle parallel agents at the product layer; Artifacts is a storage-layer answer to the same pressure.

What the contest rules say

The contest’s official rules are a PDF linked from the landing page, and they differ in emphasis from the blog post.

Four things the rules reveal

The scale drifts. The rules require only “multiple agents working on changes concurrently.” The blog post imagines “hundreds or thousands of agents” on one codebase, and the landing page asks for “a new way for hundreds of thousands of agents to work on changes concurrently.” Cloudflare’s best practices example is 10,000 agents, and its changelog says Artifacts can create “tens of millions of repos.” None of the scoring text puts a number on concurrency.

The hard problem is, at most, a quarter of the grade. The review and conflict handling that the blog post calls the open layer share one 25% criterion with concurrency, coordination and context preservation, while the largest weight, 50%, goes to originality and prototype quality. One reasonable reading is that a polished, novel interface can outscore a rigorous but plain merge arbiter. That is our reading of the rubric, not a statement from Cloudflare.

The code is open by design, and Cloudflare keeps its options. Entries must be MIT, Apache 2.0 or BSD licensed, so anyone can reuse them. The rules also say Cloudflare and its affiliates “develop products and services that may be similar to or compete with Projects” and that nothing in the rules restricts Cloudflare from “independently developing, acquiring, or marketing such products or services.” That is standard contest language rather than a prediction, but it is worth reading before spending a week on a submission.

Access is narrower than the invitation. The blog post is titled “We want you to build the next Git platform on Cloudflare,” while the rules limit entry to residents of the United States and Canada. The rules also open with “NO PURCHASE OR PAYMENT OF ANY KIND IS NECESSARY TO PARTICIPATE IN THIS CONTEST,” while the blog post and the pricing page say Artifacts is available on the Workers Paid plan. The rules never mention that plan, so how an entrant without one gets access is not answered there.

Dates and money: where the pages disagree

The October 1 blog post says: “We will begin billing for Artifacts usage on October 15, 2026.” The pricing page and the changelog, both dated October 1, say billing begins on October 14. The contest closes at 11:59 PM Pacific on October 14, finalists are announced on October 16, and Cloudflare Connect runs October 19 to 21 at Moscone West in San Francisco, with finalists presenting on October 21. Under the pricing page’s date, billing starts on the same day the contest closes.

The operations meter is cheap at agent scale. The per-unit prices match the table in the April launch post, which says Cloudflare will charge for “the operations (e.g. clones, forks, pushes & pulls) against each repo.” The illustration below assumes each task is one fork, one clone, three pushes and one pull, or six operations, and it leaves out Workers, Workflows, queue and model costs. Neither page says how a push that takes several HTTP requests is counted.

Storage is the larger unknown. The pricing page says storage is “calculated across all repositories,” and the pages we read do not say whether a fork shares objects with its parent. If it did not, 100,000 task repositories averaging 50 MB would hold about 5,000 GB, five times the default account cap of 1 TB and roughly $2,500 a month at $0.50 per GB-month. That is an illustration, not a forecast, but it shows that the fork-storage question matters more to the bill than the operation count.

What to do with it today

• Use forks as task workspaces and keep one canonical repository that only a merge service can write to. Mint read tokens for review and indexing agents.
• Decide how you will arbitrate between parallel results before you scale the agent count. GitHub’s merge queue is a useful reference for the problem even if you never use it.
• Keep tokens out of URLs. The Git protocol page recommends passing the token through http.extraHeader for local workflows and keeping “credentials out of the remote URL,” and the import guide says “Treat result.token as a secret.” The sandbox example builds a remote URL with the token embedded, so if you copy it, keep that token short-lived and out of logs.
• If you store prompts and model output as git notes, as the best practices page suggests, push and fetch refs/notes/* explicitly. The page warns that “notes live on separate refs.”
• Check the constraints before moving a large repository: 1 GB per repo, 32 MB per file, push over protocol v1 only, and no filter capability on v1 fetches.
• Put October 14 on the calendar, and ask Cloudflare which billing date is right.

What to watch

Finalists are announced on October 16 and present on October 21. The more telling signals will be in the documentation: whether the changelog adds server-side review or merge primitives, whether the billing date is corrected, and whether fork storage is spelled out. Artifacts is part of Cloudflare’s Birthday Week, which also brought the two agent billing betas we examined on September 30. Until the contest produces something, Artifacts is best understood as cheap, isolated, credentialed workspaces for agents. How the work gets back together is the part Cloudflare is sourcing from the crowd.