{"slug": "introducing-explicit-prompt-caching-for-openai-gpt-5-6-models-on-amazon-bedrock", "title": "Introducing explicit prompt caching for OpenAI GPT-5.6 models on Amazon Bedrock", "summary": "Amazon Web Services (AWS) and OpenAI announced explicit prompt caching for OpenAI GPT-5.6 Sol, Terra, and Luna models on Amazon Bedrock, offering a 90% discount on cached input tokens that remain reusable for 30 minutes. The new capability gives users precise control over which prompt portions are cached and reused, benefiting agentic workflows with repeated system instructions, tool definitions, and reference documents. GPT-5.6 models are now generally available on Amazon Bedrock via the OpenAI-compatible Responses API, with three capability tiers: Sol for complex reasoning, Terra for balanced workloads, and Luna for high-volume tasks.", "body_md": "[Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/)\n\n# Introducing explicit prompt caching for OpenAI GPT-5.6 models on Amazon Bedrock\n\n*This post is co-written with Chris Dickens from OpenAI.*\n\nOpenAI GPT-5.6 Sol, Terra, and Luna are [now generally available on Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/openai-gpt-5-6-sol-terra-and-luna-are-now-generally-available-on-amazon-bedrock/). With GPT-5.6 on Amazon Bedrock, you get the newest generation of OpenAI frontier models with pay-per-token pricing, AWS security and governance controls, and usage that counts toward your existing AWS commitments. The family covers three capability tiers: GPT-5.6 Sol for the most complex reasoning and agentic coding work, GPT-5.6 Terra for balanced everyday production workloads, and GPT-5.6 Luna for fast, high-volume tasks such as classification and summarization.\n\nAlongside the new models, GPT-5.6 introduces [explicit prompt caching](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html) on Amazon Bedrock, a new capability that gives you precise control over which portions of your prompt are cached and reused across requests. Cached input is billed at a 90 percent discount (see the [Amazon Bedrock pricing page](https://aws.amazon.com/bedrock/pricing/)) and stays available for reuse for 30 minutes. You get the most value from this in agentic workflows, where system instructions, tool definitions, and reference documents repeat across many calls.\n\nIn this post, we introduce explicit prompt caching for GPT-5.6 on Amazon Bedrock, a new capability that gives you control over which parts of your prompt are cached and reused across requests. We show how it differs from implicit caching and when to use each mode, how to set it up and verify that it is working, and how it performs in an agentic workflow. We also cover how to migrate workloads from earlier GPT models onto GPT-5.6, whether they run on Amazon Bedrock today or on another platform.\n\n## Get started with GPT-5.6 on Amazon Bedrock\n\nGPT-5.6 models are served through the OpenAI-compatible Responses API on the Amazon Bedrock `bedrock-mantle`\n\nendpoint.\n\n### Set up the client\n\nThe recommended way to authenticate is with short-term bearer tokens generated from your AWS credentials. Install the token generator alongside the OpenAI SDK:\n\nThen create a client. The token generator uses the standard AWS credential chain (IAM roles, environment variables, or your CLI profile), so your code stays free of long-lived secrets:\n\n### Make your first request\n\nGPT-5.6 models use the Responses API. A minimal request looks like this:\n\nThe three model IDs are `openai.gpt-5.6-sol`\n\n, `openai.gpt-5.6-terra`\n\n, and `openai.gpt-5.6-luna`\n\n. GPT-5.6 Sol is available in US East (N. Virginia) and US East (Ohio). Terra and Luna are additionally available in US West (Oregon). For model availability by Region, refer to Supported models by AWS Region in Amazon Bedrock ([https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html)).\n\n### Control reasoning effort\n\nGPT-5.6 supports reasoning effort levels `none`\n\n, `low`\n\n, `medium`\n\n, `high`\n\n, and `xhigh`\n\n, with `medium`\n\nas the default. Higher levels allocate more reasoning to harder problems, and `none`\n\ngives you the lowest-latency path for straightforward tasks:\n\nA practical guideline when upgrading from GPT-5.5 or GPT-5.4: start with the effort level you use today, then test one level lower. GPT-5.6 is more token efficient, and many workloads maintain quality at a lower effort setting. Sampling parameters (`temperature`\n\nand `top_p`\n\n) are supported when `reasoning.effort`\n\nis set to `none`\n\n. At other effort levels, the model’s reasoning process controls output variance.\n\n### Stream responses\n\nStreaming works through the SDK’s standard interface and delivers output as typed events:\n\n### Call tools and get structured output\n\nFunction calling and strict JSON schema output both work as they do with OpenAI’s native API. Tool definitions use the Responses API’s flat format:\n\nFor structured output, pass a strict JSON schema and the model returns valid JSON that conforms to it:\n\n## Use prompt caching for GPT-5.6 on Amazon Bedrock\n\nGPT-5.6 models support prompt caching through the Responses API, with two modes: implicit, where Amazon Bedrock places cache breakpoints for you automatically, and explicit, where you mark the cache boundary yourself for precise control. This section covers both, along with how to verify caching behavior and choose the right mode for your workload.\n\nPrompt caching lets Amazon Bedrock skip recomputing portions of your prompt that repeat across requests. On GPT-5.6, cache reads are billed at a 90 percent discount compared to uncached input tokens, and cache writes are billed at 1.25 times the uncached input rate, so the feature is designed for write-once, read-many patterns. Because a read saves far more than a write adds, a workload lowers its net input cost once cache reads make up roughly 20 percent of the tokens that flow through the cache. Implicit moves you toward that with no work on your part, because Amazon Bedrock places the breakpoint and tunes it for you. In explicit mode, marking the stable prefix yourself typically pushes the hit rate higher still, because later requests read the prefix back while it stays cached. For current rates, see the [Amazon Bedrock pricing page](https://aws.amazon.com/bedrock/pricing/).\n\n### Start with implicit prompt caching\n\nOn GPT-5.6, prompt caching is on by default in implicit mode. When you send a request without any caching parameters, Amazon Bedrock automatically places a cache breakpoint and looks for a reusable prefix. A stable prefix of at least 1,024 tokens can be cached and reused with no change to your code.\n\nImplicit caching means your existing code starts earning cache reads from day one, with no analysis of your prompt structure required. Because Bedrock chooses the breakpoint for you, the first request writes the prefix to the cache and later requests read it back. For workloads where the content after your stable prefix changes on every request, such as chat assistants and agentic tool loops, you get more predictable results by marking the prefix yourself with an explicit breakpoint. The following section describes this approach.\n\n### Set up explicit prompt caching\n\nExplicit mode gives you direct control over the cache boundary. You mark the end of your reusable prefix, and cached prefixes stay available for reuse for at least 30 minutes, long enough to cover the burst of calls a single agent run generates. Three request parameters control caching on GPT-5.6:\n\n: placed on a content block, marks the exact end of a reusable prompt prefix. Everything up to and including the marked block is cached, and everything after it can change freely while the cached prefix stays valid. Each cached prefix must contain at least 1,024 tokens, and you can set up to 4 breakpoints per request on`prompt_cache_breakpoint`\n\n`input_text`\n\n,`input_image`\n\n, and`input_file`\n\nblocks.: a stable ID that routes requests to the same cache. Set it consistently across all requests in a session or application so repeat requests find the cached prefix.`prompt_cache_key`\n\n: controls the caching mode (implicit or explicit, covered in the next section) and the TTL.`prompt_cache_options`\n\nHere is a complete example: a support assistant with a long system instruction that is identical on every call, followed by a user question that changes every time. The breakpoint goes at the end of the static content:\n\n### Verify caching behavior\n\nEvery response reports exactly what the cache did, in the `usage.input_tokens_details`\n\nobject. This is the place to verify your setup:\n\n: input tokens read from cache, billed at the 90 percent discount.`cached_tokens`\n\n: input tokens written to cache, billed at 1.25 times the uncached rate.`cache_write_tokens`\n\n*Note: Tokens served from the cache within the 30-minute window are excluded from charges on subsequent calls. The following explanation covers this in detail.*\n\n`input_tokens = cached_tokens + cache_write_tokens + non-cached remainder`\n\n`input_tokens`\n\nis the full input count for the request. `cached_tokens`\n\nand `cache_write_tokens`\n\nreport how much of that input came from the cache, and the rest is the new content you send each time, such as the user question after your breakpoint. Because the cached and written counts are part of `input_tokens`\n\nrather than added on top of it, a token served from the cache is counted once and billed once at the cache-read rate. You are never charged twice for the same token. In the following example, the requests reuse the same 3,626-token system prefix under one `prompt_cache_key`\n\n. The user question changes each time, so the non-cached remainder of `input_tokens`\n\nchanges with it:\n\nRequest |\ninput_tokens |\ncached_tokens |\ncache_write_tokens |\nNew (non-cached) input |\n| First (cold) | 3,682 | 0 | 3,626 | 56 |\n| Second | 3,671 | 3,626 | 0 | 45 |\n| Third | 3,662 | 3,626 | 0 | 36 |\n\nThe first request writes the 3,626-token prefix to the cache. From the second request onward, that prefix is read back at the cache-read discount while only the new user input (45 and 36 tokens here) is processed at the standard rate. `cached_tokens`\n\nstays high, `cache_write_tokens`\n\ndrops to zero, and `input_tokens`\n\nmoves only by the size of the changing user question.\n\nThese two fields arrive with every response. The most direct verification workflow is to log them from your application alongside the request ID and prompt_cache_key. Then confirm the write-once, read-many pattern in your logs before production traffic depends on it. For aggregate monitoring, the `bedrock-mantle`\n\nendpoint publishes inference and token metrics to Amazon CloudWatch under the `AWS/BedrockMantle`\n\nnamespace (see [Monitor bedrock-mantle inference using CloudWatch metrics](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring-mantle-metrics.html)). This tracks overall input and output token volume by account, project, and model. The per-request cache breakdown comes from the usage object in each response, which makes application-level logging of these two fields the foundation of your caching observability.\n\n### Use caching in an agentic loop\n\nAgentic workloads are where explicit caching shines. In a tool-calling loop, the system prompt and tool definitions repeat on every turn while the conversation grows at the end, a perfect fit for a breakpoint after the static content. This example builds an incident-response assistant that checks service health and recent deployments:\n\nThe model drives this loop: it decides which tools to call, and the loop ends when the model returns a final response instead of another tool call. This tool loop is the minimal form of an agent, the same loop that agent frameworks manage for you. The first turn writes the system prompt prefix to the cache. Every later turn in the run reads that prefix from the cache while the model processes the newly appended tool calls and results, and the 30-minute TTL comfortably covers multi-minute agent sessions. Logging the two usage fields per turn shows the pattern clearly: a single cache write on the opening turn, followed by cache reads on each turn after it.\n\n## Choose between implicit and explicit caching\n\nGPT-5.6 supports two caching modes, controlled by `prompt_cache_options.mode`\n\n:\n\n**Implicit (the default).** Amazon Bedrock automatically places a cache breakpoint on the latest message and attempts to maximize your cache hit rate. Any explicit breakpoints you add are honored as well. This mode delivers caching benefits with your existing request format automatically.**Explicit.** Setting “prompt_cache_options”: {“mode”: “explicit”} gives your breakpoints full control: only the breakpoints you place are used for cache reads and writes.\n\nExplicit mode puts the cache boundary under your control, and that control matters most when your prompts combine a stable prefix with content that changes on every request. In implicit mode, Bedrock places the breakpoint for you, and the number of cache writes before reads begin can vary from request to request. With one explicit breakpoint placed at the end of the static content, the behavior is deterministic: the first request writes the prefix once, and every following request reads it from the cache, because the changing content sits safely after the breakpoint.\n\nYour workload |\nRecommended mode |\n| Prompts repeat exactly (repeated document analysis, batch scoring with a fixed prompt) | Implicit (default) works with no request changes. Explicit gives the same result with deterministic control |\n| Stable prefix plus changing suffix (chat assistants, RAG, agentic tool loops) | Explicit, with one breakpoint after the static content |\n| Multiple sections that change at different frequencies (tools, system prompt, long documents, conversation) | Explicit, with up to 4 breakpoints for granular control |\n\nIf you do not want prompt caching on GPT-5.6+, you can use explicit cache mode without providing explicit breakpoints. This opts you out of prompt cache billing behavior (and does not incur cache-write charges), but parts of the prompts may still be cached on Bedrock systems to give you lower latency. Whichever mode you choose, keep monitoring the two usage fields in production. A healthy caching pattern shows meaningful cache reads following each write. If you see high cache writes with few reads in implicit mode, consider switching to explicit mode by adding an explicit breakpoint at the end of your static content so the cached prefix is deterministic. In explicit mode, move your breakpoint earlier so it covers only content that stays constant between calls. Confirm that `prompt_cache_key`\n\nis set consistently across the requests that should share a cache.\n\n## Migrate to GPT-5.6 from earlier GPT models\n\nGPT-5.6’s combination of stronger performance, better token efficiency, and controllable caching makes it a compelling upgrade target. The migration effort depends on where your workload runs today. We cover the three common starting points, from smallest change to largest.\n\n### Starting point 1: GPT-5.5 or GPT-5.4 on Amazon Bedrock\n\nIf you already run OpenAI models on Amazon Bedrock, the upgrade is a model ID change. The endpoint, authentication, and Responses API request shape stay identical:\n\nTwo things to fold into the upgrade:\n\n**Adopt explicit cache breakpoints.** On GPT-5.5 and GPT-5.4, prompt caching is automatic: the system caches eligible prefixes of 1,024 tokens or longer without additional parameters, and cache writes are free of charge. GPT-5.6 moves to the controllable model described above, including the 1.25 times cache-write rate, which applies to implicit and explicit writes alike. Plan the two changes together: when you switch the model ID, place an explicit breakpoint after your static content at the same time. That single addition establishes the write-once, read-many pattern for prompts whose ending changes on each request. It extends your cache lifetime as well, because GPT-5.6 cached prefixes remain available for at least 30 minutes.\n\n**Revisit your reasoning effort.** GPT-5.6 adds the xhigh effort level and delivers more capability per token across the range. Start with your current GPT-5.5 effort level and test one level lower. Many workloads keep their quality bar at lower cost.\n\n### Starting point 2: Responses API on another platform\n\nIf your application already uses the OpenAI Responses API on another platform, migrating to Amazon Bedrock requires three changes: the base URL, the authentication, and the model ID. Your request and response handling code stays the same:\n\nThe authentication change is also a security upgrade: aws-bedrock-token-generator derives short-term tokens from your AWS credentials, so your application uses IAM roles end to end. You keep the same identity, policy, and audit model (AWS CloudTrail) as the rest of your AWS workloads. For production, wrap token generation in a refresh routine, since tokens are short-lived by design. Because this migration typically also moves you up a model generation, fold in the two changes from starting point 1: place an explicit cache breakpoint after your static content, and test one reasoning effort level below your current setting.\n\n### Starting point 3: Chat Completions API on another platform\n\nGPT-5.6 on Amazon Bedrock is served through the Responses API, so workloads written against Chat Completions port their request and response handling as part of the migration. The mapping is mechanical:\n\nChat Completions |\nResponses API |\n`messages=[{role, content}]` |\n`instructions=\"...\"` (system) plus `input=\"...\"` or message list |\n`max_completion_tokens` |\n`max_output_tokens` |\n`response.choices[0].message.content` |\n`response.output_text` |\n`tools=[{\"type\": \"function\", \"function\": {...}}]` |\n`tools=[{\"type\": \"function\", \"name\": ..., ...}]` (flat) |\n`choices[0].message.tool_calls[i].id` |\n`output[i].call_id` |\n`{\"role\": \"tool\", \"tool_call_id\": ...}` |\n`{\"type\": \"function_call_output\", \"call_id\": ...}` |\n`response.usage.prompt_tokens` / `completion_tokens` |\n`response.usage.input_tokens` / `output_tokens` |\n`stream=True` with `delta.content` chunks |\n`stream=True` with typed events (`response.output_text.delta` ) |\n\nBefore and after, side by side:\n\nThe Responses API also brings additional capabilities, including server-managed conversation state, typed streaming events, and the explicit prompt caching covered in this post, so the port is an investment that pays beyond the migration itself.\n\n### Validate and roll out\n\nWhatever your starting point, treat the migration as a structured engineering project:\n\n**Inventory first.** Catalog the models, APIs (Responses or Chat Completions), tools, streaming usage, and state management your application relies on. This determines which starting point above applies and scopes the work.**Build a golden prompt set.** Collect representative prompts and expected behaviors from production traffic, and replay them against GPT-5.6 on Amazon Bedrock side by side with your current setup. Evaluate success rate, output quality, token consumption, and latency on the tasks that matter to your application. Amazon Bedrock evaluation tooling, or your existing evaluation harness both work.**Establish your caching baseline.** As part of the same replay, log cached_tokens and cache_write_tokens and confirm your breakpoint placement produces the write-once, read-many pattern before production traffic depends on it.**Ramp gradually.** Route a small percentage of traffic to the new model, compare KPIs against your baseline, and expand as confidence grows, keeping the old configuration available for instant rollback until the migration is complete.\n\n## Conclusion\n\nGPT-5.6 Sol, Terra, and Luna bring OpenAI’s newest frontier models to Amazon Bedrock. With explicit prompt caching you have a precision tool for the workloads that dominate modern large language model (LLM) spend: agents and AI workloads that resend the same instructions, tools, and references on every call. You need one breakpoint after your static content, a consistent cache key, and two usage fields to monitor. With those in place, you can convert that repeated context from full-price input into discounted cache reads. The same OpenAI SDK compatibility that makes caching straightforward to adopt also makes the migration itself a small, well-defined change from wherever your workload runs today.\n\nTo learn more, see the [GPT-5.6 launch announcement](https://aws.amazon.com/blogs/machine-learning/openai-gpt-5-6-sol-terra-and-luna-are-now-generally-available-on-amazon-bedrock/) and the [Amazon Bedrock prompt caching documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html) for full details on supported parameters and models. For pricing details, refer to the [Amazon Bedrock pricing page](https://aws.amazon.com/bedrock/pricing/). To monitor your workloads in production, see [Monitor bedrock-mantle inference using CloudWatch metrics](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring-mantle-metrics.html). Try GPT-5.6 with your own prompts in the [Amazon Bedrock console](https://console.aws.amazon.com/bedrock/), and share your feedback on [AWS re:Post](https://repost.aws/tags/TAQeKlaPaNRQ2tWB6P7KrMag/amazon-bedrock) for Amazon Bedrock or through your usual AWS Support contacts.", "url": "https://wpnews.pro/news/introducing-explicit-prompt-caching-for-openai-gpt-5-6-models-on-amazon-bedrock", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/introducing-explicit-prompt-caching-for-openai-gpt-5-6-models-on-amazon-bedrock/", "published_at": "2026-07-30 16:02:32+00:00", "updated_at": "2026-07-30 16:29:10.848747+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-products", "ai-infrastructure", "ai-tools"], "entities": ["Amazon Web Services", "OpenAI", "Amazon Bedrock", "GPT-5.6 Sol", "GPT-5.6 Terra", "GPT-5.6 Luna", "Chris Dickens"], "alternates": {"html": "https://wpnews.pro/news/introducing-explicit-prompt-caching-for-openai-gpt-5-6-models-on-amazon-bedrock", "markdown": "https://wpnews.pro/news/introducing-explicit-prompt-caching-for-openai-gpt-5-6-models-on-amazon-bedrock.md", "text": "https://wpnews.pro/news/introducing-explicit-prompt-caching-for-openai-gpt-5-6-models-on-amazon-bedrock.txt", "jsonld": "https://wpnews.pro/news/introducing-explicit-prompt-caching-for-openai-gpt-5-6-models-on-amazon-bedrock.jsonld"}}