Agent CPU costs: 0.2 to 180 vCPU, and the two overcommits in between

• 0.2 → 180vCPU spanning the cheapest to the most expensive agent workload, three orders of magnitude
• 8 sold, 1–2 usedvCPU per seat on the invoice against what an active user averages, held apart by two layers of overcommit
• 30–50%elasticity: ten times the agents buys three to five times the CPU, on the source's measurements

Every capacity model of the agent buildout starts with accelerators. The second bill, the one denominated in vCPU, never reaches a capex deck, and the reason it stays invisible is accounting rather than physics. Cloud providers sell fixed packages, at 2, 4 or 8 vCPU per user, that read like virtual machine sizing. What an active user of agent tooling actually draws is 1 to 2 vCPU on average, scheduled by task rather than by seat, and the gap between the two numbers is absorbed by overcommit: first from bare metal into virtual machines, then from virtual machines into a shared task pool.

What the workloads actually cost

The spread across agent workloads is enormous, and it runs against intuition: the jobs that think are cheap, and the jobs that touch the world are not. A basic orchestration step draws 0.1 to 0.2 vCPU for a fraction of a second. Opening and rendering a web page starts at 2 to 3 vCPU and reaches 60 to over 100 for a script-heavy one. PDF parsing runs 6 to 8 vCPU for every second of the job. A parallel code sandbox peaks at 150 to 180.

The discount that has not come due

This operator's sandbox clusters run at 50 to 60 percent average load against an industry norm below 50, and 65 to 70 after tuning, so there is room left to reclaim. The deeper buffer is the elasticity ratio. On the source's measurements, ten times the agents does not mean ten times the cores: it means three to five times the CPU, because most agents sit idle most of the time and overcommit absorbs the rest. The ratio is a measure of how much of an organisation has not been covered yet, not a law of nature. A thousand times the agent count is the point where the curve stops being comfortable, and that is a judgement built on watching a few large deployments rather than a published forecast.

What would change the picture

Three things are checkable without a source. Watch whether published per-seat packages drop below 2 vCPU, which would mean the metering unit is converging on the workload. Watch disclosed cluster load factors from the large agent platforms, which would show how much overcommit headroom remains. And watch for any operator publishing an elasticity measurement of its own, because the first public number ends the era in which the second bill stays invisible. The procurement side has its own drift: x86 is about 80 percent of what gets bought today, guided to 60 to 70 forward, with ARM capped near 20 to 30.

This page is the public data companion to The Call 03 in Two Tides. The conversation itself, edited and with the source's own corrections left in, is the post in the letter.