Turn Cloudflare requests, Neurons, and gigabytes into real cost

Cloudflare doesn't hand you a single cost as you go. It meters you in several different units at once. A Worker bills by the request, Workers AI by the Neuron, R2 by the gigabyte-month and again by the operation, and Workflows by the step. Each meter runs on its own, with its own free allowance and reset, so no one number tells you where you stand.

Cloudflare's analytics supplies the usage behind a running estimate. If you connect a pasted API token with Billing Read, its Billable Usage feed also supplies reported daily amounts for compatible lines. The work left is making those meters and reported rows legible together, plus a forecast for next month, before the bill lands.

How does Cloudflare bill for Workers, Workers AI, R2, and Workflows?

Cloudflare’s developer platform is usage-based, and each product is metered on the unit that fits it. Three of them carry most of a working developer’s bill, and they don’t share a yardstick.

Workers is billed by the request — each inbound request that actually runs your code, tallied across your whole account. Requests served straight from static assets, subrequests your Worker makes, and calls to another Worker over a service binding don’t add to it. (Workers also meters CPU time, the milliseconds your code actually spends running; that’s a second axis, and one CostCompass doesn’t yet track — more on that below.) The Paid plan carries a fixed monthly base charge and bundles in an allowance on each axis (the first 10 million requests, plus a block of CPU-time) before per-unit metering begins. With a Billing Read token, CostCompass reads that base charge from your account and shows it on the card as a plan fee.

Workers AI is billed in Neurons, Cloudflare’s underlying compute unit — a single flat price per thousand Neurons, the same across every model. What differs is how many Neurons a model burns: a large model spends far more on the same request than a small one, often by an order of magnitude. So the model a request lands on can move its cost more than its length does. The first 10,000 Neurons each day are free, on every plan, and reset at midnight UTC.

R2, the object store, meters on two axes of its own. Storage is billed per gigabyte-month: how much you keep, for how long. And operations are billed per request against the store, split into two classes. Class A covers the heavier calls — writes, copies, and list operations — priced higher; Class B covers the cheaper reads. Deletes are free. Egress, the bandwidth out, is the part R2 famously doesn’t charge for. Each axis carries its own monthly free allowance before the meter starts — on R2’s Standard storage class, the first 10 GB-month of storage, 1 million Class A operations, and 10 million Class B operations. Those allowances belong to R2 Standard itself, not to any Workers plan tier, and the Infrequent Access class gets none.

Both axes then run twice, because R2 has two storage classes and they price differently. Standard is the default. Infrequent Access is cheaper to keep (a third less per gigabyte-month) and dearer to touch — operations cost roughly double to two and a half times Standard’s, and unlike Standard it charges for data retrieval, per gigabyte read back out. It also carries a 30-day minimum: an object written to Infrequent Access is billed for thirty days even if you delete it on day five. The tier pays off for archives you rarely open and works against you for anything you read often.

R2 Data Catalog, the Iceberg REST catalog, meters separately again, on three axes. Catalog operations bill per operation with the first million each month included. Then, if you turn on automatic compaction for a table, that job bills twice over: per gigabyte of data it processes, with the first ten each month included, and per file it compacts, with the first million included. Snapshot expiration, the other maintenance job, is free. The catalog’s own files sit in your R2 bucket and bill as ordinary R2 storage, not as a fourth Data Catalog line.

One rule matters more than its size suggests: R2 rounds each line up to the next whole billing unit. A million and one operations bill as two million; 1.1 GB-month bills as 2. So small usage on an R2 line is rarely as cheap as multiplying it by the rate suggests — a few hundred operations past your free allowance cost a whole block, not a few hundredths of a cent.

Cloudflare publishes that rule for R2 and not for its other products. CostCompass applies the same rounding to Workers, KV, Workflows, D1 and Data Catalog anyway, because a per-million price with no stated rounding rule is more likely to round than not — but that part is our assumption, not Cloudflare’s published behaviour, so those lines are marked as estimates.

Workers KV reuses the same two yardsticks R2 does — operations and gigabyte-months — so it folds into the running cost without adding a fifth unit. Workflows adds two more meters: steps executed by Workflow instances, and stored Workflow state measured as GB-month. CostCompass reads step usage and the Workflows storage metric exposed by Cloudflare’s GraphQL schema, then prices both against the monthly Workflows allowances. Durable Objects bills on two compute meters, and CostCompass reads both: requests — which count HTTP calls, RPC sessions and alarm invocations one for one, and incoming WebSocket messages at twenty to one, since Cloudflare bills 100 of those as 5 requests and charges nothing for outgoing ones — and duration, measured in GB-seconds against the fixed 128 MB each object is allocated. Duration runs while your code is executing and while the object sits idle in memory unable to hibernate; an idle object that is eligible for hibernation stops the meter. That distinction is what makes the WebSocket Hibernation API worth reaching for on a connection that carries only occasional messages. Each meter carries its own monthly allowance, so a Durable Object that wakes often but finishes fast shows a very different shape from one that stays resident. Storage is metered too, and it is where Durable Objects gets genuinely confusing: Cloudflare bills it on two entirely different rate cards depending on which storage backend a namespace was created with. SQLite-backed namespaces — the default for anything new, and the only option on the free plan — are billed for rows read, rows written, and stored data. Older key-value-backed namespaces are billed for read units, write units, deletes, and stored data instead, at prices that are not comparable line for line. CostCompass works out which card each namespace falls under and reports its storage under the right one, so the Durable Objects card shows compute and storage together rather than half the picture.

Cloudflare meters still more — Queues, Vectorize, and the rest each have their own unit and allowance — but Workers, Workers AI, R2 (both storage classes, plus Data Catalog and its compaction charges), KV, Workflows, Durable Objects (compute and storage), and D1 are the surfaces CostCompass reads today. Cache Reserve and Workers CPU time come from Cloudflare’s account-scoped Billable Usage feed when you use a pasted API token with Billing Read. OAuth and Analytics-only tokens leave them out.

Cache Reserve’s Writes are Class A operations: when a Cloudflare cache miss fetches an asset from your origin, Cloudflare writes it into the Reserve. Reads are Class B operations: when an edge cache misses and Cloudflare can serve the asset from the Reserve, it reads it from there. Cloudflare bills those operation classes in whole-million units, so a modest number of Reserve reads or writes can appear as one full billed unit. They are Cloudflare-managed operations, not a second request counter your application emits. (The current rates and free allowances live on Cloudflare’s own Workers, Workers AI, R2, KV, Workflows, and Cache Reserve pricing pages — treat any figure you’ve memorized as provisional.)

Why is Cloudflare spend hard to keep ahead of?

The per-product metering is what makes the platform flexible, and it’s also what makes the spend resist a quick glance. Most of the difficulty is in the gap between using and being charged:

• Usage isn’t money until you price it. Cloudflare’s usage view shows requests, Neurons, gigabyte-months, and operations — the raw meters. Turning those into a running cost means applying each product’s rate and netting its free allowance every time you want to know where you stand.
• Free allowances hide the cliff. Each product runs free up to its own allowance — monthly for Workers and R2, daily for Workers AI — so spend reads as nothing right up to the line. What happens at the line depends on your plan: on the Paid plan you spill into per-unit charges, while on the Free plan there’s no overage to spill into — Workers AI stops with an error at its daily cap, and Workers is held to its daily request limit rather than billing past it. Either way, the move off free isn’t something the raw usage view announces.
• A small change moves the bill quietly. Point a Workers AI call at a larger model, let a Worker fire more often, or change an R2 access pattern from reads to writes, and the cost moves even though your app looks the same. Because what a single call costs can sit far apart within a product — a heavy model burns far more Neurons, a Class A operation costs more than a Class B read — which model or which operation class you use can matter as much as how much.
• It’s spread across four units. One bill, four yardsticks: requests, Neurons, gigabyte-months, operations. Reading whether this month is heavy means converting all four into money in your head.
• Cloudflare is rarely your only provider. Alongside it you’re likely calling Anthropic for Claude, building on OpenAI or Google, maybe routing through OpenRouter, and paying for inference hosts and serving — so Cloudflare is one slice of a bill you otherwise stitch together by hand from a stack of dashboards.

Is the Cloudflare cost exact or estimated?

It depends on the card. OAuth and Analytics-only API-token cards estimate cost from the GraphQL usage meters. A pasted API token with Billing Read also reads Cloudflare’s daily Billable Usage feed, using the reported amount for Workers requests, R2, Durable Objects, and D1, and adding Cache Reserve and Workers CPU time as billed lines of their own. Other products remain usage-derived estimates, so the overall card may be hybrid.

For Analytics-derived rows, those allowances reset when your bill does. Cloudflare’s billing period usually isn’t the calendar month — an account can run the 29th to the 28th, for instance — and an allowance that reset on the 1st would burn down against the wrong window. CostCompass reads the period start from your account and resets the free allowances, the round-up to whole billing units, and the gigabyte-month arithmetic on that boundary instead. The period comes from the Billing Read permission the API-token path already asks for. Cloudflare’s OAuth can’t grant that permission, so OAuth cards reset allowances on the 1st of the month. Reported Billable Usage rows do not have local allowances or round-up arithmetic applied on top: CostCompass uses Cloudflare’s reported daily amount as-is.

Plan fees come from the same read, so they need the Billing Read token too; OAuth cards don’t show them. The list of subscriptions that gives the billing period also gives each plan’s price, so a flat fee such as Workers Paid, a paid zone plan, or a paid add-on lands on the card as a plan fee. It’s spread across the days you hold the plan, and it counts toward month-to-date spend and the forecast. Products billed only by usage, like R2 and Cache Reserve, list a price of zero there, so nothing is counted twice. Two limits. Domain registrations and renewals aren’t subscriptions, and reading them needs a Registrar permission CostCompass doesn’t ask for, so they don’t appear. And if you’ve already typed Cloudflare in by hand as an “Other” subscription, remove it, or the fee counts twice.

The remaining Analytics-derived rows are a reconstruction rather than a copy of the bill. Because they apply the same rates Cloudflare charges on, they land close to the invoice when your account matches the assumptions below. Those assumptions are exactly where estimates can drift:

• The rates assume the Workers Paid plan. Those are the per-unit rates the rate card mirrors. A Free-plan account behaves differently: Workers and Workers AI are held to their free allowances rather than billing past them; R2 Standard past its free tier is billed on any plan, Free included. So the estimate is calibrated to Paid pricing — closest when your account is on it.
• Infrequent Access storage can read low on Analytics-only cards. CostCompass does price R2’s Infrequent Access tier — its own storage rate, its own Class A and Class B operation rates, and its data retrieval — from the storage class Cloudflare reports on each line. What it cannot see is the tier’s 30-day minimum: Cloudflare bills a short-lived object for the full thirty days, and the daily storage figure the API exposes only shows what is there right now. So if you write to Infrequent Access and delete soon after, the Analytics-derived Infrequent Access storage line is a floor rather than the figure you’ll be billed. A compatible Billable Usage storage row replaces that estimate with Cloudflare’s reported charge.
• The Neuron rate is a stored snapshot. Workers AI prices off Cloudflare’s flat per-Neuron rate, held as a dated rate that applies to every model — so a new model is priced the moment it appears, with no per-model gaps. If Cloudflare changes the rate, the estimate tracks it once the stored figure is refreshed.
• KV storage is read account-wide. KV operations are summed exactly across your namespaces, but the stored-data figure is read as one account-wide number rather than added up namespace by namespace. For a single namespace — the usual case — that’s exact; if you spread data across several namespaces it can read low, so KV storage is marked as an approximate line until that aggregation is confirmed against a multi-namespace account.
• Workflows storage is schema-derived. Cloudflare’s public Workflows pricing docs describe the GB-month storage charge, and live GraphQL schema introspection exposes a storageRate metric. That line is included, but marked approximate until Cloudflare documents the analytics field’s unit or it is checked against an invoice.

Cloudflare’s analytics datasets are not the same system that generates your invoice, so Analytics-derived rows remain running estimates you can act on while the month is still open. Reported rows are deliberately labelled as such; the card can contain both kinds at once.

How can you reduce your Cloudflare bill?

Tracking shows you where the units go. A few levers slow the burn:

• Match the model to the task. A large Workers AI model can burn an order of magnitude more Neurons than a small one on the same call, so routing routine, high-volume work to a smaller model and saving the large one for what needs it is often the biggest lever on inference cost.
• Cut what triggers a Worker. A request only costs you when it actually runs your Worker, so the lever is keeping the Worker out of the path rather than caching inside it — a Worker still runs, and bills, even when it ends up returning a cached value. Serve what you can straight from static assets or a cached response on a route with no Worker, debounce noisy triggers, and reserve the Worker for requests that genuinely need code to run.
• Watch the R2 operation classes. Class A writes and lists cost more than Class B reads, so batching uploads and trimming needless list calls keeps the pricier class down.
• Prune what R2 keeps. Storage bills per gigabyte-month, so lifecycle rules that expire stale objects stop you paying month after month for data you no longer read. (Cloudflare’s Infrequent Access tier can lower the storage rate, but it adds retrieval and per-operation fees and a 30-day minimum, so it pays off only for data you rarely touch. CostCompass tracks it as its own storage class; with Billing Read, compatible reported rows replace the corresponding estimate.)
• Watch the per-product split. A ranked, by-product view catches a Worker that started leaning on a pricier model within days — while you can still act on it, not after the bill lands.

How do you forecast next month’s Cloudflare bill?

Forecasting metered usage doesn’t need anything exotic, just a burn rate: take your spend over the last several days, turn it into a daily average, and project it across a full month.

CostCompass does exactly this. It scales your trailing seven-day burn rate to the number of days in next month and adds your Cloudflare plan fees plus any other fixed subscriptions you’ve entered. The result is one forward number for what next month costs if the current pace holds. Seven days is the window: long enough that one heavy inference day doesn’t throw the average, short enough to pick up a recent change like a Worker that started calling a larger model. It’s the same engine that runs across every provider you’ve connected, so Cloudflare folds into one whole-stack projection rather than a number you read in isolation.

How does CostCompass track your Cloudflare costs?

CostCompass reads most usage from Cloudflare’s GraphQL Analytics API — a handful of aggregate queries that cover the whole period rather than walking it day by day — and prices those rows into money: Workers, R2, KV, Workflows, Durable Objects, and D1 from its built-in rate card with the free allowances netted out, Workers AI from Cloudflare’s flat Neuron rate with the daily free allowance subtracted. The result is a running cost, grouped by product line, that you can read as the month builds. When you first connect it starts from that point forward, and each refresh brings the running total current.

There are two ways to connect Cloudflare, and both give you a running cost and a forecast. Signing in with Cloudflare (OAuth) is the quickest, with no token to create. The card prices your usage from Cloudflare’s analytics, so every line is an estimate, and free allowances reset on the 1st of each calendar month. A pasted API token with Billing Read shows all of that, then lines it up with your actual bill. On any day Cloudflare’s billed feed covers, its reported amount replaces the estimate. Your real billing period sets when allowances reset, plan fees such as Workers Paid show on the card, and Cache Reserve and Workers CPU time appear as lines of their own. A token with only Account Analytics Read works like an OAuth card.

Two things make that practical for a solo developer. First, your token is encrypted in your browser before anything is stored. The token you paste is sealed with your vault password on your own device, and only the sealed version is ever saved, a blob CostCompass can’t open because the vault password stays with you. When it’s time to read your usage, your browser unseals the token and passes it to a relay that uses it for that one call to Cloudflare and is built not to log or keep it. What we hold at rest is locked ciphertext; the token your account runs on never reaches us in usable form.

Second, Cloudflare doesn’t sit alone. The same dashboard rolls its running cost up with every other AI and compute provider you’ve connected, Claude, OpenAI, your hosting, into one figure with a forecast. How you get to that cross-provider number, by hand, through tooling, or straight from each API, is its own decision. The ways to track AI costs across providers lay the options out side by side.

Getting started takes three steps:

1. In Cloudflare, copy your Account ID (it’s in the dashboard URL) and create an API token with Account Analytics: Read. Add Billing: Read as well to include reported billing rows and Cache Reserve; without it, CostCompass still shows Analytics-derived estimates.
2. Paste both into CostCompass. The token is encrypted in your browser before it’s stored, so the server only ever holds ciphertext.
3. Click Refresh. CostCompass reads your usage, prices it, and from there your running cost and forecast roll up — broken down by product, with Cloudflare folded into the whole-stack number.