Alchemy Compute Units Explained: What Your Bill Really Depends On (2026)

A team I talked to last month got a $4,200 Alchemy bill on a $290 plan. Their user count hadn't moved. Their traffic hadn't spiked. They'd just shipped a feature that called debug_traceTransaction instead of eth_getTransactionReceipt on a few hot paths. Same shape of operation, different RPC method, 20× the Compute Units per call.

This is not a story about Alchemy doing something wrong. Their pricing is documented. The CU costs per method are public. It's a story about why "documented" doesn't mean "predictable" — and why most teams underestimate their Alchemy bill by 2-5× until they get burned.

How Compute Units actually work

Alchemy charges per "Compute Unit." Different RPC methods cost different CU amounts. Here's the abbreviated reality:

You're given a monthly CU allowance with each plan:

• Free: 300M CU/month
• Growth $49: 300M CU/month with overage at $1.20 per million
• Scale $289: 1.2B CU/month with overage at $0.50 per million
• Enterprise: custom

That all sounds tractable until you do the math on real apps.

The math that bites you

Let's price out three workloads. Same shape — 100,000 daily active users doing 10 backend operations each — but the operations differ by method.

Workload A: simple wallet UI

User opens app, app fetches balance and recent transactions:

• eth_getBalance × 1 → 19 CU
• eth_getTransactionCount × 1 → 26 CU
• eth_getTransactionReceipt × 5 (recent txs) → 75 CU
• eth_call × 3 (read token balances) → 78 CU

Total per session: 198 CU

100,000 users/day × 198 CU = 19.8M CU/day = 594M CU/month

That's already 2× the Growth plan's 300M allowance. You'd be on Scale at $289 — or paying Growth-tier overage at $1.20/M × (594M - 300M) = $353/month in overage on a $49 plan. Most teams discover this after the first month.

Workload B: DEX or analytics page

Same 100k DAU, but each session loads a chart of historical token prices, requiring log queries across a 10,000 block range:

• eth_getLogs × 3 → 225 CU
• eth_call × 5 (route lookups) → 130 CU
• alchemy_getTokenMetadata × 2 → 200 CU

Total per session: 555 CU

100,000 × 555 = 55.5M CU/day = 1.67B CU/month

That's above Scale's 1.2B allowance. You're at Scale + overage: $289 + $0.50/M × 470M = $524/month. For an app with the same user count as Workload A.

Workload C: trade analytics with traces

Same 100k DAU, but the app shows users a "trace" view of their trades for debugging:

• debug_traceTransaction × 3 → 927 CU
• eth_call × 5 → 130 CU
• alchemy_getAssetTransfers × 2 → 300 CU

Total per session: 1,357 CU

100,000 × 1,357 = 135.7M CU/day = 4.07B CU/month

Now you're at Scale + massive overage: $289 + $0.50/M × 2.87B = $1,724/month. Same user count as the wallet UI in workload A. 8.7× the cost because of which RPC methods got called.

Why this is hard to budget

The numbers above don't include any usage growth. They're steady-state. The cost variation is entirely from which methods are called, not how often. Three problems compound this:

1. You can't predict CU draw until you ship. When you're designing a feature, you know roughly how many calls it'll generate but not what they'll cost in CUs. A developer choosing debug_traceTransaction for cleaner debug output instead of eth_getTransactionReceipt increases your bill 20×, without thinking about it.

2. Library defaults make this worse. ethers and viem batch calls — that's good — but they also retry failed calls automatically. If a node is flaky for 5 minutes, you'd see no errors in production but a 10× spike in CUs that day.

3. One-off jobs blow through your budget instantly. A backfill script that traces 100k historical transactions is 100k × 309 = 30.9M CUs in a few hours. That's 10% of your Growth allowance burned in an afternoon, and you might not realize until the alert email.

The result: teams over-budget Alchemy by 2-3× as a safety margin, or they under-budget and get the surprise bill. There's no easy middle.

Why flat-rate solves this

The competitor pricing model — flat-rate per month, capped by requests-per-second — sidesteps this entirely. You pick a plan that covers your peak load. Your bill is the plan price. Period.

The honest tradeoff: if your workload is light (say, < 100M CU/mo) Alchemy's Free or Growth tier is genuinely cheaper. The break-even depends on which methods you call. For trace-heavy or log-heavy apps, flat-rate is dramatically cheaper. For lightweight reads, it's close to a wash and Alchemy's free tier may win.

When Alchemy is still the right call

Honest take: if you're using Alchemy specifically for their non-RPC products — Notify webhooks, NFT API, subgraph indexes, account abstraction toolkit — those don't have a flat-rate equivalent at SwiftNodes. Keep Alchemy for those. The decision is about plain RPC, where flat-rate's predictability wins as soon as your workload has any debug, trace, or log-query weight to it.

You can also combine. Use Alchemy for the API products you need and SwiftNodes for the bulk of your eth_call / eth_getLogs / eth_getTransactionReceipt traffic. The two providers don't interfere.

How to model your own situation

The honest cost-comparison spreadsheet:

1. Pull a day of your production RPC logs. Count calls by method.
2. Multiply each method's count by its public CU cost.
3. Sum to get a daily CU number; multiply by 30 for monthly.
4. Find the Alchemy plan that covers that CU number; add overage if applicable.
5. Find the SwiftNodes plan that covers your peak requests-per-second.
6. Compare.

For most teams whose RPC mix includes any eth_getLogs, debug_traceTransaction, or Alchemy-specific methods, this exercise reveals the flat-rate plan is cheaper. For pure lightweight reads, Alchemy might be — but in our experience that's a rare workload past the prototype stage.

FAQ

What are Alchemy Compute Units? Alchemy's billing unit: every API call costs a method-specific number of CUs — simple reads are cheap, while eth_getLogs, debug_traceTransaction, and archive queries cost up to 30× more. Your plan includes a monthly CU allowance; beyond it you're into overage/autoscaling.

Why is my Alchemy bill so high? Almost always the method mix, not the traffic. One swapped method on a hot path (a trace where a receipt sufficed) can multiply the bill 20× with zero user growth — that's the $4,200-on-a-$290-plan story that opened this post. Audit which methods consume your CUs; one path usually explains most of it.

How do I estimate CU costs before shipping? Instrument a staging run: log every RPC method per user session, multiply by each method's CU price, then by DAU × 30. The worked examples above show identical user behavior costing $400, $500, or $1,700/month depending on feature shape.

Is there an alternative to CU pricing? Flat-rate: a fixed monthly price limited by requests-per-second, where every method costs the same. Predictability instead of per-call optimization — details in the takeaway below.

The takeaway

Compute Units are not a deceptive pricing scheme. They're a legitimate way to charge for variable-cost work. But for an app developer trying to forecast next month's infrastructure bill, the variability creates real budgeting pain — the same user behavior across three different feature shapes can cost $400, $500, or $1,700 depending entirely on which RPC methods got called.

If predictability matters more than per-call optimization, flat-rate is the right answer. If your team has the bandwidth to actively monitor and optimize CU draw, Alchemy's pricing rewards that work.

SwiftNodes is the flat-rate alternative to Alchemy — one number per month, no per-method costs, no overage. See the full Alchemy alternative comparison, how the major RPC providers stack up, or grab a free API key — no credit card, no KYC.