Billing

To see your current or past usage, navigate to the Usage tab using the button in the side nav panel. To see the price schedule and add, modify, or remove a payment method, navigate to the Billing tab.

Definitions

User: Someone with an Aptos Build account (e.g. jim@stablelabs.com).
Organization: This is what actually owns projects and resources. Organizations have many members and admins but just one owner. Payment methods are attached to organizations, not users. For example stable-labs.
Monthly Credit: A credit in terms of US dollars that Aptos Labs grants the organization each month. It is use it or lose it, the credit does not roll over to the next month.
System Limits: These are caps that we set on the amount of resources that an organization is allowed to use. These exist to protect our infra from unexpectedly high usage. They are defined in terms of the service, e.g. CUs per 5 mins.
Budgets: We allow organization admins to set a daily and/or monthly budget for their spending. Budgets are in dollar terms, not per-resource terms. Since they are enforced asynchronously, it is possible to slightly exceed your budget. You can set these on the Usage tab in the side nav.

All organizations are automatically granted a $... credit per month. If this credit is insufficient for your needs, you can add a payment method and we will give you a higher monthly credit of $... per month free of charge. We will charge your payment method for any usage above this credit.

Credits and limits are applied on a per-organization basis, not a per-user or per-project basis.

Usage of our services accrues a cost in dollars (USD) according to the following price schedule:

If you have attached a payment method to your organization, you will be charged for any usage beyond your monthly credit. If you do not have a payment method attached, usage of our services will be disabled if you hit your monthly credit cap until the next month. Billing is tracked on a monthly basis, starting from 12am UTC.

Transactions sponsored using the Gas Station are charged based on the gas used and the APT price at previous close-of-day (UTC time). Read more below.

System Limits

Unlike the Monthly Credit, which is declared in dollar terms for a full month, System Limits are always either instant values (e.g. disk space usage) or measured over a short (usually rolling) window of time (e.g. CUs per 5 mins). The purpose of System Limits is to protect our infra from greater usage than we can handle (spikes). These aren’t necessarily on the same dimensions that we use for billing (see the price schedule above).

Except for the per-processor limits, these limits apply to the whole organization. For example, all API usage shares the same Compute Units / 5 mins limit.

System limits are intended to be so high that you don’t have to think about them, particularly organizations with a payment method attached. Please reach out to us if you’re having issues with system limits.

These are the default system limit values, you may have a bump in place for your organization that increases these.

Cost Dimensions

Applicable Services: Node API, Indexer API, Gas Station, No-Code Indexing, Token Management Platform, Keyless Pepper Service.

Summary

Billing: Usage of our APIs is accured in terms of Compute Units. Requests cost exponentially more CUs based on how much load they place on our infrastructure.
System Limits: There is a limit on CU usage per 5 mins.

Billing

Requests to Aptos Build APIs are measured in terms of Compute Units (CUs). CUs measure the relative cost of a request on our infrastructure. For example, a given call to /v1/accounts/0x1 (the Node API) might cost 250 CUs while a call to /v1/graphql (the Indexer API) might cost 500 CUs, indicating that the infra cost of the second request is 2x higher than the first. Compared to just rate limiting based on request count, Compute Units allow us to capture that some requests are more resource intensive than others.

Some of the above services are just APIs, e.g. the node and indexer APIs. Compute Units are the only way we track utilization for these services. Other services are more than just APIs, such as gas station or no-code indexing and accrue other costs.

For example, every request to gas station incurs a cost in terms of CUs to cover the infrastructure cost of the gas station. If through that request the gas station successfully sponsored a transaction, there will be an additional cost based on the gas used for the transaction. See the Gas Station tab for more.

Similarly, for no-code indexing, requests to the API we provision for your processor are accounted for with Compute Units. However, there are additional costs associated with indexing that are not captured by Compute Units, for example the cost of the database and processor. Those are accounted for as “Disk Usage” and “Write Throughput”. See the Indexing tab for more.

Compute Unit Calculation

The method for calculating the CUs used by a request differs per upstream type (e.g. Node API vs. Indexer API) and endpoint (e.g. /v1/view vs. /v1/accounts), but as a general rule of thumb, the more complex a request is (gas used, time taken, etc.), the more CUs it will consume. We use a variety of factors to calculate the cost of a request, and our approach is subject to change at any time. Broadly speaking, the behaviour is as described below.

Node API

The current approach for this upstream is quite simple.

upstream_processing_time * multiplier * exponential_factor

In other words, cost is just a function of how long the upstream takes to process the request. In general, node API requests are dominated by I/O time on the database. The more complex a query is, the longer it takes, the higher the cost in CUs.

Expensive, long running queries have an outsized impact on our infrastructure, so we scale the cost exponentially.

Node API (VM Endpoints)

Requests to endpoints that involve execution with the Move VM (e.g. /v1/transactions/simulate or /v1/transactions/view) return the cost of that execution in terms of gas. We use this gas cost and some multiplier to get the final gas cost:

gas_cost * multiplier

Indexer API (Other Endpoints)

We use the same formula as with the Node API, albeit with different multipliers.

System Limits

There is a limit on the number of CUs that can be used per 5 minutes. This limit is significantly higher for organizations with a payment method attached.

Applicable Services: Transaction Stream Service.

Summary

Billing: Usage is billed in terms of bytes streamed.
System Limits: There is a limit on the number of concurrent streams you can have open.

Billing

For streaming services, such as the Transaction Stream Service, billing and the system limits work on different dimensions.

Usage is billed in terms of bytes streamed. Your organization’s streaming bill at the end of the month is based on the total number of bytes you streamed: bytes_streamed * price_per_byte. You can reduce this bill by making use of upstream transaction filtering.

System Limits

Separate from how we track usage for billing purposes, there is a system limit on the number of concurrent streams an organization can have open. If the limit is 8 for example and you have 8 streams open concurrently at any given time, you will receive a 429 error if you try to open a new stream. The concurrent stream limit is higher for organizations with a payment method attached.

Applicable Services: Gas Station, Token Management Platform.

Summary

Billing: You are charged based on the amount of gas used for a transaction and the APT price at previous close-of-day.
Gas cost is only accured if the transaction executes on chain.
Compute Units are consumed for all requests, even if the transaction is rejected.

Billing

Gas billing works a bit differently compared to the other cost dimensions. Cost in dollar terms for Compute Units for example is just a function of compute_units * price_per_unit, where the price per unit is a set value for the entirety of the billing cycle. Gas billing cannot be calculated in this way because the price of gas is variable. Instead, we calculate the cost of gas in terms of gas used and the APT price at previous close-of-day.

For example, if we were trying to figure out the cost of a Gas Station resource for the 21st, 22nd, and 23rd of March, we would do essentially the following:

System Limits

N/A

function getGasUsed(resourceId, dates): number {
    const feePayerAddress = client.getFeePayerAddress(app);
    let totalCostUsd = 0;
    for (const date of dates) {
        const gasUsed = client.getGasUsed(resourceId, date);
        const previousDate = date - 1;
        const gasPrice = client.getAptPriceInUsd(previousDate);
        totalCostUsd += gasUsed * gasPrice;
    }
    return totalCostUsd;
}
 
const totalCostUsd = getGasUsed(resourceId, ["2025-03-21", "2025-03-22", "2025-03-23"]);

In other words, we sum up the gas used each day and multiply it by the APT price at the previous close-of-day.

If a transaction is rejected it does not incur any gas cost (this is not the same as a failed transaction, which is still executed and written to the ledger and therefore incurs a cost).

Each call to the gas station also incurs a flat cost in terms of CUs, even if the transaction is rejected.

Applicable Services: No-Code Indexing.

Summary

Billing

You are charged for the amount of disk space used by your processors.
You are charged for the write throughput of your processors.
You are charged a flat cost every minute your processor is running (paused processors do not accrue this cost).
Requests to the API created for the processor are accounted for with Compute Units.

System Limits

There is a maximum number of processors an organization can create.
Processors will be halted if they hit their DB space limit.
Indexing will fall behind if a processor hits its write throughput limit.

Billing

Disk Usage

You are charged for the amount of disk space used by your processors. This is charged per GiB hour (i.e. each GiB of disk space used for 1 hour costs the amount specified in the price schedule above).

Write Throughput

You are charged for the amount of data written by your processors. This is measured in terms of MiB written by the processor per 5 minutes. Both INSERTS and UPSERTS count towards this limit, the purpose of this limit is to protect the DB’s CPU, not its disk space.

Flat Cost

You are charged a flat cost every minute your processor is running (paused processors do not accrue this cost).

System Limits

Because a single processor is composed of multiple pieces of infrastructure, and the load varies based on multiple factors, we use a combination of limits for no-code indexing.

Number of processors

Each organization is allowed a certain number of processors according to the system limits table above. You cannot create a new processor without first deleting an existing one if you have hit this limit. In-place upgrades do not count against this quota (since there is no new processor created). Hard upgrades count as new processors, and therefore count against this quota.

DB space

Each processor is bound by a certain disk space cap, e.g. 50 GiB. If your processor hits this limit, it will be paused (just like if you had paused the processor yourself through the UI). Paused processors do not index new events, but the API will continue to serve queries.

This is a static limit, it is not a sliding window and it does not reset at certain time intervals.

Write Throughput

To ensure a single processor doesn’t use up too much of the query-handling capacity of the indexing infrastructure, we limit the amount of data written to the database by each processor. If a processor hits a certain limit, it will naturally lag behind the head of the chain.

This is tracked with a sliding 5-minute window.

Getting Started API Keys