OpenAI Drops the Cache-Key Requirement for GPT-6

OpenAI said Sept. 22 that GPT-6 no longer needs a prompt_cache_key to reach its highest cache-hit rate, a requirement Amazon Bedrock still imposes on the GPT-5.6 caching system it rolled out July 30.

OpenAI's announcement and its developer documentation describe cache reads on GPT-6 as billed at 0.1 times the ordinary input-token rate, a 90 percent discount, for any shared prefix of at least 1,024 visible tokens reused within a 30-minute window. Writing a prefix to the cache costs 1.25 times the standard rate. The same post introduces a caching dashboard for monitoring hit rates, a diagnostics tool that compares two requests to explain a cache miss, and a prewarming feature that loads a known context ahead of time to cut latency. A new configuration_update parameter lets a developer change GPT-6's reasoning effort between turns in the same conversation without breaking the cache, and pinning a stable set of tools with allowed_tools alongside append-only developer messages now preserves a cache that would previously have been invalidated by any change to instructions or tool definitions.

The same numbers, a different requirement

Amazon's own announcement of GPT-5.6 prompt caching on Bedrock, published July 30 and written by Melanie Li, Chris Dickens, Joe Magerramov and Saurabh Trikande, lands on nearly identical economics: a 90 percent discount on cached reads, a 1.25-times premium on writes, a 1,024-token minimum prefix, and a 30-minute cache lifetime. Where it differs is the key. Bedrock's explicit caching mode requires a consistent prompt_cache_key across requests that share a prefix, capped at four breakpoints per request, to get deterministic cache placement; its implicit mode, the default, places a single breakpoint on the latest message and cannot mix a stable prefix with a changing suffix as reliably. OpenAI's GPT-6 documentation says a key is now optional, useful mainly for keeping separate cache accounting between customers or workspaces rather than for triggering a cache hit at all.

Caching system	Cache read discount	Minimum prefix	Cache key required
OpenAI GPT-6 (Sept. 22, 2026)	90%	1,024 tokens	No
Amazon Bedrock, GPT-5.6 explicit mode (Jul. 30, 2026)	90%	1,024 tokens	Yes

The complaint this update doesn't mention

OpenAI's Sept. 22 post does not reference a thread on its own developer community opened July 12, in which a developer reported roughly 96 percent cache-hit rates on Azure's Chat Completions endpoint for GPT-5.6 against zero cached tokens on Azure's Responses API using the same explicit caching parameters. The developer wrote that the team had spent days reverse-engineering the discrepancy themselves "because there has been no clear communication," and asked only for confirmation of which system had the bug. Nothing in GPT-6's caching documentation addresses whether that Responses-API gap, specific to GPT-5.6 on Azure rather than OpenAI's own API, has been resolved.

What developers still can't see

OpenAI's post frames the changes around agents that run for hours on tasks like refactoring a codebase, where each request in a session carries forward the same instructions, tools and prior context, making a higher default cache-hit rate a direct cut to the bill for that kind of workload. What the post does not publish is a hit-rate number of its own, vendor-supplied or otherwise, so a developer cannot yet compare GPT-6's new default behavior against GPT-5.6's before deciding whether the change is worth re-testing a production integration over. Whether removing the cache-key requirement actually raises hit rates in practice, rather than just removing a step, is a claim only usage data OpenAI has not published could settle. It is the same kind of unverified before-and-after gap that ran through TypeSafe's own benchmark claims for its Jev model, and through OpenAI's own Astra for Law launch: the vendor's numbers arrived well ahead of anyone outside the company checking them.