Vercel's Fluid Compute Pricing Confuses Function Cold Starts With Idle Time: A 2026 Bill Breakdown

Vercel's pitch for Active CPU pricing is a single sentence: you don't pay for waiting. Up to 95% cheaper for I/O-heavy workloads, the changelog says — database queries, AI model calls, anything where your function is blocked on someone else's server instead of running your own code. It's true, as far as it goes. But "waiting" on Fluid Compute is actually two different things billed two different ways, and the marketing collapses them into one.

A cold start — the runtime booting, your code loading, connections opening — is CPU-bound work, and Vercel bills it as Active CPU, same as any other computation. A mid-request stall waiting on Postgres or an LLM API is genuinely free of CPU charges, but Provisioned Memory keeps billing in GB-hours for every second the instance stays alive to hold that request open. One kind of "waiting" shows up in the meter marketed as cheap; the other shows up in a meter nobody's watching. Below is what that actually costs on a real Next.js app, with the published 2026 rates.

The Three Meters, and Where "Waiting" Actually Lands​

Vercel's Fluid Compute pricing has three dimensions, priced per region. In iad1 (Washington D.C.), the rates are:

Vercel's own documentation gives the mechanism in one line: if the request is waiting on I/O, CPU billing pauses but memory billing continues. Their worked example — a 4GB function in São Paulo, 4 seconds of active CPU inside a 10-second instance lifetime — comes out to $0.221/hr × (4/3600) for CPU plus $0.0183/hr × 4GB × (10/3600) for memory, or $0.0004489 per invocation. Six of those ten seconds were pure I/O wait, and they cost nothing in CPU — but they're still in the memory line, because the instance had to stay resident to hand the response back.

Cold starts are billed differently, and this is the conflation the "you don't pay for waiting" framing invites. Vercel's own definition of a cold start is "allocate compute resources, load your application code, initialize the runtime environment, and establish network connections" — work the CPU is actually doing, not I/O it's blocked on. That lands squarely in the Active CPU meter, the one pricing page copy calls out as the cheap one. Fluid Compute's "scale to one" behavior (keeping at least one instance warm) and its request-sharing concurrency model push cold starts down to 0.63% of requests in Vercel's own reported numbers, so the CPU cost of booting is rare. But it's real compute, billed as compute — the opposite of a mid-request stall, which is common, isn't CPU work at all, and gets billed through memory instead. Two different phases, two different meters, and "no charge for waiting" is only true for one of them.

The Worked Bill: Two Route Classes, One Surprise Line​

Here's what that split looks like on an actual app. Take a mid-size Next.js API backend on Vercel Pro, Standard machine (2GB / 1 vCPU, the fluid compute default), deployed in iad1, doing 3,000,000 invocations a month across two kinds of routes:

• Fast routes (60% of traffic, 1.8M requests/mo) — CRUD reads against pooled Postgres. 40ms of active CPU per request; the instance stays alive 150ms total including the DB round trip.
• Slow routes (40% of traffic, 1.2M requests/mo) — routes that call an LLM completion API for an AI feature. 60ms of active CPU to parse/serialize; the instance stays alive 1,800ms total waiting on the model provider.

Add invocations — 3M × $0.60/million = $1.80/mo — for $21.23/mo in total usage. The Pro plan's $20/mo seat fee bundles $20/mo of usage credit, so that usage total is also the all-in bill: $20 covered by the credit, a $1.23 overage on top.

Now look at what actually drives that bill. The slow routes are 40% of requests but 71% of the CPU+memory total. Their CPU cost is identical to the fast routes' CPU cost — $2.56 either way, because both classes do comparable parsing work. Every dollar of the gap is the memory meter, ticking through 1,800ms of LLM latency the CPU spent doing nothing. If you're watching Active CPU the way the pricing page says to, the two route classes look the same. The bill says otherwise.

Why the Same Route Can Double Your Bill Without a Traffic Change​

That memory line isn't fixed — it scales directly with however long the upstream call takes, and LLM APIs are not a fixed-latency dependency. Hold the slow route's traffic and CPU time constant and vary only how long the model provider takes to respond:

Active CPU cost never moves — it's $2.56 in every row, because the code you wrote does the same amount of work regardless of how long the network call takes. But the total bill for that one route swings more than 6x, purely because a third-party API had a slow afternoon. Roll that into the combined bill from the section above and total usage moves from $21.23/mo to $43.84/mo — a near-doubling with zero code changes, zero traffic growth, and an Active CPU number that never budged. That's the practical failure mode of the "cheap because it's not CPU" framing: the meter that's actually exposed to a flaky dependency is the one the pricing page doesn't lead with.

What It Looks Like at 10x, and Against a Fixed Box​

Scale the baseline workload to 30,000,000 invocations/month — a realistic jump for a growing product — and every line above moves linearly, because every meter is metered per request and per second:

And if that same 10x growth also lands on a slow week for the LLM provider (5,000ms instead of 1,800ms average), the 30M-invocation bill is $438.43 — CPU barely moves, memory and traffic compound.

Compare that to running the same app as a persistent container on owned hardware — a Hetzner CPX31 (4 vCPU / 8GB), $24.99/mo flat, the kind of box a Cluster API–managed fleet schedules workloads onto. That container's cost doesn't know or care whether a request is computing or blocked on an upstream call; there's no per-second memory meter watching the instance while it waits, no per-invocation line, no distinction between a cold-start CPU cycle and a warm one. It's one number, whether the LLM provider responds in 500ms or 5 seconds.

The comparison isn't a blowout in either direction — it depends which variable moves. At the 3M-request baseline with a well-behaved upstream, Vercel's $21.23/mo bill is still cheaper than the $24.99/mo fixed box; per-request billing genuinely wins at low, predictable volume. But the same 3M requests on a slow upstream (5,000ms) already cost $43.84 — past the fixed box's price — with no change in traffic at all. And at 30M invocations/month, Vercel is 8.5x the fixed box on a good day and 17.5x on a bad one. The Hetzner box's number doesn't move with either variable; the Vercel bill moves with both, and the variable a team controls least — how long someone else's API takes to answer — is the one with the bigger multiplier.

None of this makes Fluid Compute's model dishonest — the docs are explicit that memory bills through I/O wait, and the worked example on Vercel's own pricing page shows exactly that math. The problem is narrower: "you don't pay for waiting" is true for one meter and false for the one that actually moves when a dependency gets slow, and a cold start's CPU-bound boot time bills like normal compute while a warm request's I/O wait bills like idle memory — two states that sound similar and price in opposite directions. A team estimating cost from request count and a glance at Active CPU will miss the number that's actually driving the bill.

The Actual Estimate to Run Before You Ship​

If a route's cost matters, the input that predicts it isn't request volume or CPU milliseconds — it's memory size × wait time × request count, computed separately for every route that talks to a slow dependency. A route calling an LLM provider, a payment gateway, or a third-party webhook target should get its own line in that math, because its memory-hours will dwarf its CPU-hours, and its wait time is the one variable you don't control. Watching Active CPU alone, the metric the pricing page foregrounds, will make that route look identical to a fast Postgres read right up until the bill arrives.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with no per-second meter running while your code waits on someone else's API. Star the repo on GitHub or deploy your first app today.

Sources

• Fluid compute pricing — Vercel Docs
• Introducing Active CPU pricing for Fluid compute — Vercel
• Scale to one: How Fluid solves cold starts — Vercel
• Configuring Memory and CPU for Vercel Functions — Vercel Docs
• Vercel Pro Plan — Vercel Docs
• Hetzner Cloud VPS Pricing Calculator (Jul 2026)