[GH-ISSUE #22905] feat: Per-model API type override (Chat Completions vs Responses) #35368

New Issue

GiteaMirror · 2026-04-25T09:35:15-05:00

GiteaMirror commented

2026-04-25 09:35:15 -05:00

Originally created by @shishiraiyar on GitHub (Mar 20, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22905

Check Existing Issues

I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

With the introduction of the Responses API toggle on connections, users can choose between Chat Completions and Responses API types — but only at the connection level. This becomes a problem when a single backend (e.g., a LiteLLM proxy) serves models that require different API types.

Real-world example

I use a LiteLLM proxy that routes to GitHub Copilot models. All models are served from the same endpoint, but:

gpt-5.4 and gpt-5.4-mini only work via /v1/responses
All other models (Claude, Gemini, older GPT) only work via /v1/chat/completions

Current workarounds and why they fail

Approach	Result
Single connection (Chat Completions)	`gpt-5.4` and `gpt-5.4-mini` fail with "model only supported in /v1/responses"
Single connection (Responses)	All other models fail
Two connections, same URL, auto-discover on both	Model IDs are deduplicated — Open WebUI routes to the first connection found, ignoring the API type of the second
Two connections, same URL, explicit model IDs on Responses only	The Chat Completions connection auto-discovers all models including the `/responses`-only ones, and takes priority due to ordering
Two connections, explicit model IDs on both, no overlap	✅ Works, but sacrifices auto-discovery entirely. Every new model must be manually added to the correct connection.

The only working solution today requires manually maintaining two separate model lists across two connections to the same backend and giving up auto-discovery.

Desired Solution

Add the ability to set the API type (Chat Completions vs Responses) per model, not just per connection. This could take several forms:

Option A: Per-model override in Admin → Models

In the model editor (Admin Settings → Models), add an "API Type" dropdown that overrides the connection-level default for that specific model.

Option B: Model-level config within a connection

In the connection's model ID list, allow specifying the API type per model, e.g.:

github_copilot/gpt-5.4 [responses]
github_copilot/gpt-5.4-mini [responses]

Option C: Connection priority / conflict resolution for duplicate models

When the same model ID appears in multiple connections, allow the user to choose which connection takes priority for that model (rather than always defaulting to the first connection).

Additional Context

As more models move to /responses-only (which is increasingly likely given that the Responses API is OpenAI's new format), this problem will affect more users.
The current workaround is manageable with a small, static model list, but breaks down for users with many models or frequently changing model availability.
The Responses API is a superset of Chat Completions, so the trend is clearly toward more models requiring it.

Originally created by @shishiraiyar on GitHub (Mar 20, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/22905 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ## Problem Description With the introduction of the Responses API toggle on connections, users can choose between **Chat Completions** and **Responses** API types — but only at the **connection level**. This becomes a problem when a single backend (e.g., a LiteLLM proxy) serves models that require different API types. ### Real-world example I use a LiteLLM proxy that routes to GitHub Copilot models. All models are served from the same endpoint, but: * `gpt-5.4` and `gpt-5.4-mini` **only work via** `/v1/responses` * All other models (Claude, Gemini, older GPT) **only work via** `/v1/chat/completions` ### Current workarounds and why they fail | Approach | Result | | --- | --- | | **Single connection (Chat Completions)** | `gpt-5.4` and `gpt-5.4-mini` fail with "model only supported in /v1/responses" | | **Single connection (Responses)** | All other models fail | | **Two connections, same URL, auto-discover on both** | Model IDs are deduplicated — Open WebUI routes to the first connection found, ignoring the API type of the second | | **Two connections, same URL, explicit model IDs on Responses only** | The Chat Completions connection auto-discovers all models including the `/responses`-only ones, and takes priority due to ordering | | **Two connections, explicit model IDs on both, no overlap** | ✅ **Works**, but sacrifices auto-discovery entirely. Every new model must be manually added to the correct connection. | The only working solution today requires **manually maintaining two separate model lists** across two connections to the same backend and giving up auto-discovery. ## Desired Solution Add the ability to set the **API type (Chat Completions vs Responses) per model**, not just per connection. This could take several forms: ### Option A: Per-model override in Admin → Models In the model editor (Admin Settings → Models), add an "API Type" dropdown that overrides the connection-level default for that specific model. ### Option B: Model-level config within a connection In the connection's model ID list, allow specifying the API type per model, e.g.: ``` github_copilot/gpt-5.4 [responses] github_copilot/gpt-5.4-mini [responses] ``` ### Option C: Connection priority / conflict resolution for duplicate models When the same model ID appears in multiple connections, allow the user to choose which connection takes priority for that model (rather than always defaulting to the first connection). ## Additional Context * As more models move to `/responses`-only (which is increasingly likely given that the Responses API is OpenAI's new format), this problem will affect more users. * The current workaround is manageable with a small, static model list, but breaks down for users with many models or frequently changing model availability. * The Responses API is a **superset** of Chat Completions, so the trend is clearly toward more models requiring it.

GiteaMirror closed this issue

2026-04-25 09:35:15 -05:00

GiteaMirror commented

2026-04-25 09:35:16 -05:00

@pr-validator-bot commented on GitHub (Mar 20, 2026):

⚠️ Invalid Issue Title

Hey @shishiraiyar, please provide a descriptive title for your issue. Titles that are empty, very short (under 10 characters), or generic (like "issue:" or "feat:") make it difficult for volunteer contributors to understand and triage issues.

Please update the title to reflect the content of your issue.

⚠️ Missing Issue Title Prefix

@shishiraiyar, your issue title is missing a prefix (e.g., bug:, feat:, docs:).

Please update your issue title to include one of the following prefixes:

bug: Bug report or error you've encountered
feat: Feature request or enhancement suggestion
docs: Documentation issue or improvement request
question: Question about usage or functionality
help: Request for help or support

Example: bug: Login fails when using special characters in password

@pr-validator-bot commented on GitHub (Mar 20, 2026): # ⚠️ Invalid Issue Title Hey @shishiraiyar, please provide a descriptive title for your issue. Titles that are empty, very short (under 10 characters), or generic (like "issue:" or "feat:") make it difficult for volunteer contributors to understand and triage issues. Please update the title to reflect the content of your issue. --- # ⚠️ Missing Issue Title Prefix @shishiraiyar, your issue title is missing a prefix (e.g., `bug:`, `feat:`, `docs:`). Please update your issue title to include one of the following prefixes: - **bug**: Bug report or error you've encountered - **feat**: Feature request or enhancement suggestion - **docs**: Documentation issue or improvement request - **question**: Question about usage or functionality - **help**: Request for help or support Example: `bug: Login fails when using special characters in password`

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#35368