What are Compute Units (CUs) and Throughput Compute Units (CUPs)?

At Alchemy, we provide a flexible and scalable approach to managing your blockchain applications by measuring usage in 2 key dimensions: Compute Units (CUs) and Throughput Compute Units (CUPs). CUs reflect the total computational resources your app uses, while CUPs measure your app's throughput in terms of Compute Units per second. In this article, we'll explain how these measurements work, how they impact your app's performance, and how to efficiently manage usage to avoid overages.

Key Differences Between Compute Units (CUs) and Throughput Compute Units (CUPs)

To give you full control over your blockchain interactions, Alchemy breaks usage down into these two dimensions:

1. Compute Units (CU): This is a measure of the total computational resources your apps use on Alchemy. You can think of this as how you would pay Amazon for compute usage on AWS. Some queries are lightweight and fast to run (e.g., eth_blockNumber) and others can be more intense (e.g., large eth_getLogs queries). Each method is assigned a quantity of compute units, derived from global average durations of each method.

2. Throughput Compute Units (CUPs): Each application has a dedicated, reserved Throughput, measured in Compute Units per Second. Applications can greatly exceed their dedicated throughputs based on elastic demand in our system. Since each request is weighted differently, we base this on the total compute units used rather than the number of requests. For example, if you send one eth_blockNumber (10 CUs), two eth_getLogs (75 CUs), and two eth_call (26 CUs) requests in the same second, you will have a total of 212 CUPS. Note that even if your application limit is 200 CUPS, the system will likely still allow this throughput.

Can I prepay for more total Compute Units?

No. On the Pay-As-You-Go plan, there is no product to purchase a block of total Compute Units in advance. CUs are billed based on your actual usage, so your total usage capacity scales automatically as you use the API rather than through a prepaid allotment.

The only capacity you can prepay for on Pay-As-You-Go is throughput (CUPs) - see How to purchase additional peak throughput. If you're seeing a charge for a throughput upgrade but were expecting it to raise your total monthly Compute Unit capacity instead, that charge is working as intended: it increased your CUPs limit, not your total CU allotment.

If you need a custom Compute Unit allocation, higher throughput, or predictable volume-based pricing, an Enterprise plan can be structured around your usage. You can view the full plan breakdown on our pricing page.

Practical Example

Consider a free-tier Alchemy account, which includes the following limits:

• Total Compute Units: 30 million CUs per month.

• Throughput: 300 CUPs.

For instance, the getNFTMetadata method consumes 100 CUs and 10 Throughput CUs (CUPs). This means:

• You can call getNFTMetadata up to 3 million times a month, given its CU cost of 100 CUs.

• You can execute up to 30 calls per second, given its throughput cost of 10 CUPs.

Managing Overages

Exceeding Throughput Compute Units: Exceeding your throughput limit typically results in a 429 error code. We recommend implementing retries to handle these errors efficiently. The Alchemy SDK includes built-in retries to help manage this automatically. Further details on managing throughput can be found in our documentation: Throughput Documentation.

Viewing CU and CUPs Costs

To better plan and manage your application's consumption of resources, you can view detailed CU and CUPs costs per endpoint on our documentation page. This will help you understand the specific costs associated with each API call you make. Visit the Compute Unit Costs page for complete details: Compute Unit Costs.

Forecasting cost for a mix of RPC methods

To forecast cost for an application that calls several different methods (for example, a bot that polls for new blocks, reads state, watches events, and submits transactions), list every method you call, its CU cost, and its throughput CU cost. Here's an Ethereum mainnet example:

To estimate monthly Compute Unit spend on Pay-As-You-Go: multiply your expected calls per month for a method by its CU cost, divide by 1,000,000, then multiply by the per-million-CU rate ($0.45/M CU for usage up to 300M CU in a month, $0.40/M CU beyond that). For example, 1 million eth_getLogs calls costs roughly 1,000,000 × 60 ÷ 1,000,000 × $0.45 = $27.

To check throughput, add up the Throughput CU of every call you expect to make in the same second and compare the total to your plan's CUPS limit. The debug and trace methods carry a much higher throughput cost (1000 CUPS each) than standard reads like eth_call or eth_getLogs, so avoid calling them from a tight polling loop and reserve them for occasional checks, such as post-trade analysis, instead.

Debug API and Trace API plan requirement

debug_traceCall, debug_traceBlockByNumber, debug_traceTransaction, and the other Debug API and Trace API methods are not available on the Free plan. They require Pay-As-You-Go or Enterprise. See the pricing plans page for the full breakdown by plan.

Related docs

• eth_blockNumber

• eth_call

• eth_getLogs

• eth_sendRawTransaction

• debug_traceCall