Vercel's Active CPU Billing Saves 93% on a Real AI Agent — Here's the Exact Math

Vercel says Fluid Compute now handles more than 45 billion requests a week, and that Active CPU pricing — the model that bills only for the milliseconds your code is actually running, not the seconds it spends waiting on a database or an LLM — saves customers "up to 95%." That number is real, but it's a fleet-wide ceiling, not a guarantee for any one workload. Run the actual math on a realistic AI-agent function and the honest answer is closer to 93% savings for an idling-heavy workload, dropping to the low double digits for a compute-heavy one, and there's a specific invocation volume — a few hundred thousand a month, for the workload shape below — where even a 93%-cheaper Vercel bill catches back up to the flat cost of a small box you already own.

What "Active CPU" Actually Bills​

Fluid Compute became the default execution model for new Vercel projects in early 2025, replacing the one-request-per-container serverless model with one that multiplexes concurrent requests onto shared instances. Active CPU pricing, which reached general availability in mid-2025, is the billing layer built on top of that: instead of charging for the full wall-clock duration a function is alive, Vercel now meters three things separately.

The distinction that matters: under the legacy model, a function that spends 4.85 seconds waiting on a slow Postgres query and 150 milliseconds actually computing something pays for all 5 seconds. Under Active CPU, it pays full price for the 150ms and only the (much cheaper) memory-holding rate for the other 4.85 seconds. Vercel's own docs describe it as pausing CPU billing whenever code is "waiting for external services" — database calls, third-party APIs, and, increasingly, LLM calls — while memory billing continues at a fraction of the rate.

None of this works without the multiplexing underneath it. The old serverless model bound one request to one container for its entire lifetime, so a container idling on an API call was reserved and billed even though it had nothing to do. Fluid Compute instead routes concurrent requests through a shared connection layer that keeps sending new work to an instance that's already warm rather than spinning up a fresh one, which is also why Vercel can afford to stop charging CPU during the idle gaps — the instance isn't sitting there exclusively reserved for one stalled request, it's available to pick up other work in the same window.

The Worked Example: An AI Agent Function​

The workload this benefits most is exactly the one growing fastest on Vercel right now: a function that calls out to an LLM and waits for a response. Take a realistic shape — a 2GB agent-handler function, invoked 1 million times a month, where each invocation spends 5 seconds of wall-clock time (mostly waiting on a streaming LLM completion) but only 150ms of that is genuine CPU work (parsing the request, assembling the prompt, relaying tokens).

Legacy Duration billing, per invocation: 2 GB × (5s / 3600) hours × $0.18/GB-hr = $0.0005

Active CPU billing, per invocation:

• CPU: (0.150s / 3600) × $0.128/hr = $0.0000053
• Memory: 2 GB × (5s / 3600) × $0.0106/GB-hr = $0.0000294
• Total: $0.0000347

At 1 million invocations a month, that's $500/month under the old model versus roughly $35/month under Active CPU — a 93% reduction, landing right in the range of Vercel's advertised "up to 95%." The 45-billion-weekly-request figure Vercel cites is a blended average across its entire fleet, and that blend is exactly why the number is a ceiling rather than a promise: it mixes idle-heavy functions like this one, which get close to the top of the range, with CPU-bound functions that barely benefit at all.

Sensitivity check. Change nothing except how much of that 5-second window is genuine compute. If the same function does 500ms of active work instead of 150ms — a heavier agent that's actually reasoning locally, not just relaying — the math shifts:

• CPU: (0.500s / 3600) × $0.128/hr = $0.0000178
• Memory: unchanged at $0.0000294
• Total: $0.0000472 vs. the same $0.0005 legacy baseline — a 91% reduction, still large, but already sliding off the advertised ceiling as the idle fraction shrinks.

Where the Savings Floor Sits​

Push that sensitivity to its logical extreme — a function with no idle time at all — and Vercel's own published numbers show the floor. A "Standard" machine size (1.7 GB memory) running at 100% active CPU utilization costs approximately $0.149/hour under Active CPU pricing, against $0.31842/hour under the legacy model (1.7 GB × $0.18/GB-hr). That's a 53% reduction — real money, but nowhere near "95%," because there's no idle time for the new model to stop charging for. Active CPU pricing doesn't make compute cheaper; it makes waiting free. A function that never waits gets none of that benefit.

That's the shape of the claim in one sentence: the "up to 95%" figure is real at the idle-heavy end (LLM calls, database round-trips, queue polling), shrinks as a workload gets more CPU-bound, and bottoms out around 50% for functions that are computing the entire time they're billed.

The Crossover Against Owning the Box​

A 93% cut is a genuine, non-marketing improvement — but it's still a meter, and meters have a crossover point against flat-rate infrastructure you already own. The AI-agent workload above costs $0.0000347 per invocation on Active CPU pricing. A small Hetzner box has no per-invocation charge at all: the box costs the same flat monthly rate whether it's handling ten requests a month or ten million, because idle-waiting on an LLM response was never a metered event on hardware you own — the CPU sits idle for free, the same way it always has.

These crossovers are for this specific workload shape (2GB, 5s wall-clock, 150ms active CPU) — a chattier agent, a bigger memory footprint, or more invocations per user session all pull the crossover point closer, not further away. For a team running a single low-traffic endpoint, none of this matters; $35/month is nothing to optimize. But an AI-agent product growing past a few hundred thousand calls a month on exactly the workload shape that Active CPU pricing was built to help is, in the same breath, approaching the point where a box that was never metered on idle time in the first place gets cheaper than a 93%-discounted meter.

Running the same arithmetic against a real function is a five-minute exercise, not a research project: pull average invocation count and average duration from the Vercel dashboard's Functions usage tab, then instrument one representative request to log how many of those milliseconds are spent actually computing versus awaiting a fetch or an LLM call. Divide active-CPU time by total wall-clock time to get the idle ratio, plug both numbers into the per-invocation formula above for your own region's rates, and multiply by monthly volume. That number, not the "up to 95%" headline, is the one worth budgeting against — and it's the same number worth checking again every time volume doubles, since the crossover point doesn't move but the workload's position relative to it does.

What This Means for Where an Agent Actually Runs​

Active CPU pricing is Vercel fixing a real problem: the old model charged full price for time a function spent doing nothing, which was always the wrong unit for I/O-bound and LLM-calling code. That fix is worth taking at face value — it's not a marketing repricing, it measurably changes what an idle-heavy function costs, and the math above shows it landing close to Vercel's own claimed range for the workload it was built for. What it doesn't change is the deeper shape of the bill: usage still accrues per invocation, per millisecond, forever, on infrastructure someone else owns.

Once an AI-agent workload's volume clears that crossover point, the operating question stops being "which billing model is fairest" and becomes "why is idle time metered at all." A self-hosted platform running on owned hardware — a Cluster API fleet on Hetzner nodes, say — never had a meter running on the seconds a function spent waiting for an LLM to respond, because that was never a chargeable event to begin with.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with AI agents treated as first-class operators rather than a new line item on someone else's invoice. Star the repo on GitHub or deploy your first agent-facing service today.

Sources:

• Fluid compute pricing — Vercel docs
• Introducing Active CPU pricing for Fluid compute — Vercel blog
• Fluid compute: How we built serverless servers — Vercel blog, July 2025
• Legacy Usage & Pricing for Functions — Vercel docs