litellm - 💡(How to fix) Fix Cost map reload doesn't fix provider routing for new bedrock models (e.g. claude-opus-4-7) [4 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#25892Fetched 2026-04-17 08:28:14
View on GitHub
Comments
4
Participants
3
Timeline
7
Reactions
1
Timeline (top)
commented ×4labeled ×1mentioned ×1subscribed ×1

Error Message

  1. Get error: max_tokens_to_sample: Extra inputs are not permitted

Root Cause

get_llm_provider in litellm_core_utils/get_llm_provider_logic.py determines the provider by splitting the model string on / and checking if the prefix is in litellm.provider_list. It never consults litellm.model_cost for the litellm_provider field.

For known models like claude-opus-4-6, a separate hardcoded auto-upgrade path in the bedrock handler switches from bedrockbedrock_converse. New models like claude-opus-4-7 aren't in that hardcoded list, so they fall through to the legacy API.

Similarly, /model/info returns mode: None and max_tokens: None for the new model even after the reload, suggesting the cost map data isn't being used to populate model info for config-defined models.

Fix Action

Workaround

Explicitly set bedrock_converse as the provider in the config:

model_list:
  - model_name: claude-opus-4-7
    litellm_params:
      model: bedrock_converse/us.anthropic.claude-opus-4-7

Code Example

model_list:
  - model_name: claude-opus-4-7
    litellm_params:
      model: bedrock/us.anthropic.claude-opus-4-7
      aws_region_name: us-west-2

---

curl -X POST /v1/chat/completions \
  -d '{"model": "claude-opus-4-7", "messages": [{"role": "user", "content": "hello"}], "max_tokens": 50}'

---

model_list:
  - model_name: claude-opus-4-7
    litellm_params:
      model: bedrock_converse/us.anthropic.claude-opus-4-7
RAW_BUFFERClick to expand / collapse

Bug

/reload/model_cost_map successfully loads new model data (e.g. us.anthropic.claude-opus-4-7 with litellm_provider: bedrock_converse, mode: chat), but requests still fail because provider routing ignores the cost map and relies on hardcoded model lists.

Reproduction

  1. Configure litellm proxy with a model:
model_list:
  - model_name: claude-opus-4-7
    litellm_params:
      model: bedrock/us.anthropic.claude-opus-4-7
      aws_region_name: us-west-2
  1. Call POST /reload/model_cost_map — returns "2670 models updated" successfully

  2. Verify the cost map has the model:

    • us.anthropic.claude-opus-4-7 exists with litellm_provider: bedrock_converse, mode: chat
  3. Send a request:

curl -X POST /v1/chat/completions \
  -d '{"model": "claude-opus-4-7", "messages": [{"role": "user", "content": "hello"}], "max_tokens": 50}'
  1. Get error: max_tokens_to_sample: Extra inputs are not permitted

The request is routed through the legacy bedrock InvokeModel handler instead of bedrock_converse (Messages API).

Root cause

get_llm_provider in litellm_core_utils/get_llm_provider_logic.py determines the provider by splitting the model string on / and checking if the prefix is in litellm.provider_list. It never consults litellm.model_cost for the litellm_provider field.

For known models like claude-opus-4-6, a separate hardcoded auto-upgrade path in the bedrock handler switches from bedrockbedrock_converse. New models like claude-opus-4-7 aren't in that hardcoded list, so they fall through to the legacy API.

Similarly, /model/info returns mode: None and max_tokens: None for the new model even after the reload, suggesting the cost map data isn't being used to populate model info for config-defined models.

Expected behavior

After a successful /reload/model_cost_map, the litellm_provider and mode fields from the cost map should be used for provider routing and model info. This is the entire value proposition of the reload endpoint and "day-0 model support" — new models should work without a code upgrade.

Workaround

Explicitly set bedrock_converse as the provider in the config:

model_list:
  - model_name: claude-opus-4-7
    litellm_params:
      model: bedrock_converse/us.anthropic.claude-opus-4-7

Environment

  • LiteLLM proxy (self-hosted, version unknown — latest as of 2026-04-16)
  • Model cost map reloaded from GitHub after merge of #25867 (day-0 opus 4.7 support)

extent analysis

TL;DR

The issue can be fixed by updating the get_llm_provider logic to consult the litellm.model_cost for the litellm_provider field.

Guidance

  • The root cause is that the get_llm_provider function does not use the litellm.model_cost data to determine the provider, instead relying on hardcoded model lists.
  • To verify the issue, check the litellm_core_utils/get_llm_provider_logic.py file and confirm that the get_llm_provider function does not consult the litellm.model_cost data.
  • A potential workaround is to explicitly set the provider in the config, as shown in the issue's "Workaround" section.
  • To mitigate the issue, consider updating the get_llm_provider function to use the litellm.model_cost data to determine the provider.

Example

No code snippet is provided, as the issue does not contain enough information to create a specific example.

Notes

The issue seems to be related to the get_llm_provider function not using the litellm.model_cost data, which is updated by the /reload/model_cost_map endpoint. The workaround provided in the issue may help mitigate the issue, but a more permanent fix would require updating the get_llm_provider function.

Recommendation

Apply the workaround by explicitly setting the provider in the config, as this is a temporary solution that can help mitigate the issue until a more permanent fix is implemented.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

After a successful /reload/model_cost_map, the litellm_provider and mode fields from the cost map should be used for provider routing and model info. This is the entire value proposition of the reload endpoint and "day-0 model support" — new models should work without a code upgrade.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

litellm - 💡(How to fix) Fix Cost map reload doesn't fix provider routing for new bedrock models (e.g. claude-opus-4-7) [4 comments, 3 participants]