If your app spends most of each request waiting on an AI model, a CRM or a WhatsApp API, and you cannot say what that waiting costs, this is for you. It is not for a team without a production workload to measure: cost it once you have real traffic, not before.
What are you paying for while a model writes a reply?
On classic serverless billing, the whole time. The function holds its CPU and memory from the first line to the last, and most of that time it is waiting for someone else's server to answer.
Vercel's functions pricing docs give the shape of it: a function that spends 100 ms working and 400 ms waiting on a database query is billed for 100 ms of active CPU. For an AI reply the gap is wider. The code that reads a record and builds a prompt takes a moment; the model takes seconds.
That waiting is the cost fluid compute goes after. Vercel's product page calls it "CPU that's charged when active, not idle."
How does fluid compute bill a request?
On three lines, and only one of them pauses while you wait.
The memory line is the one to watch. Vercel says memory "continues billing while handling requests, even during I/O operations." What brings it down is sharing. With optimized concurrency, many requests run on one instance, so the memory one instance holds is spread across every request waiting inside it. Vercel offers this on the Node.js and Python runtimes.
After the last request finishes, the instance pauses and nothing is billed until the next one arrives.
What does a parcel-status reply cost to run?
Here is a sample, not a client. A courier company answers "where is my parcel?" on WhatsApp. A function reads the tracking record, asks a model to write the reply, sends it, and writes a log after the reply has gone, using waitUntil so the customer does not wait for the log.
Our assumptions, to show the method: each reply takes 4 seconds, of which 0.05 seconds is the function's own work and the rest is waiting on the model and the APIs. The function runs on the default 2 GB, 1 vCPU size in Mumbai. We take the worst case, where no two replies overlap, so nothing is shared.
Two things follow. On waiting work, memory is about nine tenths of the Vercel line, so the saving comes from replies overlapping on a shared instance, and how much depends on how bunched your traffic is. And this table leaves out the model and WhatsApp, which bill you separately. We cost those per step as well, because that is where a reply's price usually moves. For the messaging side, see WhatsApp Business API pricing in the UAE, and for the work itself, Mindcat for couriers and delivery.
Vercel's /fluid page quotes an unnamed developer "cutting costs by over 50% with zero code changes." That is Vercel's customer quote, not a number we can promise. Run your own month and compare.
When does fluid compute not help?
When the work is the CPU. Vercel's pricing docs say compute-heavy tasks such as image processing use more CPU time than I/O-heavy tasks such as API calls. Resizing photos, building PDFs or crunching a large export keeps the CPU busy, so the active CPU line grows and there is little waiting to save.
It also does not change where the function runs. Functions run in iad1, Washington, D.C., unless you choose a region, and there is no region in the Gulf. A Gulf company calling a model and a CRM should put the function near those, which often means Mumbai or Europe, not near the customer.
How long can one request run?
Five minutes by default, and a ceiling above that.
An agent that reads 40 documents and writes a report does not belong in one request. Vercel's docs point long work to Vercel Workflows, which can pause, resume and keep state from minutes to months. Split the job into steps there, and keep each request short.
What should you check before you switch it on?
New projects have it on already: Vercel made fluid compute the default for new projects on 23 April 2025. Older projects have a toggle in Project Settings, under Functions, or "fluid": true in vercel.json. Before you flip it on an old project, check four things.
- 01Shared state: requests now share one process. Anything your code keeps in a module-level variable is visible to every request on the instance.
- 02Errors: Vercel says an unhandled error lets the other requests finish before the process stops, so log it and fix it rather than relying on restarts.
- 03The region: set it near the data, not the iad1 default by accident.
- 04The baseline: note last month's function cost and duration first, so you can compare a month on fluid compute with a month without.
What happens on the first call?
We call the method Preview every change, and that includes how a function runs: switch fluid compute on for one preview, measure it, then promote. On the call you tell us what each step calls and how long it waits. The written assessment is free and gives a cost per step, the region for each function and what moves to Workflows.
The first build week is a fixed AED/SAR 14,900, and Run plans watch the bill after go-live. See everything we build at Vercel, then send us the workload.
