Vercel moved function billing from wall time to active CPU

The workload

On 4 February 2025, Vercel published a blog post introducing what it calls Fluid compute, a change to how its functions execute and are billed. Adopting it required no new code; the vendor's account states it became available to all users the day of the post, applied to existing functions rather than requiring a rewrite. The workload for a founder already on Vercel is comprehension: understanding idle waiting time is now billed differently, and checking on the pricing page whether the new Active CPU line item changes their bill.

What the documents show

Verified: the post states Fluid compute replaces a one-request-per-instance model with a many-to-one model, in which one running instance can handle tens of thousands of concurrent invocations rather than triggering a new instance per request. Verified: functions waiting on a backend or network response can process other requests in that idle window instead of, in the post's words, sitting idle and wasting compute; cold starts are reduced through pre-warmed instances and a Rust-based runtime with bytecode caching. Self-reported: the post states early adopters saw compute costs reduced by up to 85 percent, with no baseline, sample size, or stated conditions, so the claim should be attributed to the vendor, not treated as typical.

The operating cost

Verified: the post itself states no new dollar figures; the pricing page names Fluid Active CPU and Fluid Provisioned Memory as separate line items, priced from $0.128 per hour and $0.0106 per GB-hour on Pro, with Hobby including 4 hours of Active CPU and 360 GB-hours of Provisioned Memory monthly at no charge. Estimated: whether Fluid compute lowers or raises a given bill depends on how much prior cost came from idle wait time versus actual CPU work, a ratio the post does not compute; the 85 percent figure cannot be generalised without that account's own before-and-after usage data.

The stop condition

The post does not state a condition under which Fluid compute stops being worth using; it presents the change as an unconditional replacement rather than an opt-in feature with tradeoffs. Editorially, the reasonable check is comparative: since Active CPU and Provisioned Memory are visible line items on the pricing page, the point to revisit the assumption that Fluid compute helps is when those line items grow faster, month over month, than invocations did under the prior model, indicating the workload does not fit the concurrency pattern the post describes.

• Does the application's typical function spend meaningful time waiting on network or backend calls, which is what Fluid compute's concurrency model targets?
• Have Active CPU and Provisioned Memory usage, as itemised on the pricing page, been compared against the prior billing period's total?
• Is the vendor's 85 percent savings figure being treated as a self-reported example rather than an expected outcome?

A vendor announcing a new default execution model is describing its own product in its own terms; the concurrency mechanism it describes is verifiable in principle, but the savings figure it leads with is a vendor claim about unnamed early adopters, not a measured result for any specific account.