GPT-6 Sol and Luna change the agent cost calculation

A cheaper answer can still be expensive to use. In an incident workflow, the bill continues after generation if someone must trace an unsupported claim, repeat a tool call or rewrite the update.

OpenAI announced GPT-6 Sol and Luna on September 22, alongside changes to prompt caching. The models are available through the API as gpt-6-sol and gpt-6-luna. Its announcement also describes a gradual rollout in ChatGPT Work and Codex. For operations teams, this is a reason to rerun a bounded evaluation, with the acceptance criteria held steady.

Judge the cheaper model by the total cost of an accepted task, including retries and correction work. This applies the same accounting principle behind our agent observability analysis: a provider charge becomes operational evidence when it can be connected to work someone actually accepts.

GPT-6 prompt caching has several rates

The standard prices below are dollars per million tokens, checked September 22. Sol and Luna distinguish ordinary input, cache writes, cache reads and output.

Model	Input	Cache write	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

These are standard rates, not a quotation for every request. Both model pages document higher rates above 272,000 input tokens, regional premiums and different processing tiers. Tool charges can add to the total.

Reuse must repay the cache write

OpenAI’s caching documentation describes reuse of computation for a matching prompt prefix. A write costs 1.25 times ordinary input; a read costs 0.1 times. Explicit breakpoints let an application mark the end of reusable material. Cache reuse does not eliminate new output generation.

For an illustrative 10,000-token Sol prefix, an ordinary input charge is $0.02, a cache write is $0.025 and a full cache read is $0.002. One write followed by nine reads costs $0.043 for that prefix, compared with $0.20 for ten ordinary input charges. That calculation excludes changing input, output, tools and every failed attempt. It assumes all nine reads actually reuse the full prefix.

Compare accepted work on the same cases

In a hypothetical incident-summary pilot, two models process the same source bundle, but one repeatedly omits an unresolved dependency. Its invoice is lower, yet the reviewer has to reopen the timeline before sending each update. Count that correction, retain rejected attempts, and use the same source records for the comparison. Otherwise a favorable cache run can conceal a less useful workflow.

For a pilot, record model, task identity, cached and uncached usage, output usage, retries, acceptance and correction minutes. Run both repeated-context cases and cases with genuinely new evidence. Keep the approval and service-verification rules from the incident-agent evaluation guide unchanged while comparing models.

Keep provider spending and human correction time visible as separate measurements. Dividing total provider spending by accepted tasks gives one useful cost measure. Report the acceptance count beside it; when no task is accepted, report that result rather than manufacturing an efficiency score. Reviewer minutes answer a different question and should remain visible.

For exploratory work without a fixed acceptance test, compare useful findings and reviewer effort rather than forcing every response into a binary success score. The release makes experimentation more affordable. Expansion still depends on whether the resulting work earns the additional responsibility.