fix(bedrock): send tool-search beta header for Haiku 4.5 on Invoke /v1/messages - #36502
Conversation
…1/messages Bedrock InvokeModel rejects tool_search_tool_* tool types unless the request body carries the tool-search-tool-2025-10-19 beta. The model allowlist gating that beta omitted Haiku 4.5 (and Opus 4.7, supported since launch per live verification), so every tool-search request on those models got a Bedrock 400. Add both to the allowlist and re-enable the e2e compat cell that caught it.
Greptile SummaryThe PR adds a model metadata capability for Bedrock tool search and uses it when constructing Invoke
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| litellm/llms/bedrock/messages/invoke_transformations/anthropic_claude3_transformation.py | Reads tool-search support from resolved model metadata before constructing the Bedrock-specific beta header. |
| model_prices_and_context_window.json | Adds tool-search capability metadata to supported Bedrock Claude model entries. |
| litellm/utils.py | Exposes the new capability through returned model information. |
| model_prices_and_context_window.schema.json | Adds boolean schema validation for the new model capability. |
| tests/test_litellm/llms/bedrock/messages/invoke_transformations/test_anthropic_claude3_transformation.py | Covers beta-header generation and catalog capability precedence. |
| tests/e2e/claude_code/tool_search/test_bedrock_invoke.py | Re-enables the Bedrock Invoke tool-search compatibility matrix. |
Reviews (3): Last reviewed commit: "fix(schema): declare supports_tool_searc..." | Re-trigger Greptile
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Record supports_tool_search on the Bedrock Claude entries in both cost map files and have _supports_tool_search_on_bedrock read it first via the provider-resolved capability lookup, keeping the name patterns as a fallback for ARNs and ids the map cannot resolve. Threads the flag through ModelInfoBase and drops a dated remark from the pattern list
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit df54256. Configure here.
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit df54256. Configure here.
TLDR
Problem this solves:
tool_search_tool_*tool typesHow it solves it:
supports_tool_searchon the Bedrock Claude 4.5/4.6/4.7 entries in the model cost maptool-search-tool-2025-10-19betaRCA doc: https://app.notion.com/p/3b943b8acdab81bd9e85d8c5c9cc8536
User Flow
Before: a Claude Code user on Haiku 4.5 via Bedrock (Invoke) gets a 400 whenever tool search is active
claude-haiku-4-5-bedrock-invokeand a tools array containing{"type":"tool_search_tool_regex_20251119","name":"tool_search_tool_regex"}plus their own toolstools.0: Input tag 'tool_search_tool_regex_20251119' found using 'type' does not match any of the expected tagsclaude-sonnet-4-5-bedrock-invokereturns 200, so only Haiku (and any tool-search request on Opus 4.7 relying on the documented beta path) is brokenAfter: the same request succeeds and the model invokes the discovery tool
claude-haiku-4-5-bedrock-invokeand the same tools arrayserver_tool_usecontent block namedtool_search_tool_regexclaude-sonnet-4-5-bedrock-invokeandclaude-opus-4-7-bedrock-invokealso returns 200Relevant issues
RCA doc: https://app.notion.com/p/3b943b8acdab81bd9e85d8c5c9cc8536
Linear ticket
Pre-Submission checklist
Please complete all items before asking a LiteLLM maintainer to review your PR
@greptileaito 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 against real AWS Bedrock in us-east-1, one fresh worktree, venv and proxy per leg, both booted with
litellm --config tests/e2e/claude_code/test_config.yaml --host 127.0.0.1 --port <port>. Same curl both timesBefore, at commit d8762bf (merge base), on port 41387:
The identical request at d8762bf on the other two tiers already returns 200 with a
server_tool_useblock, so only haiku is broken at the merge baseAfter, at commit 7d4488d (this PR's head), identical request on port 42417:
Same request at 7d4488d on the other two matrix tiers, to show no regression:
The e2e compat cell this PR re-enables, run at 7d4488d against that same proxy:
Commit df54256 landed after this run; it only declares the new key in the generated JSON schema and the test suite's inline copy (no runtime code), so it cannot change the proven behavior
Opus 4.7 was verified direct against AWS before touching its allowlist entry:
POST https://bedrock-runtime.us-east-1.amazonaws.com/model/us.anthropic.claude-opus-4-7/invokewith"anthropic_beta":["tool-search-tool-2025-10-19"]returns 200 with aserver_tool_useblock, so the in-code note claiming Bedrock rejects tool search on Opus 4.7 was staleThe regression tests were verified in both directions: at d8762bf the haiku and opus-4-7 beta-header parametrizations fail (
anthropic_betamissing) and sonnet passes. For the model-map read added in 7d4488d, flipping the mapped haiku entry'ssupports_tool_searchto false makes the check return false even though the name still matches a pattern; with the map-first read reverted that test fails, and with it restored all 98 tests in the file passQA notes, observed live and left alone by this PR: at the merge base only haiku hard-fails while opus 4.7 already returns 200 with
server_tool_use, matching the direct-AWS check above that the stale in-code claim about opus was wrong. Response shapes also differ slightly per tier: opus addsstop_details,output_tokens_details.thinking_tokensandservice_tierand uses a longer message id format, while haiku carries none of thoseType
🐛 Bug Fix
Caveats (if any)
_supports_tool_search_on_bedrockwith that pathQA runbook
litellm --config tests/e2e/claude_code/test_config.yaml --port 4000claude-haiku-4-5-bedrock-invoke, atool_search_tool_regex_20251119tool plus one custom tool (exact body in Proof of Fix above)server_tool_usecontent block, not a 400 naming the tool tagclaude-sonnet-4-5-bedrock-invokeandclaude-opus-4-7-bedrock-invoke, expect 200 eachFinal Attestation
Note
Medium Risk
Changes which Bedrock models get tool-search beta headers and can cause upstream 400s if flags are wrong; scope is limited to Bedrock Invoke messages transformation and catalog metadata.
Overview
Fixes Bedrock Invoke
/v1/messagestool-search failures (e.g. Haiku 4.5 400s) by ensuring thetool-search-tool-2025-10-19beta is attached when the request uses tool-search tools._supports_tool_search_on_bedrocknow consults the model cost map’ssupports_tool_searchfirst (via_get_provider_resolved_capability), with name-pattern matching only as a fallback for unmapped ids. The allowlist is expanded to include Haiku 4.5 and Opus 4.7 (replacing the prior note that Opus 4.7 lacked support).supports_tool_search: trueis added on relevant Bedrock Claude 4.5/4.6/4.7 entries in the model price JSON, wired throughModelInfo/get_model_info, and the JSON schema. Unit tests cover beta injection, map authority, and pattern fallback; the skipped Bedrock Invoke tool-search e2e test is re-enabled.Reviewed by Cursor Bugbot for commit df54256. Bugbot is set up for automated code reviews on this repo. Configure here.