[Bug] Anthropic extended thinking: reasoning blocks lost during multi-step tool calls

[NicolaiHerforth]

Description

When using streamText with Anthropic thinking models (e.g., claude-sonnet-4-20250514), reasoning content is lost during multi-step tool call workflows.

Two related issues:

1. response.messages reasoning parts are missing providerMetadata with signatures - The signature is only available in the separate reasoning array, making it impossible to properly reconstruct messages for subsequent turns.

2. In onFinish, reasoning is lost from consolidated response.messages - When using AI SDK's built-in agent loop (maxSteps), onStepFinish shows reasoning on all turns, but onFinish loses 75% of reasoning blocks.

---

Reproduction

Gist: https://gist.github.com/p3droml/503c5d4888182a75222377109bfdd291

To run:
git clone https://gist.github.com/p3droml/503c5d4888182a75222377109bfdd291.git mre
cd mre && npm install
ANTHROPIC_API_KEY=your-key npx tsx anthropic-thinking-bug.ts

ProviderMetadata Issue

When extracting reasoning from response.messages, the signature is not included:

// response.messages reasoning part:
{ type: "reasoning", text: "..." }  // NO providerMetadata!

// separate reasoning array:
{ type: "reasoning", text: "...", providerMetadata: { anthropic: { signature: "Esg..." } } }

---

Root Cause Analysis

The Pattern Explained

1. Turn 1: User message → Model generates thinking + tool call → reasoning present ✅
2. Turn 2-4: Tool results sent back → Model processes results without generating NEW thinking → reasoning missing ❌

The model doesn't always generate new thinking blocks when processing tool results. This is expected model behavior. However:

1. response.messages reasoning parts don't include providerMetadata with signatures - making it impossible to properly forward thinking blocks
2. onFinish loses reasoning that was present in onStepFinish - consolidation drops 75% of reasoning

Anthropic's Requirements

From Anthropic's Extended Thinking Documentation:

"When thinking is enabled, a final assistant message must start with a thinking block (preceding the lastmost set of tool_use and tool_result blocks). We recommend you include thinking blocks from previous turns."

"You must include the complete, unmodified thinking or redacted_thinking block back to the API."

---

Related Issues

• openai/openai-agents-js#770 - "Anthropic with reasoning and tool calling fails to send thinking content back up on subsequent turn"
• vercel/ai#4992 - appendResponseMessages ignores reasoning (fixed in PR fix (ai/core): add reasoning support to appendResponseMessages #5041)
• vercel/ai#8823 - Post-tool reasoning missing from steps
• vercel/ai#5087 - Reasoning promises undefined with streamText

---

Environment

ai: 6.0.16
@ai-sdk/anthropic: 3.0.8
Model: claude-sonnet-4-20250514
Node.js: 22.x
OS: macOS

---

Expected Behavior

1. Reasoning should be preserved and available in onFinish for ALL responses
2. The response.messages array should include reasoning blocks with providerMetadata (signatures)
3. The separate reasoning parameter should be consistent with response.messages
4. Multi-step tool call workflows should maintain reasoning context throughout

---

Actual Behavior

1. response.messages reasoning parts are missing providerMetadata with signatures
2. In onFinish, 75% of reasoning is lost (even though onStepFinish shows reasoning on all turns)
3. Both response.messages and the separate reasoning array are empty for turns 2-4

---

Additional Context

The issue was tested both before and after upgrading from:

• ai@6.0.3 → ai@6.0.16
• @ai-sdk/anthropic@3.0.1 → @ai-sdk/anthropic@3.0.8

The bug persists across versions.

AI SDK Version

ai: 6.0.16
@ai-sdk/anthropic: 3.0.8
Model: claude-sonnet-4-20250514
Node.js: 22.x
OS: macOS

Code of Conduct

• I agree to follow this project's Code of Conduct

[aayush-kapoor]

looking into this a bit more but it would help if you could clean up the reproduction example - for starters this line

const assistantMsg = response.messages.find((m) => m.role === "assistant");

in the first example will only return the first element that satisfies the condition. and hence hasReasoningInMsg=true for all 4 turns, giving a false positive

[aayush-kapoor]

i'll look into the second part of the issue though

[NicolaiHerforth]

looking into this a bit more but it would help if you could clean up the reproduction example - for starters this line

const assistantMsg = response.messages.find((m) => m.role === "assistant");

in the first example will only return the first element that satisfies the condition. and hence hasReasoningInMsg=true for all 4 turns, giving a false positive

Thanks for heads up, fixed

[aayush-kapoor]

sorry i'm having trouble reading it (diff isn't proper), could you tell me what you changed and if the bug maybe still exists. I just want to make sure the reproduction example actually brings out a bug and doesn't produce a false positive again.

also we can get rid of the manual repro script for now - if the bug exists, it should ideally come out in the agentic flow. sometimes manual creation and passing of the messages array leads to weird errors

[p3droml]

I've created a minimal reproduction that consistently triggers this bug:

Gist: https://gist.github.com/p3droml/503c5d4888182a75222377109bfdd291

To run:
git clone https://gist.github.com/p3droml/503c5d4888182a75222377109bfdd291.git mre
cd mre && npm install
ANTHROPIC_API_KEY=your-key npx tsx anthropic-thinking-bug.ts

[NicolaiHerforth]

I added the above to the issue description to keep it cleaner

[NicolaiHerforth]

Also in terms of the bug still existing, it did yes. Both in agentic flow and manual when solving the error you pointed out

[aayush-kapoor]

based on the example above, the issue might be with smoothStream

from the reproduction script when we remove smothStream, the bug goes away. which makes sense since we aren't propagating providerMetadata yet.

@NicolaiHerforth can you confirm if your previous reproduction script relied on smoothStream?

[p3droml]

@aayush-kapoor @NicolaiHerforth Removing smoothStream does indeed fix the bug, thank you.