Model Pricing

The AISIX Cloud control plane calculates request cost from the usage it observes and the price associated with the upstream provider and model. Most models are priced on token counts; models billed by duration are priced on audio length. Configure a pricing override when a model has no catalog price or when your organization uses a different rate.

Pricing affects the spend shown in Usage and the totals evaluated by AISIX Cloud budgets. Prompt and completion rates can also affect target ordering for least_cost routing groups. Pricing does not change what the upstream provider charges.

How AISIX Resolves Prices

AISIX applies the configured rates without hidden multipliers. Each usage event resolves a price by the exact (provider, model name) pair:

1. An organization override wins when it matches the provider and model name.
2. Otherwise, AISIX uses the matching catalog default from models.dev.
3. If neither source matches, the usage event retains its reported usage but records $0.00 spend.

Catalog refresh behavior depends on how pricing synchronization is configured. In online mode, the control plane refreshes the catalog at startup and every 24 hours. By default, the On-Premises Docker Compose package loads the bundled catalog snapshot at startup, even when it has internet access. To enable online synchronization for that package, see Pricing Catalog.

Within a matching price, AISIX calculates token and duration cost independently, then adds the two terms. Token pricing uses the prompt and completion rates, with the cache and reasoning fallbacks described below. Duration contributes only when the event reports audio length and Audio per minute is nonzero.

Cost is calculated and stored when the usage event is recorded. A pricing change applies to later events and does not re-price historical usage.

Identify a Missing Price

Start with an expanded event in Request Logs, which shows the cost of each usage event or routing attempt to six decimal places. The aggregate Usage view rounds spend to two decimal places and shows only the top 10 environment/model rows. Therefore, $0.00 spend or an absent model in Usage does not prove that pricing is missing. When checking a very low-priced request, generate enough token usage to make the expected cost visible before concluding that a price is missing.

A catalog price can be missing when:

• The model runs on a self-hosted or reseller upstream that models.dev does not price.
• The configured model name is a custom alias.
• The provider offers a newer model that the catalog does not yet include under that provider.

Before adding an override, note the provider and model name exactly as they are configured. A pricing row that differs from either value does not match the usage event.

Add a Pricing Override

1. Open Model pricing from the organization navigation.
2. Select Add pricing.
3. Enter the Provider and Model name exactly as configured on the model. The Provider field suggests known catalog providers but also accepts a custom value.
4. Configure the basis the provider charges:
   • For a token-priced model, enter the Prompt and Completion rates in USD per 1M tokens and leave Audio per minute at 0.
   • For a duration-priced speech-to-text model, leave the token rates at 0 and enter the Audio per minute rate in USD per minute of audio, such as 0.006.
5. For a token-priced model, optionally enter distinct Cache read, Cache write, and Reasoning rates.
6. Save the override.

A cache or reasoning rate of 0 means that no distinct rate is set. Cache tokens fall back to the prompt rate, and reasoning tokens fall back to the completion rate.

Price a Model Billed by Audio Length

Some speech-to-text models are billed per minute of audio rather than per token and report no token counts. Such a request records its audio length instead, and the Audio per minute rate turns that length into spend. A model left at 0 for this rate contributes no duration-based cost.

The current AISIX catalog does not supply duration rates, so there is no default to inherit: create the row with the provider and model name exactly as configured. For example, OpenAI currently lists whisper-1 at $0.006 per minute. At that rate, a 60-second transcription costs $0.006.

caution

Token and duration costs are additive. If an event contains both token usage and audio duration, and the matching price has nonzero rates for both, AISIX adds both terms. Configure only the usage basis that the provider charges.

Verify the Override

For the simplest verification, send a new request directly to the matching model, then expand the event in Request Logs. For a token-priced model, generate enough token usage to produce a visible cost. For a duration-priced model, use an audio sample with a known or sufficiently long duration. Confirm that the event shows the expected model and event cost. Request Logs does not currently display the measured audio duration, so calculate the expected duration cost from the sample length.

If you verify a routed or ensemble request instead, find the event or attempt rows that share its request ID. Add their costs before comparing the total with the expected cost.

Request Logs shows six decimal places. If the expected event cost rounds to $0.000000, generate enough token usage to make the cost visible at that precision.

After sufficient traffic, you can also confirm aggregate spend in Usage. Usage rounds spend to two decimal places and shows only the top 10 model rows, so it is less reliable for verifying a single low-cost request.

Historical rows do not change after the override is saved. Compare an event created after the change rather than expecting an earlier $0.00 event to be recalculated.

Edit or Reset a Price

Edit a row to change the rates used for later events. Reset to catalog default removes the organization override. If a catalog price exists, it takes effect again on the next usage event.

A manually created duration-pricing row usually has no catalog default. Resetting that row removes its effective price, so later matching events record $0.00 until another override is configured.

Next Steps

Continue with Budgets to enforce spending limits, then configure Budget Alerts and Notifications. Use Logging and Auditing to investigate individual request outcomes.