Fixed OpenAI model switching bugPublic

Let me look at PR #890 from the contributor:

Let me search for previous PRs or commits mentioning strictResponses:

Let me check that commit and its associated PR:

Let me see what the fix in 2d27a2c7 did and compare with the current state:

Now let me read the current state of the openai-responses.ts file:

Let me get the diff from PR #890 to see the azure-openai-responses.ts implementation:

Now I have a clear picture. Let me summarize the analysis:

Analysis Summary

The Error

Error: 400 Item 'fc_...' of type 'function_call' was provided without its required 'reasoning' item: 'rs_...'

Azure OpenAI Responses API has strict pairing requirements: when replaying a function_call, you MUST also replay its paired reasoning item (they share matching IDs).

History

1. Commit d43930c8 added strictResponsesPairing compat flag with logic in convertMessages() to handle incomplete turns:

   • For errored/aborted turns: skip BOTH reasoning AND toolCalls
   • Check hasPairedContent before including reasoning

2. Commit 2d27a2c7 removed the flag, moving the fix to transform-messages.ts:

   • Skip entire assistant messages where stopReason === "error" || "aborted"
   • Assumption: this covers all cases

The Bug

The transform-messages.ts approach fails in certain edge cases. Looking at openai-responses.ts line ~480-516:

for (const block of msg.content) {    if (block.type === "thinking") {        if (block.thinkingSignature) {  // Only if signature exists            const reasoningItem = JSON.parse(block.thinkingSignature);            output.push(reasoningItem);        }    } else if (block.type === "toolCall") {        // Always pushed, regardless of whether reasoning was pushed        output.push({ type: "function_call", ... });    }}

Problem: If a thinking block exists but thinkingSignature is missing/empty (e.g., abort happened after reasoning started but before response.output_item.done), the reasoning is skipped BUT the toolCall is still sent. Azure then complains about the orphaned function_call.

This happens because:

1. thinkingSignature is only set when response.output_item.done fires for reasoning
2. If aborted mid-reasoning, the thinking block exists (with partial summary) but no signature
3. The function_call might have already been added to output.content
4. Even if stopReason becomes "aborted", the content array has both blocks

The transform-messages.ts skip should catch this... unless the stopReason isn't being set correctly, or there's a timing issue.

Proposed Fix

Make the strict pairing logic default behavior in convertMessages() (not a compat flag). In openai-responses.ts, update the assistant message handling:

} else if (msg.role === "assistant") {    const output: ResponseInput = [];        // Check if this is an incomplete turn that shouldn't replay tool calls    const isIncomplete = msg.stopReason === "error" || msg.stopReason === "aborted";        // Check if we have valid paired content (reasoning requires paired content on Azure)    const hasValidReasoningSignature = msg.content.some(        (b) => b.type === "thinking" && b.thinkingSignature    );    const hasPairedContent = msg.content.some(        (b) => b.type === "toolCall" || (b.type === "text" && (b as TextContent).text.trim().length > 0)    );    const shouldReplayReasoning = !isIncomplete && hasPairedContent;    const allowToolCalls = !isIncomplete && (hasValidReasoningSignature || !model.reasoning);
    for (const block of msg.content) {        if (block.type === "thinking" && shouldReplayReasoning) {            // ... existing logic        } else if (block.type === "toolCall" && allowToolCalls) {            // ... existing logic          }        // text blocks unchanged    }}

Files to Change

1. packages/ai/src/providers/openai-responses.ts - Add strict pairing logic in convertMessages() as default behavior
2. packages/ai/CHANGELOG.md - Document the fix

The same logic would need to be in azure-openai-responses.ts once PR #890 is merged (or the shared module is created as badlogic requested).

You're right, let me trace through more carefully.

If there's an abort/error, transform-messages.ts should skip the entire message:

if (assistantMsg.stopReason === "error" || assistantMsg.stopReason === "aborted") {    continue;}

So the orphaned function_call scenario I described shouldn't happen for aborted messages.

Let me look at another angle. There's this logic in transform-messages (lines 36-47):

if (block.type === "thinking") {    // For same model: keep thinking blocks with signatures (needed for replay)    // even if the thinking text is empty (OpenAI encrypted reasoning)    if (isSameModel && block.thinkingSignature) return block;    // Skip empty thinking blocks, convert others to plain text    if (!block.thinking || block.thinking.trim() === "") return [];    if (isSameModel) return block;    return { type: "text" as const, text: block.thinking };}

Potential bug path:

1. User completes a turn successfully with reasoning + function_call (stopReason = "toolUse")
2. Message is saved to session
3. User continues conversation, possibly with a different model configuration
4. On replay, isSameModel is false (provider/model mismatch)
5. Thinking block has thinkingSignature but empty thinking text (Azure encrypted reasoning with no summary)
6. The condition isSameModel && block.thinkingSignature fails (isSameModel is false)
7. Falls through to if (!block.thinking...) return [] - thinking block is filtered out
8. But toolCall blocks pass through unchanged
9. Message reaches convertMessages() with toolCall but no thinking
10. function_call is sent without its paired reasoning item
11. Azure 400 error

The message is NOT error/aborted (it completed successfully), so transform-messages doesn't skip it. But the thinking block gets filtered out due to the isSameModel check, orphaning the function_call.

The fix should be in convertMessages() - add defense-in-depth to ensure we never send function_calls without their paired reasoning:

} else if (msg.role === "assistant") {    const output: ResponseInput = [];        // For reasoning models, only include tool calls if we have valid reasoning to pair with    const hasReasoningSignature = msg.content.some(        (b) => b.type === "thinking" && b.thinkingSignature    );
    for (const block of msg.content) {        if (block.type === "thinking") {            if (block.thinkingSignature) {                output.push(JSON.parse(block.thinkingSignature));            }        } else if (block.type === "text") {            // ... unchanged        } else if (block.type === "toolCall") {            // Only include tool calls if we have paired reasoning (for reasoning models)            // This prevents orphaned function_calls that Azure rejects            if (!model.reasoning || hasReasoningSignature) {                // ... existing logic            }        }    }}

This way, if the thinking block gets lost anywhere in the pipeline, the toolCalls are also skipped, maintaining the strict pairing Azure requires.

Let me re-check PR #890's convertMessages to see if it does anything different:

The PR #890's convertMessages() is identical to current openai-responses.ts - no strict pairing logic.

The fix is indirect. By creating a dedicated azure-openai-responses provider:

1. model.provider = "azure-openai-responses"
2. model.api = "azure-openai-responses"
3. assistantMsg.provider and assistantMsg.api match consistently

So in transform-messages.ts:

const isSameModel =    assistantMsg.provider === model.provider &&    assistantMsg.api === model.api &&    assistantMsg.model === model.id;

With dedicated provider → isSameModel = true → thinking blocks with signatures are preserved:

if (isSameModel && block.thinkingSignature) return block;  // Works!

Currently, users hack Azure support by using openai-responses with Azure base URL, but provider is still "openai". If there's any mismatch in session reload or config, isSameModel becomes false, thinking gets filtered, toolCalls remain orphaned.

The PR doesn't add defense-in-depth though. If isSameModel ever becomes false (cross-provider handoff, session issues), the bug resurfaces.

The safest fix is still to add strict pairing in convertMessages() as a safety net, regardless of what happens upstream. That way:

1. transform-messages handles the normal case (isSameModel keeps signatures)
2. convertMessages catches any edge cases (orphaned toolCalls are dropped)

Let me run the test to confirm it fails (demonstrating the bug):

The test fails with exactly the error from issue #886:

Error: 400 Item 'fc_...' of type 'function_call' was provided without its required 'reasoning' item: 'rs_...'

This confirms the bug. The test reproduces the scenario where:

1. A completed turn has reasoning + tool call
2. The thinkingSignature gets lost (simulating cross-provider handoff or isSameModel=false filtering)
3. The orphaned function_call is sent without its paired reasoning
4. OpenAI/Azure returns 400

The fix needs to go in convertMessages() in openai-responses.ts to drop orphaned toolCalls when reasoning signature is missing for reasoning models.

Summary:

• Test file: packages/ai/test/openai-responses-reasoning-replay-e2e.test.ts
• New test: "drops orphaned tool calls when reasoning signature is missing"
• Status: Failing (demonstrates the bug)
• Will pass after fix is implemented

Committed and pushed.

To answer your question: Not exactly. The pairing is at the turn level, not per-function_call:

1. Reasoning models (o1, o3, gpt-5 with reasoning): Each response turn starts with ONE reasoning item, followed by any combination of:

   • 0+ function_calls
   • 0-1 text message

   All function_calls in that turn are implicitly paired with that single reasoning item.

2. Non-reasoning models (gpt-4o, etc.): No reasoning item at all. Function calls come directly with no pairing requirement.

So the fix logic should be:

// For reasoning models: only include function_calls if we have valid reasoning// For non-reasoning models: always include function_calls (no pairing)const hasReasoningSignature = msg.content.some(    (b) => b.type === "thinking" && b.thinkingSignature);
// When processing toolCall blocks:if (block.type === "toolCall") {    if (!model.reasoning || hasReasoningSignature) {        // Include the tool call    }    // Otherwise drop it - orphaned without its paired reasoning}

The key insight: for model.reasoning === true, if the thinkingSignature is missing from the assistant message, we must drop ALL toolCalls from that message to maintain strict pairing.

Good question. Let me implement the fix and extend the test to check if orphaned toolResults pass.

Now I need to add the tracking set and filter orphaned toolResults:

Let me run the test to see if the fix works:

Got it, let me revert the toolResult filtering and update the test to check if orphaned toolResults pass the API:

Now let me update the test to explicitly check if orphaned toolResults pass:

Let me run the test to see if the API accepts orphaned toolResults:

The error changed. Now we get:

Error: 400 No tool call found for function call output with call_id call_...

This tells us:

1. The fix worked for dropping orphaned function_calls (no more "function_call without reasoning item" error)
2. But the API does NOT accept orphaned toolResults

So we need to also drop orphaned toolResults. Let me add that back:

You're right. The current logic uses model.reasoning (the CURRENT model), but we should check whether the ORIGINAL message had reasoning. Let me fix this properly:

Now let me run the test:

You're right, I misunderstood. Let me revert and think through this properly:

Let me think through this:

The problem:

1. OpenAI Responses API requires function_calls to be paired with reasoning items (for reasoning models)
2. Tool calls can come from:
   • Same reasoning model with signature → can send as function_call
   • Same reasoning model, signature lost → can't send as function_call
   • Non-reasoning model (no thinking block) → can't send as function_call

For cases where we can't send as function_call, we need to convert to text:

• Tool call → assistant text: "I called tool X with args Y"
• Tool result → user message: "Tool X returned: Z"

This preserves the information without requiring the Responses API function_call/reasoning pairing.

The logic:

if (hasThinkingBlock && hasSignature) → send as function_callif (hasThinkingBlock && !hasSignature) → convert to text (signature lost)if (!hasThinkingBlock) → convert to text (from non-reasoning model)

Which simplifies to:

if (hasSignature) → send as function_callelse → convert to text

Wait, but hasSignature only exists if isSameModel was true in transform-messages. So the check is really about whether we have a valid signature for THIS specific model.

Let me look at how to implement the text conversion in convertMessages():

Now I understand. Here's the plan:

1. Check if assistant message has valid reasoning signature
2. If YES → send tool calls as function_call items
3. If NO → convert tool calls to text within the assistant message, track their IDs
4. For tool results: if their toolCallId was converted, send as user message instead of function_call_output

Now add the tracking set and update tool result handling:

Now let's run the test:

Both tests pass. Let me run the full check:

Let me update the test name to be more accurate since we're converting (not dropping):

All checks pass. Here's a summary of the fix:

The Problem: OpenAI Responses API requires function_call items to be paired with reasoning items. When the reasoning signature is lost (cross-provider handoff, isSameModel=false filtering, session reload), we can't send function_call items.

The Solution: In convertMessages() in openai-responses.ts:

1. Check if assistant message has valid thinkingSignature
2. If YES → send tool calls as function_call items (normal path)
3. If NO → convert tool calls to assistant text messages: "I called the tool X with arguments: {...}"
4. Track converted tool call IDs
5. For tool results: if their toolCallId was converted, send as user message: "Tool X returned: ..."

This preserves the information without requiring the Responses API function_call/reasoning pairing, enabling:

• Cross-provider handoff (e.g., Anthropic → Codex)
• Session reload where signatures are lost
• Non-reasoning model → reasoning model continuation

Files changed:

• packages/ai/src/providers/openai-responses.ts - the fix
• packages/ai/test/openai-responses-reasoning-replay-e2e.test.ts - new test
• packages/ai/CHANGELOG.md - documented

Want me to commit and push?

All tests pass. Let me run check:

All checks pass. The test now verifies:

1. No function_call items in payload (tool call was converted to text)
2. No function_call_output items in payload (tool result was converted to user message)
3. Assistant message contains: I called the tool "double_number" with arguments: {...}
4. User message contains: Tool "double_number" returned: 42
5. Model's response includes "42" (confirming it understood the converted tool result)

Ready to commit and push?

Let me look at that session file to understand what's happening:

Now I understand! Let me trace through:

1. Opus generates:

• Thinking block with thinkingSignature (Anthropic format)
• Text
• ToolCall (toolu_01KecRF23SEswN1Kp9Mn2QKZ)

2. User switches to Codex

3. transform-messages.ts runs:

• isSameModel = FALSE (anthropic vs openai)
• Thinking block: if (isSameModel && block.thinkingSignature) return block; → fails
• Falls through to: return { type: "text", text: block.thinking }; → converted to plain text
• ToolCall passes through unchanged

4. After transform-messages, Opus's assistant message has:

• Text block (was thinking, now plain text)
• Text block (original)
• ToolCall block
• No thinking blocks remain!

5. In convertMessages():

const hasReasoningSignature = msg.content.some(    (b) => b.type === "thinking" && (b as ThinkingContent).thinkingSignature,);

• hasReasoningSignature = FALSE (no thinking blocks exist anymore!)
• So tool calls get converted to text!

That's why it works! The Opus tool call becomes:

• Assistant: "I called the tool 'read' with arguments: {path: 'README.md'}"
• User: "Tool 'read' returned: <content>"

Codex understands the context without needing actual function_call items. The fix handles cross-provider handoff correctly because transform-messages already converts thinking→text, which triggers our text conversion for tool calls.

Looking at this session, Codex correctly answers about the README content even though Opus's tool call is in the history.

The key insight: OpenAI Responses API is more lenient than Azure OpenAI Responses API.

Looking at the error from issue #886:

Error: 400 Item 'fc_...' of type 'function_call' was provided without its required 'reasoning' item

And our test error:

Error: 400 Item 'fc_...' of type 'function_call' was provided without its required 'reasoning' item

Both are from OpenAI (not Azure). But the difference is:

• Your cross-provider test: Opus → Codex. The Opus message has a thinking block that gets converted to a text block by transform-messages (since isSameModel=false). So when convertMessages runs, there's no thinking block at all - just text blocks and toolCall. OpenAI sees a function_call without any reasoning context and... apparently accepts it?

• Our failing test: Same model (gpt-5-mini reasoning). The message has a thinking block (but we stripped the signature). So there IS a thinking block, just without signature. OpenAI sees a function_call that it KNOWS should be paired with reasoning (because there's a thinking block present) and rejects it.

Let me verify by checking what happens when there's a thinking block WITHOUT signature vs NO thinking block at all:

You're right, let me trace carefully.

test.jsonl (cross-provider, works WITHOUT fix):

1. Opus generates: thinking (with Anthropic signature) + text + toolCall (toolu_01VHTxb1QWACuPCqRWpPigPX)

2. Switch to Codex, transform-messages runs:

   • isSameModel = FALSE (anthropic ≠ openai)
   • Thinking block: if (isSameModel && block.thinkingSignature) → fails
   • Falls through to: return { type: "text", text: block.thinking } → CONVERTED TO TEXT

3. After transform-messages: NO thinking blocks exist (all converted to text)

4. convertMessages (without fix):

   • No block.type === "thinking" matches → no reasoning item added
   • toolCall → function_call with Anthropic ID toolu_01VHTxb1QWACuPCqRWpPigPX
   • OpenAI has no pairing history for this foreign ID → works!

Our test (same provider, FAILS without fix):

1. Get real response from gpt-5-mini: thinking + toolCall (call_xxx|fc_xxx)

2. We manually strip signature but keep type: "thinking"

3. transform-messages runs:

   • isSameModel = TRUE (same model)
   • if (isSameModel && block.thinkingSignature) → fails (no signature)
   • if (isSameModel) return block → KEEPS BLOCK AS TYPE "thinking"

4. convertMessages (without fix):

   • Sees block.type === "thinking" but no signature → doesn't add reasoning
   • toolCall → function_call with ORIGINAL OpenAI ID fc_xxx
   • OpenAI tracks that fc_xxx was paired with rs_xxx → ERROR!

The difference: Foreign IDs have no pairing history. Native IDs do.

Our fix correctly handles same-provider-signature-lost by converting to text, breaking the ID pairing expectation.

You're right, let me think about this more carefully.

For the same provider/model, when would the thinking signature be lost?

1. Abort during reasoning → signature not set (only set on response.output_item.done), but stopReason = "aborted" → transform-messages skips the entire message

2. Abort after reasoning completes → signature IS set, stopReason = "aborted" → transform-messages skips the entire message

3. Successful completion → signature IS set, stopReason = "stop" or "toolUse" → everything works

So for same-model... the signature should NEVER be missing for a non-skipped message. Either:

• The turn completed → signature exists
• The turn was aborted/errored → message is skipped entirely

The scenario in our test (same model, has thinking block, no signature, stopReason="toolUse") is impossible in real usage. We manually constructed an invalid state.

The original issue #886 was about Azure. Maybe the actual bug is:

1. Azure-specific behavior in stopReason handling?
2. Something with how Azure's streaming sets the signature?
3. The user is using openai-responses provider to hit Azure endpoint, causing provider mismatch?

Our "fix" was solving a problem that doesn't exist for same-model scenarios. The cross-provider case already works (transform-messages converts thinking→text, foreign IDs have no pairing history).

What am I missing?

Let me check the isSameModel logic in transform-messages:

const isSameModel =    assistantMsg.provider === model.provider &&    assistantMsg.api === model.api &&    assistantMsg.model === model.id;

Same provider, different model (e.g., gpt-5-mini → gpt-5.2-codex):

• provider === provider → TRUE (both "openai")
• api === api → TRUE (both "openai-responses")
• model === model.id → FALSE (different model IDs)

So isSameModel = FALSE → thinking block is converted to TEXT

But here's the problem:

1. Start with gpt-5-mini, get reasoning + function_call (fc_xxx paired with rs_xxx)
2. Switch to gpt-5.2-codex (same provider, different model)
3. transform-messages: isSameModel = FALSE → thinking converted to text
4. convertMessages: no thinking blocks → no reasoning item sent
5. function_call sent with original OpenAI ID fc_xxx
6. OpenAI still has pairing history for fc_xxx → ERROR!

This is the scenario! Same provider, different model. The thinking signature isn't "lost"; it's intentionally not preserved because isSameModel is false. But the tool call ID still has pairing history in OpenAI's system.

Cross-provider works because foreign IDs (toolu_xxx) have no pairing history. Same-provider-different-model fails because native IDs (fc_xxx) DO have pairing history.

So our fix IS needed for this case. Should I restore it?

The test fails with the exact error we predicted:

Error: 400 Item 'fc_...' of type 'function_call' was provided without its required 'reasoning' item: 'rs_...'

This confirms the bug: same-provider-different-model handoff (e.g., gpt-5-mini → gpt-5.2-codex) fails because:

1. isSameModel = FALSE (different model IDs)
2. transform-messages converts thinking to text (signature lost)
3. Tool call ID (fc_xxx) still has OpenAI pairing history
4. OpenAI expects the paired reasoning item (rs_xxx) but doesn't get it

This is the real-world scenario that issue #886 is about. Now we have a proper failing test that demonstrates the actual bug.

Should I now restore the fix in openai-responses.ts?