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.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` blocksAdvisor tool result content could not be processedserver_tool_use.name: Input should be 'web_search', 'web_fetch'