fix(anthropic): ensure reasoning blocks precede tool_use in assistant messages

[riftzen-bit]

Fixes #9364

Problem

When using Claude models with Extended Thinking enabled, multi-turn conversations with tool use fail with:

messages.X.content.0.type: Expected 'thinking' or 'redacted_thinking', but found 'tool_use'

Root Cause

The normalizeMessages function filters empty content but does not reorder parts to ensure reasoning blocks come before tool-call blocks in assistant messages.

Solution

Added sorting logic for assistant messages in the Anthropic-specific block. Parts are now ordered by priority:

• reasoning: 0 (first)
• text: 1
• tool-call: 2
• everything else: 3

This ensures compliance with Anthropic's Extended Thinking API requirements.

References

• https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking
• Related: [bug] v0.8.0 Introduced thinking block bug with Claude Sonnet 4: "AI_APICallError: messages.3.content.0.type: Expected thinking or redacted_thinking, but found text." #2599, Expected thinking or redacted_thinking, but found tool_use #3077

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

Related PR:

• fix: strip incompatible thinking blocks when switching to Claude #8958 - "fix: strip incompatible thinking blocks when switching to Claude"
  • fix: strip incompatible thinking blocks when switching to Claude #8958
  • This PR appears to handle thinking/reasoning block compatibility when switching between Claude models, which is related to the extended thinking feature handling in your PR fix(anthropic): ensure reasoning blocks precede tool_use in assistant messages #10474.

This could be relevant context for understanding how thinking blocks are handled across the codebase, though it may not be a direct duplicate since your PR specifically addresses the ordering issue in normalizeMessages for Anthropic's API requirements.

[rekram1-node]

When did you encounter this issue?

Can you share the session?

Run opencode export > session.json in your TERMINAL (not the tui) and then send session export of it

[riftzen-bit]

I encountered this problem this afternoon and it hasn't been fixed yet. I'm trying to figure it out, but it doesn't seem to be working. Because I don't know where the problem is coming from.

[riftzen-bit]

session.json

[rekram1-node]

The provided session has no such errors?

[riftzen-bit]

I don't know, but I've been encountering it constantly in recent chat messages.

[riftzen-bit]

session.json

[rekram1-node]

Sorry if I wasn't clear, can you export the session in which you encountered this error? Because the sessions you are linking aren't relevant

[riftzen-bit]

I've fixed it now, it was due to plugins.