VS Code Copilot Chat with a custom endpoint on the Responses API (DeepSeek): every tool call fails with `400 No tool call found for tool output with call_id ...`

Context

Source(s): https://github.com/microsoft/vscode/issues/331636 Status: reported working by source, not reproduced by us (workaround only; root fix not confirmed).

Problem

A plain chat message works, but as soon as the agent calls a tool (for example listing a folder or reading a file), the next request fails with the 400 above and the turn stops.

Error (redacted / normalized)

[error] Server error: 400 {"error":{"message":"No tool call found for tool output with call_id call_00_<id>.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}

Applies when

VS Code 1.134.0 to 1.137.0 with Copilot Chat 0.62.0 and later; a BYOK custom endpoint ("vendor": "customendpoint") with "apiType": "responses"; DeepSeek V4 Flash through the DeepSeek API (a contributor's test of the team member's OpenRouter setup with DeepSeek V4 Pro did call tools, so OpenRouter is not confirmed affected); Windows 11 (also with a WSL remote); August to October 2026. A commenter saw it with a locally hosted OpenAI-compatible API too.

Confirm it is this problem

1. Your custom endpoint model entry has "apiType": "responses" → expect: present.
2. In the "Local" agent harness, send a message that needs no tool, then one that needs a tool → expect: the first works, the second fails with the error above.

Not this when / boundary

The same error appears with the Chat Completions API or in the "Copilot" harness; the team member's explanation covers only the Local harness on the Responses API (our inference).

Root cause

A VS Code team member explained it. On the Local harness, after a Responses API turn that makes a tool call, VS Code sends the next request with previous_response_id and only the new tool output. DeepSeek's /v1/responses endpoint returns resp_… IDs but doesn't store responses and silently ignores previous_response_id, so it sees a tool output with no matching tool call. Because that comes back as a generic invalid_request_error, VS Code's retry with the full history doesn't start. The Copilot harness always sends the full history. A commenter had earlier pointed at DeepSeek's Responses API behavior.

Variables

<id>: the call ID in your log.

Fix

1. Switch the chat to the "Copilot" agent harness → expect: a commenter confirmed tool calls work there with the same DeepSeek endpoint, while Local still failed.
2. Or move that model back to the Chat Completions API instead of "apiType": "responses" → expect: the original poster said Chat Completions still works (the thread does not show the exact apiType value; check what your VS Code accepts, our inference).
3. Once your VS Code includes PR #340081: add "statefulResponses": false to that model entry, e.g. {"id": "deepseek-v4-flash", "name": "DeepSeek V4 Flash", "url": "https://api.deepseek.com/", "toolCalling": true, "statefulResponses": false} → expect: per the team member, VS Code then sends the full history on every request (no user confirmed it in the thread yet).

How to verify

In the Local harness, ask the agent to read a file → expect: the tool runs and no No tool call found for tool output error appears.

What did not work

Updating to VS Code 1.135.0 stable did not help (a commenter). The original poster said this error only showed up after an earlier invalid tool schema error (#330610) was fixed, which had hidden it.

Risks

With "statefulResponses": false every request carries the whole conversation, so input tokens per request go up (our inference). Keep the real API key out of config files you share; the examples in the thread use a placeholder for apiKey (our inference).

Verified scope

VS Code 1.134 to 1.137 with a BYOK custom endpoint on the Responses API, August to October 2026.

Becomes obsolete when

DeepSeek's Responses API stores responses and honors previous_response_id, or VS Code falls back to full history on its own. Open question: which VS Code stable release first ships the statefulResponses option; the thread names only PR #340081 (issue closed 2026-10-06).