Error 400 with Tool Use: Number of toolResult blocks exceeds toolUse blocks

[BillWang-dev]

When attempting to use the Tool Use (Function Calling) feature via anthropic-proxy (with the backend model anthropic/claude-3.5-haiku routed through OpenRouter, where the error message indicates the actual provider is Amazon Bedrock), the API returns a 400 error. The error message states that the number of toolResult blocks in the request's messages exceeds the number of toolUse blocks from the model's previous turn.

Error Message:

  ⎿  Invalid tool parameters
  ⎿  API Error: 400 {"error":"{\"error\":{\"message\":\"Provider returned 
     error\",\"code\":400,\"metadata\":{\"raw\":\"{\\\"message\\\":\\\"The number of 
     toolResult blocks at messages.4.content exceeds the number of toolUse blocks of 
     previous turn.\\\"}\",\"provider_name\":\"Amazon 
     Bedrock\"}},\"user_id\":\"user_2m17fqmm2tL3UEVCpAlvfXvsXx5\"}"}

[xiangz19]

@BillWang-dev , I had similar issues, and I let cursor with GPT-4.1 to fix them for a while, and finally I gave up. Since I mainly uses claude modals on openrouter for testing. It should be easier than non-claude modals, so I asked GPT-4.1 to write a proxy from scratch. It works, I almost open sourced the code, then I found a repo https://github.com/1rgs/claude-code-proxy, which uses litellm, since it has 700+ stars, you can give it a try.
Actually claude code documention has instructions on working with litellm, you can install litellm proxy and configure it manually.

[BillWang-dev]

@xiangz19 thanks!

[xiangz19]

@BillWang-dev , I had similar issues, and I let cursor with GPT-4.1 to fix them for a while, and finally I gave up. Since I mainly uses claude modals on openrouter for testing. It should be easier than non-claude modals, so I asked GPT-4.1 to write a proxy from scratch. It works, I almost open sourced the code, then I found a repo https://github.com/1rgs/claude-code-proxy, which uses litellm, since it has 700+ stars, you can give it a try. Actually claude code documention has instructions on working with litellm, you can install litellm proxy and configure it manually.

sorry, it seems https://github.com/1rgs/claude-code-proxy doesn't support openrouter directly. (there is an open pull request adding openrouter support)

Anyway, you can install and configure litellm to use openrouter model.

[xiangz19]

@BillWang-dev , I just noticed https://github.com/1rgs/claude-code-proxy now supports openrouter too.

[St1ma]

@xiangz19 Did you succeed with claude-code-proxy?
It seems like they support OpenAI models, not OpenRouter directly

[xiangz19]

@xiangz19 Did you succeed with claude-code-proxy? It seems like they support OpenAI models, not OpenRouter directly

I haven't try it. I don't see openrouter mentioned now, it's only in some pull request.

[weijiafu14]

This exact error — "Number of toolResult blocks exceeds toolUse blocks" — is caused by how the proxy handles multi-turn tool calls with Gemini. When thinking mode adds extra parts (with thoughtSignature), the part count gets mismatched.

I've been dealing with this in production and open-sourced the fix: gemini-claude-bridge. It splits mixed signed/unsigned parts into separate messages, which is what Gemini's docs require.

Also submitted a fix to LiteLLM directly: BerriAI/litellm#23809

[m13v]

we hit this exact error pattern when proxying Claude tool use calls through different backends. the root cause is usually that the proxy is forwarding tool results from a previous turn that got truncated or reordered. the fix in our case was tracking the tool_use_id from the model's response and only sending back toolResult blocks that match IDs from the immediately preceding assistant turn. Amazon Bedrock is especially strict about this compared to direct Anthropic API

[m13v]

Our Claude API integration that handles tool_use/toolResult pairing correctly: https://github.com/m13v/fazm/blob/main/Desktop/Sources/Providers/ChatProvider.swift

The key is maintaining a strict mapping between tool_use_id from the assistant response and the corresponding toolResult in the next user turn. The provider abstraction layer validates this before sending to any backend.