GPT-6 Sol and Luna change the agent cost calculation

The next incident update repeats the same instructions and background, then adds new evidence. Prompt caching lets a model service reuse work for that unchanged beginning. Sol and Luna charge more to write it into the cache than to read ordinary input, then much less for later reuse. The first update pays for something the next ones may use.

OpenAI announced the models on September 22 alongside prompt-caching changes. The API identifiers are gpt-6-sol and gpt-6-luna; the announcement also describes a gradual rollout in ChatGPT Work and Codex. For a team already using model-generated summaries, comparing the same cases should include revisions that restore omitted evidence, the accounting question developed in our agent observability analysis.

What each rate buys

The standard prices below are in dollars per million tokens, rechecked October 20, 2026. The model pages for Sol and Luna distinguish ordinary input from cache writes and reads, while output has its own charge. The calculation uses these exact model identifiers; rates for a newer Sol or Luna release are a different comparison.

Model	Input	Cache write (30m)	Cache read	Output
GPT-6 Sol	$2.00	$2.50	$0.20	$10.00
GPT-6 Luna	$0.10	$0.125	$0.01	$0.50

Use the listed rates as a starting point, not a quote for every request. Both model pages describe higher rates above 272,000 input tokens, regional premiums, and processing-tier differences; tools can add charges too. The rate that matters is the one applicable to the actual request, not the most attractive cell in the table.

Why a more expensive write can still save money

OpenAI’s caching documentation describes reuse for a matching prefix, the unchanged material at the beginning of a prompt. Put the stable instructions and background first, followed by the new incident evidence. An explicit breakpoint marks where the reusable portion ends. For these two models, the default 30-minute cache write costs 1.25 times ordinary input and a read costs 0.1 times. These write rates replace the ordinary input charge for those tokens; they are not an extra surcharge. Changed input and newly generated output still carry their own charges.

The Responses API also offers a 12-hour minimum cache lifetime, with writes charged at 2.5 times ordinary input. Reads keep the same rate. That longer lifetime can help when updates arrive hours apart, but it doubles the write cost used below. A requested lifetime is not a deletion deadline.

An illustrative 10,000-token Sol prefix with the default 30-minute lifetime makes the tradeoff inspectable. Ordinary input costs $0.02, a cache write $0.025, and a complete read $0.002. One write followed by nine full reads therefore costs $0.043 for the prefix, compared with $0.20 for ten ordinary input charges. The attractive result depends on those nine reads actually matching the full prefix. It excludes changing input, output, tools and failed attempts, so it should not be presented as the price of ten completed tasks.

The premium earns its way back only when later requests match the saved beginning. Change that prefix each time and the ten-request example no longer applies. Keep it stable but repeatedly repair omitted evidence, and the cache can work while the whole job disappoints.

Correction work can consume the token saving

In a hypothetical incident-summary pilot, two models receive the same evidence bundle, but one repeatedly omits an unresolved dependency. The provider bill looks better. The reviewer then has to find the missing dependency, repair the summary, and check the update again. The token saving can be real while the next person in the workflow gets more work.

Suppose the reviewer sends that summary back with the missing dependency marked. The next answer may reuse the background successfully and still incur new input and output charges. It is a second attempt at the same update, not a second completed handoff. Keeping its model, cached and uncached input, output, retry, accepted result and correction minutes together makes that visible. Repeat-background cases belong beside genuinely new evidence, with the acceptance and service checks held steady.

When the corrected summary finally preserves the dependency, it contributes one accepted task. Both attempts contribute to provider spending, which is divided by the accepted count and shown beside it. If the reviewer still cannot accept the summary, that count does not increase; if no tasks are accepted, cost per success is undefined. The repair minutes remain visible separately because a token bill, without a labor-cost assumption, cannot price the reviewer’s extra effort.

This handoff has a concrete acceptance question: did the updated summary keep the unresolved dependency and the other evidence the next responder needs? Exploratory work may not have such a fixed test; useful findings and reviewer effort are then more honest comparisons than forcing a binary success score. For our summary, the reviewer’s correction explains exactly what the lower token bill left unfinished.

The next responder receives the corrected account, with the dependency still open rather than quietly erased. Beside it, the usage record includes the attempts and the reviewer’s extra work. Now the team can judge whether the cheaper model helped this route to a usable handoff. The cache saving may be genuine; it no longer gets credit for finishing work somebody else had to repair.