7 minIteradian Engineeringpricinginfrastructure
Compute units, credits or requests: how RPC providers actually bill you
RPC providers meter in three incompatible units — compute units, credits and plain requests. The unit decides whether a trace-heavy workload costs the same as a read-heavy one. This post explains each model and how to compare quotes that are not denominated the same way.
Comparing RPC providers is harder than it should be, because almost none of them quote the same unit. One provider sells compute units, another sells credits with a daily cap, a third sells plain requests. A quote of "80 million" from one vendor and "500,000" from another can describe very similar workloads. This post breaks down the three models so you can normalise a quote before you sign for it.
Model 1: compute units
A compute unit is a weighting applied per method. A simple read costs a few units; a trace or a wide log range costs many. Alchemy uses this model and publishes a per-method table, and its own pricing FAQ suggests assuming roughly 27 compute units per request when you estimate, which reflects the traffic mix it typically sees.
The strength of compute units is fairness: you pay in proportion to the work you actually cause. The weakness is predictability. If your method mix shifts — say you add an indexer that hammers eth_getLogs — your bill moves even though your request count did not.
Model 2: credits, often with a daily cap
Credits work like compute units, but the cap is frequently applied per day and per second rather than per month. Infura, for example, publishes its free Core plan as 3,000,000 credits per day and 500 credits per second rather than a monthly figure.
A daily cap behaves very differently from a monthly quota. A single unusual traffic day — a mint, an airdrop, a backfill — can exhaust a daily allowance while your monthly total sits comfortably inside budget. If your traffic is spiky, model the worst day, not the average.
Model 3: plain requests
Iteradian uses this model: one JSON-RPC call is one request, whatever the method. It is the least clever of the three and that is the point — you can forecast the bill from a request count you already have in your own metrics, with no multiplier table in between.
Ankr sits between the models: it meters credits internally but publishes a direct per-1,000-request rate by chain family, which makes it unusually easy to compare against.
How to normalise a quote
- Pull your real method distribution from your current provider's analytics, or from your own logs. Not an estimate — the actual mix.
- For a compute-unit vendor, multiply each method's share by its published multiplier to get your blended cost per request.
- For a credit vendor with a daily cap, take your busiest day in the last 90 days, not your average day.
- For a request-metered vendor, the number is the number.
- Only then compare monthly totals — and read what each vendor does past the included amount, because that is where surprise bills come from.
Overage is the part everyone skips
Included rates get all the attention, but what happens past the included rate is what you actually pay on your worst month. Rates vary enormously: QuickNode publishes $0.62 per million additional API credits on its Build plan, falling to $0.50 per million on Business. Pay-as-you-go vendors such as dRPC avoid the question entirely by having no overage cliff at all. Iteradian meters overage past the monthly allowance at a published per-1,000-request rate, but only up to a fixed spend cap per billing period; past the cap the request is rejected with an HTTP 429 rather than billed further, so the worst month has a known upper bound.
Whatever provider you choose, set a usage alert at 80% of quota. Every model punishes you for finding out at the end of the month.
Frequently asked questions
01What is a compute unit in RPC pricing?
A compute unit is a per-method weighting used to price a request by how expensive it is to serve. A simple balance read might cost a few units while a trace call costs hundreds. Providers publish a per-method multiplier table.
02Is request-based pricing cheaper than compute-unit pricing?
Not inherently. Request-based pricing is more predictable, because every call costs the same. Whether it is cheaper depends entirely on your method mix: read-heavy workloads often do better on compute units, while trace- and log-heavy workloads often do better on flat request pricing.
03Why do some providers cap credits per day instead of per month?
Daily caps protect the provider's shared capacity from single-tenant spikes. For the customer they are riskier: an unusual traffic day can exhaust a daily allowance even when the monthly total is well within budget.