Skip to main content

Model Pricing

The AISIX Cloud control plane calculates request cost from observed token counts and the price associated with the upstream provider and model. 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. Connected deployments refresh this catalog automatically. Offline deployments use the bundled catalog snapshot loaded at startup.
  3. If neither source matches, the usage event retains its token counts but records $0.00 spend.

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. Enter the Prompt and Completion rates in USD per 1M tokens.
  5. 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.

Verify the Override

For the simplest verification, send a new request directly to the matching model, then expand the event in Request Logs. Confirm that the event shows the expected model, token counts, and event cost. 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. When an override replaces a catalog price, Reset to catalog default removes the organization override. The catalog price takes effect again on the next usage event.

Next Steps

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