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

Based on my search, I found the following related PRs:

Potential Related PRs

1. PR fix(provider): auto-enable interleaved for reasoning models #24218 - fix(provider): auto-enable interleaved for reasoning models

   • This PR is explicitly mentioned in the current PR description as "Layer 1 only" — the current PR (24250) builds upon this fix to address all three layers of the bug.

2. PR fix(provider): preserve Bedrock Claude reasoning replay #23927 - fix(provider): preserve Bedrock Claude reasoning replay

   • Related to reasoning content preservation across multi-turn conversations for a different provider.

3. PR fix(provider): drop empty content messages after interleaved reasoning filter #17712 - fix(provider): drop empty content messages after interleaved reasoning filter

   • Related to handling empty reasoning content in interleaved transforms.

Note

The current PR #24250 is not a duplicate itself — it's a comprehensive fix that extends PR #24218 to cover the complete two-layer bug where reasoning_content is dropped on conversation replay for DeepSeek thinking mode. The description clearly indicates this is an incremental improvement over the existing fix.

Consideration: Scoping the fix to avoid unintended side effects on other reasoning models

First commit auto-enables interleaved: { field: "reasoning_content" } for all models with capabilities.reasoning: true, and the fallback injects reasoning_content: "" into providerOptions for all assistant messages when reasoning is active.

This is likely harmless for non-DeepSeek models because:

1. Provider-specific SDKs only read fields they recognize — unknown fields are ignored
2. reasoning_content is not a field used by the Anthropic, OpenAI, or Gemini SDKs
3. An empty string value is a no-op even if read

However, if you want to be conservative and scope the fix to only providers that actually need this pattern, the fallback could be gated more narrowly:

// Instead of:
if (model.capabilities.reasoning) {

// Consider:
if (model.capabilities.reasoning && (
  model.api.id.includes("deepseek") || 
  model.id.includes("deepseek") ||
  model.api.npm === "@ai-sdk/openai-compatible" ||
  model.api.npm === "@openrouter/ai-sdk-provider"
)) {

This ensures the reasoning_content injection only fires for:

• Direct DeepSeek API calls
• OpenRouter-routed DeepSeek models
• Any openai-compatible provider (since that's where the reasoning_content field pattern originates)

It would leave other reasoning models (Claude thinking, o-series, Gemini) unaffected and avoid unnecessary providerOptions writes.

Happy to push this as an additional commit if you prefer the narrower scope. Leaving it as-is is also fine if you're confident the extra fields are truly no-op for other providers.

is this working for you? As you can see here #24190 (comment) this could be an openrouter issue too.

@rekram1-node this PR addresses the reasoning_content round-trip bug discussed in #24093. The fix is client-side (transform.ts) so it applies regardless of the upstream provider (OpenRouter, opencode-go, direct API). Let me know if you need any changes.

Update: Fixed second-pass regression (commit 41eb35a)

Issue #24442 identified a regression where the interleaved transform overwrites existing with empty string on subsequent passes (after DB round-trip). Reproduced and confirmed — affects upstream dev (post-#24146), this PR, and the new #24443.

The fix (41eb35a): Swapped the order of spread and set so existing values take priority:

\

• Pass 1: no existing providerOptions → reasoningText wins ✓
• Pass 2: existing value from DB → survives empty reasoningText ✓

This is equivalent to the approach in PR #24443 — both are correct, maintainer can pick either.

Reproduction script and full trace at #24442 (comment)

I think everything behaves as expected in latest release (going out rn).

This introduces other changes that change default behaviors of reasoning models which is a separate discussion and not necessarily a bug fix.

if u want to discuss further discuss w/ me on this issue:
#24442