GPT-6 Astra Costs 2.5x More Than GPT-5.6 Sol and Scores About the Same
Book: AI That Ships - The series: AI in TypeScript - 5 books, from your first LLM call to agents in production - all five here - My project: Hermes IDE | GitHub - an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub A new model lands. Someone on your team opens a pull request that changes one string in one config file, the model id. The diff is green in five minutes. Evals look fine, maybe a point better on the suite you happen to have. It ships. Three weeks later the invoice arrives and it is a different shape than the one before it. Nobody wrote a bad loop. Nobody shipped a prompt-injection. The system does exactly what it did last month. It just costs more to do it, because a one-line diff moved every request from $2 and $10 per million tokens to $10 and $50. OpenAI announced GPT-6 Astra on 3 September 2026. OpenAI calls it the most capable model it has shipped. That is the company's claim and I am not going to argue with it. But "most capable model available" and "the model your service should call by default" are two different questions, and the distance between them shows up on your infrastructure bill. What the launch numbers say The API list price at launch, per OpenAI: - Standard tier: $10 per 1M input tokens, $50 per 1M output tokens - Fast tier: $20 per 1M input tokens, $100 per 1M output tokens Astra takes text and image input and returns text only, with a 1M token context window. It went first to a limited set of organisations under OpenAI's Daybreak Access programme, with wider access to the paid ChatGPT tiers and the API announced as planned for the days after launch. It is also listed on AWS Bedrock and Microsoft Azure. Now the third-party read. Artificial Analysis runs its own evaluations independently of the vendors. On its Intelligence Index, Astra scores 60, which puts it #14 of the 202 models the site tracks. Its cost per Intelligence Index task comes out at $0.96. The median model in that set scores 36 and lists at roughly $2 per 1M input and $10 per 1M output. Two sentences from that page are the reason this post exists. Artificial Analysis states that Astra scores close to GPT-5.6 Sol on the Intelligence Index while pricing is roughly 2.5x Sol's. It also states that on its Coding Agent Index, Astra scores equal to Claude Fable 5 at lower cost. Both of those can be true at once, and they are the whole argument. The same model is a poor default for general work and a good deal for agentic coding. Which one you get depends on what you route to it. OpenAI published its own benchmark results at launch, and they are vendor numbers rather than independent ones. Two are worth carrying forward, because the routing argument below turns on them: DeepSWE v1.1 at 74.1%, and the offline subset of OSWorld 2.0 at 72.6% at roughly 40 minutes per task. Both measure long agentic runs, which is the one shape of work where an expensive model can be the cheaper choice. The rest of the launch set is reasoning, maths and science scores that no routing decision here depends on; the system card has them. Greg Brockman, OpenAI's co-founder and president, said "I think it's not unreasonable to feel that we are now in the AGI era" (VentureBeat). That is his opinion about the field, and you can hold whatever view of it you like. Your finance team will still ask about the invoice, and the invoice is arithmetic. One caveat before any of the numbers below. Everything here is the launch price list. Model pricing moves, tiers get added, discounts appear for batch and cached input. Check the current pricing page before you budget anything. Output tokens are where the bill lives Take a service that handles 1,000 requests a day. Each request sends about 4,000 input tokens and gets back about 800 output tokens. This is an illustrative calculation from the published per-token prices, not a measured bill from anyone's account. On Astra's standard tier: - Input: 4M tokens at $10 per 1M = $40 a day - Output: 0.8M tokens at $50 per 1M = $40 a day Eighty dollars a day, roughly $2,400 over thirty days. Read those two lines again. You sent five times as many input tokens as you received output tokens, and the two halves of the bill are identical, because an output token is priced at five times an input token. That ratio is the thing to internalise. Every prompt-engineering instinct you have is about the input side, and the input side is the cheap half. A change that makes responses more verbose is worth far more on the invoice than a change that makes prompts longer. Watch what happens if output per request goes from 800 tokens to 3,000, which is an ordinary consequence of asking for more reasoning in the response: - Input: unchanged at $40 a day - Output: 3M tokens at $50 per 1M = $150 a day The bill more than doubles and your request volume did not move. Nobody wrote a loop. Somebody changed a prompt. The fast tier doubles both sides again, to $160 a day on the original workload. It buys latency. Decide whether the requests that need it are all of them or the 5% a human is sitting in front of. For contrast, running the same workload against a model at the median price Artificial Analysis reports ($2 in, $10 out) comes to $16 a day, or about $480 over thirty days. That is the gap you are deciding about. It is not marginal. Terseness is a discount The nuance cuts the other way. Per-token price is not per-task price, and Artificial Analysis publishes both. On its index run Astra emitted 16M output tokens against a 62M median across the models it tracks: roughly a quarter of the tokens, for a score of 60 against the median's 36. That concision is why its cost per Intelligence Index task lands at $0.96, rather than wherever a $50-per-million output price would put it on its own. Be careful what you take from that. The $0.96 is one benchmark suite, measured against the whole tracked field. The 2.5x is a different measurement, per token, against GPT-5.6 Sol specifically. The two do not multiply into anything. What survives is the shape: a verbose model at a low list price and a terse model at a high one can land much closer on a per-task bill than the price sheet suggests, and the ordering can flip either way. This is exactly why a price-per-million-tokens comparison is a bad way to pick a model. Two models with the same list price can differ by 3x on your actual bill, because one of them thinks out loud and the other does not. And a cheap model that fails validation, gets retried twice and then escalates has cost you three calls plus the expensive one. The number that answers the question is cost per successful task. type Outcome = { usd: number; accepted: boolean; }; export function costPerSuccess(rows: Outcome[]): number { const spend = rows.reduce((s, r) => s + r.usd, 0); const wins = rows.filter((r) => r.accepted).length; return wins === 0 ? Infinity : spend / wins; } Log usd and accepted on every request and you can compute this per model, per route, per customer tier. accepted is whatever "this actually worked" means in your domain: the JSON parsed and passed schema validation, the generated patch compiled, the support reply went out without a human editing it, the extracted invoice total matched the ledger. Run the expensive model on 10% of traffic for a week and compare that one number against the cheap model's. If the expensive model succeeds often enough to beat the cheap model's retry tax, it is the cheaper option and the per-token price was a distraction. Usually it beats it on a slice of your traffic and loses on the rest, which is the case for routing. Route cheap first, escalate on a signal The pattern is a ladder. Call the cheap model. Check the result against something you trust. If the check fails, escalate to the expensive one. Refuse any call that would push the request past a cost ceiling you set in advance. Start with prices and a cost function. // Launch list prices in USD per 1M tokens. // Verify current pricing before you rely on these. export type Price = { inPerM: number; outPerM: number }; export const PRICES = { cheap: { inPerM: 2, outPerM: 10 }, strong: { inPerM: 10, outPerM: 50 }, } as const satisfies Record ; export function costUSD( p: Price, inTok: number, outTok: number, ): number { return (inTok / 1e6) * p.inPerM + (outTok / 1e6) * p.outPerM; } Then the two shapes the router needs: what a model call returns, and what a validation check returns. export type Completion = { text: string; inputTokens: number; outputTokens: number; }; export type ModelCall = (p: string) => Promise ; export type Check = | { ok: true; value: T } | { ok: false; reason: string }; export type Validate = (text: string) => Check ; Check carries a reason on failure. That string is the most valuable thing this system produces. It tells you why the cheap model was not good enough, which is the input to every future decision about whether the escalation is worth paying for. The router's result type is where the design decision lives. A routed request and a refused one carry different fields, so make them separate members of a union keyed on stop . export type Tier = "cheap" | "strong"; export type Routed = { stop: "validated"; value: T; model: Tier; usd: number; attempts: string[]; }; export type Refused = { stop: "ceiling" | "exhausted"; value: null; model: "none"; usd: number; attempts: string[]; }; export type RouteResult = Routed | Refused; The options bag is what the caller configures. refuse builds the refusal half of the union in one place, so the two exit paths that give up cannot drift apart. export type RouteOptions = { prompt: string; cheap: ModelCall; strong: ModelCall; validate: Validate ; maxUSD: number; maxOutputTokens: number; }; const estTokens = (s: string) => Math.ceil(s.length / 4); function refuse( stop: "ceiling" | "exhausted", usd: number, attempts: string[], ): Refused { return { stop, value: null, model: "none", usd, attempts }; } The router itself walks the
Comments
No comments yet. Start the discussion.