GPT-6 Sol and Luna Cut the Cost of Trying. Build for Acceptance.

A thousand attempts at a task can now cost $1.50 on GPT-6 Luna or $30 on GPT-6 Sol, before tools and retries. That is the arithmetic for a fixed workload—not a claim that the models finish the same work equally well. The gap makes a previously awkward product question worth asking: how much should you spend trying, and how much should you spend checking?

OpenAI released GPT-6 Sol and GPT-6 Luna on September 22, with Standard short-context API rates of $2/$10 and $0.10/$0.50 per million input/output tokens respectively. Work and Codex are getting the models too; ordinary Chat is not part of this rollout.

Our Astra analysis argued that the flagship should earn its place on difficult jobs. Sol and Luna change the question underneath that recommendation. Builders now have much cheaper GPT-6 starting points, but the best route depends on whether success is easy to recognize, whether context stays cached, and how much repair the first attempt creates.

RohitAI’s read: this release rewards products that can cheaply distinguish a correct result from a convincing attempt. Lower inference prices increase the value of a good acceptance check.

The price ladder has changed; the bill has more than four numbers

Here are the direct API rates in US dollars per million tokens, using Standard processing and prompts up to 272,000 input tokens. These are billing categories, not additive charges on the same input token. OpenAI’s current pricing table supplies the rates.

Sol halves its predecessor’s input and output prices. Luna halves input pricing and cuts output pricing by about 58%, not exactly 50%. Sol also matches GPT-5.6 Terra’s fresh-input price while charging less for output. That makes Terra an obvious route to re-evaluate, not a model OpenAI has announced it is retiring.

For the opening example, assume 1,000 uncached requests, each with 10,000 input tokens and 1,000 total billed output tokens. The resulting token charges are $1.50 for Luna, $30 for Sol and $150 for Astra. This is RohitAI’s arithmetic at the listed rates. It excludes cache writes, tool fees, retries, regional premiums and changes in token consumption.

The phrase total billed output matters. Hidden reasoning also consumes the output budget and is charged as output. A short final answer can conceal a much larger generation bill; an insufficient output limit can produce an incomplete response. The reasoning guide documents both behaviors.

There is also a sharp context threshold. Above 272,000 input tokens, Sol and Luna reprice the entire request at twice the input/cache rates and 1.5 times the output rate. Under Sol’s documented rule, the input-only charge for 272,000 uncached tokens is $0.544; for 273,000 it is $1.092. An extra thousand tokens can more than double that part of the bill.

Batch and Flex halve Standard rates; API Fast doubles the applicable rates. Regional processing adds 10% where available, and Sol/Luna EU residency is Standard-only. Do not combine every advertised discount into a route that does not exist. The model pricing conditions spell out those boundaries.

Luna’s strongest opening is work you can reject cheaply

A lower price is most useful when a failed attempt is cheap to identify and discard. Consider an invoice extractor: schema validation checks the result’s shape; arithmetic checks the total; source references help check which invoice supplied the amount. None alone proves correctness, but together they can make an acceptance decision much cheaper than rereading every document.

Compare that with asking an agent to untangle a poorly documented service incident. A plausible explanation can be wrong in ways that require an experienced engineer to uncover. The inexpensive first pass may create a review obligation larger than the inference saving.

Here is a deliberately simplified routing model. Let a Luna attempt cost 5% of a Sol attempt—the ratio under identical token usage at their listed rates. Let p be the fraction of Luna attempts that are correctly accepted, and V the verification cost for each attempt. Assume every rejected result receives a full Sol retry.

Luna-first cost = 0.05 × Sol cost + V + (1 − p) × Sol cost

Luna-first beats direct Sol when:
p > 0.05 + V / Sol cost

With negligible verification cost, a correctly accepted fraction above 5% clears this narrow cost test. If verification costs half as much as a Sol attempt, the threshold rises above 55%. The model excludes handoff overhead, latency penalties and undetected errors, and assumes the same eventual acceptance standard. It is a way to identify what to measure, not permission to tolerate a 95% failure rate.

The non-obvious opportunity is the acceptance layer. A team with inexpensive domain checks can benefit from Luna even without assuming Sol-level quality. A team that needs another expensive model to judge every answer may capture much less of the tariff advantage.

• Try Luna first: bounded extraction, document tagging, mechanical transformations and small code edits with independent acceptance checks.

• Start with Sol: multi-file debugging, competing requirements and tasks where understanding the problem dominates execution.

• Escalate selectively to Astra: hard cases where your own evaluation shows its additional capability pays for the extra spend.

Use structured handoffs: source locations, artifacts, failed checks and unresolved assumptions. Passing a confident summary from a cheap worker to an expensive reviewer can hide exactly the evidence the reviewer needs.

Affordability also does not grant throughput. The Sol and Luna references both list Tier 1 at 500,000 tokens per minute. Luna’s tariff is one-twentieth of Sol’s, but an entry-tier application cannot assume twenty times the traffic. Queueing and tool-executor capacity may become the next bottlenecks.

A warm cache changes the Claude comparison

The relevant competitor is not just the Opus 5 checkpoint in OpenAI’s launch charts. Anthropic released Opus 5.5 on the same day. Sol is cheaper on fresh input and output, but the cache comparison is closer.

This table puts the principal alternatives beside Sol and Luna. Prices are Standard US dollars per million tokens, excluding cache creation/storage, tools and processing premiums. OpenAI entries use short-context rates. Sources: OpenAI pricing, Anthropic pricing and Google pricing.

Suppose a warm request contains 90,000 cached-input tokens, 10,000 fresh-input tokens and 1,000 billed output tokens. Sol costs $0.048; Opus 5.5 costs $0.078. Sol is about 38.5% cheaper in this scenario, not 50%, because the largest input category has an identical rate.

That calculation assumes identical billable token counts, no new cache writes, and no additional fees. It is a tariff comparison, not a matched-text benchmark: tokenizers and reasoning usage can differ. As cache reads dominate and fresh generation shrinks, the percentage saving narrows further.

A router should know the shape of the next request, not just the model’s sticker price. For a mostly cached repository conversation, compare cache behavior and successful completion. For a fresh document-processing job, base input pricing has more weight. For a long generation, output and reasoning usage can dominate.

Sol’s matching base rates with Sonnet 5 also mean there is no fresh-token discount to justify that switch by itself. You need better acceptance, lower token consumption, lower latency or a product capability that matters to the workflow.

Luna undercuts Gemini 3.8 Flash on these token rates, while Sol remains more expensive. Google’s $0.75/$3.75 Flash promotion runs through December 31, with $1.50/$7.50 scheduled from January 1, 2027; cache storage is a separate charge. Reprice recurring jobs when that schedule changes. Google’s published schedule is more useful than an undated comparison chart.

Do not flatten the modality difference either: Flash accepts audio and video input as well as text and images. Sol and Luna’s native contract is text/image input and text output. A cheaper text route is not automatically a replacement for an audiovisual pipeline.

Read our Opus 5.5 analysis for its integration changes, and the Gemini 3.8 Flash piece for the earlier cost-efficiency argument. Sol/Luna add new candidates; they do not settle those workload-specific comparisons.

Raise effort within a phase before rebuilding the whole route

Cache reuse creates another reason to avoid switching models reflexively. The GPT-6 guide documents an appended configuration_update item for changing reasoning effort while preserving the earlier prompt prefix. The new effort remains in effect until changed again.

This is different from rewriting the original configuration or earlier conversation. Preserve the original request-level effort and apply the supported update at the new point in the conversation. Likewise, stable tool definitions with controlled availability are different from editing schemas every turn. OpenAI’s caching guide explains why prefix stability matters.

For a repository task, an experiment worth running is to keep Sol through investigation, implementation and review, increasing effort for the difficult part. Compare that with a Luna-to-Sol handoff carrying explicit evidence. Do not assume another model inherits the same cache or hidden reasoning state.

Our hypothesis: the economical unit of routing may be a coherent work phase, not an individual message. A slightly more expensive model can win if staying put avoids repeated context processing and reconstruction. The result needs measurement; the documentation establishes the control, not the saving.

Caching also has a first-use cost. At a 1.25× write rate and 0.1× read rate, writing a reusable prefix once and reading it once costs 1.35 uncached-input equivalents instead of two. That advantage depends on an actual eligible reuse. Put timestamps and frequently changing material after stable instructions, and inspect misses instead of budgeting every prompt at the read price.

The launch charts support a trial, not a universal winner

OpenAI’s launch announcement reports an attractive cost-quality tradeoff. Keep the model versions, effort levels and scoring rules attached to the numbers:

These are vendor-reported comparisons, not RohitAI measurements. The announcement also notes different evaluation environments and the use of publicly reported competitor results. No matched production test was run for this article.

Two methodological details are especially useful. AutomationBench grades the resulting business state, requiring all scored assertions to pass, rather than trusting the final message. OSWorld distinguishes partial progress from binary completion. An agent can accumulate useful progress without finishing the job.

And Epoch’s September 7 DeepSWE audit found false-negative issues in at least 23 of 113 tasks. That is a reason to be cautious about small score gaps, not a license to invent corrected scores or dismiss unrelated evaluations.

For a builder, the useful comparison is whether the right artifact or business change survived the whole run. A better-looking final answer is insufficient evidence.

The API migration has an endpoint trap

Use the exact identifiers gpt-6-sol and gpt-6-luna. OpenAI’s Python 3.18.0 and Node 7.22.0 releases add those names. SDK recognition is integration evidence, not account authorization.

Both models document 1,050,000 tokens of total context, a maximum input of 922,000 tokens and maximum output of 128,000. That is not 1.05 million input tokens plus another 128,000 output tokens. Both support streaming, structured outputs and six reasoning efforts: none, low, medium, high, xhigh and max, with medium as the API default. The Sol reference lists the limits.

The important compatibility restriction: Chat Completions function calling requires reasoning_effort=none. Use Responses for tool-using reasoning workflows. Its documented tools include web/file search, shell, computer use and MCP. Image generation is a tool, not native image output from these text models. The Luna reference distinguishes supported endpoints from tools.

Before changing a production model string, exercise the full tool loop: dispatch, error handling, continuation and final acceptance. A successful request that produces a tool call is not a completed operation. This is the same model-versus-execution distinction in our Agents API analysis.

Work-first availability is a deployment event

The September 22 product changelog separates entitlement from rollout and client support. Here is the practical access map at publication:

Enterprise defaults are not permissions, and local model selection does not override workspace restrictions. Hosted Codex workflows have their own model support; a local picker is not proof that every cloud job has moved. Workspace model availability explains these boundaries.

Billing differs too. Work and Codex share usage, and supported GPT-6 Fast mode consumes 2.5× Standard credits, versus 2× pricing in the direct API. Codex credit billing has no separate cache-write charge. Credit purchase terms vary, so do not turn a credit table into a universal dollar conversion. The product pricing guide is the relevant reference.

The migration deadline has not moved: GPT-5.5 is scheduled to retire from ChatGPT, Work and Codex on October 14, but not from the API. What changed is the recommended destination. Current guidance points eligible paid users toward GPT-6 Sol and Free/Go users toward desktop Luna.

That updates the replacement choice in our earlier retirement guide. Teams that already changed a saved default to GPT-5.6 Sol should evaluate the new option, without treating the still-available GPT-5.6 family as retired.

The distribution bet, in our reading: OpenAI can make this release commercially useful inside existing work queues before it appears in ordinary Chat. The immediate test is whether customers finish more worthwhile tasks inside their budgets, not whether every user notices a different chatbot.

The canary I would run this week

Start with a bounded sample from real traffic: invoice-style extraction, evidence-grounded summaries, repository fixes, multi-tool business workflows and long-context continuations. Include known failures and ambiguous inputs, not only clean examples. Compare the current production route against Sol and Luna at explicitly recorded efforts.

1. Define acceptance before running. For extraction, verify values against source material as well as schema. For code, use independent tests and scope review. For tool workflows, inspect final state and unintended changes. Keep a route to abstention when evidence is missing.

2. Hold the task constant, not the token count. Feed equivalent source material and requirements to each route; let actual token usage differ. Record model, effort, tools, processing tier and harness version so a price difference can be explained.

3. Charge failed attempts to the experiment. Measure total inference and tool spend divided by accepted results, alongside human review minutes. Include rejected attempts, retries and handoffs. Track undetected errors separately rather than hiding them inside an average.

4. Separate cold starts from continuations. Measure cache reads and writes, then test a realistic interruption or changed tool configuration. Include cases on both sides of the 272K threshold. A retrieval or compaction policy should consider lost information and cache reuse, not just prompt length.

5. Test the queue, not only one request. Measure end-to-end latency at intended concurrency, including tool execution and rate-limit backoff. Lower token prices cannot rescue a workflow that times out in an external system.

6. Roll out by task class. Move the clearly verifiable wins first. Keep the prior route available while inspecting regressions. Preserve the same action permissions during the model trial so a quality comparison is not confounded by broader authority.

For example, a support workflow can use Luna to classify a ticket and extract candidate account details, while a deterministic lookup confirms the account before anything changes. If the evidence conflicts, hand the unresolved case to Sol. The benefit comes from separating a cheap proposal from an authorized update—not merely adding more agents.

Over the next month, watch three outcomes: how many Luna proposals pass independent checks, how much Sol continuation cost changes with a warm cache, and whether saved Work/Codex jobs actually use the intended replacement. Those observations will be more actionable than a single overall win rate.

Questions worth settling before changing a default

Should every GPT-5.6 Terra workload move to Sol?

No automatic migration follows from the price table. Sol’s tariff makes it a strong candidate, but Terra remains available. Compare latency, acceptance and changed behavior on the tasks Terra currently handles well.

Can Luna replace Sol for extraction?

It is a sensible experiment when correctness is cheap to check. Well-formed JSON is not proof of a correct customer, date or amount. Escalate on contradictory evidence and measure the review burden.

Does max effort guarantee the best value?

No. More reasoning can improve a difficult result while increasing generation cost and latency. Compare accepted outcomes at explicit efforts. Work/Codex Ultra is also not a seventh API effort value; the product guide describes it as orchestration beyond a single-agent run.

Spend the saving where uncertainty remains

Sol and Luna give builders room to redesign the first attempt. Luna is worth testing where a correct result is recognizable at low cost; Sol is a plausible everyday reasoning route; Astra still needs to justify escalation on the hard remainder.

My prediction is that the strongest early deployments will be selective: verified extraction and bounded repository work, with effort changes inside stable phases and explicit evidence at handoffs. That is an adoption hypothesis, not a measured market trend.

The price cut is real. The useful product advantage comes from deciding which uncertainty can be handled cheaply, which deserves more reasoning, and which still needs a person.