GPT-5.6’s latest economics are about routing work and reusing context

OpenAI’s July 30 GPT-5.6 update did not lower the standard price of GPT-5.6 Sol. Instead, it cut Luna input and output pricing by 80% and Terra pricing by 20%, while introducing Fast mode for Sol. OpenAI says Fast mode delivers up to 2.5 times the speed of Standard processing at twice the price, with unchanged intelligence, and that existing API requests marked as priority will route to Fast mode. The concrete change for Sol users is therefore a latency-priced option, not a cheaper default tier.

AWS added a separate cost-control layer for the GPT-5.6 family on Amazon Bedrock: explicit prompt caching through its OpenAI-compatible Responses API. AWS says cache reads are billed at a 90% discount from uncached input, cached prefixes can be reused for at least 30 minutes, and writes cost 1.25 times the ordinary uncached input rate. The cache is most relevant when a long system prompt, tool definitions, or reference material recur across calls, rather than when each request is mostly new text.

Together, the two updates make the family easier to treat as a staged system rather than a single endpoint. OpenAI explicitly presents Sol as the model for consequential or uncertain steps and Luna as the lower-cost implementation tier; AWS exposes Sol, Terra, and Luna through the same Responses API shape. That interoperability does not erase deployment constraints: AWS lists Sol only in US East (N. Virginia) and US East (Ohio), while Terra and Luna are also listed for US West (Oregon). Teams that route work by latency, cost, or region need to test the whole path, not only the selected model.

The limitations are operational as well as financial. AWS says implicit caching is enabled by default only for a stable prefix of at least 1,024 tokens; explicit caching requires deliberately placing breakpoints and consistently reusing a cache key. Because a cold cache write costs more than ordinary input, AWS estimates that a workload lowers net input cost only once cache reads represent roughly 20% of tokens flowing through the cache. Fast mode likewise carries a stated 2x price premium. Neither vendor page independently establishes task-quality gains for a particular application, so production evaluation should track latency, cache-write and cache-read tokens, and task success before changing routing policies.