The 80% price cut for the GPT-5.6 Luna changes the order of magnitude of the comparison. With the values in force on August 4, 2026, a call with the same amount of tokens costs Luna one tenth of Terra and one twenty-fifth of Sol. This means that Luna can make mistakes or require rework more frequently and still retain a financial advantage.
This advantage, however, does not automatically make the model better. The relevant number for a real operation is not the price per million tokens, but the cost per completed and approved task — including internal reasoning, retries, human review, latency, and impact of errors.
The practical conclusion is straightforward: Luna should be the first candidate for well-defined, high-volume tasks; Terra continues to be the reference for mixed loads; and Sol should be reserved for tasks in which a gain in quality or reliability compensates for a much greater cost. The final decision needs to be made by testing the flow itself, not just general benchmarks.
What changed on July 30, 2026
The official API changelog reports that, as of July 30, 2026, GPT-5.6 Luna will cost 80% less and Terra will cost 20% less. The Sun had no reduction announced in this update. On the same date, OpenAI replaced the name Priority Processing with Fast mode.
The GPT-5.6 launch page, published on July 9, records previous prices: $1 per million tokens in and $6 out on Luna; US$2.50 and US$15 at Terra; and US$5 and US$30 in Sol. The page itself received a note about the reduction on July 30, although the textual release table still shows the old values.
Current prices for short context are:
| Model | Entry for 1 million tokens | Cache Entry | Write to cache | Exit for 1 million tokens |
|---|---|---|---|---|
| GPT-5.6 Luna | US$0.20 | US$0.02 | US$0.25 | US$1.20 |
| GPT-5.6 Earth | US$ 2.00 | US$0.20 | US$2.50 | US$ 12.00 |
| GPT-5.6 Sol | US$5.00 | US$0.50 | US$6.25 | US$30.00 |
Amounts are charged in dollars and do not include currency conversion, taxes, paid tools or any regional processing surcharges. Prompts with more than 272 thousand input tokens now use higher prices for the entire request.
The cut made Luna ten times cheaper than Terra
The difference does not depend on whether the task uses more input or more output. Luna's two tariffs correspond to 10% of the equivalent Terra tariffs. Compared to the Sun, they correspond to 4%.
Keeping the number of tokens per attempt equal:
- one Terra call costs the equivalent of ten Luna calls;
- one call from Sol costs the equivalent of 25 calls from Luna;
- one call from the Sun costs the equivalent of two and a half calls from Earth.
This produces an unusual break-even point. If Terra solves a task on the first try, Luna could consume up to ten equivalent attempts before just matching the API spend. Against the Sun, there would be up to 25 attempts.
This account does not authorize accepting 24 bad answers. Each failure can tie up a reviewer, delay the user, or produce an operational error. It just shows that, after the cut, the price of the tokens is no longer the main obstacle to the adoption of Luna. The real obstacle becomes the cost of rework.
Price is not quality: results vary by task
The benchmarks published by OpenAI do not indicate a uniform distance between the three models. In some assessments, Terra and Luna are very close; in others, Luna loses a relevant portion of performance.
In Agents’ Last Exam and SWE-Bench Pro, Luna approaches Terra. In the Big Finance Bench, the difference is 15 percentage points. This reinforces that “minor model” is not a sufficient classification: performance depends on the domain, complexity, need for tools, and the criteria used to consider the task complete.
These numbers were released by the supplier itself and do not replace an independent assessment. Nor do they directly measure service in Brazilian Portuguese, reading of national public documents or transformation of data with local formats.
Three Brazilian tasks for a reproducible comparison
A useful assessment should employ inputs similar to those found in production and binary passing criteria. The protocol below covers three payload profiles: short classification, document synthesis and structured transformation.
Task 1: Ecommerce Fulfillment Screening
Assemble 30 synthetic calls in Brazilian Portuguese involving delivery, Pix, exchange, cancellation, address, deadline and damaged product. Do not use real personal data.
The response should return:
- category belonging to a closed list;
- low, medium or high priority;
- next action;
- short justification;
- valid output in the defined schema.
Approval: all valid fields, correct category according to the template and no action contrary to the policy presented in the prompt.
Reference profile for calculation: 1,500 input tokens and 500 total output tokens per attempt.
Task 2: auditable synthesis of municipal notice
Select 30 frozen public excerpts or documents for the round. Each case must require the extraction of dates, requirements, impediments, necessary documents and values, always indicating the page or section of origin.
Approval: all mandatory items present, correct dates, verifiable references and no statements that are not supported by the document.
Reference profile for calculation: 8,000 input tokens and 1,200 total output tokens per attempt.
Task 3: Transforming orders into structured data
Provide 30 synthetic files with dates in Brazilian format, values with decimal point, incomplete addresses, optional fields and masked identifiers. The model must normalize records according to a fixed schema and point out inconsistencies without inventing values.
Approval: Valid JSON, all automated tests passed and no fabricated data.
Reference profile for calculation: 4,000 input tokens and 2,000 total output tokens per attempt.
How much each task would cost before rework
The table below applies current prices to the defined token profiles. The numbers are mathematical scenarios per thousand tries, not measurements of actual use. The total output must include visible tokens and internal reasoning tokens charged as output.
| Task | Luna for 1,000 tries | Land for 1,000 tries | Sol for 1,000 attempts |
| Service triage | US$0.90 | US$ 9.00 | US$22.50 |
| Notice summary | US$3.04 | US$30.40 | US$76.00 |
| Structured transformation | US$3.20 | US$ 32.00 | US$80.00 |
Proportionality remains the same in all three cases: Earth costs ten times Luna and Sun costs 25 times Luna. The actual result may change if a model uses more reasoning tokens, produces longer responses, or requires new calls.
Thought tokens are not visible as text, but appear in usage details and are charged as output tokens. They are already part of the total output and should not be added a second time when calculating the invoice.
The spreadsheet that avoids misleading comparison
Each call must occupy one line. At a minimum, record these columns:
| Field | What to register |
| Date and time | Absolute time of the request |
| Region | Processing region or endpoint |
| Endpoint | Responses or Chat Completions |
| Model requested | gpt-5.6-luna, gpt-5.6-terra or gpt-5.6-sol |
| Model returned | Identifier present in the response |
| Service tier | Standard or Fast |
| Task ID | Set case and version |
| Prompt version | Hash or immutable identifier |
| Reasoning effort | Same value in the main round |
| Entry Tokens | Total reported by API |
| Cached tokens | Cache reading |
| Tokens written in cache | Writing charged |
| Output Tokens | Total, including reasoning |
| Reasoning Tokens | Informative field, without doubling the cost |
| Time to first token | TTFT in milliseconds |
| Total latency | Time until complete response |
| Passed on the first attempt | Yes or no |
| Number of attempts | One, two or three |
| Approved at the end | Yes or no |
| Minute human review | Time actually spent |
| API Cost | Value calculated by use |
| Total cost | API, review and external costs |
The gpt-5.6 alias directs the call to the GPT-5.6 Sol. Therefore, using it in place of the full identifier may accidentally turn a Luna or Terra test into traffic from the more expensive model.
How to run the test
Use 30 cases per task and per model, totaling 270 calls in the initial round. Mix the order of models to reduce the effect of momentary load changes.
Keep constant:
- the content and version of the prompt;
- the endpoint;
- the maximum output limit per task;
- the effort of reasoning;
- the set of tools available;
- the service tier;
- approval rules;
- the processing region;
- the maximum number of retries.
Start with Standard processing and the same level of reasoning, such as medium, for all three models. Once you identify the winner per task, do a second round by reducing the effort by one level. Official migration guidance recommends comparing models with configurations representative of real flow, including the possibility of achieving similar quality with less thought.
In the main round, prevent cache differences from distorting the result. In GPT-5.6, cache writes cost 1.25 times the normal entry fee, while reads are discounted. The test can disable implicit writing or separately measure a second round with reused prefixes.
The correction must be made without revealing to the evaluator which model produced the response. Pass or fail criteria tend to be more reliable than vague grades, and any automated grader should be compared with human labels before replacing review.
The four metrics that decide migration
First attempt completion rate
Is the percentage of cases approved without correction or new call.
This metric shows how much work the model delivers without intervention, but does not capture the possibility of cheap recovery.
Completion rate within budget
Define a limit in advance, such as three attempts or a certain value per case. Count how many tasks were approved before reaching this limit.
A model can present an inferior initial result and still win because it corrects its own errors at low cost.
Cost per completion
Use:
Cost per completion = total API spend ÷ number of approved tasks
For a more complete operational assessment:
Total cost per completion = API + human review + infrastructure + expected impact of failures
It is this second account that prevents a false migration. Saving pennies on tokens is not worth transferring conference hours to the team.
P50 and p95 latency
Median shows typical experience. The 95th percentile reveals the behavior in the slowest cases.
Separately record time to first token and time to completion. The OpenAI documentation notes that most of the latency tends to be in generating the output, which is why longer or more thoughtful responses may take longer.
The point of balance between Luna, Earth and Sun
When the composition of tokens is similar, the expected cost of a task can be simplified as:
Expected cost per success = cost per attempt ÷ probability of success
Three mathematical limits arise from this:
- Luna is cheaper than Terra if its success rate is greater than 10% of Terra's rate;
- Luna is cheaper than Sol if its success rate exceeds 4% of Sol's rate;
- Earth is cheaper than Sun if its success rate is greater than 40% of the Sun's rate.
If Terra completes 90% of cases, for example, Luna would only need to surpass 9% to maintain an advantage in gross API spend. This result seems permissive because it still does not include human labor or the harm associated with an incorrect answer.
In practice, migration should require that the cheapest model remains within a team-defined quality, latency, and review tolerance. An operation with mandatory human approval can be more tolerant of cheap mistakes. Automation that publishes, transfers values or changes systems needs much stricter limits.
When to choose GPT-5.6 Luna
Luna should be the first model tested when the task has:
- short answer and rigid format;
- objective approval criteria;
- high volume;
- low failure cost;
- possibility of automatic validation;
- well-defined prompt and context;
- simple recovery by a second attempt.
Classification, extraction, routing, data normalization, and closed policy-based responses are natural candidates. Official guidance describes the Luna as the model in the family optimized for cost-sensitive, high-volume cargo.
When Terra continues to make sense
Land is the most important control in the test because it represents the balance between cost and capacity. It costs ten times more than the Luna, but still costs 60% less than the Sol.
Terra tends to justify the award when:
- Luna loses important criteria on a recurring basis;
- the content requires a synthesis of several instructions;
- there is moderate use of tools;
- the answer must combine text and structure;
- Luna's human rework beats API economics;
- flow mixes simple and difficult cases without a reliable router.
An efficient architecture can route most of the volume to Luna and reserve Terra for cases disapproved by validators or identified as more complex.
When to pay for the Sun
Sol costs 25 times Luna and two and a half times Terra in the same token composition. This award should only be accepted when the additional capacity produces measurable value.
Use it as a candidate for:
- complex multi-step tasks;
- highest impact programming and debugging;
- analysis with different tools;
- decisions that are difficult to recover;
- documents that require global consistency;
- cases in which a failure costs much more than the call;
- evaluation or review of results from smaller models.
The templates page positions the Sol as the frontier option for complex professional work, while the documentation recommends the smaller templates to reduce cost and latency.
Fast mode must be tested after the model
Fast mode costs twice as much as Standard processing. For short context, entry and exit prices become $0.40 and $2.40 on Luna; US$4 and US$24 at Terra; and US$10 and US$60 in Sol.
OpenAI claims that on GPT-5.6 Sol, the mode can reach 2.5 times the speed of Standard processing and offer more consistent latency. This number is a limit announced by the supplier, not a guarantee for every request nor an equivalent promise for Terra and Luna.
The correct sequence is:
- choose the model based on the relationship between quality and cost;
- measure Standard latency;
- define the maximum acceptable p95;
- repeat the same cases in Fast mode;
- pay double only if the observed gain justifies the value.
The service can also temporarily downgrade requests to Standard speed when traffic grows too quickly. In these cases, the response informs the tier actually used and the charge follows the Standard rate. Therefore, the benchmark needs to record the returned service_tier, not just the requested one.
Verdict: don't change a model, distribute the tasks
After trimming, Luna should enter virtually every defined load and high volume test. The price difference is too big to ignore, especially when there is automatic validation and cheap retries.
This does not mean replacing Earth or Sun en bloc. The most efficient strategy tends to be task routing:
- Luna for volume, structure and low risk;
- Ground for mixed loads and intermediate complexity;
- Sol for hard exceptions, high-value review, and expensive failures;
- Fast mode only where measured latency violates a service objective.
“80% cheaper” answers how much a try costs. The matrix answers what really matters: how many attempts, how many minutes and how many dollars are needed to deliver an approved task.
Save this matrix and repeat the round whenever prices, versions or configurations change. Subscribe to the newsletter to receive the next review of values and criteria. Any commercial or affiliate links must be explicitly identified.





