OpenAI Cuts Agent Costs With GPT-6 Sol, Luna and Better Caching

An agent can spend a surprising amount of its budget rereading the job. The instructions, tool descriptions and accumulated context travel through repeated requests while the work continues. OpenAI's September 22 releases target both sides of that expense: cheaper GPT-6 Sol and Luna models, plus better reuse of computation already performed. For a builder deciding whether an agent belongs inside a real product, the combination matters more than another isolated leaderboard victory.

The new models extend the GPT-6 family beneath Astra. OpenAI lists Sol at $2 per million input tokens and $10 per million output tokens under standard short-context pricing. Luna is $0.10 and $0.50, respectively. Those are API rates, not a subscription price or an estimate of what a finished task costs. The pricing page separately lists cached input, cache writes, longer contexts and other processing tiers. A budget that ignores those distinctions can be precise to the cent and still be wrong.

The accompanying caching announcement concerns work the model has already done with an unchanged beginning of a request. OpenAI's technical guide describes preserving intermediate key-value states, rather than storing a completed answer and handing it back. New material still needs processing and a new response still needs generation. The useful mental model is reuse of preparatory computation. It is not a permanent notebook, and it does not make an agent remember facts that the application never supplies.

That creates a different engineering question from simply choosing the cheapest model: how much of the job changes between requests? An application with stable instructions and new evidence offers a different reuse opportunity from one that rewrites its opening context every time. Before optimizing, identify which repeated information still serves the task and which is merely baggage.

OpenAI describes improved default cache hit rates and a 30-minute window for eligible shared prefixes, alongside a dashboard, diagnostics, explicit cache breakpoints and prewarming. A breakpoint identifies the end of context intended for reuse. Prewarming prepares known context before the user needs the response. Neither feature removes the need to measure the actual workload. Processing something early can improve responsiveness, but it is not automatically useful if the anticipated request never arrives.

The price-cut headline also deserves careful arithmetic. The announcement compares Sol's new rates with its predecessor's promotional rates of $4 input and $20 output. Both halve. Its table moves Luna from $0.20 to $0.10 for input, but from $1.20 to $0.50 for output. That second reduction is about 58 percent, not exactly 50 percent. More importantly, a percentage attached to a token category is not a promise that the total operating bill falls by the same amount.

Consider an explicitly hypothetical workload: a 20,000-token prefix reused across 20 Sol requests, all eligible for the standard short-context rates. Processing that prefix afresh on every request would cost $0.80. At the listed cache-write rate of $2.50 per million tokens, the first write would cost $0.05. Nineteen complete reads at $0.20 per million would add $0.076. The prefix total becomes $0.126, an 84.25 percent reduction compared with processing that same prefix 20 times without caching.

That calculation is deliberately narrow. It assumes a matching, available cache entry on every later request. It excludes changing input, generated output, tools, retries and human review. It is not a customer result or a prediction of anyone's monthly invoice. Its value is showing where the leverage comes from: repeated processing can dominate one portion of a workflow, so changing how that portion is billed can matter more than squeezing a few words from the final response.

There is also a cost to writing context that will never be reused. OpenAI's guide explains that the cache-write rate replaces the ordinary input rate for those tokens; it is not an additional fee stacked on top. Explicit breakpoints let developers avoid writing a changing tail unnecessarily. That suggests a practical experiment: compare the default behavior with deliberate boundaries around genuinely stable material. Do not add caching controls merely because a launch announcement makes them sound like an obligatory architecture upgrade.

The new diagnostics compare a request with an earlier response to identify changes in the model, tools, settings or input that prevented reuse. The comparison does not retrieve the earlier conversation or repair the cache. Actual usage fields measure reused tokens. Diagnosis and recovery remain separate jobs, even when the interface makes them look adjacent.

Teams can investigate regressions by comparing representative requests and testing whether an adjustment restores reuse. The feature is best effort and reports the first classified reason, so one explanation may not exhaust the problem. OpenAI says diagnostics themselves cost nothing extra, while additional baseline or retry requests are billed normally.

Cache efficiency should not become an excuse to preserve the wrong instructions. A policy change, an updated permission boundary or newly corrected evidence can be more important than a cache hit. The appropriate question is whether the application can preserve stable context while representing the change accurately, not whether it can keep an attractive percentage green. Reuse is an optimization inside the product's correctness requirements. It should never be allowed to quietly rewrite those requirements.

OpenAI reports roughly half as many Sol mistakes on an internal factuality evaluation, but says the conversations were selected because users had flagged earlier errors. The set is not representative of typical usage. That makes it a stress test of known trouble spots, not an independently established everyday error rate or a reason to remove verification.

A separate view comes from Zapier's AutomationBench. Its published 1.0.6 leaderboard lists GPT-6 Sol at xhigh effort with a 33.2 percent score and a $0.27 cost per task. At max effort, the displayed result is 32 percent at $0.34. Those entries do not establish that more effort is universally worse. They do establish that this table is not a simple staircase where every additional unit of spending buys a better observed result.

Zapier tests workflows across simulated business applications and grades the final state with deterministic assertions. Its headline measure requires all scored conditions to pass, while partial credit is diagnostic. That is a materially different test from asking whether a response sounds competent. It also means the score should not be translated into a claim that Sol succeeds at precisely one-third of all office work. The benchmark defines a particular task distribution, environment and success standard.

For a company deploying an agent, the transferable lesson is to inspect what changed in the system of record. Did the intended account get updated? Were prohibited recipients left out? Was an instruction satisfied completely rather than approximately? Those questions make failure observable without asking another fluent model to admire the answer. They are proposed acceptance criteria, not evidence that every workflow can be reduced to the same simple pass-or-fail test.

Cognition's FrontierCode provides another useful boundary. Its methodology asks whether a maintainer would merge the resulting change, considering correctness, tests, scope discipline, style and repository standards. It combines tests with rubrics and other verifiers. The benchmark also distinguishes legitimate internet research from consulting solution-bearing material, which receives a zero. This broader definition of a successful code change is more relevant to a shipping team than raw output volume, even though rubric-based judgments still involve choices about quality.

That leaves a cost category the launch prices cannot settle: acceptance. A cheaper attempt that needs substantial correction may be less economical than a more expensive attempt that can be used. Conversely, paying for the largest model on a narrow extraction task may buy capability the task never exercises. The sensible experiment compares models on the same representative work, with the same tools and acceptance rules, and records both failures and the effort required to recover.

A useful internal comparison would therefore keep several measurements separate: model charges, elapsed time, tool spending, correction time and accepted outcomes. Combining them too early can hide the reason a change helped or hurt. A team might discover that caching improves the bill while leaving quality unchanged, or that a different model reduces review time enough to justify higher inference cost. These are hypotheses to test, not performance results established by today's releases.

Availability needs care. OpenAI lists Sol and Luna in Work and Codex for eligible paid plans, and Luna in the desktop app for Free and Go, but says neither is yet in Chat. TechCrunch instead reports an expected Chat rollout through the day. The API names are gpt-6-sol and gpt-6-luna. Product access should not be assumed universal.

The diagnostics documentation also notes that compacting context can reduce reuse while saving money through fewer input tokens. That tradeoff belongs in the evaluation. Carrying irrelevant material just to improve a cache statistic would optimize a reporting artifact rather than the work. The right objective is the useful cost of the job.

OpenAI has made a concrete offer: lower rates for two model tiers and more control over a recurring source of agent expense. The strongest response is neither automatic migration nor reflexive dismissal. Run an existing, well-defined workload against the new economics, preserve its acceptance standard and measure the entire path to a usable result. If the same work becomes dependable at a lower cost, expand it. If only the token bill improves, keep the claim that narrow.

LaunchPad positionMeasure cost per accepted outcome, including cache writes, retries and review, before treating a token-price reduction as a workflow saving.