@ai-sdk/open-responses: reasoning items are never replayed in assistant messages, breaking tool loops on providers that require them

[Astro-Han]

Description

convertToOpenResponsesInput() handles only text and tool-call parts in the assistant branch — there is no reasoning case. Reasoning received from the provider is parsed correctly on the response side but is silently dropped when the conversation is sent back, so the round trip is asymmetric.

Reproduction

Deterministic, and needs no API key, no network and no particular provider:

import { createOpenResponses } from '@ai-sdk/open-responses';

let body;
const fetch = async (_url, init) => {
  body = JSON.parse(String(init.body));
  return new Response(
    JSON.stringify({ id: 'r', object: 'response', created_at: 0, model: 'm',
                     status: 'completed', output: [], usage: { input_tokens: 1, output_tokens: 1 } }),
    { status: 200, headers: { 'content-type': 'application/json' } });
};

const model = createOpenResponses({
  apiKey: 'test', baseURL: 'https://example.invalid/v1', fetch,
})('any-model');

await model.doGenerate({
  prompt: [
    { role: 'user', content: [{ type: 'text', text: 'q' }] },
    { role: 'assistant', content: [
      { type: 'reasoning', text: 'REASONING THAT MUST BE REPLAYED' },
      { type: 'tool-call', toolCallId: 'call_1', toolName: 't', input: {} },
    ]},
    { role: 'tool', content: [
      { type: 'tool-result', toolCallId: 'call_1', toolName: 't',
        output: { type: 'json', value: { ok: true } } },
    ]},
  ],
  tools: [{ type: 'function', name: 't', inputSchema: { type: 'object', properties: {} } }],
});

console.log('reasoning items sent:', body.input.filter((i) => i.type === 'reasoning').length);
console.log(body.input.map((i) => i.type ?? `message:${i.role}`).join(', '));

reasoning items sent: 0
message, function_call, function_call_output

A reasoning part goes in; no reasoning item comes out.

Why it matters

For providers that merely tolerate missing reasoning this is invisible. For providers that require reasoning to be replayed inside a tool loop it makes multi-step tool use impossible.

DeepSeek (deepseek-v4-flash, https://api.deepseek.com/v1/responses) requires it — thinking mode is on by default there, so any tool loop is affected. Omitting the reasoning item returns:

The `reasoning_text` in the thinking mode must be passed back to the API.

Replaying it by hand as {"type":"reasoning","content":[{"type":"reasoning_text","text":...}]}, using a call_id the server cannot associate with a record of its own, and varying only the replayed length:

replayed reasoning	HTTP	usage.input_tokens
omitted	400	—
empty string	400	—
1 char	200	472
3653 chars	200	1388
7307 chars	200	2189
14615 chars	200	4022

Input token accounting scales with the replayed payload, so it is loaded into context rather than accepted and ignored.

Note on server-side recovery

A tool loop run end to end against DeepSeek will often not surface the 400. DeepSeek recovers the reasoning associated with a call_id it issued itself, so as long as the SDK forwards that id unchanged, the omission is masked and the request succeeds — while still being billed for reasoning the SDK never sent.

That recovery is DeepSeek's own behaviour, not part of the Open Responses shape, and another provider implementing that shape need not offer anything comparable. Isolating it with an unassociated call_id is what makes the omission observable, which is why the table above uses one. The serialization gap itself is independent of all of this — see the reproduction above.

Expected

The assistant branch should emit reasoning parts as Open Responses reasoning items, positioned with the function_call they belong to:

{"type": "reasoning", "content": [{"type": "reasoning_text", "text": "..."}]}

This is the same shape the package already parses on the response side (case "reasoning": for (const contentPart of part.content) ...).

Notes

• @ai-sdk/openai's Responses implementation is not an alternative here: it speaks OpenAI's proprietary summary[] + encrypted_content extension, and its request-side pass drops any reasoning item whose encrypted_content is null when store is not true. Providers following the Open Responses shape lose reasoning in both directions there.
• Related, on the Chat wire: Feature Request: Preserve provider-specific fields in @ai-sdk/openai-compatible message conversion #11342.

Environment

@ai-sdk/open-responses 2.0.23

[ai-sdk-factory]

Identify issue type

Identified as Bug
Confidence: High

Rationale

This describes a concrete failure in existing message conversion behavior: provider-returned reasoning is silently omitted on replay, breaking multi-step tool use for providers that require it.

Evidence

• convertToOpenResponsesInput() reportedly drops assistant reasoning parts while converting conversation history.
• In a DeepSeek tool loop, the missing replayed reasoning causes the second request to fail with HTTP 400.
• The package already parses reasoning response items, but does not serialize them back into subsequent requests, preventing a symmetric round trip.

[ai-sdk-factory]

Bug Reproduction - AI SDK 7

Bug could not be reproduced.

Target branch: main

• The runnable artifact at examples/ai-functions/src/reproduction/open-responses-deepseek-reasoning-replay.ts exercises the reported two-step tool loop using @ai-sdk/open-responses 2.0.23, deepseek-v4-flash, and https://api.deepseek.com/v1/responses.
• The expected round-two HTTP 400 did not occur; DeepSeek returned HTTP 200 and the AI SDK completed the tool loop with the final date response.
• The captured round-two request omitted the reasoning item, confirming the secondary serialization gap in packages/open-responses/src/responses/convert-to-open-responses-input.ts.
• The round-two request retained DeepSeek's provider-issued tool call ID; DeepSeek accepted that request despite the missing reasoning item.
• A direct narrowing check with an unassociated synthetic call ID returned HTTP 400 when reasoning was omitted and HTTP 200 when one reasoning character was supplied, but that failure did not occur in the actual AI SDK tool loop.

Relevant Documentation

• https://api-docs.deepseek.com/guides/thinking_mode
• https://api-docs.deepseek.com/api/create-chat-completion
• https://api-docs.deepseek.com/quick_start/pricing/

Closed PR: cannot-reproduce investigation pull request

[ai-sdk-factory]

Cannot reproduce.

[Astro-Han]

Thanks for running this down — I think the investigation actually reproduced it. The report reads as "cannot reproduce" because it treats the 400 as the defect, but the 400 is only how the defect surfaces when server-side recovery is unavailable. Three findings in your own report:

The captured round-two request omitted the reasoning item, confirming the secondary serialization gap in packages/open-responses/src/responses/convert-to-open-responses-input.ts

That is the bug.

The round-two request retained DeepSeek's provider-issued tool call ID; DeepSeek accepted that request despite the missing reasoning item

That is why the loop still passed. DeepSeek recovers the reasoning associated with a call_id it issued, so the omission is masked for as long as that association holds — while the request is still billed for reasoning the SDK never sent.

A direct narrowing check with an unassociated synthetic call ID returned HTTP 400 when reasoning was omitted and HTTP 200 when one reasoning character was supplied

That is exactly the isolation the issue described, and it reproduced.

Reproduction without a provider

I've rewritten the issue to lead with this instead of the 400, since the serialization gap is deterministic and needs no key, no network and no DeepSeek:

import { createOpenResponses } from '@ai-sdk/open-responses';

let body;
const fetch = async (_url, init) => {
  body = JSON.parse(String(init.body));
  return new Response(
    JSON.stringify({ id: 'r', object: 'response', created_at: 0, model: 'm',
                     status: 'completed', output: [], usage: { input_tokens: 1, output_tokens: 1 } }),
    { status: 200, headers: { 'content-type': 'application/json' } });
};

const model = createOpenResponses({
  apiKey: 'test', baseURL: 'https://example.invalid/v1', fetch,
})('any-model');

await model.doGenerate({
  prompt: [
    { role: 'user', content: [{ type: 'text', text: 'q' }] },
    { role: 'assistant', content: [
      { type: 'reasoning', text: 'REASONING THAT MUST BE REPLAYED' },
      { type: 'tool-call', toolCallId: 'call_1', toolName: 't', input: {} },
    ]},
    { role: 'tool', content: [
      { type: 'tool-result', toolCallId: 'call_1', toolName: 't',
        output: { type: 'json', value: { ok: true } } },
    ]},
  ],
  tools: [{ type: 'function', name: 't', inputSchema: { type: 'object', properties: {} } }],
});

console.log('reasoning items sent:', body.input.filter((i) => i.type === 'reasoning').length);
console.log(body.input.map((i) => i.type ?? `message:${i.role}`).join(', '));

reasoning items sent: 0
message, function_call, function_call_output

A reasoning part goes in; no reasoning item comes out.

Why the recovery shouldn't settle it

It is DeepSeek's own behaviour, tied to a call_id it issued — not part of the Open Responses shape, and another provider implementing that shape need not offer anything comparable. The narrowing check already shows what happens the moment the association is gone: omitting reasoning is a hard 400, supplying a single character is a 200. Correctness here currently rests on a provider-specific fallback rather than on sending what the conversation contained.