ThinkFacility

Error messages

Each `advisor_tool_result` block must have a corresponding `server_tool_use` block before it.

The message

Each `advisor_tool_result` block must have a corresponding `server_tool_use` block before it.
Claude Code 2.1.282 read September 25, 2026Claude Codeadvisorserver_tool_use400

What it means

An advisor call and its answer got separated in the saved conversation, usually because Claude Code wrote something between them, and the API now rejects the whole history on every turn.

What to do

Run claude update, since 2.1.282 strips the broken advisor blocks and retries. If it still fails, /rewind to before the advisor call or start a new session.

This one only shows up in sessions that have used the advisor, the Claude Code feature that lets the model you're working with ask a stronger one for guidance. The full line reads like this, with a different message number and id each time:

API Error: 400 messages.7.content.0: unexpected `tool_use_id` found in `advisor_tool_result` blocks: srvtoolu_01TCvooHAGVGdTUkNybFFiVd. Each `advisor_tool_result` block must have a corresponding `server_tool_use` block before it.

The wording comes from Anthropic's API, not from Claude Code, and the reports quoting it match word for word. 143 issues in anthropics/claude-code mention server_tool_use as of September 25, 2026, and 49 quote this sentence.

What a server_tool_use block is

The advisor runs as a server tool. When Claude calls it, the response contains a server_tool_use block (the call) and, later in the same response, an advisor_tool_result block (the answer). The API wants the answer to follow its call inside one assistant message. If anything sits between them in the history Claude Code sends back, the answer arrives with nothing to match, and the request fails.

It's the server-side cousin of “400 due to tool use concurrency issues”, which is about ordinary tool calls and their results.

What splits the pair

An advisor call can take a while, and Claude Code keeps writing the session file while it waits. The reports I read all found the same thing in that file: an extra record sitting between the call and the answer. The ones people identified were a slash command run mid-call (/usage, /effort, /mcp), the reminder Claude Code writes when a session gets renamed, and a Stop hook firing mid-turn. Compaction breaking the pair turns up in older issue titles too.

Boris Cherny, of the Claude Code team, confirmed the mechanism in August on version 2.1.233. With slash-command records "between the two halves of a single assistant message that carries a server-side tool call, every request from then on fails", and removing those records got the same transcript past the check. He said the team was tracking two fixes: stop writing records into the middle of such a message, and drop an orphaned server-tool result when a request is assembled so a broken session recovers by itself.

Turning the advisor off doesn't help once it's happened. The first reporter in May tried exactly that. The broken pair is already in the history, so every request carries it.

What 2.1.282 does about it

The second of those fixes is in the code now. In the 2.1.282 binary, Claude Code recognizes this 400, strips the advisor blocks out of the affected messages (leaving the text [Advisor response] where nothing else remains) and retries. The changelog for 2.1.281 says such a history "is now repaired once" rather than failing a request every turn.

I can't tell you it always works. Someone reported the error on 2.1.281 on September 24, the day before I read this, and I couldn't find a report either way for 2.1.282.

What to do

Update first with claude update and resume the session. If it still fails, Anthropic's error reference gives /rewind (or Esc twice) as the way back from a history whose tool blocks don't line up. Pick a point before the advisor call. None of the threads say whether that clears this particular case, so if it doesn't, a new session will. Until the injection side is fixed, it's worth not running slash commands or renaming the session while the advisor is being consulted.

The proxy version

A different server_tool_use error hits people behind a third-party proxy set with ANTHROPIC_BASE_URL. The error reference says sessions written through such a proxy could fail every turn on resume with server_tool_use.name: Input should be 'web_search', 'web_fetch', ... before v2.1.246. Newer versions remove that content on load when connected straight to Anthropic, leaving the line [Unsupported tool content removed].

Other lines the same feature prints

Match yours against these if the one at the top of the page is not quite it. They come from the same code and mean related things.

  • API Error: 400 messages.7.content.0: unexpected `tool_use_id` found in `advisor_tool_result` blocks: srvtoolu_
  • unexpected `tool_use_id` found in `advisor_tool_result` blocks
  • Advisor tool result content could not be processed
  • server_tool_use.name: Input should be 'web_search', 'web_fetch'