BYOK Custom Endpoint with DeepSeek reasoning models fails with HTTP 400 on multi-turn tool calling (`reasoning_content` not echoed back)

[ziqiangai]

Bug Description

When using the Custom Endpoint BYOK feature with DeepSeek reasoning models (or similar providers like Moonshot/Minimax that emit reasoning_content without an explicit ID), the first LLM turn succeeds, but any subsequent turn (after a tool call) fails with:

400 {"error":{"message":"The `reasoning_content` in the thinking mode must be passed back to the API.","type":"invalid_request_error",...}}

The Copilot extension already contains logic in OpenAIEndpoint.createRequestBody() to echo back reasoning_content on assistant messages, but this logic is gated on data.id being present. DeepSeek does not send an id alongside reasoning_content, so the echo-back is silently skipped, and DeepSeek rejects the second turn.

This makes Agent mode (multi-turn tool calling) unusable with DeepSeek reasoning models via BYOK.

Version

• VS Code: 1.122 (latest main)
• GitHub Copilot Chat extension: bundled
• OS: all (reproducible on Windows, macOS, Linux)

Steps to Reproduce

1. Configure a Custom Endpoint with DeepSeek:

   {
     "name": "DeepSeek",
     "vendor": "customendpoint",
     "apiKey": "sk-...",
     "apiType": "chat-completions",
     "url": "https://api.deepseek.com/chat/completions",
     "models": [{
       "id": "deepseek-v4-flash",
       "toolCalling": true,
       "thinking": true,
       "maxInputTokens": 128000,
       "maxOutputTokens": 8192
     }]
   }

2. Open Chat, select the DeepSeek model
3. Send a prompt that triggers tool calling (e.g. "Create a file named test.txt with some content")
4. Observe: first turn succeeds, model returns reasoning_content + tool call
5. After tool executes, second turn is sent
6. Observe: HTTP 400 from DeepSeek

Expected Behavior

The reasoning_content from the first turn should be echoed back in the assistant message of the second turn, so DeepSeek accepts the request.

Actual Behavior

The reasoning_content is silently dropped because it has no id, and the second turn fails with HTTP 400.

Logs

2026-05-29 07:10:17.012 [info] message 0 returned. finish reason: [tool_calls]
2026-05-29 07:10:17.019 [info] ccreq:d3c749f5.copilotmd | success | deepseek-v4-flash | 1336ms
2026-05-29 07:10:17.392 [info] Request ID for failed request: 1d4d4316-...
2026-05-29 07:10:17.396 [error] Server error: 400 {"error":{"message":"The `reasoning_content` in the thinking mode must be passed back to the API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}
2026-05-29 07:10:17.399 [info] ccreq:0a452385.copilotmd | failed | deepseek-v4-flash | 225ms

Affected Providers

• DeepSeek (V4, V3 reasoning mode)

Any OpenAI-compatible provider that sends reasoning_content without an accompanying id field will hit this issue.

[KKKayleX]

I encountered the same issue as well, but I discovered it while adding an OpenRouter model.

Steps to reproduce:

1. Add OpenRouter in GitHub Copilot
2. Select DeepSeek V4 Flash or V4 Pro
3. Ask questions and wait for multiple rounds of conversation

Here is the error I received:

Sorry, your request failed. Please try again.

Client Request Id: 120004f8-7448-4e57-b360-b2a2c3c59b8b

Reason: Request Failed: 400 {"error":{"message":"Provider returned error","code":400,"metadata":{"raw":"{"error":{"message":"The reasoning_content in the thinking mode must be passed back to the API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}","provider_name":"DeepSeek","is_byok":true}},"user_id":"user_3D7KWL0whx2znXHtHcq9wQutKXS"}: Error: Request Failed: 400 {"error":{"message":"Provider returned error","code":400,"metadata":{"raw":"{"error":{"message":"The reasoning_content in the thinking mode must be passed back to the API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}","provider_name":"DeepSeek","is_byok":true}},"user_id":"user_3D7KWL0whx2znXHtHcq9wQutKXS"} at dG._provideLanguageModelResponse (/vscode/vscode-server/bin/linux-x64/6a49527b96e326fe62fbdb56f60e16877c9aa724/extensions/copilot/dist/extension.js:1710:16552) at process.processTicksAndRejections (node:internal/process/task_queues:103:5) at async dG.provideLanguageModelResponse (/vscode/vscode-server/bin/linux-x64/6a49527b96e326fe62fbdb56f60e16877c9aa724/extensions/copilot/dist/extension.js:1710:17555)

[KKKayleX]

It may be fixed in version 1.123.0.

#318809

[ziqiangai]

It may be fixed in version 1.123.0.

#318809

no

The main branch running in my device.

[vritant24]

Please try your scenario in the latest insiders and let me know if you still hit this issue.

I was unable to reproduce this issue on the latest insiders:

Version: 1.122.0-insider (Universal)
Commit: 4459d58b5428c36de656f9241ffd31e2a2118150
Date: 2026-05-28T21:14:22-07:00
Electron: 42.2.0
ElectronBuildId: 14159160
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Darwin arm64 25.5.0

My reproduction was slightly different from what you set u primarily because I cannot access the deep seek api directly, I can only do so through open router.

I don't think the core issue here is the id. we have

vscode/extensions/copilot/src/extension/prompt/common/toolCallRound.ts

Lines 76 to 77 in e7cc101

	item = new ThinkingDataItem(delta.id ?? generateUuid());
	}

that ensures the id is truthy

[ziqiangai]

I can't retest until Monday, but I can provide you with some information now. I'm not sure if your router has erased some differences. For example, the deepseek official compatible openai interface url has no v1 prefix. This is why the url configured above is The reason for the full writing (I saw that the source code specially judged this writing method), and then my Claude Code helped to submit the pr (#318933) can really solve this problem, at least I can run the agent in multiple rounds of dialogue. Is there any missing case in the test?