Cloudflare Moves Workers to CPU-Time Billing
Cloudflare has announced a major change to how Cloudflare Workers and Pages Functions are billed. Starting October 31, 2023, pricing will be based on CPU time consumed, not the wall-clock duration of function executions. The company claims this makes it the first global serverless platform with standard pricing based purely on compute time rather than the time a function spends waiting on network calls or other I/O operations.
Why Duration Matters Less Than Compute
Traditional serverless platforms bill based on function duration—the total time from invocation to response. This model stems from the underlying architecture: virtual machines that can't be paused or resumed quickly enough to run other code during I/O waits. With Workers, Cloudflare runs your function's code only while it's executing logic. If a function handles a request that takes 100ms from start to finish but only spends 10ms performing CPU work—parsing JSON, running computations—you shouldn't be billed for the other 90ms spent waiting on external APIs or databases.
The distinction has real cost implications. External dependencies like hosted LLMs (such as GPT-4 or Stable Diffusion), SaaS databases, and payment processors introduce unpredictable latency that is entirely outside a developer's control. If an upstream service responds twice as slowly, duration-based billing charges you twice as much, even though your own code executed identically. With CPU-time billing, the cost of slow upstream services lands where it belongs: on the provider.
What Was Announced
Developers on the Workers Paid plan can opt in individual Workers and Pages Functions projects to the new pricing when it launches October 31. Newly created projects will default to the new pricing model. The dashboard will include cost estimation tools to help you gauge the impact. Cloudflare states that for the majority of existing applications, the new pricing will cost the same or less than the existing Bundled or Unbound plans.
A soft migration window is in place: all Workes Paid projects will be automatically migrated on March 1, 2024, if not switched over manually before then. Enterprise customers will see new pricing at contract renewals after that date. Cloudflare says it will provide advance notice via email and dashboard notifications before changes take effect.
The Rationale: Predictability and Cost Control
Wall-time billing introduces costs tied to factors outside your control—third-party response times, LLM inference latency, or an upstream service suffering an outage. CPU time is functionally different: CPU-time costs are consistent given the same logic and input data, regardless of when those requests hit. Your workload's cost depends only on what your own code does. The incentive structure shifts as well: better-optimized code directly reduces what you pay.
Not every use case sees cost changes that are easy to predict upfront.
New Pricing Model: One Simple Option
The new structure consolidates what previously required choosing between pricing tiers. Cloudflare's earlier model offered separate Bundled and Unbound rate cards, each with tradeoffs around cost versus resource limits. The new unified model introduces
While wall time is generally outside a developer's control, CPU time is determined by your request handling logic and the efficiency of the code supporting it.
The Serverless Cost Problem That Didn't Go Away
Serverless platforms preserve the marketing promise of "scale to zero" efficiently—no paying for idle VMs when traffic subsides. But scale-to-zero as conventionally implemented was incomplete: you still paid for compute while your function sat idle waiting on I/O. Most serverless applications spend far more time waiting on network responses than executing CPU instructions—frequently by a factor of ten or more. That wait time was presented as unavoidable overhead.
If charging for that idle time is common practice, then under other serverless pricing, you've been paying for the functional equivalent of time when your application is performing no work. The question, as Cloudflare phrased it, comes down to this: whether the meter runs while your function idles, the platform still has the infrastructure provisioned and available to handle your traffic.
Billing by CPU time instead of wall-clock duration
Cloudflare is overhauling how Workers usage is billed. The shift is from duration-based pricing to CPU-time-based pricing. In the old model, a request that spent most of its time waiting on I/O — a database query, an API call, or a network round trip — still accrued charges for that idle time. Under the new model, you are charged only for the milliseconds your code is actually executing on the CPU.
Consider a typical workload: one billion requests per month, each taking seven milliseconds of CPU time and 200 milliseconds of wall-clock duration. The comparison below shows what that costs on the new Workers pricing versus AWS Lambda.
Table values are based on public pricing as of September 20, 2023, and do not include taxes or additional fees. AWS Lambda and Lambda@Edge figures use public US-East (Ohio) pricing.
This makes Workers cheaper than Lambda for this kind of request mix, and the cost advantage is compounded by what you don't pay for. There are no separate charges for provisioned concurrency, no premium for streaming responses, and no egress fees.
How this changes the economics of AI workloads
Long-running requests are where the new pricing model has the most dramatic effect. AI inference is the obvious example: generating an image, transcribing audio, or producing a story can take seconds, far exceeding the typical latency of a database query or API response.
Under the old Workers usage model, a two-second request to an AI model incurred duration charges for the entire time. Under the new CPU-based model, that same request is billed only for the actual CPU cycles used while waiting for the model to respond. The duration of the request is irrelevant to cost.
Capping CPU usage to prevent runaway bills
Unexpected bills from misconfigured or buggy code are a common cloud computing complaint. New Workers pricing includes a safeguard: per-Worker CPU time limits. You can set a hard cap on the CPU time a Worker is allowed to consume per request.
For example, if a Worker has a p99 CPU time of 15ms, you could set the limit to 40ms. This leaves headroom for legitimate spikes while ensuring that an infinite recursion bug or an unforeseen edge case with user-generated input cannot result in a large bill or a denial-of-wallet attack.
If you prefer less intervention, there is also an option to configure notification thresholds. Workers that exceed a chosen CPU time per request can trigger an email, a page, or a webhook through Cloudflare's notification system, allowing you to stay on top of costs without a hard cap.
Durable Objects and idle connections
Durable Objects keep duration-based pricing, and that model will not change. The rationale is that Durable Objects are stateful and long-lived, holding state in memory while clients are connected. That in-memory presence is a real cost.
The exception is when a client is connected but idle. A collaborative whiteboard app with a browser tab left open for days, with a live WebSocket connection and no activity, should not generate charges. The Hibernation API, currently in beta, addresses this.
The API lets a Durable Object define an automatic response for use while hibernated, and serialize its state so it survives the hibernation. Cloudflare can then maintain open WebSocket connections while the Durable Object is not actively running, and you are not billed for duration during that period.
A free tier for CDN customization
For developers who use Workers for lightweight CDN tasks — modifying headers, performing country-based redirects, or handling custom cache logic — Cloudflare Snippets is now the zero-cost path. Snippets, which entered alpha last year, are positioned as the replacement for Workers in these smaller use cases where you want to programmatically customize Cloudflare's application services without paying for compute.
What this means for existing projects
The pricing change removes a ceiling on the types of applications that make economic sense on Workers. CPU time as the billing unit, along with the introduced safeguards, aims to let developers scale without worrying about idle charges or provisioning compute across regions.
The migration window is defined. Starting October 31, 2023, you can opt individual Workers and Pages Functions projects into the new pricing, and new projects will default to it. You have until March 1, 2024, or the end of your Enterprise contract if later, to switch voluntarily. After that, all projects will be migrated automatically, with advance notice via email and dashboard notifications before the change.
