fix(bedrock): honor disabled reasoning efforts on native chat route

[Aasif-Simpplr]

TLDR

Problem this solves:

• Bedrock GPT-5.6 and newer default to native Chat Completions since feat(bedrock): serve gpt-5.6+ chat completions natively by default, with chat_completions/ opt-in for gpt-oss and grok #44307
• That route ignores the model map's disabled effort levels from fix(bedrock): honor unsupported reasoning effort levels for OpenAI GPT models #44183
• reasoning_effort: minimal reaches Bedrock and gets a 400, even with drop_params
• Bedrock GPT-6 Sol and Luna rows wrongly mark none unsupported
• So Converse now refuses none for them, though Bedrock accepts it

How it solves it:

• Native Chat Completions now reads supports_<effort>_reasoning_effort like Converse
• A disabled effort is dropped under drop_params, otherwise refused before the call
• Bedrock GPT-6 Sol and Luna rows now say none is supported

The row fix is part of the same change, not a second one: once native Chat Completions reads these flags, the wrong none rows would refuse a working GPT-6 Sol request on the default route (an existing test catches it)

User Flow

Before: a developer asking for minimal reasoning on a Bedrock GPT-5.6 deployment gets a 400 on every call, even with drop_params on

1. The proxy admin adds bedrock/us.openai.gpt-5.6-luna with drop_params: true
2. The developer sends POST https://litellm-domain/v1/chat/completions with "reasoning_effort": "minimal"
3. It comes back 400 with Bedrock's Unsupported value: 'reasoning_effort' does not support 'minimal' with this model
4. A second developer sends "reasoning_effort": "none" to bedrock/converse/us.openai.gpt-6-sol and gets a 400 from LiteLLM saying none is unsupported

After: the same requests succeed with drop_params on, and fail fast with a clear message when it is off

1. The proxy admin adds bedrock/us.openai.gpt-5.6-luna with drop_params: true
2. The developer sends the same POST https://litellm-domain/v1/chat/completions with "reasoning_effort": "minimal"
3. It comes back 200 with a normal completion, and with drop_params off they get a 400 from LiteLLM naming minimal, without a round trip to Bedrock
4. The none request to bedrock/converse/us.openai.gpt-6-sol comes back 200

Relevant issues

Follow-up to #44183, which wired the same model map flags into Converse and native Responses but landed after #44307 moved GPT-5.6 and newer onto native Chat Completions

#42854 makes the same supports_none_reasoning_effort change on these GPT-6 Sol and Luna rows (plus the Mantle ones) for /v1/messages. The row edits here are identical, so whichever lands second merges cleanly

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• The handful of test files covering my change pass locally, e.g. uv run pytest tests/unit/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more
• My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.)
• My PR's scope is as isolated as possible; it only solves 1 specific problem (the row fix is required by the code fix, see TLDR)
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

Live proxy on localhost:4000 (python litellm/proxy/proxy_cli.py --config proof-config.yaml --port 4000 --detailed_debug), real Bedrock calls in us-east-1 with AWS_BEARER_TOKEN_BEDROCK set and LITELLM_LOCAL_MODEL_COST_MAP=true so each side uses its own model map. Config:

model_list:
  - model_name: gpt-5.6-luna
    litellm_params:
      model: bedrock/us.openai.gpt-5.6-luna
      aws_region_name: us-east-1
  - model_name: gpt-5.6-luna-drop
    litellm_params:
      model: bedrock/us.openai.gpt-5.6-luna
      aws_region_name: us-east-1
      drop_params: true
  - model_name: gpt-6-sol
    litellm_params:
      model: bedrock/us.openai.gpt-6-sol
      aws_region_name: us-east-1
  - model_name: gpt-6-sol-converse
    litellm_params:
      model: bedrock/converse/us.openai.gpt-6-sol
      aws_region_name: us-east-1

Every case sends this request, changing only model and reasoning_effort:

curl -s localhost:4000/v1/chat/completions -H "Authorization: Bearer $LITELLM_KEY" -H 'Content-Type: application/json' \
  -d '{"model":"gpt-5.6-luna","reasoning_effort":"minimal","messages":[{"role":"user","content":"Say hi"}]}'

The "sent to Bedrock" lines come from the POST Request Sent from LiteLLM entries in the --detailed_debug log

Before (10444df)

minimal, drop_params off

1. "model":"gpt-5.6-luna","reasoning_effort":"minimal"
2. Sent to Bedrock: POST https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1/chat/completions with 'reasoning_effort': 'minimal'
3. HTTP 400: litellm.BadRequestError: BedrockException - {"error":{"message":"Unsupported value: 'reasoning_effort' does not support 'minimal' with this model. Supported values are: 'none', 'low', 'medium', 'high', and 'xhigh'.","type":"invalid_request_error"...

minimal, drop_params on

1. "model":"gpt-5.6-luna-drop","reasoning_effort":"minimal"
2. Sent to Bedrock: the same URL, still with 'reasoning_effort': 'minimal'
3. HTTP 400: the same Bedrock Unsupported value error, so drop_params did not help

low, drop_params off and on

1. "model":"gpt-5.6-luna" and "model":"gpt-5.6-luna-drop", both with "reasoning_effort":"low"
2. HTTP 200 for both, content Hi!

none on GPT-6 Sol, default route

1. "model":"gpt-6-sol","reasoning_effort":"none"
2. Sent to Bedrock: /openai/v1/chat/completions with 'reasoning_effort': 'none'
3. HTTP 200, content Hi!

none on GPT-6 Sol, Converse

1. "model":"gpt-6-sol-converse","reasoning_effort":"none"
2. HTTP 400 from LiteLLM, no Bedrock call: litellm.UnsupportedParamsError: converse/us.openai.gpt-6-sol does not support reasoning_effort=none. To drop unsupported params, set litellm.drop_params = True.

After (e0b6eb0)

minimal, drop_params off

1. "model":"gpt-5.6-luna","reasoning_effort":"minimal"
2. Nothing sent to Bedrock
3. HTTP 400 from LiteLLM: litellm.UnsupportedParamsError: us.openai.gpt-5.6-luna does not support reasoning_effort=minimal. To drop unsupported params, set litellm.drop_params = True.

minimal, drop_params on

1. "model":"gpt-5.6-luna-drop","reasoning_effort":"minimal"
2. Sent to Bedrock: POST https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1/chat/completions with {'model': 'us.openai.gpt-5.6-luna', 'messages': [...], 'stream': False}, no reasoning_effort
3. HTTP 200, content starting Hi!

low, drop_params off and on

1. "model":"gpt-5.6-luna" and "model":"gpt-5.6-luna-drop", both with "reasoning_effort":"low"
2. Sent to Bedrock with 'reasoning_effort': 'low' both times
3. HTTP 200 for both

none on GPT-6 Sol, default route

1. "model":"gpt-6-sol","reasoning_effort":"none"
2. Sent to Bedrock: /openai/v1/chat/completions with 'reasoning_effort': 'none'
3. HTTP 200, content Hi!

none on GPT-6 Sol, Converse

1. "model":"gpt-6-sol-converse","reasoning_effort":"none"
2. Sent to Bedrock: POST .../model/us.openai.gpt-6-sol/converse with "additionalModelRequestFields": {"reasoning": {"effort": "none"}}
3. HTTP 200, content Hi!

/v1/responses, affected by the row change

Same proxy, curl -s localhost:4000/v1/responses -d '{"model":"gpt-6-sol","reasoning":{"effort":"none"},"input":"Say hi"}', changing only model and effort. Both models take the native Responses route (POST https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1/responses)

Before (10444df):

1. gpt-6-sol, none: HTTP 400 from LiteLLM, no Bedrock call: us.openai.gpt-6-sol does not support reasoning.effort=none
2. gpt-6-sol, minimal: HTTP 400 from LiteLLM: does not support reasoning.effort=minimal
3. gpt-5.6-luna, none: HTTP 200, output Hi!
4. gpt-5.6-luna, minimal: HTTP 400 from LiteLLM: does not support reasoning.effort=minimal

After (e0b6eb0):

1. gpt-6-sol, none: sent to Bedrock /openai/v1/responses, HTTP 200, output Hi!
2. gpt-6-sol, minimal: unchanged, HTTP 400 from LiteLLM
3. gpt-5.6-luna, none: unchanged, HTTP 200
4. gpt-5.6-luna, minimal: unchanged, HTTP 400 from LiteLLM

For the row change, raw Bedrock with no LiteLLM in between, us-east-1 and us-west-2, reasoning_effort: none: GPT-6 Sol and Luna (us. and global.) return 200 on both /openai/v1/chat/completions and Converse, while GPT-6 Astra and GPT-6.1 Sol return 400 'none' is not supported with this model, which matches the rows that keep false

Type

🐛 Bug Fix

Caveats (if any)

Low

• With drop_params on, the call runs at the model's default effort, not something close to minimal
• The proxy pulls the hosted model map by default, so the GPT-6 none fix reaches proxies once the map refreshes
• The Bedrock Mantle GPT-6 Sol and Luna rows are left to fix(bedrock): stop sending reasoning effort none to GPT-6 Astra when /v1/messages disables thinking #42854
• The row change also reaches native /v1/responses: GPT-6 Sol and Luna none now goes to Bedrock instead of being refused, shown live above
• GPT-6 Astra and GPT-6.1 Sol with none on the default native route used to reach Bedrock and get its 400; LiteLLM now refuses them before the call, or drops none under drop_params, matching the raw Bedrock results above
• The error message names the route-qualified model string (for example chat_completions/us.openai.gpt-5.6-luna), the same way Converse says converse/...
• Not covered: /v1/messages, which this change does not touch

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Adds validation for disabled reasoning effort on Bedrock models.

The PR appears safe to merge; no actionable regression was identified.

Summary

The PR makes Bedrock native Chat Completions respect explicitly disabled reasoning efforts and updates GPT-6 Sol and Luna model metadata to allow none.

• Unsupported efforts are rejected locally or dropped when drop_params is enabled.
• The primary and backup model maps receive matching capability changes, with new mapping and request-level tests.

_{Reviews (1) · Last reviewed commit: "fix(bedrock): honor unsupported reasonin..."}

[codspeed]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing Aasif-Simpplr:fix-bedrock-minimal-effort (e0b6eb0) with main (d4619c4)¹}

Footnotes

1. No successful run was found on main (10444df) during the generation of this report, so d4619c4 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[VANDRANKI]

Community review. This does not clear the merge gate. I checked this by running AmazonBedrockRuntimeChatCompletionsConfig().map_openai_params on the PR head and on main, using the local cost map (LITELLM_LOCAL_MODEL_COST_MAP=True). I did not run the repo's pytest suite and I did not make a real call to AWS.

What I ran, each with max_tokens=64:

• On main, global.openai.gpt-5.6-sol with reasoning_effort="minimal" passes through untouched, with or without drop_params. That matches the PR's description of the bug.
• On the PR head, the same call raises UnsupportedParamsError (400, message names reasoning_effort=minimal) without drop_params, and with drop_params=True returns {'max_completion_tokens': 64} with the effort removed.
• bedrock/us-east-1/us.openai.gpt-5.6-luna (region-prefixed name) behaves the same, so the lookup through bedrock_reasoning_effort_disabled works with the region path.
• us.openai.gpt-6.1-sol and us.openai.gpt-6-astra refuse none. us.openai.gpt-6-sol, openai.gpt-6-luna, global.openai.gpt-5.6-sol and us.openai.gpt-5.4 accept none. The flipped supports_none_reasoning_effort rows are what makes the gpt-6-sol/luna cases pass.
• us.openai.gpt-oss-120b-1:0 is untouched, since it is not covered by bedrock_model_is_openai_gpt.

The change reads correct to me. disabled_reasoning_effort only fires when the map says false explicitly, so models with no flag keep today's behavior. It is also merged into the same _without_params call as the other two refusal sets, so the max_completion_tokens mapping is preserved, which I saw in the output.

Two small observations, neither blocking:

1. The effort is matched case-sensitively through f"supports_{effort}_reasoning_effort". reasoning_effort="MINIMAL" on gpt-5.6-sol still goes through unchanged on the PR head. I do not know whether AWS lowercases it, so I am not claiming that is a bug.
2. The map edit only touches the bedrock_converse gpt-6-sol/luna rows. The bedrock_mantle/openai.gpt-6-sol and -luna rows still say none false in this checkout. The PR text says #42854 covers those, so this is fine if that one lands, but it means the two rows disagree until it does.

I did not verify the claim that AWS returns 400 for minimal on 5.4+ since I have no AWS access. I am taking the description's word for it.

[Aasif-Simpplr]

Thanks for running it on both main and the PR head, including the region-prefixed name.

On the two notes:

1. Case. The case-sensitive match is deliberate. It follows the convention used elsewhere: gpt_5_transformation.py and the Anthropic config look up supports_{level}_reasoning_effort the same way, and REASONING_EFFORT in types/llms/openai.py is a lowercase Literal. Normalizing the case would need to happen for every provider at once, so I'd keep it out of this PR.
2. bedrock_mantle rows. Right, this PR only flips the bedrock_converse rows, because those are the ones the native chat route reads. I checked fix(bedrock): stop sending reasoning effort none to GPT-6 Astra when /v1/messages disables thinking #42854's head against main: it flips the same six rows plus both bedrock_mantle/openai.gpt-6-sol and -luna. So the two disagree only until fix(bedrock): stop sending reasoning effort none to GPT-6 Astra when /v1/messages disables thinking #42854 lands, and the overlapping rows are identical, so whichever lands second rebases cleanly.