CI Queue Depth Is the Next Runner Bottleneck

The runner market spent the last two years racing to eliminate cold starts. It worked. Tenki, Blacksmith, Namespace, Depot — they all deliver runner boot times under 15 seconds, some under 5. For most teams, the cold start problem is done.

But something else is happening. AI coding agents are generating PRs at a pace nobody planned for, and CI infrastructure wasn't designed to absorb it. The bottleneck has moved. It's not how fast your runner boots. It's how many jobs are sitting in the queue ahead of yours.

The numbers that make this real

Greptile's Rise of the Overnight Agents report, published May 2026, puts hard data behind what platform teams have been feeling: 27.6% of merged PRs in April 2026 showed evidence of full AI authorship. In February 2025, that number was 0.86%.

Greptile identified these PRs by tracking bot author tags, Co-Authored-By footers from Claude and Devin, and branch prefix conventions like codex/ and cursor/ from Codex and Cursor background agents. This is a floor estimate — the real number is probably higher.

Think about what that means for CI. A single developer running 10 agents in parallel — which is already common — means 10 PRs triggering CI simultaneously. A team of five engineers doing the same produces 50 concurrent workflow runs. Most organizations provisioned their runner pools for a world where humans pushed code, reviewed it, waited, revised, and pushed again. That world had natural rate limits built into the process. Agents don't have those.

Why faster runners don't fix queue problems

Cold start optimization assumes the constraint is provisioning time: how quickly you can go from "job requested" to "runner executing." And for a long time, that was the right problem to solve. GitHub's hosted runners could take 30–60 seconds to start. Cutting that to 5 seconds was a genuine improvement.

But provisioning a runner in 2 seconds doesn't matter when your job is 15th in a queue of agent-pushed commits. The latency isn't in boot time. It's in wait time. Your job is ready to run; there's just nowhere to run it.

This is a category shift. Cold start is a provisioning problem. Queue depth is a scheduling and capacity problem. They require different solutions.

What queue-aware CI scheduling actually requires

If you accept that queue depth is the new constraint, the feature set you need from your CI infrastructure changes substantially. Three things matter most:

Priority routing. Not all PRs are equal. A human-gated PR that's blocking a release should run ahead of an agent's fifth iteration on a refactoring task. Today, most CI systems process jobs in FIFO order with no awareness of whether the commit came from a human engineer or an agent doing speculative work. Priority routing means your CI system can differentiate: human-reviewed PRs get fast-tracked, agent iteration loops run when capacity is available.

Concurrency budgets. Without guardrails, a single developer running aggressive agent loops can monopolize a team's entire runner pool. Concurrency budget allocation per author or agent caps the blast radius. Agent X gets 10 concurrent slots, Agent Y gets 5, and the remaining capacity stays available for everyone else.

Queue telemetry. You can't manage what you can't see. Engineers need visibility into queue depth, wait times, and which jobs are consuming capacity. GitHub's built-in metrics tell you how long a workflow ran, but they don't tell you how long it waited before it started running. That gap makes it nearly impossible to diagnose throughput issues when agents are flooding the queue.

How isolation changes the equation

Running 50 concurrent agent jobs isn't just a capacity problem. It's a safety problem. If those jobs share any state — cached dependencies, file system artifacts, environment variables from a previous run — one agent's flawed commit can silently contaminate another's test results.

This is where Tenki's architecture becomes relevant. Every Tenki runner job executes in a fresh Firecracker microVM — new filesystem, no shared memory, no process space carried over from a previous job. The VM is destroyed immediately when the job finishes. There's no persistent state between jobs, period.

That isolation model is what makes it safe to scale concurrency aggressively. On Tenki's Team plan, you get 50 concurrent Linux x64 jobs by default, with custom limits on Enterprise. Jobs that exceed your concurrency cap queue — they don't fail — and queue time isn't billed. So you're not paying for the wait, and the jobs that are running can't interfere with each other.

Compare that with self-hosted runners sharing a host machine, where cross-job contamination is a real risk that only gets worse as concurrency increases. The higher your agent-driven job volume, the more isolation matters.

What teams should configure now

You don't need to wait for new products to start managing queue depth. GitHub Actions already has the primitives. Most teams just haven't configured them for agent-scale workloads.

Use concurrency groups aggressively. GitHub Actions concurrency groups let you scope parallel execution by branch, PR, or actor. For agent workloads, key the group on the branch ref so each agent branch only occupies one runner slot at a time:

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

The cancel-in-progress: true flag is critical for agent workflows. When an agent pushes a new commit to the same branch, it cancels the in-flight run for the previous commit. Without it, you accumulate stale runs that burn capacity on code the agent has already moved past.

Size your runner pool for burst, not average. If your team runs 5 agents in parallel and each triggers a 3-job workflow, your peak concurrent demand is 15 jobs. On GitHub's hosted runners, you're subject to their org-level concurrency cap (typically 20 for paid plans). With Tenki, the Team plan gives you 50 concurrent jobs out of the box. If you're hitting that ceiling regularly, Enterprise plans offer custom concurrency limits.

Set cancel-in-progress for agent branches specifically. You probably don't want to cancel in-progress CI for your main branch or release branches. Use a conditional concurrency group that only enables cancellation for branches matching agent naming patterns:

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: ${{ startsWith(github.head_ref, 'codex/') || startsWith(github.head_ref, 'cursor/') }}

This keeps human-authored CI runs stable while letting agent iteration loops self-cancel as new commits land.

Monitor queue wait time, not just run time. GitHub's workflow run API exposes both created_at and run_started_at timestamps. The delta between them is your queue wait. If that number is trending up, you have a queue depth problem regardless of how fast your runners boot. Export it to your observability stack and set an alert. A queue wait above 30 seconds during working hours is the canary.

The product frontier is smarter queues, not faster runners

Here's the trajectory. Cold start latency fell from 60 seconds to under 5 across most providers. Runner price-per-minute converged to within 20% across the market. Compute performance on equivalent instance types is basically identical — AMD EPYC hardware is AMD EPYC hardware regardless of who racks it.

So what differentiates a CI runner platform in a world where boot time, price, and raw compute are commoditized? The scheduling layer. The thing that decides which job runs next, how many can run at once, and what happens when demand exceeds capacity.

The features that will matter in the next 12 months aren't shaving another second off boot time. They're:

• Priority lanes that let human-critical paths bypass agent backlogs
• Per-author and per-agent concurrency caps that prevent any single source from starving the pool
• Queue observability dashboards that expose wait time, depth, and capacity utilization in real time
• Automatic cancellation policies that terminate stale agent runs without operator intervention
• Isolation guarantees that hold up at 50+ simultaneous jobs, not just 5

Tenki's ephemeral microVM model and configurable concurrency tiers already address the isolation and capacity side of this problem. As AI agents push PR volume higher — and there's no sign of that curve flattening — the platforms that build queue intelligence on top of raw capacity will be the ones that keep CI from becoming the bottleneck in agent-driven development.

The cold start war is over. The queue depth war hasn't started yet. Teams that prepare for it now will barely notice the transition. Everyone else will feel it when their agents are writing faster than CI can validate.