Amazon Bedrock 为 OpenAI GPT-5.6 模型推出显式提示缓存

本文由 OpenAI 的 Chris Dickens 共同撰写。

OpenAI GPT-5.6 Sol、Terra 和 Luna 已在 Amazon Bedrock 正式可用。通过 Amazon Bedrock 上的 GPT-5.6，你可以使用新一代 OpenAI 前沿模型，并获得按 Token 付费、AWS 安全与治理控制，以及计入现有 AWS 承诺用量的能力。该模型家族涵盖三个能力层级：面向最复杂推理和 Agent 编程工作的 GPT-5.6 Sol、面向均衡日常生产工作负载的 GPT-5.6 Terra，以及面向分类、摘要等高速高吞吐任务的 GPT-5.6 Luna。

除新模型外，GPT-5.6 还在 Amazon Bedrock 上引入了显式提示缓存。这项新能力使你能够精确控制提示词中的哪些部分会被缓存，并在多次请求间复用。缓存输入的计费可享受 90% 折扣（参见 Amazon Bedrock 定价页面），并可保持 30 分钟以供复用。该功能在 Agent 工作流中最具价值，因为系统指令、工具定义和参考文档会在多次调用中重复出现。

本文将介绍 Amazon Bedrock 上 GPT-5.6 的显式提示缓存，这项新能力使你能够控制提示词中哪些部分会被缓存并在请求间复用。我们将说明它与隐式缓存的区别、每种模式的适用时机、如何配置和验证其正常工作，以及它在 Agent 工作流中的表现。我们还将介绍如何将早期 GPT 模型上的工作负载迁移至 GPT-5.6，无论这些工作负载目前运行在 Amazon Bedrock 还是其他平台。

在 Amazon Bedrock 上开始使用 GPT-5.6

GPT-5.6 模型通过 Amazon Bedrock bedrock-mantle 端点上的 OpenAI 兼容 Responses API 提供服务。

配置客户端

推荐使用由 AWS 凭证生成的短期 bearer token 进行身份验证。请与 OpenAI SDK 一同安装 token 生成器：

pip install openai aws-bedrock-token-generator

然后创建客户端。token 生成器使用标准 AWS 凭证链（IAM 角色、环境变量或 CLI 配置文件），因此你的代码无需包含长期有效的密钥：

from openai import OpenAI
from aws_bedrock_token_generator import provide_token

REGION = "us-east-2"

client = OpenAI(
    base_url=f"https://bedrock-mantle.{REGION}.api.aws/openai/v1",
    api_key=provide_token(region=REGION),  # short-term token from your AWS credentials
)

发起第一个请求

GPT-5.6 模型使用 Responses API。一个最简请求如下：

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    instructions="You are a concise technical assistant.",
    input="What is Amazon Bedrock?",
    max_output_tokens=500,
)
print(response.output_text)

三个模型 ID 分别为 openai.gpt-5.6-sol、openai.gpt-5.6-terra 和 openai.gpt-5.6-luna。GPT-5.6 Sol 可在美国东部（弗吉尼亚北部）和美国东部（俄亥俄）使用。Terra 和 Luna 还可在美国西部（俄勒冈）使用。有关按区域划分的模型可用性，请参阅 Amazon Bedrock 中的“按 AWS 区域划分的受支持模型”(https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html)。

控制推理强度

GPT-5.6 支持 none、low、medium、high 和 xhigh 推理强度级别，默认值为 medium。更高的级别会为更困难的问题分配更多推理资源；而 none 则为简单任务提供最低延迟路径：

response = client.responses.create(
    model="openai.gpt-5.6-luna",
    input="Classify this ticket as bug, feature request, or question: 'App crashes on login.'",
    reasoning={"effort": "none"},
)

从 GPT-5.5 或 GPT-5.4 升级时，一个实用的指导原则是：先采用当前使用的强度级别，然后测试降低一个级别。GPT-5.6 的 Token 使用效率更高，许多工作负载在较低的强度设置下仍可维持质量。当 reasoning.effort 设为 none 时，支持采样参数（temperature 和 top_p）。在其他强度级别下，模型的推理过程会控制输出差异性。

流式传输响应

流式传输可通过 SDK 的标准接口实现，并以类型化事件的形式提供输出：

with client.responses.stream(
    model="openai.gpt-5.6-terra",
    input="Write a haiku about distributed systems.",
) as stream:
    for event in stream:
        if event.type == "response.output_text.delta":
            print(event.delta, end="", flush=True)

函数调用和严格 JSON Schema 输出均可像使用 OpenAI 原生 API 一样工作。工具定义采用 Responses API 的扁平格式：

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    input="What's the weather in Seattle?",
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get current weather for a city",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    }],
)
for item in response.output:
    if item.type == "function_call":
        print(item.name, item.arguments)  # get_weather {"city":"Seattle"}

对于结构化输出，传入严格 JSON Schema，模型将返回符合该 Schema 的有效 JSON：

response = client.responses.create(
    model="openai.gpt-5.6-luna",
    input="Extract: 'Order #1234 shipped to Berlin on May 2.'",
    text={
        "format": {
            "type": "json_schema",
            "name": "order",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string"},
                    "destination": {"type": "string"},
                },
                "required": ["order_id", "destination"],
                "additionalProperties": False,
            },
        }
    },
)
print(response.output_text)  # {"destination":"Berlin","order_id":"1234"}

在 Amazon Bedrock 上为 GPT-5.6 使用提示缓存

GPT-5.6 模型通过 Responses API 支持提示缓存，提供两种模式：隐式模式由 Amazon Bedrock 自动为你放置缓存断点；显式模式则由你自行标记缓存边界，以实现精确控制。本节将介绍这两种模式，以及如何验证缓存行为并为工作负载选择合适的模式。

提示缓存使 Amazon Bedrock 无需重新计算在多个请求间重复出现的提示词部分。对于 GPT-5.6，相对于未缓存的输入 Token，缓存读取按 90% 折扣计费，而缓存写入按未缓存输入费率的 1.25 倍计费，因此该功能专为一次写入、多次读取的模式设计。由于一次缓存读取节省的成本远大于一次缓存写入增加的成本，当缓存读取约占流经缓存 Token 的 20% 时，工作负载即可降低净输入成本。隐式模式无需你进行任何操作即可帮助实现这一点，因为 Amazon Bedrock 会为你放置断点并进行调优。在显式模式下，自行标记稳定前缀通常可以进一步提高命中率，因为后续请求会在缓存有效期间重新读取该前缀。有关当前费率，请参阅 Amazon Bedrock 定价页面。

从隐式提示缓存开始

在 GPT-5.6 上，提示缓存默认以隐式模式启用。当你发送不含任何缓存参数的请求时，Amazon Bedrock 会自动放置缓存断点并查找可复用前缀。只要稳定前缀至少包含 1,024 个 Token，即可在不修改代码的情况下被缓存和复用。

# Implicit caching: no caching parameters needed
response = client.responses.create(
    model="openai.gpt-5.6-terra",
    instructions=SYSTEM_INSTRUCTIONS,  # stable prefix, >= 1,024 tokens
    input=user_question,
)
details = response.usage.input_tokens_details
print(f"cached: {details.cached_tokens}, written: {details.cache_write_tokens}")

隐式缓存意味着现有代码从第一天起就能获得缓存读取，无需分析提示词结构。由于 Bedrock 会为你选择断点，第一个请求会将前缀写入缓存，后续请求则会从缓存中读取。对于稳定前缀之后的内容在每次请求中都会变化的工作负载，例如聊天助手和 Agent 工具循环，通过显式断点自行标记前缀可以获得更可预测的结果。下一节将介绍这种方法。

配置显式提示缓存

显式模式让你能够直接控制缓存边界。你可以标记可复用前缀的结尾；缓存前缀至少可保持 30 分钟以供复用，足以覆盖单次 Agent 运行产生的一连串调用。GPT-5.6 上有三个请求参数可控制缓存：

• prompt_cache_breakpoint：放置在内容块上，用于标记可复用提示词前缀的精确结尾。被标记的块及其之前的所有内容都会被缓存，其后的内容则可以自由变化，同时缓存前缀仍然有效。每个缓存前缀必须至少包含 1,024 个 Token；每个请求最多可在 input_text、input_image 和 input_file 块上设置 4 个断点。
• prompt_cache_key：将请求路由到同一缓存的稳定 ID。在一个会话或应用中的所有请求中保持一致设置，以便重复请求能够找到缓存前缀。
• prompt_cache_options：控制缓存模式（隐式或显式，下一节将介绍）和 TTL。

以下是一个完整示例：一个支持助手在每次调用中都使用相同的长系统指令，随后是每次都会变化的用户问题。断点应位于静态内容的结尾：

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    prompt_cache_key="support-app:kb-v1",  # same key across all requests
    input=[
        {
            "type": "message",
            "role": "developer",
            "content": [{
                "type": "input_text",
                "text": SYSTEM_INSTRUCTIONS,  # long, static: guidelines, KB excerpts (>= 1,024 tokens)
                "prompt_cache_breakpoint": {"mode": "explicit"},
            }],
        },
        {
            "type": "message",
            "role": "user",
            "content": [{
                "type": "input_text",
                "text": user_question,  # changes on every request
            }],
        },
    ],
    extra_body={"prompt_cache_options": {"mode": "explicit"}},
)

验证缓存行为

每个响应都会在 usage.input_tokens_details 对象中准确报告缓存执行情况。这是验证配置的关键位置：

• cached_tokens：从缓存读取的输入 Token，按 90% 折扣计费。

• cache_write_tokens：写入缓存的输入 Token，按未缓存费率的 1.25 倍计费。

  details = response.usage.input_tokens_details print(f"cached: {details.cached_tokens}, written: {details.cache_write_tokens}")

注意：在 30 分钟窗口期内从缓存提供的 Token，在后续调用中不计入费用。以下说明将对此进行详细解释。

input_tokens = cached_tokens + cache_write_tokens + non-cached remainder

input_tokens 是请求的完整输入计数。cached_tokens 和 cache_write_tokens 报告其中有多少输入来自缓存，其余部分则是每次发送的新内容，例如断点后的用户问题。由于缓存和写入计数是 input_tokens 的组成部分，而不是额外叠加在其上，因此一个从缓存提供的 Token 只会被计数一次，也只会按缓存读取费率计费一次。你绝不会为同一个 Token 被重复收费。在下例中，请求通过一个 prompt_cache_key 复用相同的 3,626 Token 系统前缀。用户问题每次不同，因此 input_tokens 中未缓存部分也会随之变化：

请求	input_tokens	cached_tokens	cache_write_tokens	新增（未缓存）输入
首次（冷缓存）	3,682	0	3,626	56
第二次	3,671	3,626	0	45
第三次	3,662	3,626	0	36

首次请求会将 3,626 Token 前缀写入缓存。从第二次请求开始，该前缀会以缓存读取折扣从缓存中取回，只有新的用户输入（本例中的 45 和 36 Token）按标准费率处理。cached_tokens 保持较高水平，cache_write_tokens 降至零，而 input_tokens 仅会因变化的用户问题长度而变动。

这两个字段会随每个响应一同返回。最直接的验证流程是：在应用程序日志中，连同请求 ID 和 prompt_cache_key 一起记录它们；然后，在生产流量依赖该功能之前，确认日志中存在一次写入、多次读取的模式。对于聚合监控，bedrock-mantle 端点会在 AWS/BedrockMantle 命名空间下向 Amazon CloudWatch 发布推理和 Token 指标（参见使用 CloudWatch 指标监控 bedrock-mantle 推理）。这会按账户、项目和模型跟踪总体输入和输出 Token 量。而每请求的缓存

This post is co-written with Chris Dickens from OpenAI.

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.

Alongside the new models, GPT-5.6 introduces explicit prompt caching 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) 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.

In 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.

Get started with GPT-5.6 on Amazon Bedrock

GPT-5.6 models are served through the OpenAI-compatible Responses API on the Amazon Bedrock bedrock-mantle endpoint.

Set up the client

The recommended way to authenticate is with short-term bearer tokens generated from your AWS credentials. Install the token generator alongside the OpenAI SDK:

pip install openai aws-bedrock-token-generator

Then 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:

from openai import OpenAI
from aws_bedrock_token_generator import provide_token

REGION = "us-east-2"

client = OpenAI(
    base_url=f"https://bedrock-mantle.{REGION}.api.aws/openai/v1",
    api_key=provide_token(region=REGION),  # short-term token from your AWS credentials
)

Make your first request

GPT-5.6 models use the Responses API. A minimal request looks like this:

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    instructions="You are a concise technical assistant.",
    input="What is Amazon Bedrock?",
    max_output_tokens=500,
)
print(response.output_text)

The three model IDs are openai.gpt-5.6-sol, openai.gpt-5.6-terra, and openai.gpt-5.6-luna. 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).

Control reasoning effort

GPT-5.6 supports reasoning effort levels none, low, medium, high, and xhigh, with medium as the default. Higher levels allocate more reasoning to harder problems, and none gives you the lowest-latency path for straightforward tasks:

response = client.responses.create(
    model="openai.gpt-5.6-luna",
    input="Classify this ticket as bug, feature request, or question: 'App crashes on login.'",
    reasoning={"effort": "none"},
)

A 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 and top_p) are supported when reasoning.effort is set to none. At other effort levels, the model’s reasoning process controls output variance.

Stream responses

Streaming works through the SDK’s standard interface and delivers output as typed events:

with client.responses.stream(
    model="openai.gpt-5.6-terra",
    input="Write a haiku about distributed systems.",
) as stream:
    for event in stream:
        if event.type == "response.output_text.delta":
            print(event.delta, end="", flush=True)

Function 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:

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    input="What's the weather in Seattle?",
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get current weather for a city",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    }],
)
for item in response.output:
    if item.type == "function_call":
        print(item.name, item.arguments)  # get_weather {"city":"Seattle"}

For structured output, pass a strict JSON schema and the model returns valid JSON that conforms to it:

response = client.responses.create(
    model="openai.gpt-5.6-luna",
    input="Extract: 'Order #1234 shipped to Berlin on May 2.'",
    text={
        "format": {
            "type": "json_schema",
            "name": "order",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string"},
                    "destination": {"type": "string"},
                },
                "required": ["order_id", "destination"],
                "additionalProperties": False,
            },
        }
    },
)
print(response.output_text)  # {"destination":"Berlin","order_id":"1234"}

Use prompt caching for GPT-5.6 on Amazon Bedrock

GPT-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.

Prompt 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.

Start with implicit prompt caching

On 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.

# Implicit caching: no caching parameters needed
response = client.responses.create(
    model="openai.gpt-5.6-terra",
    instructions=SYSTEM_INSTRUCTIONS,  # stable prefix, >= 1,024 tokens
    input=user_question,
)
details = response.usage.input_tokens_details
print(f"cached: {details.cached_tokens}, written: {details.cache_write_tokens}")

Implicit 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.

Set up explicit prompt caching

Explicit 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:

• prompt_cache_breakpoint : 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 input_text, input_image, and input_file blocks.
• prompt_cache_key : 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_options : controls the caching mode (implicit or explicit, covered in the next section) and the TTL.

Here 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:

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    prompt_cache_key="support-app:kb-v1",  # same key across all requests
    input=[
        {
            "type": "message",
            "role": "developer",
            "content": [{
                "type": "input_text",
                "text": SYSTEM_INSTRUCTIONS,  # long, static: guidelines, KB excerpts (>= 1,024 tokens)
                "prompt_cache_breakpoint": {"mode": "explicit"},
            }],
        },
        {
            "type": "message",
            "role": "user",
            "content": [{
                "type": "input_text",
                "text": user_question,  # changes on every request
            }],
        },
    ],
    extra_body={"prompt_cache_options": {"mode": "explicit"}},
)

Verify caching behavior

Every response reports exactly what the cache did, in the usage.input_tokens_details object. This is the place to verify your setup:

• cached_tokens : input tokens read from cache, billed at the 90 percent discount.

• cache_write_tokens : input tokens written to cache, billed at 1.25 times the uncached rate.

  details = response.usage.input_tokens_details print(f"cached: {details.cached_tokens}, written: {details.cache_write_tokens}")

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.

input_tokens = cached_tokens + cache_write_tokens + non-cached remainder

input_tokens is the full input count for the request. cached_tokens and cache_write_tokens report 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 rather 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. The user question changes each time, so the non-cached remainder of input_tokens changes with it:

Request	input_tokens	cached_tokens	cache_write_tokens	New (non-cached) input
First (cold)	3,682	0	3,626	56
Second	3,671	3,626	0	45
Third	3,662	3,626	0	36

The 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 stays high, cache_write_tokens drops to zero, and input_tokens moves only by the size of the changing user question.

These 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 endpoint publishes inference and token metrics to Amazon CloudWatch under the AWS/BedrockMantle namespace (see Monitor bedrock-mantle inference using CloudWatch metrics). 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.

Use caching in an agentic loop

Agentic 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:

import json

SYSTEM_PROMPT = "..."  # long runbook and instructions (>= 1,024 tokens)
MAX_TURNS = 10
TOOLS = [
    {"type": "function", "name": "get_service_health",
     "description": "Get health status for a microservice",
     "parameters": {"type": "object",
                    "properties": {"service": {"type": "string"}},
                    "required": ["service"]}},
    {"type": "function", "name": "get_recent_deploys",
     "description": "List deployments in the last N hours",
     "parameters": {"type": "object",
                    "properties": {"hours": {"type": "integer"}},
                    "required": ["hours"]}},
]
conversation = [
    {"type": "message", "role": "developer",
     "content": [{"type": "input_text",
                  "text": SYSTEM_PROMPT,
                  "prompt_cache_breakpoint": {"mode": "explicit"}}]},
    {"type": "message", "role": "user",
     "content": [{"type": "input_text",
                  "text": "Is checkout-service healthy? If not, was there a recent deploy?"}]},
]
for turn in range(MAX_TURNS):
    response = client.responses.create(
        model="openai.gpt-5.6-sol",
        prompt_cache_key="incident-agent:session-42",
        input=conversation,
        tools=TOOLS,
        extra_body={"prompt_cache_options": {"mode": "explicit", "ttl": "30m"}},
    )
    tool_calls = [o for o in response.output if o.type == "function_call"]
    if not tool_calls:
        print(response.output_text)
        break
    for call in tool_calls:
        # execute_tool is your implementation: call the real system
        # and return a JSON-serializable result
        result = execute_tool(call.name, json.loads(call.arguments))
        conversation.append({"type": "function_call", "call_id": call.call_id,
                             "name": call.name, "arguments": call.arguments})
        conversation.append({"type": "function_call_output", "call_id": call.call_id,
                             "output": json.dumps(result)})

The 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.

Choose between implicit and explicit caching

GPT-5.6 supports two caching modes, controlled by prompt_cache_options.mode:

• 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.

Explicit 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.

Your workload	Recommended mode
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
Stable prefix plus changing suffix (chat assistants, RAG, agentic tool loops)	Explicit, with one breakpoint after the static content
Multiple sections that change at different frequencies (tools, system prompt, long documents, conversation)	Explicit, with up to 4 breakpoints for granular control

If 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 is set consistently across the requests that should share a cache.

Migrate to GPT-5.6 from earlier GPT models

GPT-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.

Starting point 1: GPT-5.5 or GPT-5.4 on Amazon Bedrock

If 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:

response = client.responses.create(
    model="openai.gpt-5.6-terra",  # was: openai.gpt-5.5
    instructions=SYSTEM_PROMPT,
    input=user_input,
    max_output_tokens=1000,
)

Two things to fold into the upgrade:

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.

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.

Starting point 2: Responses API on another platform

If 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:

from openai import OpenAI
from aws_bedrock_token_generator import provide_token

REGION = "us-east-2"

client = OpenAI(
    base_url=f"https://bedrock-mantle.{REGION}.api.aws/openai/v1",  # 1. endpoint
    api_key=provide_token(region=REGION),  # 2. auth
)

response = client.responses.create(
    model="openai.gpt-5.6-terra",  # 3. model ID
    instructions=SYSTEM_PROMPT,
    input=user_input,
)

The 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.

Starting point 3: Chat Completions API on another platform

GPT-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:

Chat Completions	Responses API
messages=[{role, content}]	instructions="..." (system) plus input="..." or message list
max_completion_tokens	max_output_tokens
response.choices[0].message.content	response.output_text
tools=[{"type": "function", "function": {...}}]	tools=[{"type": "function", "name": ..., ...}] (flat)
choices[0].message.tool_calls[i].id	output[i].call_id
{"role": "tool", "tool_call_id": ...}	{"type": "function_call_output", "call_id": ...}
response.usage.prompt_tokens / completion_tokens	response.usage.input_tokens / output_tokens
stream=True with delta.content chunks	stream=True with typed events (response.output_text.delta)

Before and after, side by side:

# Before: Chat Completions on another platform
response = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {"role": "system", "content": "You are a concise assistant."},
        {"role": "user", "content": "What is Amazon Bedrock?"},
    ],
    max_completion_tokens=200,
)
print(response.choices[0].message.content)

# After: Responses API on Amazon Bedrock
response = client.responses.create(
    model="openai.gpt-5.6-terra",
    instructions="You are a concise assistant.",
    input="What is Amazon Bedrock?",
    max_output_tokens=200,
)
print(response.output_text)

The 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.

Validate and roll out

Whatever your starting point, treat the migration as a structured engineering project:

1. 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.
2. 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.
3. 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.
4. 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.

Conclusion

GPT-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.

To learn more, see the GPT-5.6 launch announcement and the Amazon Bedrock prompt caching documentation for full details on supported parameters and models. For pricing details, refer to the Amazon Bedrock pricing page. To monitor your workloads in production, see Monitor bedrock-mantle inference using CloudWatch metrics. Try GPT-5.6 with your own prompts in the Amazon Bedrock console, and share your feedback on AWS re:Post for Amazon Bedrock or through your usual AWS Support contacts.

---

About the authors

Melanie Li

Melanie Li, PhD, is a Senior Generative AI Specialist Solutions Architect at AWS based in Sydney, Australia, where her focus is on working with customers to build solutions using state-of-the-art AI/ML tools. She has been actively involved in multiple generative AI initiatives across APJ, harnessing the power of LLMs. Prior to joining AWS, Dr. Li held data science roles in the financial and retail industries.

Joe Magerramov

Joe is a VP/Distinguished Engineer at AWS. Joe has been with Amazon since 2005, and with AWS since 2014. At AWS Joe focuses his attention on EC2 networking, VPC, and ELB. Prior to AWS, Joe worked on the services responsible for Amazon.com’s payments, fulfillment, and marketplace systems. In his free time Joe enjoys learning more about physics and cosmology.

Chris Dickens

Chris is a Member of Product Staff at OpenAI focused on the OpenAI APIs. His work includes collaboration with AWS on Amazon Bedrock to make OpenAI’s frontier models widely accessible to developers.

Saurabh Trikande

Saurabh Trikande is a Senior Product Manager for Amazon Bedrock and Amazon SageMaker Inference. He is passionate about working with customers and partners, motivated by the goal of democratizing AI. He focuses on core challenges related to deploying complex AI applications, inference with multi-tenant models, cost optimizations, and making the deployment of generative AI models more accessible. In his spare time, Saurabh enjoys hiking, learning about innovative technologies, following TechCrunch, and spending time with his family.