RPC credits, compute units and flat pricing explained

Last updated: September 22, 2026

Three ways to meter the same request

• Credits. Each method has a weight in credits; the plan includes a monthly credit allowance and charges overage per million credits beyond it. The weight can differ by chain as well as by method.
• Compute units. Credits whose weights are meant to track the cost of serving a method. The rate limit may also be in compute units per second, so heavy calls lower the requests per second you get.
• Request units. Closest to counting requests: one unit per ordinary request, with some request kinds (for example archive reads) counted as more than one.
• Flat, rate-limited. No units at all: a fixed monthly price and a cap on requests per second, often split by method category. The bill does not change with volume; the cap does not change with the bill.

Published weights

The same call can be 1 unit at one provider and 20 or 200 at another, so unit counts are not comparable across providers — only the requests and the dollars they turn into are.

Worked example: what an allowance is worth in requests

Divide the included units by the weight of the calls you make most.

A rate limit written in units converts the same way: Alchemy's free plan is limited to 500 CU per second, which Alchemy itself equates to about 25 requests per second — fewer when the calls are heavier than average.

Worked example: the same traffic past the allowance

Both plans get the same month of traffic: 20,000,000 calls, the size of Chainstack Growth's own included allowance.

The same number of calls costs different amounts on the two plans for a reason that has nothing to do with the plan price: the weight. On the credit plan every EVM call counts 20 credits; on the request-unit plan an archive call counts 2 units.

How flat, rate-limited pricing works

A flat plan has no allowance to run out of. What it caps is the rate: at most N requests per second, usually with a separate, lower limit for heavy methods and a short burst above the sustained rate. The monthly volume it can serve is the rate times the seconds in a month (2,592,000 in 30 days), and the cost of a request depends on how much of that capacity you use. For any flat monthly plan:

1. Maximum monthly requests = RPS limit × 2,592,000
2. Cost per 1M requests at full use = monthly price ÷ (maximum monthly requests ÷ 1,000,000)
3. Cost per 1M requests at partial use = the full-use figure ÷ the share of the limit you actually use — half the traffic doubles it

No method costs more than another on a flat plan, but a heavy method can still be throttled sooner if it has its own lower limit. The question to ask is not “how many units” but “does my peak rate per method category fit under the caps”.

Which model fits which workload

• Small or occasional traffic: a metered plan with a free allowance usually costs least; a flat plan charges its full price regardless.
• Sustained traffic near a steady rate: flat pricing tends to win, because every extra request is free until the cap.
• Heavy methods (program scans, archive reads, asset APIs): check the weight on metered plans and the separate rate limit on flat plans — this is where offers differ most.
• Spiky traffic: on a flat plan the limit has to cover the peak, not the average; on a metered plan the peak costs nothing extra but the volume does.

How to compare two offers

1. Estimate your monthly calls per method, and your peak requests per second.
2. For each metered offer, multiply calls by that provider's weights, subtract the included units and price the rest at its overage rate.
3. For each flat offer, check that your peak fits the limit for every method category you use, then take the price as it is.
4. Compare the monthly totals, then the cost per million requests at your real volume, not at the plan's maximum.

For one example of flat, per-category RPS pricing, see Triport pricing.