fix(bedrock): stop base_model label from stripping tools/tool_choice

[andrey-dubnik]

Relevant issues

Fixes #29618

A Router/proxy Bedrock deployment whose model_info.base_model is a friendly label (e.g. claude-haiku-4-5) silently lost tools and tool_choice. The outgoing Bedrock Converse request was built without toolConfig, so the model behaved as if no tools were provided. This worked in v1.84.0 and regressed in v1.85.0; with drop_params: true it failed silently rather than surfacing an error

Linear ticket

Root cause

Two changes compound into the bug. completion() passed model_info.base_model as the model argument to get_optional_params (introduced in #27720), so the real Bedrock model id never reached supported-param resolution. Separately, get_supported_openai_params resolved the provider config's params from base_model or model (#28582), letting the label fully replace the real model. For Bedrock the label resolves to no tool support (Bedrock gates tools on recognizing the Converse model id), so tools/tool_choice were stripped before transformation and never reached toolConfig. Azure was unaffected because its deployment names are opaque, so base_model is the only signal it has

Fix

completion() now keeps model as the real deployment model and threads the resolved base_model (the kwarg, falling back to model_info) through separately. get_supported_openai_params treats base_model as additive: it returns the union of the params supported by model and by base_model. A hint can only add capabilities, never strip ones the real model already exposes. That keeps the original base_model behavior from #27717 (a registered base_model adding reasoning_effort/thinking for an unregistered model) and Azure's base_model driven model-type detection working, while restoring Bedrock tool support

Pre-Submission checklist

• I have added meaningful tests
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

CI (LiteLLM team)

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Screenshots / Proof of Fix

Verified against a live proxy hitting real Bedrock (real, billable calls)

The fix: a friendly base_model label no longer strips tools

This is the configuration from the issue, a Bedrock deployment whose model_info.base_model is the label claude-haiku-4-5, with drop_params: true

model_list:
  - model_name: claude-haiku-4-5
    litellm_params:
      model: bedrock/eu.anthropic.claude-haiku-4-5-20251001-v1:0
    model_info:
      base_model: claude-haiku-4-5

litellm_settings:
  drop_params: true

general_settings:
  master_key: sk-1234

python litellm/proxy/proxy_cli.py --config bedrock_basemodel_test.yaml --port 4000

curl -s http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-1234" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-haiku-4-5",
    "messages": [{"role": "user", "content": "What is the weather in Copenhagen?"}],
    "tools": [{"type": "function", "function": {"name": "get_weather", "description": "Get the weather for a city", "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}}}],
    "tool_choice": "auto"
  }' | jq '{model, finish_reason: .choices[0].finish_reason, tool_calls: .choices[0].message.tool_calls, usage}'

Response on this branch:

{
  "model": "claude-haiku-4-5",
  "finish_reason": "tool_calls",
  "tool_calls": [
    {
      "index": 0,
      "function": { "arguments": "{\"city\": \"Copenhagen\"}", "name": "get_weather" },
      "id": "tooluse_bBi2LpRSJZixywecGRb5MV",
      "type": "function"
    }
  ],
  "usage": { "completion_tokens": 54, "prompt_tokens": 564, "total_tokens": 618 }
}

The model selects get_weather with {"city": "Copenhagen"}, so tools/tool_choice reach Bedrock Converse. On the pre-fix code the same request drops both params before transformation, so no toolConfig is sent and the model cannot call the tool

No regression for the common pattern (no base_model)

The same model registered the usual way, without model_info.base_model, which was never affected but is worth confirming stays correct

model_list:
  - model_name: claude-haiku-4-5
    litellm_params:
      model: bedrock/eu.anthropic.claude-haiku-4-5-20251001-v1:0
      aws_region_name: eu-west-1

litellm_settings:
  drop_params: true

Same curl, response on this branch:

{
  "model": "claude-haiku-4-5",
  "finish_reason": "tool_calls",
  "tool_calls": [
    {
      "index": 0,
      "function": { "arguments": "{\"city\": \"Copenhagen\"}", "name": "get_weather" },
      "id": "tooluse_OGbWS86RtufrlCBmBiZhC3",
      "type": "function"
    }
  ],
  "usage": { "completion_tokens": 54, "prompt_tokens": 564, "total_tokens": 618 }
}

Type

Bug Fix

Changes

litellm/main.py: in completion(), resolve base_model from the kwarg or model_info, and stop overwriting the model passed to get_optional_params with the base_model label so the real model reaches capability resolution

litellm/litellm_core_utils/get_supported_openai_params.py: make base_model additive for the provider-config path by returning the union of the params supported by model and by base_model, instead of letting base_model replace model

Tests: a get_supported_openai_params suite covering the union both directions (Bedrock label that would strip tools, gemini base_model that adds reasoning_effort, Azure detection preserved, no-base_model and base_model==model unchanged); a get_optional_params regression asserting tools/tool_choice survive drop_params with the label; and an update to test_completion_optional_params_base_model to assert per case that model stays the real deployment model while base_model is threaded through as the additive hint

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[greptile-apps]

Greptile Summary

This PR fixes a regression introduced in v1.85.0 where Bedrock deployments with a friendly model_info.base_model label (e.g. claude-haiku-4-5) silently lost tools/tool_choice when drop_params: true was set. Two root-cause changes are reverted/replaced: main.py no longer overwrites the real deployment model with the base_model label when calling get_optional_params, and get_supported_openai_params now returns the union of params from both model and base_model so a hint can only add capabilities, never remove them.

• litellm/main.py: base_model is resolved from the kwarg or model_info and threaded as a separate additive hint; the real deployment model id is preserved when building optional_param_args.
• litellm/litellm_core_utils/get_supported_openai_params.py: The provider-config path now returns list(dict.fromkeys([*model_params, *base_model_params])) instead of letting base_model fully replace model, keeping Azure model-type detection and the existing #27717 reasoning-effort use-case intact.
• Tests: New file test_get_supported_openai_params.py covers the regression, the additive direction, Azure detection, and edge cases; test_utils.py adds a get_optional_params-level regression; test_main.py asserts both model and base_model are threaded correctly per parametrized case.

Confidence Score: 5/5

Safe to merge; the fix is narrowly scoped to how base_model is resolved and applied in get_optional_params, all changed paths have explicit regression tests, and the additive-union design prevents any existing capability from being stripped.

The two-line change in main.py is mechanical and the union logic in get_supported_openai_params is straightforward. Tests cover the Bedrock regression, gemini reasoning-effort preservation, Azure detection, and edge cases. One small gap exists where spreading None could throw if a provider config returns None for an unrecognized model id, but this does not affect the intended code paths.

litellm/litellm_core_utils/get_supported_openai_params.py — the union spread lacks a None guard for the unlikely case where get_supported_openai_params returns None for an unrecognized model.

Important Files Changed

Filename	Overview
litellm/litellm_core_utils/get_supported_openai_params.py	Core fix: base_model is now additive (union of both param sets) instead of a full replacement; one defensive null-check gap when either get_supported_openai_params call returns None.
litellm/main.py	Resolves base_model from kwarg or model_info, stops overwriting model with the base_model label when calling get_optional_params, threads base_model as a separate additive hint instead.
tests/test_litellm/litellm_core_utils/test_get_supported_openai_params.py	New test file with thorough coverage: Bedrock regression, additive direction, Azure detection preserved, base_model==model edge case, and the gemini capability-adding scenario.
tests/test_litellm/test_main.py	Updated parametrized test to assert both model stays the real deployment id and base_model is separately threaded through; adds expected_base_model_param per case.
tests/test_litellm/test_utils.py	Adds TestBedrockBaseModelLabelKeepsTools class with two integration-style tests confirming tools survive drop_params with the real model id, and confirming the label alone correctly drops them.

_{Reviews (2): Last reviewed commit: "test(main): make base_model param test r..." | Re-trigger Greptile}

[andrey-dubnik]

@greptileai

[Sameerlite]

LGTM

[andrey-dubnik]

@Sameerlite do you know when this changes is schedule for release? We can't upgrade without it in-place as Bedrock no longer works in LiteLLM.

[Sameerlite]

v1.89.0-rc.1 has the change