AWS Builder Center

Builder Center

Invoking OpenAI Frontier Models GPT 5.4 & 5.5 through the Amazon Bedrock SDK

How to access OpenAI's GPT-5.4 and GPT-5.5 on Amazon Bedrock using SigV4 auth with notes on the Responses API shape, reasoning effort, and implicit prompt caching.

Arya Subramanyam

The Announcement

GPT-5.5, GPT-5.4, and Codex  — OpenAI's frontier reasoning and agentic models — can now be called using your existing AWS credentials, billed through your AWS account, and governed by the same IAM policies you already have in place. This post focuses on the GPT-5.4 and GPT-5.5 frontier models; Codex (OpenAI's coding agent powered by GPT-5.5, used by 4M+ developers weekly) is also available on the same endpoint and covered in the launch blog .
This is a significant shift for AWS builders. Until now, adding GPT to an AWS-native stack meant maintaining a separate OpenAI account, a separate API key rotation process, and a separate billing stream. With GPT on Amazon Bedrock, that's no longer the case. You get frontier OpenAI models alongside Anthropic Claude, Meta Llama, Amazon Nova, and the rest of the Bedrock model catalog — under one roof, with one authentication model. The integration was previewed at What's Next with AWS 2026  before GA, which gives a sense of how significant this partnership is.
The infrastructure making this possible is Mantle, Amazon Bedrock's next-generation distributed inference engine. This post covers what Mantle is, how to call GPT models through it (both via raw HTTP with SigV4 and via the OpenAI SDK), what the response shape looks like, and how to monitor your usage through the new Bedrock console.

What is Amazon Bedrock Mantle?

Mantle  is Amazon Bedrock's distributed inference engine for large-scale machine learning model serving. It's the infrastructure layer behind the bedrock-mantle endpoint — designed specifically to power OpenAI- and Anthropic-compatible APIs at scale.
A few things that make Mantle distinct from the standard bedrock-runtime:
  • OpenAI-compatible API surface — supports the OpenAI Responses API, Chat Completions API, and the Anthropic Messages API natively, so existing applications can migrate with minimal code changes
  • Stateful conversation management — the Responses API can store conversation state automatically, letting you reference previous turns via previous_response_id without manually passing full history in every request
  • Zero-operator access design — Mantle is built with a security model where AWS operators have no access to the model weights or customer inference data. For a deep dive on the architecture, see Exploring the zero-operator access design of Mantle 
  • Separate quota namespace — inference traffic to bedrock-mantle runs on a separate quota pool from bedrock-runtime, so GPT calls don't contend with your existing Bedrock workloads
  • Projects — a first-class organizational primitive that lets you scope API keys, track costs, and isolate observability by application or team (more on this below)
The bedrock-mantle endpoint follows this pattern:
1
https://bedrock-mantle.{REGION}.api.aws
Check the official docs  for the current list of supported regions — availability is expanding and the docs are the authoritative source.

Two Ways to Call GPT on Bedrock

The docs support two authentication approaches: Bedrock API keys (which work with the standard OpenAI SDK) and AWS credentials with SigV4 (for direct HTTP). Both talk to the same bedrock-mantle endpoint.

Option 1: OpenAI SDK (Recommended for Migration)

If you're migrating existing OpenAI code, this is the simplest path. Install the OpenAI Python SDK and point it at your Bedrock endpoint:
1
pip install openai boto3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
from openai import OpenAI

client = OpenAI(
base_url="https://bedrock-mantle.us-east-2.api.aws/openai/v1",
api_key="<your-bedrock-api-key>", # NOT your OpenAI API key
)

response = client.responses.create(
model="openai.gpt-5.4",
input=[
{
"role": "developer",
"content": "You are an expert AWS solutions architect. Be concise and practical.",
},
{
"role": "user",
"content": "Explain the difference between SigV4 and API key auth on Amazon Bedrock.",
},
],
reasoning={"effort": "low"},
)

print(response.output_text)
⚠️ Use your Amazon Bedrock API key, not your OpenAI API key. Set OPENAI_BASE_URL to your Bedrock regional endpoint — not https://api.openai.com/v1. The two are completely separate; using the wrong base URL routes your calls (and billing) to OpenAI directly. See API keys in Amazon Bedrock  for how to create a Bedrock API key.
To list available models via the SDK:
1
2
3
models = client.models.list()
for model in models.data:
print(model.id)

Option 2: Raw HTTP with SigV4 (No API Key Required)

If you're building AWS-native and want to use IAM roles directly — no API key management — you can sign requests with SigV4 using botocore. The required IAM permission is bedrock-mantle:CreateInference.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
import json, time, boto3, requests
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest

REGION = "us-east-2"
ENDPOINT = f"https://bedrock-mantle.{REGION}.api.aws/openai/v1/responses"

# Standard boto3 credential chain — IAM role, env vars, ~/.aws/credentials
_session = boto3.Session()
_creds = _session.get_credentials().get_frozen_credentials()

def call(model: str, input_, reasoning_effort=None) -> tuple[dict, float]:
payload = {"model": model, "input": input_}
if reasoning_effort:
payload["reasoning"] = {"effort": reasoning_effort}

payload_json = json.dumps(payload)
req = AWSRequest(
method="POST",
url=ENDPOINT,
data=payload_json,
headers={"Content-Type": "application/json"}
)
SigV4Auth(_creds, "bedrock-mantle", REGION).add_auth(req)

t0 = time.perf_counter()
r = requests.post(ENDPOINT, headers=dict(req.headers), data=payload_json, timeout=120)
elapsed = time.perf_counter() - t0

r.raise_for_status()
return r.json(), elapsed
IAM policy required:
1
2
3
4
5
{
"Effect": "Allow",
"Action": "bedrock-mantle:CreateInference",
"Resource": "*"
}
For credentials setup, see the boto3 credentials guide  and AWS Signature Version 4 .

The Response Structure (Read This Before You Ship)

The Responses API on Bedrock returns a subtly different shape from calling OpenAI directly. The most important gotcha: the top-level text field is not a string — it's a config object. The actual response text lives in output[].content[].text.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
"text": {"format": {"type": "text"}}, // NOT the response — this is config
"output": [
{
"content": [
{"text": "Paris is the capital of France.", "type": "output_text"}
]
}
],
"usage": {
"input_tokens": 15,
"output_tokens": 9,
"input_tokens_details": {
"cached_tokens": 0
}
}
}
The cached_tokens field also lives under input_tokens_details on Bedrock, not prompt_tokens_details as on OpenAI Direct. Use the wrong key and you'll always read zero.
A safe extraction helper for the raw HTTP path:
1
2
3
4
5
6
7
8
9
10
11
def extract_text(resp: dict) -> str:
# Top-level "text" on Bedrock is NOT a string — skip it
if "text" in resp and isinstance(resp["text"], str):
return resp["text"]

# Primary path for Bedrock Responses API
for msg in resp.get("output", []):
for item in msg.get("content", []):
if isinstance(item.get("text"), str):
return item["text"]
return ""

Reasoning Effort

GPT models support a reasoning.effort parameter: "low", "medium", or "high". Higher effort means the model "thinks" longer before responding — useful for multi-step reasoning tasks, but it directly trades off against latency.
1
2
3
4
5
# Fast, good for most production use cases
resp, t = call("openai.gpt-5.4", "Solve this step by step: ...", reasoning_effort="low")

# Slower, better for complex analytical tasks
resp, t = call("openai.gpt-5.4", "Solve this step by step: ...", reasoning_effort="high")
Default to "low" for production inference. Only go higher when reasoning quality on a specific task is measurably better and worth the latency cost.

Implicit Prompt Caching (IPC)

OpenAI's Implicit Prompt Caching  automatically caches repeated prompts of 1,024+ tokens — and this works on Bedrock too, with no configuration required.
For context, Amazon Bedrock also supports explicit prompt caching (using cachePoint markers) for models that support it — though this is not currently supported for GPT models on the bedrock-mantle endpoint. See Prompt caching for faster model inference   for details.

Checking for cache hits

1
2
3
4
5
usage = resp.get("usage", {})
cached = usage.get("input_tokens_details", {}).get("cached_tokens", 0)
total = usage.get("input_tokens", 0)
hit_rate = f"{cached/total*100:.1f}%" if total > 0 else "n/a"
print(f"Cached: {cached}/{total} tokens — {hit_rate}")

The New Bedrock Mantle Console

Soon after the GPT launch, AWS shipped a redesigned Amazon Bedrock console  optimized specifically for the bedrock-mantle endpoint. You can access it from within the Amazon Bedrock console or directly at bedrock-mantle.{region}.console.aws.amazon.com.
What you get in the new console:
  • Model catalog — browse GPT, Claude, and open-weight models side by side with capability comparisons, context window sizes, pricing, and Regional availability in a single view — no more cross-referencing docs and limit calculators separately
  • Projects — a first-class organizational unit that scopes API keys, groups usage, and gives you per-project dashboards. Projects are free; you pay only for underlying inference
  • Usage dashboards — token usage per minute, inference requests per minute, tokens per request, and model distribution — all at the project level, helping you make informed decisions about model selection and prompt optimization
  • Model comparison — run the same prompt against up to 3 models simultaneously to compare output quality before committing to a choice
  • Live API docs — automatically prefilled with your project's model ID, endpoint, and API key reference, so you can copy a working snippet directly into your app
The Projects API  is also available programmatically, giving you application-level isolation for access control, cost tracking, and observability across teams.

Observability and Monitoring

CloudWatch Metrics

Amazon Bedrock now publishes CloudWatch metrics for the  bedrock-mantle endpoint , at the account, project, and model level. This means you can build the same dashboards and alarms you use for other AWS services.
Key metrics available in the AWS/BedrockMantle namespace (see full reference ):
MetricDescription
TotalInputTokensAggregate billable input tokens
TotalOutputTokensAggregate billable output tokens
InputTokensPer-inference input token count
OutputTokensPer-inference output token count
InferenceRequestsCount of completed inference calls
InvocationLatencyEnd-to-end latency per request
These are published at account, project, and model granularity — making it straightforward to attribute costs to a specific application or team. If your organization already has AWS-native observability tooling, you don't need to build a separate pipeline for GPT usage.

Summary

GPT-5.4 and GPT-5.5 are fully accessible on Amazon Bedrock via the Responses API on the bedrock-mantle endpoint. You can authenticate with either a Bedrock API key (for use with the OpenAI SDK) or AWS credentials via SigV4 — both routes are supported and practical depending on your stack. Reasoning effort (low, medium, high), implicit prompt caching for prompts, and stateful multi-turn conversations via previous_response_id. Observability is AWS-native: CloudWatch metrics are available at the account, project, and model level, and the Projects API lets you scope usage and costs by application or team.

Resources

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article