What is the right cost metric for a fleet of AI coding agents?

Cost per successful task, not cost per token. Divide the model spend plus workspace spend for an attempt by the share of attempts that produce a merged change. Failed attempts cost the same as successful ones and appear in no success metric, so a cheaper model that lowers the success rate makes the fleet more expensive rather than cheaper.

How many AI coding agents can you run concurrently?

The practical ceiling is set by budget and by review capacity rather than by cluster capacity. Spotify reports deploying agent sessions in Kubernetes pods so it can schedule many sessions concurrently. Because agent work is asynchronous, a bounded worker pool with a queue in front is usually a better default than autoscaling to meet every burst.

Does running more agents ship more software?

Not automatically. If reviewers can absorb forty changes a week, a fleet tuned to produce eighty ships forty and queues the rest, while paying for all eighty. Spotify reports a 76 percent increase in pull request frequency and states directly that the flip side is 76 percent more pull requests to review. Fleet capacity should be planned against review throughput.

Agent Fleets - Parallel AI Agent Workspaces and Cost

Running many coding agents concurrently: workspace sizing, concurrency limits, cost per successful task, and the economics that actually govern scale.

The Metric That Moved

Cost per token is the input price. Cost per successful task is the number that decides whether a fleet is worth running.

A single-shot completion has a simple cost model: one prompt in, one response out, price the tokens, done. An agent has none of that simplicity. It reads files, calls tools, runs tests, reads the failures, re-reads context it has already seen, retries, and sometimes gives up after consuming a great deal of budget without producing anything mergeable. Every one of those steps is another billed request, and the workspace it runs in is billed for the whole wall-clock span whether the agent is computing or waiting.

The consequence is that token price is a weak predictor of what a fleet costs. Two agents on identical pricing can differ by an order of magnitude in what they spend to land the same change, because one converges in three tool calls and the other thrashes through twenty. Multipliers for "how many more tokens does agentic work consume" circulate widely, but they are workload-specific and are rarely published with methodology attached. Treat any number you have not measured on your own repositories as unverified, and instrument for the real one.

What replaces it is a ratio you can actually compute from your own telemetry. This page uses it as the spine, and it is the only fleet metric that survives contact with a finance conversation. General cost controls for cloud development environments are covered on FinOps for CDEs; what follows is specific to fleets of agents.

Cost Per Successful Task

cost_per_successful_task =
      ( model_spend_per_attempt + workspace_spend_per_attempt )
    / success_rate

where:
  model_spend_per_attempt      = input + output + cached tokens, priced,
                                 summed across every turn of the attempt
  workspace_spend_per_attempt  = wall-clock seconds the sandbox existed
                                 x the per-second rate of its size class
  success_rate                 = attempts that produced a merged change
                                 / total attempts started

The denominator is what makes this useful. A cheaper model that halves the success rate makes the fleet more expensive, not less. A larger workspace that cuts the attempt from twenty minutes to eight can pay for itself twice over. And an attempt that ends in an unmergeable pull request is not a discount, it is pure loss plus the reviewer time it consumed on the way out.

Retries Are the Hidden Line Item

Failed attempts do not appear in any success metric, but they consume the full model and workspace cost of a successful one. If you are not counting abandoned attempts, your reported cost per task is wrong by exactly the failure rate.

Context Is Re-Read Constantly

Each turn resends accumulated context. Long sessions therefore cost superlinearly in input tokens unless caching is in play. Prompt caching and tighter context windows move this line item more than switching models usually does.

Idle Time Is Still Billed

Between tool calls an agent is blocked on a model response, doing nothing. The workspace is reserved and billed for that entire window. This is the single largest source of waste in a naively sized fleet.

What Published Fleets Look Like

Four organizations that have published concrete numbers about running agents at scale

Stripe

Stripe reports that "Over 1,300 Stripe pull requests (up from 1,000 as of Part 1) merged each week are completely minion-produced, human-reviewed, but containing no human-written code." That is an absolute weekly count of pull requests, not a share of Stripe's codebase, and it should not be read as one. On the infrastructure side Stripe states that "unattended agent coding at scale requires a cloud developer environment that's parallelizable, predictable, and isolated," and that it keeps capacity hot: "we proactively provision and warm up a pool of devboxes so they are ready when a developer wants them."

Stripe Engineering, Minions Part 2

Spotify

Spotify describes the scheduling substrate for its agent harness directly: it "runs Claude using the Agent SDK, wrapped inside our own harness and deployed in Kubernetes pods so we can schedule many sessions concurrently across our cloud environment." On adoption and throughput, Spotify reports that "more than 99% of our engineers use AI coding tools every week, 94% report that AI has made them more productive, and we're seeing a 76% increase in pull request frequency."

Spotify Engineering, 2026

Block

Block reports that its internal agent suite "executes over 200,000 operations per day and merges approximately 1,500 pull requests per week, about 15% of all production code changes across Block." The operations-per-day figure is the more useful one for capacity planning, because operations, not merged pull requests, are what your sandbox layer has to absorb.

Block, BuilderBot announcement

Ramp

Ramp reports that "~30% of all pull requests merged to our frontend and backend repos are written by Inspect," its background agent. Each session "runs in a sandboxed VM on Modal with everything an engineer would have locally," and Ramp explicitly removed the concurrency ceiling: "There's no limit to how many sessions you can have running concurrently, and your laptop doesn't need to be involved at all."

Ramp Engineering

Read These Numbers Carefully

These are self-reported figures from engineering blogs, not audited disclosures, and each one measures something slightly different. Stripe publishes an absolute count of pull requests. Block and Ramp publish a share of merged pull requests. Spotify publishes a change in pull request frequency. None of them is a claim about the fraction of code written by agents, and none is directly comparable to the others. You will also see per-engineer monthly agent spend quoted as a tidy range in conference talks and vendor decks. We have not found a primary disclosure behind any of those figures, so this page does not repeat one. Measure your own cost per successful task instead; it is the only number that reflects your repositories, your models and your success bar.

Sizing a Fleet Workspace

Agent workspaces have a different load profile from developer workspaces, and sizing them the same way wastes money

A human developer's workspace is sized for peak: the full build, the full test suite, the language server indexing a large repository. An agent's workspace has a spikier and much emptier profile. Between model calls the agent is blocked on the network, using no CPU at all. Its bursts are real but short: a build, a test run, a dependency install. Sizing every agent workspace for its peak burst means paying for cores that sit idle through most of the session.

Platform pricing has started to reflect this shape. Cloudflare Workers bills on CPU time rather than wall-clock duration, documenting "30 million CPU milliseconds included per month" with "No charge or limit for duration" on standard requests, so time spent blocked on I/O is not billed. Most compute you will run an agent fleet on does not work that way. A pod or a VM is billed for every second it exists, idle or not, which is why the shape of your idle time is a first-class sizing input rather than a detail. The broader treatment of this trade-off lives on capacity planning and performance optimization.

Where a Fleet's Money Goes

Cost driver	Scales with	Typical lever	Failure mode if ignored
Model tokens	Turns per attempt, context length	Prompt caching, context trimming, turn caps	A looping agent bills indefinitely
Workspace compute	Wall-clock session length	Right-sizing, idle reaping, hard timeouts	Abandoned sessions bill until someone notices
Warm pool	Pool depth, held continuously	Depth tuned to arrival rate, not peak	Paying full price for capacity nobody claimed
Storage and image pulls	Sessions started, image size	Layer caching, snapshots, node-local registry	Cold start dominates short tasks
Egress and API calls	Tool calls, package installs	Internal mirrors, egress allowlists	Invisible until the bill arrives

Warm Pools Trade Money for Latency

A warm pool holds pre-provisioned environments so a session starts immediately. Stripe describes exactly this pattern for its devboxes, and the Kubernetes SandboxWarmPool resource encodes it as a first-class object. The pool is billed whether or not anything claims it, so depth should track the arrival rate of new sessions, not the theoretical peak. Over-deep pools are one of the easiest fleet costs to accumulate and one of the hardest to notice.

Queue Rather Than Autoscale to Infinity

Agent work is usually asynchronous. Nobody is watching a spinner, so a task that waits ninety seconds in a queue costs almost nothing in human terms while an unbounded fleet that scales to meet every burst costs real money. A bounded worker pool with a queue in front is usually the correct default, with the bound set by budget rather than by available cluster capacity.

Controls That Keep a Fleet Bounded

Concurrency caps, circuit breakers, quotas, and the attribution that tells you whose fleet is burning the budget

A Fleet Policy, Sketched

The exact schema depends on your orchestrator, but every control below has an equivalent in any serious platform. The point is that each one is declared, versioned, and enforced by the platform rather than left to an agent's own restraint.

fleet:
  name: backend-refactor
  owner: team-payments

  concurrency:
    maxConcurrentSessions: 24      # hard ceiling, budget-derived
    maxPerEngineer: 4              # stops one person consuming the fleet
    queueDepth: 200                # beyond this, reject rather than buffer

  session:
    workspaceClass: standard-4c-8g
    idleTimeout: 5m                # no tool call in 5m, reclaim it
    hardTimeout: 45m               # wall-clock kill, no exceptions
    maxTurns: 60                   # stops a loop before it stops itself

  budget:
    monthlyLimitUsd: 12000
    circuitBreaker:
      at: 80%                      # warn and require approval to start new work
      at_hard: 100%                # refuse new sessions, let running ones finish

  attribution:                     # every session carries these to the bill
    labels:
      team: team-payments
      costCenter: eng-platform
      repo: payments-api
      trigger: nightly-refactor

Timeouts Before Budgets

An idle timeout and a wall-clock kill catch the common failure of a session nobody closed. They are cheap to implement, they cannot be argued with by an agent, and they recover most of the waste before any budget logic is needed.

Circuit Breakers, Not Alerts

An alert at eighty percent of budget is a notification someone may read tomorrow. A breaker that refuses to start new sessions is a control. Fleets can consume a month of budget in a day, so the enforcement has to be synchronous with session admission.

Attribution at Session Start

Labels applied when a session is created are the only reliable way to answer "whose agents cost this." Retroactive attribution across pods, model calls, and storage is close to impossible. See cost analysis for the wider allocation model.

Measure Success, Not Activity

Sessions started, tokens consumed, and operations executed are activity metrics that always go up. Merged changes per unit of spend is the one that can go down, which is precisely why it is the one worth putting on the dashboard. Wire it into monitoring from day one.

More Agents Is Not More Shipped Software

The constraint moves rather than disappears

Spotify Names the Trade Explicitly

Alongside the 76 percent increase in pull request frequency, Spotify writes: "The flip side: we now have 76% more PRs to review. We're learning where to apply human judgment - auto-merging what's safe, focusing review where it matters most." The company's broader framing is that "As coding velocity increases, the constraints shift toward human decisions." Every organization in the section above emphasizes that agent output is human-reviewed; Stripe's 1,300 weekly pull requests are described as "human-reviewed."

This is the honest limit on fleet scaling, and it is an economic argument rather than a cultural one. If reviewers can absorb forty changes a week, a fleet tuned to produce eighty does not ship eighty. It ships forty and accumulates a queue, and the second forty were paid for in full. Cost per successful task quietly doubles, and no dashboard that counts sessions or tokens will show it.

The practical implication is that fleet capacity should be planned against review throughput, not against cluster capacity or budget headroom. That means measuring how long changes wait for review, deciding in advance which categories of change can be merged without a human in the loop, and treating an expansion of the fleet as a request for reviewer capacity at the same time. The governance side of that decision is covered on autonomous development.

The second-order effect is on task selection. A fleet that produces many small, mechanically verifiable changes puts far less load on reviewers than one producing a smaller number of sprawling ones, even at identical spend. Fleet economics and task decomposition are the same problem viewed from two angles, which is why orchestration design ends up being a cost decision as much as an architectural one.

The infrastructure a fleet runs on, and the money it spends