Understanding Cost: Active CPU Pricing
Vercel's current pricing model charges for active CPU time, provisioned memory, and invocations — genuinely different from older, simpler "GB-seconds" serverless billing, and worth understanding clearly.
Active CPU pricing charges for actual compute time used, not total wall-clock duration. A function that's waiting on a slow external API isn't necessarily burning "active CPU" the whole time it's waiting — this is a meaningfully different (and often more favorable) model than older serverless pricing that charged for the full request duration regardless of what the function was actually doing.
Fluid Compute's instance reuse (from the Domains & Edge course) directly affects cost, not just cold-start latency. Reusing function instances across requests reduces the overhead — and therefore cost — of handling concurrent traffic, compared to a traditional one-instance-per-request serverless model.
Bandwidth (data transfer) is a separate cost dimension from compute. Serving large assets (images, video, big API responses) to many users contributes to your bill independently of function execution time — a real consideration for content-heavy applications specifically.
The Usage dashboard shows exactly where cost is coming from, per Project — the same "check real data before optimizing" principle as every other platform in this library's capstone course.
Right-sizing matters here too: an Edge-compatible function running on the standard runtime unnecessarily, or a function doing more work than its actual task requires, both cost more than needed — connecting back to the Domains & Edge course's point about matching workload to runtime deliberately.
Why this matters for you
Vercel's current pricing genuinely rewards efficient, well-architected functions — understanding what actually drives cost (active CPU, not just "it ran for N seconds") lets you make informed architecture decisions rather than optimizing blindly.
▶️ Before the next lesson
Open your Vercel project's Usage dashboard and identify what's currently driving the most cost — compute, bandwidth, or something else — before this course's later lessons build on that awareness.