Runner Compute Parity Is Here. The Real Race Is After the Build.

The GitHub Actions runner market spent the last 18 months in a compute arms race. Faster CPUs, warmer caches, shorter cold starts. And it worked. But by mid-2026, the results are in: the contestants are all within shouting distance of each other.

Namespace designs and deploys its own server racks in custom datacenters. WarpBuild ships full-disk VM snapshots so your runner picks up where the last one left off. RunsOn just launched v3 with a new Flex control plane and scaling boosts. Depot built Switchyard, an orchestration engine with parallel steps and durable checkpoint replay. Every one of these vendors is shipping meaningful compute improvements. And every one of them, on a well-optimized workflow, lands within a 20-30% band of the others on cold-start and raw throughput.

That's not a bad thing. It means the floor has risen for everyone. But it also means that if you're a CTO or platform lead evaluating runner vendors right now, raw speed alone can't justify a migration. The question has shifted: what does your CI platform do with the build output once the runner is done?

The evidence for convergence

Look at what shipped in Q1 and Q2 of 2026:

Namespace raised $23M in a Series A (March 2026) to scale its bare-metal infrastructure. They don't rent cloud instances; they design and deploy their own server racks across multiple datacenters. Their pitch is purpose-built hardware for build and test workloads, and customers like Ghostty's Mitchell Hashimoto and Warp's Aloke Desai publicly praise the performance. Namespace claims 2x-10x faster CI compared to GitHub-hosted runners, and they've got the customer logos to back it up.

WarpBuild tackles the same problem from a different angle: full-disk VM snapshots. Instead of booting a clean runner and re-installing dependencies every time, WarpBuild snapshots the entire VM state so your next job picks up exactly where the last one left off. They claim 2x faster and 50% cheaper than GitHub-hosted runners, with customers like Comcast and Sonar on the roster.

RunsOn v3 landed April 29 with a rebuilt Flex control plane, scaling boosts, simpler sizing, and better metrics. It's a solo-founder project processing 1.36 million GitHub Actions jobs in a single day as of March 2026. RunsOn runs in your own AWS account, so compute costs pass through at EC2 prices.

Depot went further than just runners with Depot CI, a programmable CI engine built from scratch. Their Switchyard orchestration layer dispatches workflows, resolves dependencies, and handles durable checkpoint replay. Depot reports saving over 233,000 compute hours for customers in a single week.

These are four different technical approaches (bare metal, VM snapshots, self-hosted control plane, purpose-built CI engine) all converging on a similar outcome: fast, reliable builds. The compute race isn't over, but the gap between the front-runners has narrowed to the point where it's hard to justify switching vendors on speed alone.

Why 20% faster builds don't change the developer experience

Here's the thing about a 20-30% speed difference in CI: most developers can't feel it. A 12-minute build that drops to 9 minutes is nice, but you're still context-switching away from that PR. A 5-minute build that drops to 3.5 minutes is better, but you're probably still not sitting there watching it.

The perceptual threshold for CI speed is somewhere around 2x. Below that, you notice it on a chart but not in your day. And when every vendor is within that sub-2x band of each other, the decision has to be about something else.

Cost is the obvious second axis. And there's real variance there, particularly between hosted solutions like WarpBuild and self-hosted approaches like RunsOn, where you pay EC2 prices directly. But cost alone is a thin moat. As compute commoditizes, margins compress for everyone.

The axis that hasn't converged is what happens during and after the build.

The latency that actually matters

Think about what happens after your CI pipeline goes green. In most teams, the PR sits in a review queue. Someone has to look at it. They leave comments. You respond. Maybe there's a second round. The elapsed time from "CI passed" to "PR merged" is often measured in hours or days, not minutes.

You saved 3 minutes on the build. Then the PR waited 6 hours for review. The runner vendor's speed improvement is rounding error in that timeline.

This gets more pronounced with agentic workflows. GitHub's own engineering team published a detailed analysis of token efficiency in agentic workflows on May 7, 2026. The core finding: agent idle time and wasted inference cycles are the real cost drivers. They instrumented their production agentic workflows, discovered that most agent turns were spent on deterministic data-gathering rather than actual reasoning, and built optimization workflows to prune the waste.

Their Auto-Triage Issues workflow saw a 62% reduction in effective token usage after optimization. Security Guard dropped 43%. But here's the part the runner vendors don't talk about: all of those gains came from eliminating unnecessary work inside the workflow, not from running the same work on faster hardware. A faster runner executing 38 unused MCP tool registrations per API call is just burning tokens more quickly.

The implication is clear. For agentic teams, the feedback loop isn't just runner-to-result latency. It's runner-to-reviewed-result latency. And that's a fundamentally different product problem than making VMs boot faster.

What the runner-only vendors aren't building

Namespace, WarpBuild, RunsOn, and Depot are all excellent at compute. Each has made real engineering investments to push build times down. But none of them have built anything that touches code review.

No automated review comments. No AI-powered fix suggestions. No coverage metrics that tell you whether the PR was actually reviewed before merge. Their product boundary ends when the runner hands back a green or red status check.

That's a deliberate product decision, and it's a reasonable one if you believe compute is the main bottleneck. But the GitHub token efficiency research suggests otherwise. The biggest gains don't come from faster execution; they come from not doing unnecessary work and from closing the gap between "build finished" and "someone actually looked at this."

This is where Tenki sits differently in the market. Tenki ships both managed GitHub Actions runners and an AI code reviewer as a single platform. The runners handle the compute side (30-50% faster, 50-80% cheaper than GitHub-hosted, depending on the workload). But the code reviewer is what closes the loop: it reviews PRs automatically, catches bugs, and provides context-aware feedback before a human reviewer even opens the diff.

That combination matters because the two products address different parts of the same timeline. Fast runners shrink the build step. Fast automated review shrinks the review wait. Together, they compress the entire path from push to merge in a way that a runner-only product can't.

The token efficiency connection

GitHub's token efficiency post describes a specific version of this problem. Their agentic workflows trigger on events like new issues and PRs, run on GitHub Actions, and consume LLM tokens at every step. The optimizations they found (pruning unused MCP tools, replacing MCP calls with deterministic CLI commands, adding pre-agentic data downloads) all share a common theme: remove the parts where the agent is waiting, guessing, or repeating itself.

Now extend that logic to the full PR lifecycle. An AI coding agent opens a PR. CI runs and passes. Then the PR sits. No one reviews it because the team is busy, or because review assignments are manual, or because the diff is large and intimidating. The agent can't proceed until the review clears. Every minute it waits is waste, the same kind of idle-time waste GitHub's team optimized away inside individual workflows, but at the process level instead of the token level.

Fast runners don't solve this. Faster boot times, better caching, purpose-built hardware: none of it helps once the build is done and the PR is waiting for human attention. Automated code review is the only thing that shortens that gap without hiring more reviewers or lowering your quality bar.

What to actually evaluate

If you're choosing or re-evaluating your CI stack right now, runner benchmarks are table stakes. Check them, make sure the vendor isn't dramatically slower than the competition, and move on. The real differentiators are:

• Push-to-merge latency, not just build time. How long does the full cycle take from code push to merged PR? If your CI finishes in 4 minutes but review takes 4 hours, your bottleneck isn't compute.
• Review automation depth. Does the platform just tell you the build passed, or does it actually look at the code? Automated review that catches real issues before human review starts is a different category of value than a green checkmark.
• Agent-readiness. If you're running or planning to run AI coding agents, your CI platform needs to handle higher PR volume without proportionally more human review time. That's a product capability, not a hardware spec.
• Total cost of the feedback loop. Runner cost per minute is easy to compare. The harder question is: what's the cost of a slow feedback loop in developer time, context-switch overhead, and delayed deployments?

The market is telling you where it's going

Namespace's $23M raise, RunsOn v3, WarpBuild's snapshot caching, Depot's Switchyard engine: these are all signs that the compute layer is maturing. When four serious competitors all ship major infrastructure upgrades in the same quarter, that's convergence, not differentiation.

Meanwhile, GitHub's own research is pointing at a different bottleneck entirely: the waste that happens when fast CI feeds into slow review processes. The token efficiency work shows that even inside GitHub's infrastructure, the biggest wins came from eliminating idle time and unnecessary inference, not from faster hardware.

The vendors that win the next phase of this market won't be the ones with the fastest cold start. They'll be the ones that do something useful with the build output, that close the feedback loop all the way to a reviewed, merged PR. Runner speed got the market to parity. What happens after the build will determine who pulls ahead.