# Why the Sol 6.1 cache discount is not a task-cost estimate

The Sol upgrade cut a cache-read rate, but completed-task costs also depend on cache eligibility, output, retries and accepted work.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-29
Original announcement: https://developers.openai.com/api/docs/changelog
Canonical URL: https://retrivium.ai/retrospectives/sol61-cache-price-vs-total-task-cost/

The cache price in a model announcement is a rate for one component, not a quotation for a completed task. Sol's upgrade made that distinction especially relevant because a lower cache-read price arrived alongside a more capable model, leaving several possible explanations for a changed bill.

## Put the rate in its release sequence

The [API changelog](https://developers.openai.com/api/docs/changelog) records Astra on September 3, 2026, [Sol and Luna](https://openai.com/index/introducing-gpt-6-sol-and-luna/) on September 22, 2026, and the [Sol upgrade](https://openai.com/index/introducing-gpt-6-1-sol/) on September 29, 2026. The latter announcement compares cached-input rates of $0.10 and $0.20 per million tokens. That comparison concerns cached input; it does not measure an application's total cost.

## A discount needs an eligible quantity

Imagine a repository assistant whose repeated system instructions occupy much of its input. Another assistant receives short questions but produces extensive reports. The same cache-read discount can have different importance because the eligible portion of their workloads differs.

The relevant quantity is reported cached input in equivalent accepted work. Request count is an inadequate substitute, and repeated meaning does not establish cache eligibility. A fixed model price can coexist with changing request construction, context length and output volume.

## Capability can move other components

The upgraded model might need fewer attempts, produce a longer explanation or call another tool. Any of these changes can affect the completed-task bill independently of the cache-read rate. A cheaper component and a cheaper workflow are therefore separate findings.

Do not attribute a lower total automatically to the announced discount. Inspect whether the task population or acceptance rule changed. Finishing less work can reduce expenditure while making the service worse. Conversely, completing a previously unresolved task can increase total spending while creating a useful result.

## Use a matched accounting comparison

Preserve a reviewed task set and its completion criteria. For each accepted outcome, retain uncached input, cached input, output and additional execution costs where available. Keep unresolved attempts visible instead of dropping them from the denominator.

Compare the old and new configurations under that same record structure. A missing usage category should remain unknown, not silently become zero. Inspect outliers such as a large report or a retry chain, because an average can hide the mechanism that matters to the budget.

## What the price announcement supports

The historical announcement supports a component-level pricing comparison at launch. It does not provide a current quote, a universal savings percentage or a return estimate for operating infrastructure.

Its broader lesson is about attribution. Separate the changed rate from the amount of eligible work and the behavior of the new model. That produces an explanation another reviewer can audit, rather than a task-cost claim inferred from a single attractive number.

## Related reading

- [Components of an inference budget](/journal/inference-economics/)
- [Comparing equivalent completed work](/journal/inference-benchmark-method/)