← Back to Cloudflare Bill Estimator
A Workers Paid invoice is a monthly minimum plus separately metered usage: Worker requests, CPU time, KV reads and writes, and R2 storage and operations. R2 egress is free, so the money moves to operation counts. The useful question is not "how do I spend less" but "which line, changed by how much, saves the most". That is arithmetic you can do before the invoice, from the numbers in your dashboard.
Every request that reaches a Worker is billed as a request and as CPU time. Responses that rarely change can be served from the Cache API or the CDN cache instead. Serving 40% of 110M requests from cache removes 44M requests and the CPU time they used.
KV writes cost ten times a read. Writing a value that has not changed, or updating a key on every request, is the fastest way to a surprising line. Compare before you write and batch updates. Of the 11M writes in the worked example, 40% fewer saves about $22 a month, more than any Workers-side change.
A small set of keys usually takes most reads. Hold them in the Worker's memory for the life of the isolate or in the Cache API. Halving 60M reads saves about $15.
R2 reads are Class B operations. Serving a popular asset through the CDN cache means R2 is only asked on a miss; 60% fewer reads on 110M is about $24.
Class A operations (writes, lists) cost more than twelve times a read. Use larger multipart parts, avoid listing a bucket on every request and write fewer, larger objects.
CPU time is cheap per millisecond but scales with traffic: lazy-parse large JSON, shrink the bundle and keep heavy work off the hot path. For storage, lifecycle rules that expire old objects and abort stale multipart uploads keep the GB-months from only growing.
Enter your usage in the estimator or from the CLI, and gate a budget in CI:
node cli.mjs estimate usage.csv --budget 100
Plans, add-ons, contracts and price changes are outside it. Prices here are approximate list prices and editable. The estimate is arithmetic on your inputs, never a bill reader.
It depends on the workload. Request-heavy APIs are dominated by Worker requests and CPU time; apps that write to KV on every request are dominated by KV writes; media and backup workloads by R2 operations. Estimate your own mix with the estimator rather than assuming.
Workers Paid carries a monthly minimum, so the bill never falls below it however little you use. The estimator shows the minimum as a floor and lets you edit it.
No. Edge caching and CPU trimming act on the same Worker CPU time, so each lever is calculated alone and the list is a ranking, not a plan total.