Amazon Bedrock、OpenAI GPT-5.6 モデルの明示的プロンプトキャッシュを導入

*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)

Call tools and get structured output

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