Credits Conversion Configuration
https://app.example.comis an example address. Replace it with the actual address of your environment, retaining the route path and query parameters.
1. Configuration Goal
Configure the following three Token-to-Credits conversion ratios separately for each model:
- Input tokens: input Tokens;
- Output tokens: output Tokens;
- Cached tokens: cached Tokens.
After configuration, the monetary value represented by 1 Credit must be consistent regardless of which model the user calls or whether the consumed Tokens are input, output, or cached Tokens.
The conversion-ratio unit in the Admin Console is
credits / 1K tokens. The1 / 1 / 1values shown in an interface screenshot only illustrate field placement and are not the values to enter.
2. Preparation
Prepare and confirm the following information before starting:
- A common settlement currency, such as USD;
- The common monetary value of a Credit:
1 Credit = V currency units; - The official billing prices for each model:
- Input Token price;
- Output Token price;
- Cached Token price;
- The pricing unit for each price, such as
currency units / 1M tokens; - If providers use different currencies, convert them to the settlement currency using the exchange rate confirmed during initialization, and record the exchange rate, source, and effective date.
Do not copy Credits ratios directly from another model. Calculate the ratio separately when model prices or price types differ.
3. Conversion Formulas
Let:
V= the monetary value represented by 1 Credit;P_in= the input Token price, incurrency units / 1M tokens;P_out= the output Token price, incurrency units / 1M tokens;P_cache= the cached Token price, incurrency units / 1M tokens.
The Admin Console requires the number of Credits per 1K tokens, so the conversion formulas are:
Input credits / 1K tokens = P_in / (1000 × V)
Output credits / 1K tokens = P_out / (1000 × V)
Cached credits / 1K tokens = P_cache / (1000 × V)If the provider already supplies prices in currency units / 1K tokens, use:
Credits / 1K tokens = monetary price per 1K tokens / V4. Configuration Steps
Configuration entry: System → Models in the Admin Console.
Example route: https://app.example.com/admin/settings/model
app.example.comis an example domain. During actual operation, replace it with the AOS Work access domain for the customer environment. Keep the route path/admin/settings/modelunchanged.
- Use the customer environment's AOS Work domain to open the route above and enter System → Models.
- Select the target model and open its edit window.
- Verify the model display name and Actual model ID to ensure that the correct model is being edited.
- Calculate the conversion value from the model's official input price and fill in Input tokens.
- Calculate the conversion value from the model's official output price and fill in Output tokens.
- Calculate the conversion value from the model's official cached-token price and fill in Cached tokens.
- Enter the calculated results at the precision supported by the system fields; do not use another model's ratio for convenience.
- Save the configuration and record the model, price source, original prices, settlement currency, exchange rate, effective date, and final conversion values.
If a model does not support cached billing, or the provider explicitly sets the cached-token price to zero, configure it according to the provider's actual billing rules. Do not infer a cached price.
5. Consistency Check
Before saving, perform a reverse check for each model's three conversion ratios:
Monetary value per input Credit = monetary price per 1K input tokens / Input credits
Monetary value per output Credit = monetary price per 1K output tokens / Output credits
Monetary value per cached Credit = monetary price per 1K cached tokens / Cached creditsExcept when both the price and conversion value are zero, every reverse-calculated result must equal the common V. The check covers:
- the input, output, and cached prices for the same model;
- like-for-like prices across different models;
- cross-comparisons across different models and Token types.
Permitted error may only come from the decimal precision supported by the Admin Console. If a reverse-calculated result exceeds the rounding tolerance agreed during initialization, increase the conversion-value precision or recheck the original price and pricing unit.
6. Calculation Example
The following numbers only demonstrate the calculation method; they are not actual model prices or system defaults.
Assume:
- the settlement currency is USD;
1 Credit = 0.001 USD;- a model's input price is
2 USD / 1M tokens; - its output price is
8 USD / 1M tokens; - its cached-token price is
0.5 USD / 1M tokens.
Enter the following values:
| Configuration item | Calculation | Conversion ratio |
|---|---|---|
| Input tokens | 2 ÷ (1000 × 0.001) | 2 credits / 1K tokens |
| Output tokens | 8 ÷ (1000 × 0.001) | 8 credits / 1K tokens |
| Cached tokens | 0.5 ÷ (1000 × 0.001) | 0.5 credits / 1K tokens |
Reverse check:
Input: 0.002 USD / 2 credits = 0.001 USD / credit
Output: 0.008 USD / 8 credits = 0.001 USD / credit
Cached: 0.0005 USD / 0.5 credits = 0.001 USD / creditThe monetary value per Credit is consistent for all three Token types, so the configuration passes.
7. Completion Criteria
This chapter is complete only when all of the following conditions are met:
- Input, output, and cached-token Credits ratios are configured for every enabled model;
- All original prices use the same currency and pricing unit;
- The reverse-calculated monetary value per Credit is consistent for all non-zero conversion ratios;
- Price sources, exchange rates, and effective dates are recorded for future auditing;
- It has been confirmed that screenshot example values and other models' configurations were not directly reused as actual values.