Tests and Comparisons04/08/2026Laboratório de IA12 min readUpdated on 12/09/2026

GPT-5.6 Luna became 80% cheaper: when is it worth exchanging Earth or Sun?

Luna fell to a tenth of the price of Terra. See the break-even point per task, how to account for rework and when Sol still pays off.

Tabela comparando custo, latência e taxa de conclusão entre GPT-5.6 Luna, Terra e Sol

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:

  1. choose the model based on the relationship between quality and cost;
  2. measure Standard latency;
  3. define the maximum acceptable p95;
  4. repeat the same cases in Fast mode;
  5. 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.

Topics in this articlebenchmark de modeloscusto por conclusãoFast modeGPT-5.6 LunaGPT-5.6 SolGPT-5.6 Terrapreços de API