In a post on X, @TheRealAdamG pointed to OpenAI’s announcement of improved prompt caching for the GPT-6 family. OpenAI says the update raises cache hit rates by default, offers discounts for eligible shared prefixes—the unchanged beginning of multiple requests—reused within a 30-minute window, and adds tools for monitoring and diagnosing cache performance. A cache hit rate is the share of an application’s input that can be reused from cache instead of processed as new input.

The changes target persistent agents: applications that make many API requests while carrying forward some combination of instructions, tool definitions and earlier context. Reusing that shared context can reduce repeated processing, response times and input-token costs, although the announcement does not establish that every GPT-6 workload will receive the same improvement.

OpenAI’s announcement says cached input tokens can receive discounts of up to 90%. That is an attributed product statement, not a guarantee that every request or cached prefix qualifies.

What changed in GPT-6 prompt caching

OpenAI describes the GPT-6 caching system as having higher cache hit rates by default. It also says eligible shared prefixes can receive cache discounts when they are reused within a 30-minute window.

The announcement does not provide the complete pricing schedule or define every condition for eligibility. Developers should therefore treat the 30-minute period as the stated eligibility window for the described shared-prefix discounts, not as a promise that every prefix remains discounted for that long.

OpenAI also introduces optional controls and observability features. These are intended to help developers decide what context to reuse, see how much of an application’s input is cached, and investigate why a request failed to reuse earlier context.

How the dashboard and diagnostics explain cache performance

The Prompt Caching Dashboard shows how much application input is served from cache. OpenAI says developers can use it to track hit rates over time and compare cached and uncached tokens through an input-composition chart.

That makes the dashboard useful for detecting changes rather than merely checking a single request. For example, a drop in the hit rate after a tool or prompt update could indicate that an application is producing less reusable context. The dashboard can also help compare caching before and after an integration change, but the announcement does not specify its full interface or alert configuration.

For an individual miss, OpenAI’s prompt caching diagnostics tool compares a request with a recent response. It can identify changes to the model, tools, settings or input that prevented reuse, and it estimates how many tokens were affected.

The announcement gives this example:

{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

Here, the reported reason is tools_changed. The two token counts show the scale of the affected comparison: 5,629 reusable tokens were identified, while 5,629 tokens missed the cache. This example illustrates how diagnostics can connect a cause with an estimated impact; it does not show that tool changes are the cause of every cache miss.

How changes to tools, instructions and reasoning affect reuse

Persistent agents often change behavior between requests. They may need a different set of tools, receive new instructions or increase reasoning effort for a harder task. OpenAI’s guidance is to change those parts in ways that preserve the stable beginning of the prompt where possible.

Keep tool definitions stable

OpenAI recommends keeping tool definitions, schemas and ordering stable as an agent’s tool needs change. Instead of removing tool definitions from a request, developers can use allowed_tools to restrict which tools are callable. When no tools are needed, the announcement recommends setting tool_choice to none rather than removing the definitions.

The practical distinction is between changing which tools can be used and changing the shared tool-definition context itself. Stable definitions give earlier requests a better chance of sharing the same prefix, while the allowed-tool setting controls the tools available for the current step.

Append new instructions

When an agent needs new directions, OpenAI recommends using new developer messages to append instructions toward the end of the context. Later instructions can override older ones without rewriting the earlier stable portion.

This approach is useful for persistent workflows in which the agent’s general operating instructions remain unchanged but a later task adds a temporary constraint. The announcement does not define all precedence behavior for developer messages, so applications should still test their own instruction structure.

Change reasoning effort without breaking the cache

OpenAI says GPT-6 models allow developers to change reasoning effort between responses without breaking the cache. The described method is to append a configuration_update while leaving request-level reasoning effort unchanged.

That lets an application raise reasoning effort for a difficult task or lower it for a routine follow-up while preserving reusable context. The announcement does not provide the complete API schema for this operation, so the product documentation is needed for implementation details.

Explicit breakpoints and prewarming

Explicit cache breakpoints let developers choose which prompt prefixes to reuse. This can help separate stable context from content that changes frequently, such as the latest user request or a short-lived task state.

OpenAI says its refreshed prompt caching guide explains how to use breakpoints, how long cached prefixes remain eligible and how changes to tools and inputs affect reuse. The announcement does not include the breakpoint syntax or the complete eligibility rules, so those details should not be inferred from the product description.

Prewarming addresses a different part of the workflow: when the application performs the work. OpenAI describes prewarming as preparing known context before a request arrives. An application could prewarm shared instructions, tool definitions or reference material during startup, moving that processing out of the user’s wait time.

Prewarming is most relevant when the application knows which context will be needed soon. It does not remove the need to keep reusable context stable, and the announcement does not quantify the latency improvement for a particular workload.

A practical cache-preservation workflow

For a persistent-agent integration, developers can use the announcement’s controls as a troubleshooting sequence:

  1. Measure the baseline. Use the Prompt Caching Dashboard to record the share of input served from cache and the split between cached and uncached input tokens.

  2. Keep stable context stable. Avoid unnecessary changes to shared instructions, tool definitions, schemas and tool ordering.

  3. Restrict tools without rewriting definitions. Use allowed_tools for a narrower tool set, or tool_choice set to none when the current step needs no tools.

  4. Append temporary instructions. Add new developer messages toward the end of the context instead of rewriting earlier reusable instructions.

  5. Adjust reasoning separately. On GPT-6, use the described configuration_update approach when changing reasoning effort between responses.

  6. Investigate unexpected misses. Compare the affected request with a recent response using prompt cache diagnostics, then check the reported cause and token impact.

  7. Choose breakpoints deliberately. Use explicit breakpoints to keep long-lived context reusable while allowing frequently changing content to remain later in the prompt.

  8. Prewarm known context. Prepare shared material during startup when doing so can reduce work during the user-facing request.

OpenAI includes results reported by two quoted speakers to illustrate the potential impact. Mario Rodriguez, identified in the announcement as a chief product officer, says the share of prompt tokens requiring fresh processing for GitHub Copilot fell by more than 50% across billions of requests relative to a previous baseline. Arian Hanifi says dashboard and diagnostics work improved cache hit rates by a few percentage points and reduced costs by 20%.

Those figures describe the named speakers’ reported experiences, not universal GPT-6 benchmarks. The useful takeaway for other applications is to measure their own hit rates, identify the changes behind misses and preserve stable prefixes where the workload makes that practical.

Sources