Get Started with GPT-5.6 on Amazon Bedrock in 15 Minutes
OpenAI's GPT-5.6 (Sol / Terra / Luna) is now generally available on Amazon Bedrock. This walkthrough takes you from zero to running in six steps: set up, first call, compare all three tiers, sweep all six reasoning effort levels, cut the cost of repeated input to a tenth with prompt caching, and finally let the model call a real MCP tool. It all runs through your own AWS account with no OpenAI API key. Every command is copy-pasteable and every number is measured, not estimated.
Series: OpenAI Models on Amazon Bedrock (1 article)
- 1Get Started with GPT-5.6 on Amazon Bedrock in 15 Minutes This article
OpenAI's GPT-5.6 comes in three tiers — Sol, Terra and Luna — and you can now call them on Amazon Bedrock through your own AWS account, with no OpenAI API key.
This takes the shortest path: clone, run, understand the output. Every command is copy-pasteable, every number below came from a real run, and you should see the same order of magnitude on your own account.
Full code | github.com/hanyun2019/openai-bedrock-samples
Background: two things worth knowing first
GPT-5.6 became generally available on Amazon Bedrock in July 2026. Two things are worth understanding before you start.
First, Sol / Terra / Luna are not version numbers. The 5.6 identifies the generation; Sol, Terra and Luna are three capability tiers that can each advance on their own cadence. So the question when choosing is "how much reasoning does this task need", not "which one is newer". Per OpenAI's published evaluations, Sol is their strongest reasoning model to date, clearly ahead of the previous generation on coding-agent and security-research work while spending fewer output tokens; Terra
beats the previous generation at lower cost; Luna targets high volume and low latency. Sol also gets one extra reasoning level,
beats the previous generation at lower cost; Luna targets high volume and low latency. Sol also gets one extra reasoning level,
max.Second, why run this on Bedrock instead of calling OpenAI directly. All three points below come from the AWS GA announcement (linked in the appendix):
- Inference stays in the AWS Region you specify, which helps with data residency
- Every call goes through your own IAM policies, inside your VPC, and lands in CloudTrail
- Pricing matches OpenAI's first-party rates, and usage counts toward your existing AWS commitments
Now let's build.
What you need
- Python 3.10 or newer
- An AWS account with working credentials (
~/.aws/credentialsorAWS_PROFILE) - GPT-5.6 available in your target Region, and an IAM identity permitted to call Bedrock
Confirm your credentials resolve. If you have the AWS CLI:
1
aws sts get-caller-identity
If it prints your account and identity, you're good. The AWS CLI is not required — the examples never call it, and credentials are read through the Python SDK. Without it, run this equivalent check after step 1 installs the dependencies:
1
python -c "import botocore.session as s; print('credentials found' if s.get_session().get_credentials() else 'NO credentials')"
Step 1: Set up
1
2
3
4
5
6
git clone https://github.com/hanyun2019/openai-bedrock-samples.git
cd openai-bedrock-samples
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txt
You don't set an API key. That's the biggest difference from calling OpenAI directly: the code uses your AWS credentials to mint a short-lived Bedrock token before every request.
openai>=2.45.0 is a hard requirement, because that's where the BedrockOpenAI client lives.Step 2: First call
1
python -m src.gpt56.hello
1
2
3
4
5
6
7
8
9
10
============================================================
Tier : terra
Model ID : openai.gpt-5.6-terra
Region : us-east-1
Usage : in=20 out=36 total=56
reasoning=0
============================================================
I'm best suited for understanding and generating text, answering
questions, summarizing and analyzing information, ...
============================================================
Working. Only one thing here is worth memorizing: run with
-m, not a file path.1
2
python -m src.gpt56.hello # correct
python src/gpt56/hello.py # ImportError
The example modules use relative imports, and running a file directly leaves Python with no idea which package it belongs to.
The whole project has exactly one essential file,
src/gpt56/client.py. It does two things: validate the tier/Region combination, and build a client whose token renews itself. Everything else imports it.Step 3: Which tier?
The short version:
| Tier | Model ID | When to use it |
|---|---|---|
| Sol | openai.gpt-5.6-sol | Complex refactoring, long reasoning chains, security research |
| Terra | openai.gpt-5.6-terra | Everyday production. Start here |
| Luna | openai.gpt-5.6-luna | Classification, summarization, routing — high volume, low latency |
Here's the problem it uses:
It deliberately splits the information in two: the vertex form hides "the maximum is at x=3", and g(3) has to be looked up in the table. The model has to combine both rather than pattern match its way to an answer. The answer is B.
Same problem, all three tiers:
1
python -m src.gpt56.compare_tiers
1
2
3
4
5
6
7
built-in text problem · effort=low · region=us-east-1
Correct answer: B (k=3, g(3)=6)
==============================================================================
tier sec in out reasoning answer
sol 2.4 133 79 0 B
terra 1.5 133 67 0 B
luna 1.5 133 95 25 B
All three got it right, and that's the point: on an easy task, the expensive tier does not buy you a better answer. On this run Terra was also faster than Sol and spent fewer output tokens. Tier differences only show up on hard problems.
The exact numbers drift run to run (a rerun gave me 87 output tokens for sol and 85 for terra, with the timings reordered), so don't anchor on any single figure. The conclusion is what matters: all three got it right, so paying more bought nothing here.
So work upward: start on Terra, move to Sol when Terra isn't enough — not the other way around.
One gotcha that will actually raise an error: Sol exists only in
us-east-1 and us-east-2, while Terra and Luna add us-west-2. client.py catches this before any request goes out:1
2
ValueError: GPT-5.6 sol is not available in us-west-2.
Available Regions: us-east-1, us-east-2
Step 4: Reasoning effort
GPT-5.6 reasons before it answers, and
reasoning.effort controls how hard. Six levels: none, low, medium, high, xhigh, max.This step switches to an algebra problem:
It needs exactly one exponent-rule transformation (dividing powers subtracts the exponents, so 3x - y substitutes straight in). That looks trivial, but the single transformation is the reasoning step — which makes it a good probe for whether
a unique answer. The correct answer is A.
effort is doing anything. D is the trap: x and y really are individually undetermined, but the expression only depends on the combination 3x - y, so there isa unique answer. The correct answer is A.
Sweep them:
1
python -m src.gpt56.effort_sweep terra
1
2
3
4
5
6
7
8
9
10
Model: openai.gpt-5.6-terra @ us-east-1
Correct answer: A 1 run(s) per level
effort sec in out reasoning answer
none 3.1 83 79 0 A OK
low 1.2 83 73 0 A OK
medium 2.9 83 115 30 A OK
high 1.1 83 116 32 A OK
xhigh 1.7 83 121 43 A OK
max 1.7 83 126 46 A OK
Two columns tell the story.
The
reasoning column climbs from 0 to 46. That is what effort buys: an amount of thinking.The
in column is flat at 83. The prompt didn't change, so input doesn't either — effort only affects the output side. Which means raising effort only raises output cost.Meanwhile
sec is all over the place (3.1 → 1.2 → 2.9 → 1.1). Don't read "higher effort is slower" out of a single run. Network jitter alone swamps the difference, and per the AWS docs the bedrock-mantle endpoint may briefly queue a request while in-flight work completes and throughput frees up. That's by design — it trades queueing for higher initial throughput limits — not a fault, but it makes a single timing measurement even less meaningful.The
reasoning column also comes out unordered in a single run. Another run gave me 0, 0, 33, 28, 31, 40 — high spent less than medium. The upward trend is real, but one sample doesn't clear the noise. Average a few runs per level to see it:1
python -m src.gpt56.effort_sweep terra 3
1
2
3
4
5
6
7
effort sec in out reasoning accuracy answers
none 1.5 83 80 0 3/3 A, A, A
low 1.3 83 77 0 3/3 A, A, A
medium 1.4 83 103 22 3/3 A, A, A
high 1.4 83 111 31 3/3 A, A, A
xhigh 1.5 83 117 33 3/3 A, A, A
max 1.6 83 121 49 3/3 A, A, A
Averaged, it's monotonic:
0, 0, 22, 31, 33, 49. This problem isn't hard — 18 out of 18 correct — so what you're seeing is the cost gradient, not an accuracy difference.One thing you do need to know: reasoning tokens are billed as output tokens, and they draw down your
max_output_tokens budget. Set that budget too low and reasoning can consume all of it, leaving you a status="incomplete" response with empty text. The examples default to 32000 to stay clear of this.Practical advice: start at
low. none gets a reasoning budget of zero, which is fine for extraction and formatting, but anything needing even one inference step belongs at low or above.Step 5: Saving money with prompt caching
If you ask repeated questions against the same long document — the shape of RAG and document Q&A — caching pays off.
1
python -m src.gpt56.prompt_cache
The script uses the opening of Moby-Dick (1851, public domain) as a reference document and asks two different questions against the same prefix:
1
2
Q1: In two sentences, what is the narrator's stated reason for going to sea?
Q2: In two sentences, describe the mood of the opening chapter.
One asks for a fact, the other for atmosphere, but both are scoped to that document. This is exactly the shape where caching pays off most: the document stays fixed, the questions change.
1
2
3
4
Reference doc: first 12000 chars of Moby-Dick (public domain)
[] input=3002 cached=0 written=2980 hit_rate=0.0%
[] input=2998 cached=2980 written=0 hit_rate=99.4%
The second call hit cache on 99.4% of its input. Cached input bills at 10% of the uncached rate (writes bill at 1.25x) and doesn't count against your input TPM quota — that's where the savings come from, so write-once, read-many wins. (The first run downloads the full text from Project Gutenberg; a few
IncompleteRead retries are normal.)The trap that catches everyone: the cached prefix must be at least 1,024 tokens. Below that nothing is cached and no error is raised —
cached just stays 0 forever. You'll assume your code is wrong when the prefix is simply too short.One more thing that looks wrong but isn't: run that same
python -m src.gpt56.prompt_cache again right away, and this time call 1 reports a hit too:1
[] input=3002 cached=2980 written=0 hit_rate=99.3%
Labelled cache write, yet 99.3% cached. That's correct — the cache written by the previous run is still inside its retention window (at least 30 minutes), so this run's first call reads it. The label describes which call it is in the script, not a guarantee that this particular call writes the cache.
Step 6 (optional): Function calling and MCP
The first five steps are all ask-once, answer-once. This step lets the model call external tools, which is where agents start. Skip it if you're not building one. The repo has two versions. The protocol is identical; only the source of the tools differs.
Version one: a stub function, to see the protocol clearly
1
python -m src.gpt56.tool_calling
1
2
3
4
5
6
Model: openai.gpt-5.6-terra @ us-east-1
-> model requested get_weather({'location': 'Seattle, US', 'unit': 'fahrenheit'}) -> returned {'location': 'Seattle, US', 'temperature': 18, 'condition': 'Partly cloudy'}
Final answer:
Seattle is currently **18°F** and **partly cloudy**.
One full round trip is three steps: send your tool definitions in
tools= → the model replies with a function_call naming the tool and its arguments → you execute it locally and send the result back as a function_call_output, paired to that call via call_id. Your code always executes the tool; the model only decides whether to call it and with what arguments.Version two: a real MCP server, returning real data
MCP (Model Context Protocol) is an open protocol that connects AI models to external tools and data sources. This example uses AWS documentation MCP server:
- Read-only access to public docs - no AWS permissions needed
- Requires uv/uvx (install first)
- First run downloads the server automatically
1
python -m src.gpt56.mcp_tools
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Starting MCP server: awslabs.aws-documentation-mcp-server ...
MCP offers 5 tools; bridging 2 to the model: ['read_documentation', 'search_documentation']
Model: openai.gpt-5.6-terra @ us-east-1
Question: Using the AWS documentation tools, find the model ID and the AWS Regions for GPT-5.6 Sol on Amazon Bedrock. ...
[] model called MCP tool search_documentation
[] model called MCP tool read_documentation
Final answer (turn 3):
The Amazon Bedrock model ID for GPT-5.6 Sol is `openai.gpt-5.6-sol`.
It is available for in-Region inference in `us-east-1` (N. Virginia) and `us-east-2` (Ohio).
Source: [AWS documentation—GPT-5.6 Sol](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-56-sol.html).
The model planned two steps on its own: search first, then read the specific page, and only answered on turn 3 — with a citation to the official URL, genuinely read out of the docs rather than invented.
In code, the only difference from version one is where the tools come from: instead of hand-written definitions, they're translated from the MCP server's
list_tools() into the Responses API function format, and execution forwards to session.call_tool() instead of a local function. The protocol part is unchanged.Two things worth knowing:
- Don't hand the model every tool an MCP server offers. This one exposes 5; the example allows 2. Tool definitions cost input tokens and raise the chance the model picks the wrong one
- Set a turn limit. My first attempt asked something too broad ("which reasoning levels are supported") and the model kept searching without converging. Asking a specific question and telling it to stop once it had the two facts got it done on turn 3
Error cheat sheet
Errors you might hit at any of the steps above, listed by the message you see.
| What you see | Why |
|---|---|
| ImportError: attempted relative import... | You ran a file path; use python -m |
| ValueError: GPT-5.6 sol is not available in... | Sol has no us-west-2 |
| status="incomplete" with empty text | Reasoning ate max_output_tokens; raise it or lower effort |
| cached stuck at 0 | Cached prefix is under 1,024 tokens |
| HTTP 429 | Throttled. The client already sets max_retries=6; or spread the work out |
| AccessDeniedException | Missing permissions. Check that IAM allows calling Bedrock and that no SCP explicitly denies it |
| 401 Unauthorized: Signature expired | The short-lived Bedrock token expired (12 hours max). The examples renew it automatically; you'll normally only see this with Codex |
| command not found: aws | No AWS CLI. It's optional — use the botocore check above instead |
Wrapping up
At this point you've run GPT-5.6 end to end on your own AWS account: environment set up, first call out, all three tiers compared side by side, all six effort levels swept, caching cutting repeated input to a tenth of the price, and the model calling a real external tool. None of it is a mock-up — it's code you can lift into a project.
Two directions from here. Point the Codex CLI at Bedrock so your coding agent's reasoning also runs through your own account — that works quite differently from the calls above, and the repo README covers it end to end. Or take the two examples from Step 6 as a skeleton and swap in your own tools to build an agent.
Full code | github.com/hanyun2019/openai-bedrock-samples
Happy agentic AI coding!
Appendix: References
AWS documentation
- GPT-5.6 Sol, Terra, and Luna are now generally available on Amazon Bedrock
— the GA announcement and the source for the background section above: tier positioning, benchmark results, the inference engine, and the security model - GPT-5.6 Sol model card — authoritative source for model IDs and Regions
- Endpoints supported by Amazon Bedrock — explains the split between the
bedrock-mantleandbedrock-runtimeendpoints, and the different throughput and quota model each uses. - Amazon Bedrock pricing — current rates.
- Bedrock API keys permissions — calling the Responses API needs the
bedrock-mantle:CallWithBearerTokenaction. - Request access to models — how model access permissions work.
OpenAI documentation
- Getting Started with OpenAI Models on Amazon Bedrock — the official OpenAI Cookbook guide. Covers the advanced surface this post skips: structured outputs, JSON mode, server-side state, encrypted reasoning context, background work, direct PDF input, custom tools, and compaction.
- Reasoning models — the official reference for
reasoning.effort
Tools and dependencies
- Installing uv / uvx — required by
mcp_tools.py - awslabs/mcp — AWS's collection of MCP servers; the AWS Documentation MCP Server used here comes from it
- Codex on Amazon Bedrock — pointing Codex at Bedrock
Material used in the examples
- Moby-Dick, Project Gutenberg #2701 — the reference document in
prompt_cache.py; published 1851, public domain
Code
- openai-bedrock-samples — every example in this post
Series: OpenAI Models on Amazon Bedrock (1 article)
- 1Get Started with GPT-5.6 on Amazon Bedrock in 15 Minutes This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article