GPT-6 Sol and Luna: When Is Astra Still Worth Paying For?

OpenAI launched GPT-6 Sol and GPT-6 Luna on September 22, 2026, three weeks after Astra. One API, three tiers, and a 100x spread between the cheapest and most expensive input tokens. OpenAI describes Astra as its most capable model for the hardest end-to-end work, Sol as built for complex coding and agentic workflows, and Luna as its most efficient model for focused, high-volume tasks. [1] [2]

The interesting question changed shape. It is no longer “which model is best” but “which model, at which reasoning effort, with which verification cost”. A model choice now has three dials, and the launch data shows effort alone can flip a tier comparison. This post works through the rate card, the benchmark evidence, and three cost scenarios, then ends with the routing table I would actually start from. The metric I care about throughout is cost per accepted result, not cost per million tokens, for the same reason as in the Astra pricing post.

The new rate card

Standard short-context pricing per million tokens, checked on the OpenAI API pricing page the day after launch: [3]

	Input	Cached read	Cache write	Output
GPT-6 Astra	$10.00	$1.00	$12.50	$50.00
GPT-6 Sol	$2.00	$0.20	$2.50	$10.00
GPT-6 Luna	$0.10	$0.01	$0.125	$0.50

Astra costs exactly 5x Sol and 100x Luna at equal token volumes, and the ratios hold for cached reads. There is no GPT-6 Terra tier: Sol takes over GPT-5.6 Terra’s old input price of $2, at a lower output price than Terra charged. Note that the “50% cheaper” launch claim compares against GPT-5.6 promotional rates, and GPT-5.6 Sol’s promo price of $4/$20 remains available at least through November 21, 2026, so the comparison baseline matters when you do the arithmetic yourself. [1] [3] [11]

The long-context catch is easy to miss. Once a request exceeds 272,000 input tokens, the higher rates apply to the entire request: input and cache prices double, and output becomes 1.5x the short-context rate. Astra’s long-context output is $75 per million. A 100k-token document stays cheap. Blindly stuffing a 300k-token repository into the prompt doubles your effective input rate for that call. [3] [2]

The rest of the tier structure, from the same page:

Batch and Flex processing cost 50% of Standard rates, with a completion window of up to 24 hours for Batch.
Fast mode costs 2x the applicable Standard rate.
EU data residency for Sol and Luna is available only with Standard processing, and eligible regional processing carries a 10% uplift.

Reasoning effort is the hidden price dial. Sol and Luna support none, low, medium, high, xhigh, and max. Astra starts at low and cannot disable reasoning at all. Reasoning tokens never appear in the answer but are billed as output tokens, so a comparison that counts only visible response length understates the bill. One API constraint matters for migrations: on Sol and Luna, Chat Completions function calling works only with reasoning set to none; OpenAI directs tool-using reasoning workloads to the Responses API. [2] [11]

All three models advertise the same 1,050,000-token context window, 128,000 max output tokens, text and image input, Structured Outputs, function calling, and a broadly similar Responses API tool set. On paper they differ mostly in price. The benchmarks say the differences are real but positioned, not ranked. [2] [11]

What the benchmarks actually say

OpenAI did not publish one score per model. The launch charts plot score against cost per task at every reasoning effort, which is the right way to present a family that shares one scale of effort. A few data points stand out. [1] [11]

On DeepSWE v1.1, Astra scores 74.1% (at xhigh in the cost charts), Sol 68.8% at max, and Luna 66.6% at max. Sol’s best score is below GPT-5.6 Sol’s 72.7% from the Astra launch tables. The upgrade on that benchmark is cost per task, not peak score: Sol reaches 68.8% for $2.74 where its predecessor needed $6.46. On Terminal-Bench 4.0, OpenAI’s launch charts for the new models are absent, and Astra’s launch number is 57.9%. [1] [10] [11]

The most useful single chart is AutomationBench, because it shows effort reversing a tier comparison. Sol at xhigh scores 33.2% for $0.27 per task. Astra at low scores 30.3% for roughly four times as much. That does not establish that Sol beats Astra; it establishes that “Astra vs Sol” without an effort setting is an underspecified question. It also cuts the other way: Luna at low effort scores 2.4% on DeepSWE and 1.2% on AutomationBench, barely usable for agentic work, while Luna at max reaches 66.6% and 20.7% respectively. The cheap model is not uniformly cheap to use; it is cheap at a specific operating point. [11]

The usual vendor-chart caveats apply, and OpenAI supplies the best ones itself. Its research harness may differ from production ChatGPT, competitor figures can come from public reports rather than a common rerun, and the Fable 5.1 comparison in the AutomationBench chart omits the cost of Opus 5 fallbacks that occurred on about 40% of tasks. [11]

Artificial Analysis ran the family through its Intelligence Index v4.3.2 on launch day. Their headline matches the launch framing: aggregate capability stays roughly level with the GPT-5.6 predecessors, with gains on some evaluations and regressions on others, while the price cut halves cost per task. Both new models also consumed somewhat more output tokens per task than their predecessors in that run (31k vs 29k for Sol, 51k vs 41k for Luna), which eats into the price cut. [6]

Selected configurations from their published tables: [7] [8] [9]

Configuration	Intelligence Index	Cost per index task
Astra max	53	$3.26
Sol max	48	$1.06
Astra low	46	$0.82
Sol xhigh	44	$0.53
Luna max	37	$0.07
Sol low	34	$0.13

The Astra-low and Sol-max rows are worth staring at. The supposedly expensive model, run at low effort, lands within two index points of Sol at maximum effort, at $0.82 against $1.06 per task. The new tiers also hallucinate less than their predecessors: Artificial Analysis measured Sol cutting its AA-Omniscience hallucination rate from 92% to 60% at max effort, and Luna from 93% to 77%, with Sol getting there partly by declining to answer more often rather than guessing. [6] [8]

Latency has an even wider spread than price. Artificial Analysis reports time to first answer token of 0.71 seconds for Luna without reasoning, 0.97 seconds for Sol without reasoning, and 2.73 seconds for Astra at low effort. Reasoning changes the picture completely: tokens spent thinking are generated and billed before the first visible token arrives, and at max effort both new models burn tens of thousands of output tokens per task in the index runs. For a real deployment I would measure p50 and p95 time to first answer token and full completion time from the same region, account tier, and prompt sizes the application will use, because none of the public numbers substitute for that. [7] [9] [8]

Three cost scenarios

All three scenarios are mechanical token arithmetic from the rate card, with assumptions stated. They are illustrative, not measured workloads.

Scenario 1: one code-edit attempt

An illustrative agentic edit: 50,000 input tokens, 12,000 total billed output tokens including reasoning. [3]

Model	Cost per attempt
Astra	$1.100
Sol	$0.220
Luna	$0.011

Using the published DeepSWE pass rates as a crude success-rate proxy gives about $1.48, $0.32, and $0.0165 per proxy-success. Treat that with suspicion: it assumes identical token consumption across models, treats a benchmark pass rate as your task’s success probability, and ignores retries, tool loops, effort differences, and your task mix. My earlier DeepSWE post covers what that benchmark does and does not measure. [1] [11]

There is a blunt mathematical implication anyway. Under equal token consumption, Astra costs 5x Sol, so a naive retry-only model would need Astra’s success probability to be more than five times Sol’s before Astra is cheaper per success. Once Sol succeeds more than 20% of the time, that is impossible, because Astra’s cannot exceed 100%. The premium has to earn itself elsewhere: fewer reasoning and output tokens, fewer tool loops, fewer damaging failures, less human review, or better outcomes on tasks where failure has a large external cost.

Scenario 2: document Q&A with a stable prefix

A 100,000-token document plus a 2,000-token answer per question. One uncached request happens to cost $1.10 on Astra, $0.22 on Sol, and $0.011 on Luna. Now ask ten questions against the same document, once uncached and once with a single cache write followed by nine cached reads: [3] [5]

Model	Ten uncached	One write + nine reads	Average per cached answer
Astra	$11.00	$3.15	$0.315
Sol	$2.20	$0.63	$0.063
Luna	$0.110	$0.0315	$0.00315

The cache math is the same for every tier because the multipliers are: writes at 1.25x ordinary input, reads at 0.1x. OpenAI’s own guidance notes that one full write followed by one full reuse costs 1.35x a normal input instead of the 2x you would pay for processing it twice, so a stable prefix pays for itself on the second use. Ten questions without caching cost more than three times the cached version on every tier, which is why repeated large prefixes should never be re-sent uncached. [5]

Scenario 3: one million small classifications

One million requests, each 500 input tokens and 20 output tokens: [3]

Model	Standard	Batch
Astra	>= $6,000	>= $3,000
Sol	$1,200	$600
Luna	$60	$30

The Astra figure is a lower bound because Astra cannot set reasoning to none, so hidden reasoning tokens can only increase the output bill. Sol and Luna can use none if your evaluation shows reasoning does not improve classification, which makes their numbers exact under the stated assumptions. A 500-token request also cannot use prompt caching at all: the minimum cacheable prefix is 1,024 visible input tokens. For offline bulk jobs, Batch is the more interesting discount than Fast mode, at half price with looser limits and a 24-hour completion window. [3] [5] [1]

Where I would start

This routing table is my inference from the pricing and the benchmark evidence, not an OpenAI recommendation. The pattern behind it: route by output verifiability and failure cost, then tune effort on your own workload.

Workload	First model I would test
High-volume classification, extraction	Luna `none` / `low`
Routine document Q&A	Luna or Sol
Normal repository work	Sol `medium` / `high`
Long-running coding agents	Sol first, Astra fallback
Difficult computer-use workflows	Astra, or Sol with a fallback
Weakly verifiable research, synthesis	Astra
Consequential autonomous actions	Astra plus application controls
Offline bulk processing	Luna or Sol through Batch

flowchart TD
    start[Choose the first model to test] --> volume{Is a label or score the entire output?}
    volume -->|Yes, high volume| luna[Luna at none or low effort]
    volume -->|No| verifiable{Is there a cheap way to verify a result?}
    verifiable -->|Tests, validators, labeled data| sol[Sol at medium or high effort]
    verifiable -->|Judgment calls, weak verification| hard{Do failures cost more than tokens?}
    hard -->|Wrong edits, bad actions, expensive unwind| astra[Astra with application-level controls]
    hard -->|Mostly reading and synthesis| mix[Sol first, escalate to Astra on hard steps]
    luna --> measure[Measure cost per accepted result]
    sol --> measure
    astra --> measure
    mix --> measure

Two warnings before trusting the cheap rows. First, the effort point: Luna at low is not the same model as Luna at max, and the difference on agentic benchmarks is the difference between broken and competitive. Test the effort setting rather than defaulting. Second, peak-score tasks remain Astra’s: on DeepSWE, Sol’s 68.8% is still more than five points below Astra’s 74.1%, and on OSWorld 2.0 offline Astra’s 72.6% tops every Sol setting (best: 64.4% at max) by more than eight points. Cheap tiers approximate the flagship at their best effort settings; they do not match it. [11] [13]

Where Astra still earns the premium

Hard agentic work is the clearest case. Astra holds the strongest first-party results on difficult coding, computer-use, and professional-work evaluations, and it wins the peak-score rows even where Sol’s cost efficiency is impressive. When a failed agent run burns twenty minutes of tool calls, leaves the repository in a wrong state, or takes a developer an hour to unwind, the token bill is a rounding error. [1] [10] [11]

Weakly verifiable work is the second case. Code has tests. Structured extraction has validators. Classifiers have labeled data. Cross-document research, ambiguous planning, and long chains of professional judgment mostly do not, and that is exactly the territory OpenAI positions Astra for. Where you cannot cheaply check the output, the model that is more often right is worth more than the model that is cheaper per token. [1]

Long-context reliability is a third, and the one most easily over-trusted. All three models advertise 1.05M context windows, but a window size says what fits, not how reliably the model uses evidence half a million tokens apart. OpenAI’s Astra launch reported 96.3% on its MRCR 8-needle test at 512k to 1M context, against 73.8% for GPT-5.6 Sol. I did not find a first-party Astra/Sol/Luna long-context comparison in the Sol/Luna launch material, so downgrading a 500k-token production workload without a local eval would be premature. [13]

Safety-sensitive autonomy favors the stronger route as well, though the independent numbers complicate the story. OpenAI’s stress tests show large improvements for both new models over GPT-5.6 on coding deception and tool disclosure, but Sol’s warning-circumvention rate barely moved (68.2% to 64.4%), and it sits well behind Astra’s 17.4%. Those are vendor measurements from deliberately adversarial evaluations, not production failure rates. They are still the best available signal, and the signal says: Astra for agents operating near guardrails, and application-enforced permission checks regardless of model. [11]

The last case is the least intuitive: Astra at low effort is a genuinely interesting operating point. Independent measurement puts it within two index points of Sol at max for $0.82 against $1.06 per task, and on AutomationBench the launch charts put Astra-low at 30.3% against Sol-xhigh’s 33.2% at roughly four times the price per task. If your workload needs Astra-tier judgment with Sol-tier budget, test Astra at low effort before settling for Sol at high. [8] [7] [11]

The reverse also holds, and it is where I would have a hard time justifying Astra by default: short classification, schema-constrained extraction, routine text transformation, and large offline batches. The 5x and 100x gaps are too large to pay for capability the task cannot use. The free inference comparison post makes the same point from the other direction: match the model to the job before optimizing anything else.

Caching and migration deserve their own eval

GPT-6 prompt caching is more configurable than a flat discount, and the details change the architecture of a document-Q&A or agent loop. [5]

The minimum cacheable prefix is 1,024 visible input tokens. Writes cost 1.25x the ordinary input rate and reads 0.1x. Implicit caching works out of the box, and explicit breakpoints let you end the cached prefix after stable instructions, examples, tool definitions, or document content, with up to four cache writes per request. Content after your last breakpoint bills at the ordinary input rate, so you can avoid paying a write premium on content that will not repeat.

For GPT-5.6 and later, prompt_cache_options.ttl supports only "30m", which is also the default; reuse refreshes the lifetime, and OpenAI may retain entries longer. Two behavioral details matter for agents. Reordering or rewriting earlier prompt content can break prefix matching, so stable context should stay byte-stable where possible. And reasoning effort can be changed mid-conversation through the supported configuration-update mechanism while preserving the earlier cacheable prefix, which makes a start-cheap-escalate-when-hard pattern viable without rewriting the whole history.

flowchart TD
    req[Request with a stable prefix] --> size{At least 1,024 visible input tokens?}
    size -->|No| nocache[No cache write, full input price every call]
    size -->|Yes| stable{Will the prefix repeat within 30 minutes?}
    stable -->|No| nocache
    stable -->|Yes| write[Write once at 1.25x input rate]
    write --> reuse[Reuse at 0.1x per read]
    reuse --> effort{Reasoning effort must change mid-session?}
    effort -->|Configuration update| keep[Prefix cache survives the change]
    effort -->|Rebuild the prompt| lose[Prefix match breaks, full price again]

Log cached_tokens and cache_write_tokens from the usage response instead of inferring hits from prompt similarity. During migrations, watch those fields alongside acceptance metrics, because a silent caching regression looks like a modest cost increase and nothing else.

One versioning limitation is worth recording. As of September 23, the model pages expose only bare identifiers like gpt-6-sol in their Snapshots sections, with no dated snapshot IDs to pin against. Until those appear, the practical defenses are a representative eval suite, canarying model changes, and logging the returned model information and usage on every call. [2]

A final caution about aggregate benchmark numbers. Artificial Analysis found Sol dropping roughly 100 Elo points in GDPval-AA and Luna about 75, plus a Luna regression in AA-Briefcase, even as index-level scores stayed level. Generation-over-generation “same capability, half the price” headlines are averages over evaluations that moved in both directions. Your eval suite should cover your work mix, not the index’s. [6]

The meter, again

Sol and Luna are a real price cut that moves the cost-efficiency frontier, and for a large fraction of production token volume they make Astra hard to justify. What they do not change is the accounting problem from the Astra post and the Jev post: the rate card prices tokens, the business prices accepted results, and the distance between those two is yours to measure. Three tiers and six effort settings make that measurement more valuable, not less. The team that knows its cost per accepted result can drop 80% of its token spend by routing to Luna and Sol. The team that does not know it will guess, and the guess will be wrong in both directions.

Sources

Sources checked September 23, 2026.