For a developer using GPT-5.5, a price comparison can be concrete: $35 in the displayed provider-reference column versus $2.45 at XiuRouter's current default rate for the same token counts.
Here is the arithmetic, followed by a method you can apply to your own usage.
September 30 deadline for existing benefit-group users
Update, September 13, 2026: XiuRouter's benefit group is closed to new selection. Existing access remains available for now, but the group will stop completely after September 30, 2026. If your key still uses it, migrate to another available group before then. Retaining a key's old settings does not extend the group's availability.
Recheck the destination model, price and quota before migrating. For Astra, Fast consumes 2.5 times the quota of Standard. Verify a small request and its recorded cost before restoring normal traffic.
Official retirement notice (Chinese) · Current pricing and migration guide
A worked example: $35 versus $2.45
Prices checked on September 12, 2026 in XiuRouter's public pricing catalog. The model is gpt-5.5. The public catalog currently exposes one selectable group, max, so the ordinary price page no longer requires a Value-versus-Managed choice. Historical or account-specific keys may retain other group settings; use the rate available to the key that will make the request.
Assume your application accumulates one million uncached input tokens and one million output tokens across multiple requests. Each request stays within the 272,000-input-token pricing tier.
| Token usage | Displayed provider-reference rate | XiuRouter rate |
|---|---|---|
| 1 million uncached input tokens | $5.00 | $0.35 |
| 1 million output tokens | $30.00 | $2.10 |
| Estimated token cost | $35.00 | $2.45 |
Reference estimate = $5.00 + $30.00 = $35.00
XiuRouter estimate = $0.35 + $2.10 = $2.45
Difference = $32.55, or 93%
These are USD token-rate estimates using the reference prices displayed by XiuRouter. This example contains no cache reads or writes, and it does not add taxes or other non-token charges. Requests above the input threshold use different rates. No new paid model request was run for this example.
For your own app, replace the token counts with usage from a representative task. Keep the exact model, service tier and applicable input-length band fixed. The worked example below shows why a different input/output mix can change the winner when two routes have different rate ratios.
Why an input discount is not the whole bill
The current gpt-6-astra standard input-length band illustrates the difference. At no more than 272,000 input tokens per request, the September 12 catalog lists an input rate of $0.875 and an output rate of $5.25 per million tokens, against displayed provider-reference rates of $10 and $50 respectively.
That is about 91.3% less for input and 89.5% less for output. Accumulating one million uncached input tokens and one million output tokens across requests costs an estimated $6.125, versus a $60 reference estimate: about 89.8% less in total. It would be inaccurate to advertise this workload as saving over 90% on the whole bill.
The calculation excludes cache usage, tool fees, taxes and other non-token charges. Longer inputs use another pricing band. It is a calculation from the public catalog, not a newly executed or billed model request.
A discount percentage is not a price model
Before comparing two offers, define the exact thing being compared.
A useful comparison tuple is:
model
+ provider or source model
+ service group or route
+ API protocol
+ input price
+ output price
+ cache-read price
+ cache-write price
+ currency and unit
+ pricing version or checked-at time
If one of these fields changes, you may no longer be comparing the same offer.
For example:
- A model alias can point to a different upstream model later.
- An OpenAI-compatible route and a native Anthropic Messages route can expose different capabilities.
- A lower-cost service group can have a different availability boundary.
- A cached-input price cannot be compared with an uncached-input price.
- A price copied from an old screenshot may no longer match the live catalog.
The first rule is therefore simple: compare a complete route, not a model name.
Separate the token buckets
Token-based APIs commonly charge different rates for several token types.
At minimum, keep these buckets separate:
- uncached input tokens;
- output tokens;
- cache-read tokens;
- cache-write or cache-creation tokens.
A normalized cost calculation is:
cost = (
input_tokens * input_rate_per_1m
+ output_tokens * output_rate_per_1m
+ cache_read_tokens * cache_read_rate_per_1m
+ cache_write_tokens * cache_write_rate_per_1m
) / 1_000_000
Use raw token counts for the *_tokens values and prices per one million tokens for the *_rate_per_1m values. The division by 1,000,000 converts the unit rates into the estimated cost.
Do not add cache-read tokens to uncached input and then charge both rates. Do not apply the input rate to output tokens. Do not assume cache write and cache read have the same price.
Weight the comparison with a real workload
An input-heavy workload and an output-heavy workload can produce opposite results from the same price table.
Consider this hypothetical example:
| Route | Input / 1M | Output / 1M | Cache read / 1M |
|---|---|---|---|
| Route A | $0.50 | $5.00 | $0.05 |
| Route B | $1.00 | $3.00 | $0.10 |
Assume one workload uses:
- 8 million uncached input tokens;
- 2 million output tokens;
- 5 million cache-read tokens.
Because these rates are per one million tokens, the quantities in the following equations are expressed in millions:
The weighted costs are:
Route A = 8 × 0.50 + 2 × 5.00 + 5 × 0.05 = $14.25
Route B = 8 × 1.00 + 2 × 3.00 + 5 × 0.10 = $14.50
Route A has the lower input price. Route B has the lower output price. Neither headline tells you the result by itself.
These numbers are illustrative, not current XiuRouter or provider prices. Replace them with the live rates and your own token distribution.
Keep reference prices traceable
A savings claim needs a reference source.
Record:
- the reference model;
- the provider or published source;
- the input, output, cache-read, and cache-write reference rates;
- the date or pricing version used;
- the gateway route being compared.
If the gateway maps one public model name to another source model, that mapping must be visible in the evidence. Otherwise, the comparison may combine two different products.
XiuRouter's public pricing API exposes a pricing_version and, where available, structured reference_price fields such as input, output, cache_read, cache_write, and source_model. The live response can change as models and routes change, so store the version with the comparison instead of treating one response as permanent.
Use the price available to your API key
Price is not independent of the route that delivers the request.
A gateway can make the same model available through multiple service groups. A cheaper group may have different availability, permissions, or upstream characteristics. A key may also be restricted to only some groups or models.
For XiuRouter, the September 12 public catalog has only max as a selectable group. A single-group account does not need to choose a tier in the interface. If an existing key has a different group or account-specific access, include that group in the estimate and request check.
Do not calculate using the cheapest visible group and then send production traffic through a different group.
Protocol compatibility is a separate decision
Pricing does not prove that a client workflow will work.
OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, and Gemini GenerateContent have different request shapes and behavior. A model that works through one endpoint does not automatically work through another.
Before accepting a lower price, confirm:
- the client sends the protocol you expect;
- the route supports the required endpoint;
- tool calls and streaming work for the actual client;
- the selected key can access the model and service group.
A request that fails cannot be made economical by a lower token rate.
Verify the estimate against a real request
A spreadsheet is only the estimate.
Run a small, non-destructive task through the exact client configuration you plan to use. Then inspect the gateway's request or usage record.
For XiuRouter, verify:
- the intended API key;
- the intended model;
- the intended endpoint;
- the selected service group;
- request status;
- input, output, and cached-token usage;
- recorded cost.
If the usage record does not match the estimate, investigate the route before scaling traffic.
Common causes include:
- the client used an older provider configuration;
- the API key selected a different model or group;
- the final request path was not the expected protocol route;
- cache usage differed from the assumption;
- the catalog changed after the estimate was created.
Include non-token costs explicitly
Token rates are not always the complete commercial cost.
Check whether the comparison also needs:
- currency conversion;
- prepaid balance or recharge fees;
- taxes;
- minimum commitments;
- subscription fees;
- failed-request charging rules;
- image, audio, or other non-token pricing units.
Do not hide these costs inside an unexplained multiplier.
A practical comparison checklist
Before choosing a route, confirm:
- [ ] The model and source model are identified.
- [ ] The service group is fixed.
- [ ] The API protocol is fixed.
- [ ] Input and output rates use the same unit.
- [ ] Cache read and cache write are separate.
- [ ] The reference price has a source and checked-at time.
- [ ] The gateway price has a pricing version or checked-at time.
- [ ] The estimate uses a representative workload.
- [ ] Currency, taxes, subscriptions, and recharge costs are included when applicable.
- [ ] A real request completed through the expected route.
- [ ] The usage record matches the key, model, group, token buckets, and cost.
This method produces a smaller claim than "Gateway A is always cheaper," but it produces a claim that can be checked.
Usage records and conversation content
Cost verification uses statistics such as model, token counts, charges and request status. It does not require saving the prompt or model reply.
XiuRouter's Data Processing and Privacy statement, updated September 12, says that XiuRouter does not store model conversation content, use it for model training or sell user data. Usage statistics and model performance data are retained long term. Model developers process requests under the policies of their respective services; this is not a claim of zero retention across every provider.
XiuRouter sources
Current model and route prices:
https://router.xiu.ai/en/pricing
Machine-readable public pricing response:
https://router.xiu.ai/api/pricing
Protocol and endpoint boundaries:
https://docs.xiu.ai/en/router/api-compatibility/
Prices, models, service groups, protocol support, and reference data can change. Re-run the comparison against the live catalog and verify a real request before using the result for a production decision.
Disclosure: XiuRouter and XiuAI are operated by XiuLab Inc, a U.S. corporation.
Top comments (1)
The approach you've outlined for comparing LLM API prices is incredibly insightful, especially the emphasis on breaking down costs by token type and maintaining clear distinctions between routes and service groups. It's a crucial reminder that a seemingly attractive discount can obscure significant costs depending on usage patterns. One possible enhancement could be to implement a visualization tool that dynamically illustrates these cost comparisons based on user input, making it even easier to grasp the implications of different pricing structures. If you're looking for help with building such a tool or additional development support, I’d be glad to explore a paid collaboration. How do you envision users best utilizing this pricing comparison framework in their projects?