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 ...`

发生场景

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

问题

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] 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"}}

适用环境

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.

如何确认是这个问题

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.

不是这个问题时 / 边界

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).

根因

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.

占位变量

<id>: the call ID in your log.

修复步骤

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).

如何验证

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.

试过没用的办法

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.

风险提示

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).

验证范围

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

何时失效

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).