How to Price a Model Endpoint: GPT-6 Astra on OpenRouter
Treat a third-party endpoint as a routing policy, then check provider cost, throughput, fallback filters, routing mode, and failover before production.
The trade-off is speed against cost. Start with the listed rates: $10.00 per 1M input tokens, $50.00 per 1M output tokens, and $1.00 per 1M cache reads. Multiply those rates by your token mix before you call the endpoint cheap. Treat the endpoint as a routing policy, not a model price.
GPT-6 Astra on OpenRouter is a useful test case because the public listing exposes the parts that matter: price, context, providers, routing, and failover. The model is recent enough that provider data can still move. GPT-6 Astra launched on September 4, 2026.
The context cap changes the bill
The context window is 1,050,000 tokens, and the completion cap is 128,000 tokens. A long prompt can dominate the bill before the answer begins. The completion cap matters when the product needs long reports, code diffs, or structured output. If the expected answer approaches the cap, the output rate becomes the main cost factor. Put both limits in the cost model before you estimate monthly spend. Keep the token mix in the same units as the price table.
The provider spread changes the answer
The endpoint is served by two providers, OpenAI and Azure (US), with automatic failover between them. The listed endpoint price is not the only number. OpenAI Fast is shown at $20.00 per 1M input tokens and $100.00 per 1M output tokens, with 51 tokens/s throughput and 99.99% uptime. That spread is the first cost variable for a third-party endpoint. It can change the monthly bill more than the model choice.
Throughput sets the limit for perceived speed. Compare the listed rate against your latency target before you promise a response time. Uptime is the other side of the same trade-off. A higher rate can be worth it if the feature is user-facing.
The provider table is the place to compare price, throughput, and uptime. Do not compare only the endpoint price. A faster provider can be worth the extra cost when the user is waiting. A slower provider can be fine when the job runs in the background.
Use the same token mix for every provider comparison. If the product sends mostly input tokens, the input rate drives the estimate. If it sends mostly output tokens, the output rate drives the estimate. If it repeats prompts, the cache-read rate changes the average before you choose a provider. Record the endpoint estimate in the launch checklist before the endpoint ships.
Run these checks before production
Keep this list with the launch checklist. Each item is a quick test, not a design review.
- List provider prices and throughput.
- Compute input, output, and cache cost from your token mix.
- Check fallback filters before relying on failover.
- Select routing mode by latency or accuracy.
- Test error failover with a forced provider failure.
Provider spread is why the price item comes first. The cost item forces a real calculation, not a copy-paste. The filter item checks the request settings before launch. The mode item forces a choice, because routing mode changes product behavior. The failover item tests the failure case with a real request in staging.
Routing and failover are product decisions
OpenRouter describes three routing modes for this endpoint: Balanced for price and speed, Nitro for fastest response, and Exacto for highest tool-calling accuracy. Pick the mode that matches the user-visible requirement. If the feature needs fast answers, speed is the constraint. If it calls tools, accuracy is the constraint.
The first mode fits products that need both cost and speed. The second mode fits latency-sensitive surfaces. The third mode fits agentic flows where a wrong tool call costs more than a slower answer.
If an upstream provider returns an error, the request can move to another healthy provider when filters allow it. The provider list is not the whole story. A forced failure test should cover the same filters the production request uses. If the test request uses different filters, the failover behavior may differ from the production behavior. Document the mode, the filters, and the expected failover behavior before the endpoint ships.