theRPC
All posts
5 min read

What is a Compute Unit?

TheRPC charges by Compute Units (CU), not by request count. Here is what one CU buys you, why we picked this model, and how to think about it when sizing your usage.

If you've shopped for an RPC provider in the last few years, you've seen "Compute Unit" pricing on most of the bigger names — Alchemy, Infura, QuickNode all use some variant. TheRPC's billing works the same way. This post explains what a Compute Unit (CU) is in our system, why we use it, and how to estimate your real-world cost.

The short version

One Compute Unit ≈ the work it takes to serve one cheap read. A call to eth_blockNumber or eth_chainId is 1 CU. A call to eth_call reading an ERC-20 balance is also 1 CU. A call to eth_getLogs over a 5,000-block range is more — somewhere between 50 and 200 CU depending on the result size — because the upstream node has to do meaningfully more work.

CU pricing is the way to align what you pay with what the system actually does on your behalf.

Why not just "per request"?

Per-request pricing works fine for a uniform workload. Five thousand eth_blockNumber calls is the same shape as five thousand eth_getBalance calls. But the moment you mix in a few eth_getLogs calls or debug_traceTransaction calls, the request-level cost diverges by 50–500×. Two providers can quote you the same per-request price and end up charging wildly different bills for the same workload.

CU pricing makes the math explicit. The doc page for every method shows the CU cost. You can estimate your monthly bill in 30 seconds with a spreadsheet.

How we set the CU values

Three inputs:

  1. Upstream work. How much CPU + memory + I/O the underlying chain client spends serving the call. A getBalance against an unsealed state trie node is cheap; a getLogs over a 10k-block range is not.
  2. Response payload size. Egress costs money. Calls that return 1 KB get one rate; calls that can legitimately return 1 MB get a steeper one.
  3. Cache hit ratio. Calls that are aggressively cached at the edge (chain ID, current block height) are cheaper than calls that have to round-trip to the chain client every time.

We rebalance the CU table roughly every six months. The current values are at /pricing.

What 1 CU actually costs

The free tier gives you 300,000 CU per month — enough for a typical hobby indexer or a small frontend that polls the chain every few seconds.

Paid plans run $0.50 per million CU at the entry tier and scale down at volume. A million CU sounds like a lot until you remember that an active mempool watcher subscribing via eth_subscribe to pending transactions can burn that in an afternoon.

The single-method bills add up faster than you'd expect. A back-of-envelope:

  • An indexer doing 1 eth_getLogs per chain head, range 5,000 blocks, response 100 KB → ≈100 CU per scan
  • At one scan every 12 seconds, that's 7,200 CU per chain per hour
  • Across 5 chains, 24 hours: 864,000 CU per day
  • Over 30 days: ≈26M CU → about $13/month at the entry tier

Indexers are heavy. Most workloads don't look like that.

When CU pricing doesn't fit you

Three workloads where CU is a worse fit than a flat-rate alternative:

  1. Archival queries. State at block N from 18 months ago — high upstream cost regardless of provider. Most CU pricing tables (ours included) charge a premium. If your workload is mostly archive, ask us about flat-rate node access instead.
  2. WebSocket subscription firehoses. A newPendingTransactions subscription on Ethereum mainnet emits 10–50 tx hashes per second. Per-message CU adds up fast. We offer subscription-based pricing for this case at the enterprise tier — same CU table, different bundle.
  3. Heavy eth_call simulation. Tx simulation workloads (MEV, AMM aggregators) spend most of their CU on eth_call with state overrides. The math still works, but the rate matters. Look at the volume tier before committing.

How to size your usage

  1. Find your two or three highest-frequency methods. For most apps it's eth_call + eth_getLogs + eth_blockNumber.
  2. Multiply each by its CU cost. From the table on the pricing page.
  3. Multiply by frequency. Per second × seconds in a month (≈2.6M).
  4. Sum and round up 30%. Real traffic is bursty.

That gives you a CU/month estimate that's usually within 2× of reality. Iterate from there.

TL;DR

Compute Units are how TheRPC charges for the work upstream chain nodes actually do, in proportion to what each method costs us. Cheap reads cost 1 CU. Heavy reads cost more. The doc page for every method tells you the number. Estimating your bill is a spreadsheet exercise, and the free tier covers most hobby projects without you needing to think about it.

See the live CU table on /pricing. For workload-specific questions, reach out — we're happy to help you size it.