[Feature]: Support OpenAI frontier models (gpt-5.5 / gpt-5.4) on bedrock-mantle via the /openai/v1/responses path

[odinwang]

The Feature

AWS launched OpenAI frontier models (openai.gpt-5.5, openai.gpt-5.4) on the Bedrock bedrock-mantle endpoint on 2026-06-01. These are Responses-API-only and live on a distinct path: https://bedrock-mantle.{region}.api.aws/openai/v1/responses (note the openai/ prefix). Per the AWS model card, Chat Completions / Converse / Invoke are not supported for these models, and they are currently in us-east-2 only.

Today LiteLLM has no route that targets /openai/v1/responses, so these models cannot be reached through either existing mantle integration.

Current behavior (tested on v1.83.14 and v1.86.2)

Route	Auth	URL LiteLLM builds	Result
bedrock/mantle/openai.gpt-5.5 (completion & responses)	SigV4 / IAM	…/anthropic/v1/messages	400 invalid_request_error: The model 'openai.gpt-5.5' does not support the '/anthropic/v1/messages' API
bedrock_mantle/openai.gpt-5.5	Bearer API key	…/v1/chat/completions	wrong endpoint — these models are Responses-only

The bedrock/mantle/ route (PR #26196, path fixed in #27943) is hardwired to the Anthropic Messages path for Claude Mythos; the bedrock_mantle/ provider (PR #22866) is hardwired to /v1/chat/completions. Neither emits /openai/v1/responses.

Confirmed working (raw request)

A hand-signed SigV4 POST to https://bedrock-mantle.us-east-2.api.aws/openai/v1/responses with body {"model":"openai.gpt-5.5","input":"…"} returns 200 with a valid OpenAI Responses payload. So the model, endpoint, and IAM/SigV4 auth all work — only LiteLLM's routing is missing this path.

Proposed

1. Route openai.* mantle models to /openai/v1/responses (Responses mode), distinct from the /anthropic/v1/messages (Mythos) and /v1/chat/completions paths.
2. Support SigV4 / IAM auth on this path (the Mythos route already does SigV4), not just BEDROCK_MANTLE_API_KEY.
3. Register Bedrock pricing for gpt-5.5 / gpt-5.4 under the mantle provider (currently logs This model isn't mapped yet, producing $0 cost).

Environment

• LiteLLM: reproduced on v1.83.14 and v1.86.2
• Region: us-east-2 (only region where these models are currently available)

Twitter / LinkedIn details

No response

[kk137]

Same issue reproduced on LiteLLM v1.84.3.

[aleck31]

Confirmed on v1.83.14-stable.patch.3 (ECS deployment via deploy-generative-ai-gateway-on-aws).

Tested bedrock_mantle/openai.gpt-5.4 with Bearer API key + explicit api_base pointing to us-west-2:

• Auth passes ✅
• Returns: The model 'openai.gpt-5.4' does not support the '/v1/chat/completions' API

Same behavior as described — LiteLLM routes to /v1/chat/completions but these models only accept /openai/v1/responses.

[cncoder]

+1 — Same issue confirmed. We're deploying LiteLLM on EKS with IRSA (SigV4 via IAM role) and cannot route to GPT-5.5/5.4 through any existing provider prefix.

Environment:

• LiteLLM v1.83.7 ~ v1.83.14 (tested both)
• Auth: IRSA (SigV4, service=bedrock, region=us-east-2)
• Deployment: EKS + serverless-litellm

What we tested:

Config	Result
bedrock/mantle/openai.gpt-5.5	Routes to /anthropic/v1/messages -> 400 "does not support the '/anthropic/v1/messages' API"
bedrock_mantle/openai.gpt-5.5	Routes to /v1/chat/completions with Bearer token auth -- wrong path AND wrong auth for IAM users

Workaround (confirmed working):

Hand-signed SigV4 POST directly to https://bedrock-mantle.us-east-2.api.aws/openai/v1/responses works perfectly with both openai.gpt-5.5 and openai.gpt-5.4. We are currently running a local SigV4-signing proxy as a stopgap, but this should be native in LiteLLM.

What we need:

1. A route that targets /openai/v1/responses (not /anthropic/v1/messages or /v1/chat/completions)
2. SigV4/IAM auth on that route (same as the existing bedrock/mantle/ Mythos path)
3. Responses API request/response format (input/output, not messages array)

Happy to test any PR that adds this -- we have direct access to the endpoint and can validate immediately.

[XionZhao]

+1 Same Issue on 1.85.0

[saivarunk]

+1 Same Issue on 1.86.0

[seaphu]

+1 same issue 1.87.0

[jgournet]

I got it working with those settings:

      - model_name: "gpt_model_beta"
        litellm_params:
          model: "openai/openai.gpt-5.5"
          api_base: "https://bedrock-mantle.us-east-2.api.aws/openai/v1"
          drop_params: true
          additional_drop_params: ["output_config"]
          api_key: XXXX==

    litellm_settings:
      route_all_chat_openai_to_responses: true

my current problem is that my api_key is from a IAM USER - I need that "SigV4/IAM auth" (I'll edit once I find out how to do that - please let me know if you already know)

[tinuva]

I got it working with those settings:

      - model_name: "gpt_model_beta"
        litellm_params:
          model: "openai/openai.gpt-5.5"
          api_base: "https://bedrock-mantle.us-east-2.api.aws/openai/v1"
          drop_params: true
          additional_drop_params: ["output_config"]
          api_key: XXXX==

    litellm_settings:
      route_all_chat_openai_to_responses: true

my current problem is that my api_key is from a IAM USER - I need that "SigV4/IAM auth" (I'll edit once I find out how to do that - please let me know if you already know)

Go to your AWS Console, Bedrock, API Keys. Create a short or long term api key.

[odinwang]

The bearer-key workaround above is helpful, but it does not work for IAM-only deployments.

For security and compliance reasons, we must authenticate via IAM Role (IRSA / Pod Identity / instance role, SigV4) and cannot use a Bedrock API key — a long-lived bearer credential is a non-starter under our security posture (no long-lived static secrets; IAM-role-only access).

That rules out the openai/ + api_key bearer path entirely. What we need is native SigV4 / IAM-role auth on the /openai/v1/responses route — the same SigV4 signing the existing bedrock/mantle/ (Claude Mythos) route already performs, just pointed at the OpenAI Responses path instead of /anthropic/v1/messages.

This is the hard blocker for any enterprise running LiteLLM on EKS/ECS with IRSA. +1 on prioritizing the native SigV4 path for openai.* Mantle models.

[Cerrix]

+1, we need accurate cost tracking for the Bedrock-hosted OpenAI models (openai.gpt-5.5 / openai.gpt-5.4). Right now they log $0 since they aren't in the price map.
One thing worth flagging: the two open PRs for this diverge. #29476 adds the Responses routing and api_base fix but doesn't touch the price map. #29490 includes the actual model_prices_and_context_window.json entries (bedrock_mantle/openai.gpt-5.5 and gpt-5.4 with in-region pricing). Could we make sure whichever lands includes the price-map entries? Routing alone won't resolve item 3 (the $0 cost) in this issue

[Sameerlite]

This PR is merged:#29490