GPT-6 Astra launches at 2.5 times Sol’s token prices

OpenAI released GPT-6 Astra on September 3 across ChatGPT, Codex and the API, with standard token rates 2.5 times GPT-5.6 Sol’s current promotional rates. For developers tackling difficult coding work, an independent benchmark offers a reason to try it anyway: Astra’s higher completion rate more than offset its larger total bill when measured by approximate cost per resolved task.

On Snorkel’s Terminal-Bench 4.0 leaderboard, which tests software-engineering and systems work in a terminal, Astra using Codex at maximum reasoning effort resolved 58.2% ±2.8 of tasks, against Sol’s 37.3% ±3.8. That is a 20.9-percentage-point gain using the same agent. It measures the model working inside Codex, rather than the model alone.

The economics are more interesting than the score alone. Across the 66-task benchmark, Astra used about 1.5 billion tokens and cost roughly $3,300; Sol used 4.4 billion and cost about $2,500. Dividing those rounded bills by the expected number of resolved tasks gives approximately $86 per resolution for Astra versus $102 for Sol. That is our calculation from aggregate results, not reported per-task billing. It does not separately account for latency, human intervention or whether a team would accept the output.

Those results make Astra worth testing where an unresolved task already consumes expensive engineering time. They do not establish that Astra saves money on routine code edits or office work. The Astra model page and Sol model page show the premium teams must recover through better results or lower token consumption.

Sol’s promotional prices are listed through at least November 21, 2026. Astra API requests exceeding 272,000 input tokens also trigger a surcharge across the whole request: twice the input and cached-input rates, and 1.5 times the output rate. Astra use in Codex has a documented exception from that multiplier. Tool calls, cache writes, speed tiers and regional processing can add charges.

Astra also changes how developers can supervise a long task. OpenAI’s model guidance describes asynchronous custom tool calls, allowing the model to continue independent work while a tool runs, and mid-turn steering over a Responses WebSocket, allowing corrections without discarding completed work. A developer can also change reasoning effort through configuration_update items while preserving the cached prompt prefix. The application still executes tools and manages pending results; steering requires the documented WebSocket event flow, and mutable effort has compatibility limits and is documented for standard single-agent requests.

That extra flexibility comes with a consequential deployment detail. OpenAI’s misalignment monitoring, which checks whether an agent is acting outside the user’s instructions, can stop supported Responses conversations that preserve their trajectory through persisted reasoning, WebSockets or OpenAI compaction. Stateless Responses requests remain monitored but chiefly produce webhook alerts. Chat Completions is outside this particular monitor, although other safety checks may apply.

The monitor runs asynchronously. A harmful external action can finish before it intervenes, and stopping the conversation does not undo that action. API stops return 403 and have no general resume path. OpenAI has not published production rates for missed detections, false alarms or intervention latency. Our deployment recommendation is to retain human approval for consequential actions and enforce permissions in the application.

For knowledge workers, the evidence is less decisive. OpenAI’s work launch describes improvements in spreadsheets, presentations and financial analysis, supported by company evaluations, demonstrations and customer statements. Those statements are not independent replication; most lack representative raw outputs, correction counts and matched operating costs. One independent spreadsheet case study found Astra passed 12 of 12 initial checks while Sol passed 10 and needed one correction. Both ultimately passed. Astra’s first response took longer, and the test used a spreadsheet runtime rather than native Excel, different retrieval paths and no repeated-trial or per-run cost measurement.

Access also needs checking before a pilot. OpenAI’s Enterprise documentation says Astra initially requires Daybreak access and is disabled by default for the first two weeks; entitlement and rollout vary by surface. Its deployment guidance recommends starting with a limited group and a recurring workflow, measuring quality, rework, completion, time and billing impact. We would use that pilot to answer one question: does Astra reduce the cost of work your team actually accepts?