Bedrock adds reasoning summaries for OpenAI models on the Responses API

What did AWS announce on 9 October?

Amazon’s What’s New item for 9 October 2026 states that Bedrock supports the reasoning.summary parameter for OpenAI models through the Responses API. AWS frames the feature as a way to request a human-readable summary of how a model approached coding, analysis, or multi-step work, returned with the answer.

The same note says the summary appears in the summary array of the reasoning output item. Availability, per AWS, covers all OpenAI models on Bedrock wherever those GPT models are offered, and includes in-Region inference plus geographic (GEO) and global cross-Region inference.

This is a Bedrock product change, not a new OpenAI model family. For how reasoning models are usually explained outside a cloud wrapper, see our DeepSeek-R1 reasoning explainer.

Reasoning summaries on Bedrock’s OpenAI-compatible Responses path are a platform affordance: you ask the API to return a shorter, auditable summary of a model’s hidden reasoning trace according to AWS’s field names. That is not the same as OpenAI’s consumer ChatGPT UI, and it is not a promise that every OpenAI-branded model on Bedrock exposes identical summary behaviour.

How do you request a summary on Bedrock?

OpenAI’s reasoning guide describes the Responses API pattern: set reasoning.summary (for example to auto) when creating a response, then read summary_text entries from reasoning items in the output array. Raw reasoning tokens are not exposed; the summary is an opt-in window into the model’s intermediate process.

AWS’s What’s New points readers to that OpenAI documentation and to Bedrock’s OpenAI-on-Bedrock getting-started material. Bedrock’s own Responses API user guide documents the OpenAI-compatible endpoints on bedrock-runtime and bedrock-mantle, including base URLs, model ID rules, and storage behavior for previous_response_id.

On bedrock-runtime, AWS’s guide says closed-weight OpenAI GPT models must be named with system inference profiles such as us.openai.gpt-5.6-sol or global.openai.gpt-5.6-sol, and that model must be present on every request—including follow-ups that supply previous_response_id.

Copy the request shape from AWS’s dated announcement and the Responses API docs you open the same day—field names drift across previews. Log whether the summary is billed as output tokens, whether it can be disabled per request, and what redaction AWS applies before the summary leaves the service boundary.

What is Bedrock’s Responses path, and what is it not?

OpenAI’s help article on Responses API support on Amazon Bedrock states that AWS provides and operates an OpenAI-compatible implementation for supported models. Requests go to Bedrock with Bedrock authentication; the OpenAI-hosted Responses API is not in the request path.

OpenAI’s Bedrock feature matrix lists many Responses capabilities as available, and also lists gaps—hosted file search, remote MCP, shell tool, and several other hosted tools are marked unavailable on Bedrock. Reasoning effort is listed as available; “reasoning updates” are not. Read the matrix on OpenAI’s OpenAI on Amazon Bedrock guide before assuming parity.

That separation matters for security reviews as much as for features. Earlier agent-platform reporting on AWS remains a different storyline; see Zenity’s AgentCore findings for an unrelated AgentCore report, not a Bedrock Responses bug.

Who benefits, and what should you measure?

Teams that already debug agent traces on Bedrock get a vendor-supported summary channel without leaving AWS billing and IAM. Product UIs that show “how the model thought” can surface summary_text instead of inventing their own post-hoc explanations.

Summaries are still model-generated text. They are not a cryptographic proof of the hidden chain of thought, and they are not a substitute for eval harnesses that score final answers. For why multiple samples can still share a wrong plan, see self-consistency in reasoning.

AWS’s note does not publish latency, token, or price deltas for enabling summaries. Measure output tokens and end-to-end latency on your own workloads before assuming the summary is free.

Ops and compliance teams want summaries for ticket trails; agent builders want them for cheaper downstream routers. Measure both faithfulness (does the summary omit a tool failure?) and leakage (does it echo secrets from the trace?). Neither property is established by the launch note alone.

What limits does AWS leave explicit?

Availability is scoped to Regions where OpenAI GPT models are already on Bedrock. The What’s New item does not list every model ID or every summarizer mode (auto vs detailed vs concise); those details sit in OpenAI’s model docs and Bedrock model cards.

Bedrock Runtime and Mantle differ on background mode, hosted web search, and some inheritance rules around previous_response_id. A summary feature does not erase those endpoint differences.

Stored Responses on Bedrock default to retention behavior described in AWS’s guide; teams with residency requirements need geographic profiles and an explicit store:false policy where appropriate. That is AWS’s retention documentation, not something we retested.

Region availability, model IDs, and preview-versus-GA language on the announcement page are the deployment constraints. If your agents already store full reasoning traces, decide whether summaries replace raw traces in logs or sit beside them; that retention choice is yours, not AWS’s marketing bullet.

What did we not test?

We did not create a Bedrock API key, call /openai/v1/responses with reasoning.summary, or compare summary quality across GPT SKUs. This article reports the AWS What’s New item, Bedrock Responses documentation, and OpenAI Bedrock/reasoning pages we opened on 10 October 2026.