I Tried Testing How Compatible Bedrock Mantle's Responses API Is with Azure
This page has been translated by machine translation. View original
In the previous article, I used Codex CLI v0.124.0 to connect to the Bedrock Mantle Responses API and confirmed that a coding agent can be used with AWS authentication alone.
For the basic usage of the Responses API on Bedrock Mantle, please also refer to Takakuni's article.
In February 2026, OpenAI and Amazon announced a strategic partnership, including the joint development of a Stateful Runtime Environment running on Bedrock. About two months later, on April 28, Amazon CEO Andy Jassy said that the availability of OpenAI models on Bedrock would begin within a few weeks.
Meanwhile, on Azure AI Foundry, the Responses API has been GA since 2025, and its full feature set is available, including stateful conversations via previous_response_id and server-side tools (web_search, code_interpreter, file_search).
The main event is the upcoming GPT-5 family of models, but in preparation for their arrival, this time I'll use models that work today to do some practice swings on the portability of the Responses API and the architectural differences.
Test Environment
| Azure AI Foundry | Bedrock Mantle | |
|---|---|---|
| Region | East US 2 | us-east-1 |
| Model | gpt-4.1-mini | openai.gpt-oss-120b |
| Endpoint | /openai/v1/responses |
/v1/responses |
| Authentication | API Key | AWS IAM (SigV4) |
Because the models that support the Responses API differ between Azure and Bedrock, I used the models available on each. Azure supports many models including the GPT-5 family, but Bedrock supports only two models: openai.gpt-oss-120b and openai.gpt-oss-20b (verified in the first article). Also, gpt-oss-120b on Azure does not support the Responses API (Chat Completions only), so a comparison using the same model is not possible.
The axes of comparison are not model performance differences, but narrowed down to compatibility of the Responses API response structure and differences in tool support.
Stateful Conversations (previous_response_id)
When you use previous_response_id in the Responses API, the conversation history is retained on the server side, so you can carry over context without managing the history on the client side. However, internally the past inputs and outputs are included in the prompt and billed, so the number of billable tokens may increase as turns progress. You need to choose how to use it according to your workload.
As a practical scenario, I tried error log analysis for an ECS task.
Azure AI Foundry
In Turn 1, I send a CloudWatch error log. gpt-41-mini in the curl command is the deployment name (because a period cannot be included when deploying the model name gpt-4.1-mini).
curl -s "${ENDPOINT}openai/v1/responses" \
-H "Content-Type: application/json" \
-H "api-key: ${KEY}" \
-d '{
"model": "gpt-41-mini",
"instructions": "You are a DevOps engineer assistant. Be concise.",
"input": "Our ECS task keeps failing. Here is the error from CloudWatch:\n\nResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth: service call has been retried 3 time(s): RequestError: send request failed caused by: Post https://api.ecr.us-east-1.amazonaws.com/: dial tcp 10.0.1.42:443: i/o timeout"
}'
Response (extracted with jq '{id, object, status, output: [.output[] | {type, content}]}'):
{
"id": "resp_087784ee8eba51a60069f0bed6d29c819585e6d3c2530c9844",
"object": "response",
"status": "completed",
"output": [
{
"type": "message",
"content": [
{
"type": "output_text",
"text": "The ECS task is failing because it cannot retrieve ECR registry auth due to a network timeout when trying to reach the ECR endpoint.\n\n**Likely causes:**\n1. The ECS task's subnet does not have proper internet access or NAT gateway configured.\n2. Security group or NACL blocking outbound HTTPS (port 443).\n3. Missing or incorrect VPC endpoint for ECR if running in a private subnet without internet.\n\n**Actions to fix:**\n- Ensure the ECS tasks are in subnets with NAT Gateway or Internet Gateway for outbound HTTPS access.\n- Check and allow outbound port 443 in Security Groups and NACLs.\n- Alternatively, configure VPC Endpoints for ECR (`com.amazonaws.us-east-1.ecr.api` and `com.amazonaws.us-east-1.ecr.dkr`) and for S3 if needed to avoid internet dependency."
}
]
}
]
}
In Turn 2, I follow up with previous_response_id attached. The error log is not resent.
curl -s "${ENDPOINT}openai/v1/responses" \
-H "Content-Type: application/json" \
-H "api-key: ${KEY}" \
-d '{
"model": "gpt-41-mini",
"input": "What VPC networking changes should I check? Give me the AWS CLI commands.",
"previous_response_id": "resp_087784ee8eba51a60069f0bed6d29c819585e6d3c2530c9844"
}'
VPC troubleshooting steps and AWS CLI commands (aws ec2 describe-route-tables, aws ec2 describe-nat-gateways, aws ec2 describe-security-groups, aws ec2 describe-vpc-endpoints, etc.) were returned, taking into account the context from Turn 1 (connection timeout to the ECR endpoint).
Bedrock Mantle
I tried the same scenario on Bedrock as well.
# Turn 1
curl -s --aws-sigv4 "aws:amz:us-east-1:bedrock-mantle" \
--user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" \
-H "x-amz-security-token: ${AWS_SESSION_TOKEN}" \
-H "Content-Type: application/json" \
-X POST "https://bedrock-mantle.us-east-1.api.aws/v1/responses" \
-d '{
"model": "openai.gpt-oss-120b",
"instructions": "You are a DevOps engineer assistant. Be concise.",
"input": "Our ECS task keeps failing. Here is the error from CloudWatch:\n\nResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth: service call has been retried 3 time(s): RequestError: send request failed caused by: Post https://api.ecr.us-east-1.amazonaws.com/: dial tcp 10.0.1.42:443: i/o timeout"
}'
Response (extracted with the same jq filter, reasoning type omitted):
{
"id": "resp_pbknkjxqs4ekzxoujxftabh2msmflyzyb4yfge4rs3zg3gazjtjq",
"object": "response",
"status": "completed",
"output": [
{
"type": "message",
"content": [
{
"type": "output_text",
"text": "## TL;DR\n\nThe error means the task's execution role cannot reach the Amazon ECR public endpoint (or the VPC endpoint you've set up for it). In practice this is almost always a networking problem (security group, subnet routing, NAT/Internet gateway, VPC endpoint, DNS, or a mis-configured task execution role).\n\n..."
}
]
}
]
}
# Turn 2: with previous_response_id
curl -s --aws-sigv4 "aws:amz:us-east-1:bedrock-mantle" \
--user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" \
-H "x-amz-security-token: ${AWS_SESSION_TOKEN}" \
-H "Content-Type: application/json" \
-X POST "https://bedrock-mantle.us-east-1.api.aws/v1/responses" \
-d '{
"model": "openai.gpt-oss-120b",
"input": "What VPC networking changes should I check? Give me the AWS CLI commands.",
"previous_response_id": "resp_pbknkjxqs4ekzxoujxftabh2msmflyzyb4yfge4rs3zg3gazjtjq"
}'
On Bedrock as well, VPC troubleshooting steps and AWS CLI commands based on the Turn 1 error log were returned.
Compatibility Check
Placing both responses side by side, the JSON structure (id, object, status, output[]) is in the same format, and the message → content → output_text hierarchy within the output array was also the same. The Bedrock response also includes reasoning type output, but the structure of the message type is identical to Azure.
Because the models differ (gpt-4.1-mini vs gpt-oss-120b), I did not compare token consumption or response speed.
Comparison of Tool Support
| Tool | Azure | Bedrock | Notes |
|---|---|---|---|
function |
✅ | ✅ | |
mcp |
✅ (server_url) | ⚠️ (connector_id) | Connection methods differ* |
web_search |
✅ | ❌ | |
code_interpreter |
✅ | ❌ | Azure executes code and returns results |
file_search |
✅ | ❌ |
- MCP is accepted by both, but Azure connects directly via
server_url, while Bedrock requires connection through an AWS-side connector viaconnector_id.
function tool — works on both
I sent requests to both with the same function definition.
# Azure
curl -s "${ENDPOINT}openai/v1/responses" \
-H "Content-Type: application/json" \
-H "api-key: ${KEY}" \
-d '{
"model": "gpt-41-mini",
"input": "What is the weather in Tokyo?",
"tools": [{"type": "function", "name": "get_weather", "description": "Get weather", "parameters": {"type": "object", "properties": {"city": {"type": "string"}}}}]
}'
I sent the same payload to Bedrock (only the model name, endpoint, and authentication method differ), and both returned a function_call. The output structure was also identical.
code_interpreter tool — Azure only
On Azure, Python code can be executed on the server side.
curl -s "${ENDPOINT}openai/v1/responses" \
-H "Content-Type: application/json" \
-H "api-key: ${KEY}" \
-d '{
"model": "gpt-41-mini",
"input": "Calculate the first 10 Fibonacci numbers using Python.",
"tools": [{"type": "code_interpreter", "container": {"type": "auto"}}]
}'
The response output included a code_interpreter_call type, and the executed code and results were returned.
{
"output": [
{"type": "message", "content": [{"type": "output_text", "text": "Sure! Here's a Python code snippet..."}]},
{"type": "code_interpreter_call", "code": "def fibonacci(n):\n fib = [0, 1]\n ..."},
{"type": "message", "content": [{"type": "output_text", "text": "The first 10 Fibonacci numbers are:\n\n0, 1, 1, 2, 3, 5, 8, 13, 21, 34"}]}
]
}
Tools Not Supported on Bedrock
When specifying web_search, code_interpreter, or file_search on Bedrock, the same error was returned for all of them.
Invalid 'tools': unknown variant `web_search`, expected `function` or `mcp`
Error messages for each tool
web_search:
Failed to deserialize the JSON body into the target type: ?[0]: Invalid 'tools': unknown variant `web_search`, expected `function` or `mcp` at line 4 column 37
code_interpreter:
Failed to deserialize the JSON body into the target type: ?[0]: Invalid 'tools': unknown variant `code_interpreter`, expected `function` or `mcp` at line 4 column 74
file_search:
Failed to deserialize the JSON body into the target type: ?[0]: Invalid 'tools': unknown variant `file_search`, expected `function` or `mcp` at line 4 column 69
The only tool types supported by Bedrock Mantle are function and mcp.
Summary
In this article, I compared the Responses API of Azure AI Foundry and Bedrock Mantle using the same tests. As a practice swing in preparation for GPT-5 family models on Bedrock, here is what we learned so far.
- ✅ Response structures are compatible — The JSON structure of
id,object,status, andoutput[]is identical. Existing client code can be reused by only changing the endpoint and model name - ✅
previous_response_idworks on both — Server-side conversation history retention works on both Azure and Bedrock - ⚠️ Server-side tools are Azure only —
web_search,code_interpreter, andfile_searchare not supported on Bedrock. You need to abstract the tool layer on the application side - ⏳ Waiting for expanded model support — Bedrock has only the two gpt-oss models. Once the GPT-5 family is available, a comparison using the same model will be possible
It is expected that these gaps (server-side tools and support for proprietary models) will be filled by the Stateful Runtime Environment. Once it becomes available, I plan to run the verification again using the same model.
Reference Links
- I tried Amazon Bedrock support in Codex CLI v0.124.0 (Part 1)
- Amazon Bedrock now supports OpenAI's Responses API (by Takakuni)
- Bedrock Mantle Documentation - Generate responses using OpenAI APIs
- Use the Azure OpenAI Responses API
- The Responses API in Azure AI Foundry is now generally available
- Introducing the Stateful Runtime Environment for Agents in Amazon Bedrock
- OpenAI and Amazon announce strategic partnership
