Follow-up turn + previousResponseId + client tool call → "No tool call found for function call output with call_id"

[ahmedharis994]

Description

Using @ai-sdk/openai@4.0.29 with ai@7.0.51. A multi-turn conversation via the OpenAI Responses API, chaining turns with providerOptions.openai.previousResponseId, and using a plain client-executed tool (tool({ inputSchema, execute }), not a provider-defined tool like local_shell/shell/apply_patch/computer).

First turn (no previousResponseId): the model calls the tool, everything works, response streams normally.

Any follow-up turn (a previousResponseId from the prior turn is set) where the model makes a new tool call: the request fails with

AI_APICallError: No tool call found for function call output with call_id call_XXXXXXXX.

Minimal repro shape:

import { streamText, tool, stepCountIs } from 'ai';
import { openai } from '@ai-sdk/openai';
import { z } from 'zod';

const myTool = tool({
  description: 'a plain client-executed tool',
  inputSchema: z.object({ query: z.string() }),
  execute: async ({ query }) => ({ result: `results for ${query}` }),
});

// Turn 1 — works
const r1 = await streamText({
  model: openai.responses('gpt-4.1-mini'), // or a reasoning model, e.g. gpt-5.x
  prompt: 'search for red shoes',
  tools: { myTool },
  stopWhen: stepCountIs(3),
});
for await (const _ of r1.fullStream) {}
const responseId = (await r1.finalStep).providerMetadata?.openai?.responseId;

// Turn 2 — FAILS: "No tool call found for function call output with call_id ..."
const r2 = await streamText({
  model: openai.responses('gpt-4.1-mini'),
  prompt: 'now search for blue shoes',
  tools: { myTool },
  stopWhen: stepCountIs(3),
  providerOptions: { openai: { previousResponseId: responseId, store: true } },
});
for await (const part of r2.fullStream) {
  if (part.type === 'error') console.error(part.error); // <-- the 400 surfaces here
}

What I found tracing the root cause

In packages/openai/src/responses/convert-to-openai-responses-input.ts, case 'tool-call':, there's an early break:

if (hasPreviousResponseId && store && id != null) {
  break;
}

This drops the assistant's function_call item on a follow-up turn whenever the tool call carries a provider itemId (i.e. id != null) — which includes plain client-executed tool calls, not just provider-defined ones. The matching function_call_output for that call is still sent (it's only referenced by call_id, unconditionally), so the request ends up with a function_call_output whose function_call was never included → OpenAI 400s.

Below that break, there's already a guard for provider-defined tools:

const isProviderDefinedToolCall = /* local_shell | shell | apply_patch | computer | custom */;
if (store && id != null && isProviderDefinedToolCall) {
  input.push({ type: 'item_reference', id });
  break;
}

It looks like the intent (per #15795's own description — "Plain client-executed function calls must NOT be [sent as item_reference]… the matching function_call_output can only reference the call by call_id") was that plain client tool calls should fall through to the unconditional function_call push further down, so they pair with their output by call_id regardless of store/previousResponseId. But the earlier hasPreviousResponseId && store && id != null break fires first and drops them before that fallthrough is reached.

Guarding that break with the same isProviderDefinedToolCall check (and hoisting that const above it) seems to resolve it in local testing — plain client tool calls then fall through and pair correctly.

Environment

• ai: 7.0.51
• @ai-sdk/openai: 4.0.29 (also reproduces on 4.0.33, latest — confirmed same guard ordering on main)
• Node: 24
• Model: reproduces with both gpt-4.1-mini and reasoning models (gpt-5.x)

Related

• AI SDK returns "No tool call found for function call output" when state is "output-available" #8216 (closed) — same error message, similar shape, addressed by fix(openai): send client-executed tool calls as full function_call items in the Responses API #15795
• fix(openai): skip passing reasoning items when using previous response id #15503, fix(openai): send client-executed tool calls as full function_call items in the Responses API #15795 — prior art that introduced/shaped this guard; this looks like a leftover edge case from fix(openai): send client-executed tool calls as full function_call items in the Responses API #15795's fix

Impact

Any multi-turn conversation that chains via previousResponseId (rather than resending full message history) and uses a plain client-executed tool cannot make a new tool call on any turn after the first. This affects any app using server-side conversation chaining + tools with the Responses API — a fairly standard combination.

Reproduction

No response

AI SDK Version

• ai: 7.0.51
• @ai-sdk/openai: 4.0.29 (also reproduces on 4.0.33, latest — confirmed same guard ordering on main)

Code of Conduct

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

[ai-sdk-factory]

Identify issue type

Identified as Bug
Confidence: High

Rationale

This is a concrete failure in current OpenAI Responses API behavior. Follow-up client-executed tool calls are converted incorrectly and cause an API error.

Evidence

• A minimal reproduction shows the first Responses API tool-call turn succeeds, while a follow-up using previousResponseId fails with an OpenAI 400 error.
• The report identifies conversion logic that drops the assistant function_call but still sends its matching function_call_output, leaving an invalid call_id reference.
• The failure reproduces on the latest cited @ai-sdk/openai version and affects existing multi-turn tool behavior.

[ai-sdk-factory]

Bug Reproduction - AI SDK 7

Bug was reproduced.

Branch: main
PR: successful reproduction pull request

Details

• examples/ai-functions/src/reproduction/issue-18537.ts completed the first client-tool turn, but the follow-up chained with previousResponseId returned OpenAI HTTP 400 instead of consuming the new tool result and completing.
• The failed follow-up request contained function_call_output without its matching function_call; adding the matching call to the same request made the direct OpenAI request succeed with HTTP 200, locating the defect in AI SDK request conversion.
• packages/openai/src/responses/convert-to-openai-responses-input.ts skips tool calls carrying an item ID whenever previousResponseId and storage are enabled, including plain client-executed tools.
• packages/openai/src/responses/openai-responses-language-model.test.ts adds a regression test that fails with the primary provider error until the call and output remain paired.
• packages/openai/src/responses/__fixtures__/openai-issue-18537-error.1.json records the live OpenAI 400 response.
• The issue reproduces on main with @ai-sdk/openai 4.0.33 and ai 7.0.55, so the newer core package does not resolve the reported behavior.

Relevant Documentation

• https://platform.openai.com/docs/api-reference/responses-streaming/response/refusal/delta?lang=curl
• https://developers.openai.com/api/docs/models/gpt-4.1-mini

[ai-sdk-factory]

Bug Reproduction - AI SDK 5

Bug could not be reproduced.

Target branch: release-v5.0

• examples/ai-functions/src/reproduction/issue-18537.ts executed a plain client tool exactly once on both the initial live gpt-4.1-mini turn and the previousResponseId-chained follow-up; both returned final text, and the expected OpenAI 400 error did not occur.
• examples/ai-functions/package.json and pnpm-lock.yaml provide the runnable reproduction workspace setup.
• The target branch contains ai@5.0.228 and @ai-sdk/openai@2.0.117 in packages/ai/package.json and packages/openai/package.json, not the reported AI SDK 7/OpenAI provider 4 versions; installing those newer majors would test a different release line.
• packages/openai/src/responses/convert-to-openai-responses-input.ts does not contain the reported hasPreviousResponseId && store && id != null early-break path.

Relevant Documentation

• https://platform.openai.com/docs/api-reference/responses-streaming/response/refusal/delta?lang=curl
• https://developers.openai.com/api/docs/models/gpt-4.1-mini

Closed PR: cannot-reproduce investigation pull request

[ai-sdk-factory]

Bug Reproduction - AI SDK 6

Bug was reproduced.

Branch: release-v6.0
PR: successful reproduction pull request

Details

• On release-v6.0 with ai@6.0.244 and @ai-sdk/openai@3.0.90, the first forced client-tool turn completed, but the follow-up chained through previousResponseId received OpenAI HTTP 400: "No tool call found for function call output with call_id".
• The failed AI SDK request contained function_call_output without its matching function_call; directly adding the matching call produced HTTP 200 and a completed OpenAI response, locating the defect in AI SDK request conversion.
• examples/ai-functions/src/reproduction/issue-18537.ts reproduces the expected issue behavior by exiting non-zero on the failed follow-up instead of completing normally.
• packages/openai/src/responses/__fixtures__/openai-issue-18537-error.1.json records the live provider error, and packages/openai/src/responses/openai-responses-language-model.test.ts contains a regression test that fails with the primary provider error.

Relevant Documentation

• https://developers.openai.com/api/docs/guides/function-calling
• https://developers.openai.com/api/docs/guides/conversation-state
• https://developers.openai.com/api/docs/models/gpt-4.1-mini