Alchemy Compute Units: What Each Method Costs

Alchemy's pricing has changed since we first wrote this post in May 2026, and so has the method that caused the most surprise bills. The fixed $49 and $289 tiers are gone: there is now a Free plan and a single Pay As You Go rate. And debug_traceTransaction, which used to bill 309 Compute Units, now bills 40, but carries a throughput cost of 1,000 CU per second.

So the question has shifted. It's less "which method multiplies my bill" and more "which method runs me out of throughput". This is the updated version, with Alchemy's published numbers as of 2026-09-28.

How Compute Units work now

Every call costs a method-specific number of Compute Units (CUs), from Alchemy's compute unit cost table:

And the plans, from Alchemy's pricing page:

There are now two separate meters. The billed CU decides your invoice. The throughput CU decides how many calls per second you can make before you are rate-limited or buying more capacity. For most methods they are the same number. For debug_traceTransaction they are 40 and 1,000.

Three workloads, priced

Same shape as before: 100,000 daily active users, a handful of backend calls per session, 30 days a month. Only the method mix changes.

Workload A: wallet UI

• eth_getBalance × 1 → 20 CU
• eth_getTransactionCount × 1 → 20 CU
• eth_getTransactionReceipt × 5 → 100 CU
• eth_call × 3 → 78 CU

218 CU per session → 21.8M CU a day → 654M CU a month → $343 a month at $0.525 per million.

Workload B: DEX or analytics page

• eth_getLogs × 3 → 180 CU
• eth_call × 5 → 130 CU
• alchemy_getTokenMetadata × 2 → 20 CU

330 CU per session → 990M CU a month → $520 a month.

Workload C: trade analytics with traces

• debug_traceTransaction × 3 → 120 CU
• eth_call × 5 → 130 CU
• alchemy_getAssetTransfers × 2 → 240 CU

490 CU per session → 1.47B CU a month → $772 a month in billed CU.

The spread between A and C is now 2.25×, not the 8.7× it was under the old trace price. Method mix still moves the bill, but the bigger trap for Workload C is the other meter.

The throughput trap

Workload C makes 300,000 trace calls a day. Spread evenly, that's about 3.5 a second. Real traffic isn't even: if most of it lands in an 8-hour busy window, it's about 10 traces a second. At 1,000 throughput CU each, 10 traces per second is the entire 10,000 CU/s included with Pay As You Go, before a single eth_call from the same users.

Past that, calls are throttled until you buy more throughput at $160 per 5,000 CU/s. The billed-CU line on your invoice can look reasonable while your trace endpoint returns rate-limit errors at peak.

Backfills hit the same wall. Tracing 100,000 historical transactions bills only 4M CU, about $2.10. But at 10 traces a second it takes almost three hours of your entire throughput allowance, and anything else your app does in that window competes for the same budget.

Why this is still hard to budget

1. Two meters, one of them invisible in planning. Most teams model monthly CU and never model CU per second until production throttles them.
2. Retries count. ethers and viem retry failed calls. A flaky upstream minute becomes extra CU on both meters.
3. Method choices hide in libraries. An SDK helper that calls alchemy_getAssetTransfers (120 CU) instead of a filtered eth_getLogs (60) doubles that path's cost without anyone choosing to.

Flat-rate, for comparison

A flat-rate plan meters one thing: requests per second. Every method counts as one request.

The honest trade-off: for light workloads, Alchemy's Free plan (30M CU a month) costs nothing, and a small app may never leave it. Flat-rate wins once usage is steady and the method mix includes logs or traces, and when you need the bill to be the same every month.

When Alchemy is still the right call

If you use Alchemy for its non-RPC products, such as webhooks, NFT and token APIs or the account-abstraction stack, keep it for those; there is no flat-rate equivalent for most of them. You can split traffic: Alchemy for the products, a flat-rate endpoint for the bulk eth_call, eth_getLogs and eth_getTransactionReceipt traffic.

How to model your own bill

1. Pull a day of production RPC logs and count calls by method.
2. Multiply each count by its billed CU from the cost table, sum, and multiply by 30 for a monthly number.
3. Take your busiest minute, convert calls to throughput CU per second, and compare it with the 10,000 CU/s included.
4. Price the monthly CU at $0.525 per million, plus any throughput blocks you need.
5. Compare with a flat-rate plan sized to your peak requests per second.

FAQ

What are Alchemy Compute Units? Alchemy's billing unit. Each method has a CU price (for example eth_call 26, eth_getLogs 60), and a few methods have a higher throughput cost that counts against your CU-per-second limit.

How much does Alchemy cost per Compute Unit? $0.525 per million CU on Pay As You Go. The Free plan includes 30M CU a month.

Why is my Alchemy bill higher than expected? Usually the method mix. For trace-heavy apps, also check throughput: each debug_traceTransaction uses 1,000 CU/s.

Is there an alternative to CU pricing? Flat-rate: a fixed monthly price limited by requests per second, where every method counts the same.

SwiftNodes is the flat-rate alternative to Alchemy: one price a month, no per-method costs, no overage. See the full Alchemy alternative comparison, how the major RPC providers compare, or get a free API key.