Vercel Fluid compute pricing: what functions really cost

Vercel bills functions on Fluid compute with three meters: Active CPU, Provisioned Memory and Invocations. The pitch is that you stop paying for time your code spends waiting. That is true for CPU and not true for memory, and the difference decides whether functions are a rounding error on your invoice or its biggest line. Below are the rates, the arithmetic for three kinds of app at our four standard traffic levels, the AI-route case, and where functions sit in a full Vercel bill.

The short answer

• For a typical Next.js app, functions are the small part of the bill. Our SSR-with-database profile at 3M page views a month comes to $15.72 of compute in iad1. The CDN tier for the same traffic is $300.
• CPU-heavy pages cost several times more per request. The same traffic with 150 ms of real CPU per render is $37.30 in iad1 and $52.40 in Frankfurt.
• Slow routes pay for memory while they wait. An AI chat route that streams for 12 s costs $73.40 per million chats if requests never overlap, and $7.15 if 16 share an instance. CPU is $2.13 of that either way.
• Europe costs about 44% more per CPU-hour and GB-hour than US regions. Invocations are $0.60 per million everywhere.

The rate card

Pro prices from Vercel’s docs, checked 2026-10-17, in USD excluding VAT. Pro includes a $20 monthly credit that applies to all metered infrastructure from the first unit; anything above it is billed on demand. Unused credit does not roll over.

Other US regions (Cleveland, Portland) match iad1. San Francisco is $0.177 / $0.0147, London and Paris $0.177 / $0.0146, Dublin $0.168 / $0.0139. Functions default to 2 GB / 1 vCPU; Pro can switch a project to 4 GB / 2 vCPU (Performance). Hobby is fixed at the default and its terms only allow personal, non-commercial projects.

How the three meters behave

So a single request costs CPU seconds × CPU rate + memory GB × busy seconds × GB rate + $0.0000006. Vercel’s own example: 4 GB in São Paulo, 4 s of CPU, 10 s alive = $0.000449 per call. The memory term grows with waiting, the CPU term with work.

Three app profiles

We can’t measure your code, so these profiles are stated assumptions, chosen to show how the meters react. Swap in your own numbers (see the last section). All run at the 2 GB default and assume no overlap between requests, which makes the memory column an upper bound.

For the SSR profile in iad1, a million calls is $1.42 CPU, $1.47 memory and $0.60 of invocations. The invocation fee is a big share of a cheap request, and memory edges past CPU even though the code does little work, because the request spends most of its life waiting on the database.

Monthly function bills at four traffic levels

Our standard scenarios (the ones behind every cost page). Each cell is the functions-only bill in iad1 / fra1, before the $20 Pro credit.

Red: functions alone use up the $20 credit in iad1. The credit is shared with every other metered line (CDN on demand, Fast Origin Transfer, image optimization, ISR, Blob).

At the top traffic level the heavy profile burns 188 CPU-hours and 1,000 GB-hours; the SSR profile 50 and 625. That spread is all in the code: same traffic, same platform, about 2.4× the bill.

How far Hobby’s allowance goes

For personal projects only. Hobby stops at whichever allowance runs out first:

• Content site: about 2.4M page views a month, limited by Active CPU (4 h).
• SSR app + database: about 240k page views a month, limited by Active CPU (4 h).
• CPU-heavy SSR: about 64k page views a month, limited by Active CPU (4 h).

CPU is the first wall for every profile here. A personal blog will never notice; a server-rendered side project with heavy pages hits it at about 64k page views a month.

AI routes: where waiting gets expensive

A chat endpoint that calls an LLM and streams the answer does very little work itself (we assume 60 ms of CPU) but stays open for the whole answer (12 s here). CPU barely registers. Memory is billed for the full 12 seconds, unless several chats run on the same instance at once, which Fluid’s in-function concurrency allows.

iad1, 2 GB, Vercel functions only. The model’s own token bill is separate and almost always much larger. See our LLM API pricing guide and the LLM cost calculator. Real overlap depends on traffic shape: a quiet app at 3 a.m. runs one chat per instance, a busy one shares. Treat the “no overlap” column as the ceiling.

What actually moves a function bill

• Per-request CPU. The heavy profile costs 2.4× the SSR profile per call. Cache rendered output (ISR, Runtime Cache), pre-generate OG images at build, and move PDF or image work to a queue if it isn’t needed in the response.
• Busy time on slow upstreams. A 2 s third-party API call costs 2 seconds of 2 GB memory per request, even at zero CPU. Timeouts and caching the upstream response matter more than micro-optimising code.
• Region. CPU and memory cost ~44% more in fra1 than in iad1, ~73% more in São Paulo. Keep functions beside the database, though: a cross-ocean DB round trip adds busy time that costs more than the regional difference.
• Performance (4 GB) memory. Doubles the memory rate per second. Worth it for CPU-bound routes that get noticeably faster, not for I/O-bound ones.
• Invocations you didn’t want. Failed requests count. Crawlers on uncached dynamic routes, middleware-less 404 pages and polling clients all add calls.

Functions inside a full Vercel bill

The SSR profile in iad1 for our three commercial scenarios: Pro platform fee, the cheaper of Flat Rate CDN or on-demand CDN at 20 CDN requests per page view (method from our Flat Rate CDN guide), functions, and Fast Origin Transfer at 60 KB per response. The $20 credit is set against metered usage. One seat, no add-ons, no image optimization.

Alternatives come from the live ranking for Next.js (data as of 2026-10-12), leaving out Vercel and $0 plans. They include egress but not a database, CDN or CI, which Vercel bundles, and they are the smallest plan that fits our RAM and bandwidth rules, so at high traffic budget for a bigger box and a CDN in front. The exit calculator adds the missing pieces back.

The honest reading: for this kind of app, Fluid compute is rarely the reason a Vercel bill is high. CDN request tiers and extra seats grow faster. Functions become the main line when the code is CPU-heavy or spends seconds waiting per request, and that is also when a long-running server on a PaaS like Railway or a VPS starts to look better, because it costs the same whether a request takes 50 ms or 12 s.

Measure your own numbers

1. Open Usage in the Vercel dashboard for the last full month and note Fluid Active CPU (hours), Fluid Provisioned Memory (GB-hours) and Function Invocations.
2. Divide each by invocations: that gives your CPU seconds and GB-seconds per call. GB-seconds ÷ 2 (your memory size) is your effective busy time; if it is far above CPU time, your routes are waiting, not working.
3. Divide invocations by page views from your analytics to get invocations per view, then multiply by the traffic you expect and by the rates above.
4. Use Observability to find which routes carry the CPU. Vercel’s spend management notifies new Pro teams at $200 per cycle by default; set your own threshold lower if your bill is normally near $20.

Methodology: Vercel rates are official list prices from vercel.com/docs, checked 2026-10-17, in USD excluding VAT. Workload profiles (invocations per view, CPU and busy time per call, response size), the 20CDN requests per page view and the AI route’s timings are assumptions, not benchmarks. Memory is computed with no request overlap unless stated, so it is an upper bound. Hosting alternatives come from our data set as of 2026-10-12. Vercel does not pay us a commission, and every link in this article goes to our own pages.