--- title: "Scaling Git for the agent era | Coline" description: "How we pushed Rapid past 10,000 pushes a second in a weekend." url: https://coline.app/blog/scaling-git-for-the-agent-era --- [Sign in](https://coline.app/auth/signin) [Sign up](https://coline.app/auth/signup) [Sign in](https://coline.app/auth/signin) [Sign up](https://coline.app/auth/signup) [All posts](https://coline.app/blog) EngineeringNovember 10, 2026 # Scaling Git for the agent era How we pushed Rapid past 10,000 pushes a second in a weekend. Written by **The Coline Team** Last week, we announced that Upstream Rapid, our new Git engine, hit around 1,800 pushes per second, beating all of our competitors. Since then, GitHub Universe happened, and they announced Rubicon, their new engine, hitting 7,200 pushes/second. We took that as a challenge, and over this past weekend, we pushed Rapid even further. With agents, the demands on Git hosting are changing rapidly. Agents make far more commits than humans, day and night. Existing forges simply weren’t built for that kind of load. So we set out to solve that problem. On Saturday afternoon, we had 1,024 agents hitting a single Rapid repo at 1,317 pushes per second, and 36 hours and many optimizations later, we had 6,144 agents pushing to a single repo and hitting 10,527 pushes per second under sustained load with zero errors. Here's how "we" (our agents) built it, the issues we hit, and what it means for you and your agents. ## Building at speed We used Coline Code with a team of Opus 5.5 agents on this over the weekend. The rules were simple: no cutting corners, no visible changes for users, and keep the infrastructure simple and scaling to zero when idle. Our push throughput climbed rapidly: The first win came from the agents optimizing our push lanes. By having each lane index only its own branches’ history, they cut CPU usage by more than half, from 12.5 ms to just 5.3 ms per push. That alone took us from 1,317 to 1,734 pushes per second. They realized that by switching lanes, hubs, and branch list copies over to persistent WebSocket connections, each object could take far more messages a second. That got throughput to 7,060, and spacing each hub's sends 40 ms apart packed more data into each send, taking it to 8,249, past Rubicon’s 7,200. Next, they added dedicated reader objects to serve the branch list that every push needs, bringing publish time per push from 350 ms to 152 ms, with throughput going from ~8.5k to over 10k. And then there were the smaller (but still important!) optimizations. Caching advert templates, compressing adverts, increasing lanes per new repo, speeding up that first push on an empty repo. Meanwhile, our test rig was hitting its limits: The Go benchmark clients, written to simulate thousands of agents hammering the system, were maxing out 32-core VMs just parsing the ref lists coming back from Rapid. We had to scale up from a single client machine to 9, and then to 21, to keep the test load high enough to push Rapid to its limits. ## 10k holds at every size We ran Rapid through its paces to confirm the 10k result is no fluke: We also ran Rapid through a ton of other scenarios to make sure that the 10,000 result wasn't a one off. When we had 6,144 agents against 64 repositories simultaneously, Rapid had zero issues, getting 18,718 pushes per second with zero errors. In a 15-minute stress test, we had 6,144 agents continuously pushing. It held steady at 10,527 pushes per second, handling a total of 9.47 million pushes, no errors. We even extended that test to 30 minutes, during which Rapid processed an impressive 17.4 million pushes at a rate of 9,646 per second. To simulate real-world conditions where reads and writes mix, we had 384 agents cloning the same repository while another 6,144 pushed. Rapid maintained 10,777 pushes per second throughout, unfazed. We even saw bursts as high as 11,305 pushes per second. Of course, speed means little without accuracy. We verified that the ref advertisements produced were byte-for-byte identical to before, reads immediately following a push always retrieved the latest data, and clones of a repository withstanding 145,000 concurrent pushes passed git fsck integrity checks. ## Scaling up for monorepos Of course, we couldn’t just test Rapid on small repositories. We needed to see how it would handle massive monorepos. So we imported Chromium’s entire history into Rapid: 55GB, 28M objects, 1.68M commits. With 1,000 agents pushing concurrently across 4 global regions, Rapid delivered 1,934–2,333 pushes/sec with zero errors. That’s a huge leap from where we were in October (aka last week), at 1,220 pushes/sec. GitHub, for comparison, manages 4.7 pushes/sec on ForgeMark. And when we ramped up to 6,144 agents, Rapid scaled up, reaching 7,906 pushes/sec. But what about cloning? After all, fast pushes are great, but developers also need to be able to clone quickly. We tested this too. For a shallow clone of the Chromium repository on the same machine, back-to-back, Rapid took just 46 seconds. GitHub took 107 seconds. When cloning an old commit, something that used to take about an hour back in October, Rapid now does it in 7-10 minutes. For full clones, we saw speeds hit 30MB/s, finishing in 34 minutes to GitHub's 37. That’s because Rapid can stream data directly from storage, making even the largest clones fast. Memory optimization was another factor in handling these massive repos. Our agents were able to reduce the in-memory object index from 90 bytes per object down to just 16 bytes. For a repo the size of Chromium, that means the index now loads in 2.1GB. This is what lets Rapid handle the largest repositories at all. Chromium's index used to blow past WebAssembly's 4GB memory limit and crash the engine. Now it fits with room to spare, and less RAM per repository means lower costs and easier scaling. ## Still cheap None of this meant leaving servers running. A Rapid repository is still a set of small objects that go to sleep when nobody is pushing, and a sleeping repository only costs its storage. The helper containers that merge pushes in the background start when a repository gets busy, and go back to sleep ten minutes after it calms down. So a repository taking 10,000 pushes a second and one nobody has touched in a month run on the same engine. Only one of them costs more than its storage. ## Try it now Rapid runs every repository on Upstream, on every plan, including Free. It's normal Git, so `git`, your editor, your CI and your agents push to it exactly the way they do today. Make a repository on [upstream.codes](https://upstream.codes), point your agents at it, and see how fast they can go.