Comparing LLM API prices by looking at one headline number is usually wrong.
The same model can have separate prices for input, output, cache reads, and cache writes. A gateway may also expose the model through several service groups or protocol routes. If those dimensions are mixed together, a large-looking discount can still produce a higher bill for the workload you actually run.
This guide presents a reproducible way to compare token-based model API prices. XiuRouter is used as a concrete example, but the method applies to other gateways and provider aggregators.
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
+ output_tokens × output_rate
+ cache_read_tokens × cache_read_rate
+ cache_write_tokens × cache_write_rate
All rates must use the same unit, such as price per one million tokens.
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.
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.
Service groups are part of the price
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.
Therefore, include the selected service group in both the estimate and the acceptance test.
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.
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/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.
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?