Summary

  • Workers Cache charges the standard request rate for requests to the enabled Worker, including normally free static assets. A cache hit avoids code execution and its CPU charge; the request still counts.
  • Cloudflare's compute-heavy example saves $11.20 with caching. Applying the documented rules to its mostly static example instead adds $1.50, with the account's monthly allowances fully available.

A useful cache gives the processor less to do. Cloudflare's Workers Cache can also give the request meter more to count.

The distinction sits in the official documentation. The feature looks for a stored response before running a Worker. A hit returns the response without executing the code. But enabling it makes every request to that Worker billable at the standard request rate, including static-asset requests that would normally be free.

Cloudflare describes the feature as having no separate pricing. It also spells out the wider billable population. Both statements fit: a supplier can keep the price list and change which traffic enters it. That makes the scope of the switch a purchasing decision.

The $5 workload with a $1.50 addition

Workers Paid Standard starts at $5 per account each month. That includes 10 million requests and 30 million CPU milliseconds. Additional requests cost $0.30 per million; additional CPU costs $0.02 per million milliseconds. These are account allowances, not a fresh allocation for each Worker.

The pricing page's Example 2 serves 15 million monthly requests: 12 million for static assets and three million dynamic requests averaging seven CPU milliseconds each. The static requests are free. The dynamic requests and their 21 million CPU milliseconds fit inside the allowances. The published total is $5.

Keep that traffic and enable Workers Cache for the whole Worker. For this calculation, use one paid Standard account with its full monthly allowances available, no other usage or products, and no tax or discount adjustments. All 15 million requests now enter the billable count. The five million above the allowance cost $1.50.

Even if none of the dynamic responses hits the cache, CPU remains at 21 million milliseconds, below the included 30 million. Its overage charge stays at zero. More cache hits cannot push that charge below zero. The resulting total is $6.50.

That is a conditional calculation made here by applying the published cache rules to Example 2, rather than an invoice observed at a customer. It isolates the mechanism: avoiding work already covered by an allowance does not automatically pay for requests newly brought into the charging population.

A large hit rate still leaves a request bill

Cloudflare also supplies an example where caching produces a clear cash saving. At 100 million monthly requests averaging seven CPU milliseconds, the bill is $5 base, $27 for requests and $13.40 for CPU: $45.40.

With an 80% cache-hit rate, only 20 million requests run the code. CPU falls to 140 million milliseconds and its overage charge to $2.20. The request charge remains $27. Total: $34.20.

The saving is $11.20, roughly a quarter of the whole bill. An 80% hit rate measures responses delivered without executing the Worker. The bill also prices request delivery, while the included CPU allowance affects how the reduction in work turns into a reduction in dollars.

A compute-heavy dynamic service has an existing CPU charge for the cache to attack. A mostly static service with dynamic work inside its allowance may encounter the enlarged request count first. The feature is the same; the starting economics differ.

The boundary matters more than the word cache

Workers Cache is this specific pre-execution feature. It has a different scope from the older Cache API used inside Worker code and ordinary zone-level CDN caching. The documentation says zone Cache Rules and Page Rules do not configure it.

The billable population also includes Worker-to-Worker invocations that would normally carry no additional request fee under Standard service bindings. In an application split across Workers, choosing which Worker enables the feature becomes part of the cost design. A precise chain bill needs the actual path and configuration; counting components alone will not produce one.

Tiered caching and request collapsing can reduce repeated executions further. Delivered requests retain their own count. The platform sells a response-delivery service as well as the computation that sometimes produces it.

A real bill needs the traffic classes, CPU use, allowances consumed by other workloads and applicable contract terms. Those figures decide which effect wins.

For the buyer, the useful follow-up to “the hit rate improved” is “which requests started costing money?” The processor has earned its break. Procurement still has a counter to read.

Sources