- Category
- Cost
- Reading time
- 9 minutes
- Published
- Updated
How to reduce Alchemy CU usage
Alchemy uses a compute-unit model where different RPC methods can consume different amounts of capacity. For many teams, this is manageable. For heavy workloads, CU usage can become hard to forecast and optimize.
If your bill is growing because of archive reads, eth_getLogs, trace/debug, retries, or backfills, the goal is not simply to “send fewer requests.” The goal is to reduce waste, control heavy methods, and align your provider strategy with your workload.
Start with method-level visibility
Before optimizing, collect usage by:
- method
- chain
- endpoint
- application
- worker
- retry count
- time window
- success vs failure
- archive vs non-archive behavior
Without method-level visibility, you may optimize the wrong thing.
Estimate Alchemy RPC pricing from your method mix
Alchemy's pricing and method tables make raw RPC call count an incomplete cost metric. As of August 3, 2026, the Free plan includes 30 million compute units per month. Pay As You Go lists $0.45 per million CUs for the first 300 million in a month and $0.40 per million after that.
Published EVM weights show why method mix matters: eth_blockNumber costs 10 CUs, eth_getTransactionReceipt 20, eth_call 26, debug_traceTransaction 40, and eth_getLogs 60. Throughput CUs are a separate capacity control for some methods, so do not use a throughput limit as the billed-CU estimate.
Calculate monthly usage as:
- Group all calls by method and outcome, including retries.
- Multiply each group by its current CU weight.
- Add WebSocket, webhook, enhanced API, and other separately metered usage.
- Apply the current plan tiers to the total.
- Model normal sync, backfill, and failure months separately.
Recheck Alchemy's live pricing and compute-unit tables before budgeting because prices and method weights are time-sensitive.
Practical ways to reduce CU usage
1. Optimize eth_getLogs ranges
eth_getLogs can become expensive when ranges are too wide or retries are frequent.
Use adaptive range sizing:
- smaller ranges for dense contracts
- larger ranges for sparse contracts
- dynamic adjustment after timeout or failure
- separate backfill workers from live sync workers
2. Cache historical data
Once data is finalized, many historical responses do not need to be requested repeatedly. Cache old blocks, logs, receipts, and stable contract reads where safe.
3. Reduce retry storms
Retries can multiply CU usage quickly. Use:
- exponential backoff
- jitter
- retry budgets
- circuit breakers
- workload-level concurrency limits
A failed request plus repeated retries can cost more than the original workload.
4. Separate live and backfill traffic
Backfills should not compete with production requests. Put them behind separate queues, rate limits, and endpoints where possible.
5. Avoid unnecessary polling
Replace aggressive polling with smarter intervals, WebSockets where appropriate, or chain-tip-aware scheduling.
6. Review trace/debug usage
Trace/debug calls are often expensive operationally. Cache trace results where safe and avoid repeated traces for the same transaction.
7. Do not assume batching reduces CUs
Alchemy's current method table prices a JSON-RPC batch as the CU cost of each method multiplied by the number of calls. Batching can reduce connection overhead, but it does not by itself reduce the billed method total.
8. Measure cost per successful result
Do not only measure total CU usage. Measure how much useful data you get per unit of spend. Timeouts and retries lower efficiency.
When optimization is not enough
Sometimes high CU usage is not a bug. It is the natural result of a heavy workload.
That is common for:
- indexers
- analytics platforms
- archive-heavy systems
- trading infrastructure
- block explorers
- compliance tools
- security products
In that case, the better fix may be a provider model with predictable quotas, dedicated capacity, or managed node infrastructure.
Where SolidRPC fits
SolidRPC is designed for teams that want to replace compute-unit complexity and a multi-provider RPC stack with one integration.
The platform focuses on:
- monthly response quotas on paid plans and a 10,000-response daily Free quota
- one response unit per method call
- no compute-unit math or archive surcharge
- archive access and chain-specific trace/debug families on supported networks
- managed upstream routing, failover, monitoring, and recovery
- staged migration from existing providers
For teams reducing Alchemy CU usage, SolidRPC becomes the HTTPS JSON-RPC layer for standard, archive, logs, and supported trace/debug workloads. Confirm the required method family on each chain, qualify the integration in stages, then retire the old provider routing.
Bottom line
To reduce Alchemy CU usage, optimize method mix, retries, caching, polling, and backfills. But if the workload is genuinely heavy, also compare whether a predictable-quota RPC model fits better.