This repository was archived by the owner on May 20, 2026. It is now read-only.
[BYOK/CustomOAI] Payload format incorrectly defaults to ChatCompletions when using explicit /responses endpoint - #5111
Open
Simba98 wants to merge 1 commit into
Open
[BYOK/CustomOAI] Payload format incorrectly defaults to ChatCompletions when using explicit /responses endpoint#5111Simba98 wants to merge 1 commit into
Simba98 wants to merge 1 commit into
Conversation
Responses endpoint usually do not support chat completions
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes Custom OpenAI/Azure BYOK behavior when a user explicitly configures a deployment URL that already targets the /responses endpoint, ensuring the extension doesn’t advertise/support Chat Completions for that model and thus doesn’t risk producing a Chat Completions-shaped payload for a Responses-only backend.
Changes:
- Updates Custom OAI BYOK model metadata so URLs containing
/responsesadvertise only theResponsessupported endpoint (removingChatCompletionsfrom the list).
Comment on lines
147
to
152
| const modelInfo = resolveModelInfo(model.id, this._name, undefined, modelCapabilities); | ||
| if (modelCapabilities?.url?.includes('/responses')) { | ||
| modelInfo.supported_endpoints = [ | ||
| ModelSupportedEndpoint.ChatCompletions, | ||
| ModelSupportedEndpoint.Responses | ||
| ]; | ||
| } |
Member
|
Thanks for the contribution! This repository has been archived because the project has moved into the main VS Code repository. Could you please reopen/recreate this PR against: We’ll continue reviewing contributions there. Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description:
When configuring a Custom OpenAI or Azure BYOK provider in settings.json with a custom deployment URL ending in /responses (e.g., "https://my-custom-gateway.azure/v1/responses"), the Copilot Chat extension incorrectly sends the payload using the standard /chat/completions JSON format instead of the expected Responses API format.
This causes 400 Bad Request errors on custom backend servers that are explicitly designed to parse the Copilot Responses API schema.
Root Cause Analysis:
I traced the issue to src/extension/byok/vscode-node/customOAIProvider.ts in the AbstractCustomOAIBYOKModelProvider.createOpenAIEndPoint method:
Why this matters (Use Case):
While /responses is not a standard public OpenAI API endpoint, it is the native protocol used by Copilot to support advanced streaming, thinking parts, and tool calling. Enterprise users and developers often build custom middleware/gateways that implement the /responses endpoint to fully support Copilot's advanced features. When the user explicitly sets the URL to /responses, they expect the client to send the Responses payload, not the legacy ChatCompletions payload.
In future (More Flexible): Do not hardcode this in createOpenAIEndPoint. Instead, allow users to specify supportedEndpoints in settings.json under the model capabilities, and let resolveModelInfo() handle it (it already has logic to parse supportedEndpoints from BYOKModelCapabilities).