[GH-ISSUE #24855] feat: Add Responses type for direct OpenAI connections #123724

New Issue

GiteaMirror · 2026-05-21T03:11:53-05:00

GiteaMirror commented

2026-05-21 03:11:53 -05:00

Originally created by @JKGeovision on GitHub (May 17, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24855

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

Good day

I have the particular situation that I want to enable each user to use their own local Hermes runtime which is hosted with docker. Therefore, I cannot configure the OpenAI connection in the Admin Settings and need to enable direct connections for the users. That works fine, but direct connections can only use the Chat Completions API type which does not show the current Tool usage used by Hermes and makes for an untransparent chatting experience. Would it be possible to also add the Responses type for direct connections?

Thank you very much and have a great day,
Joshua Krimmer

Desired Solution you'd like

Add the responses type for direct connection

Alternatives Considered

No response

Additional Context

No response

Originally created by @JKGeovision on GitHub (May 17, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24855 ### 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 Good day I have the particular situation that I want to enable each user to use their own local Hermes runtime which is hosted with docker. Therefore, I cannot configure the OpenAI connection in the Admin Settings and need to enable direct connections for the users. That works fine, but direct connections can only use the Chat Completions API type which does not show the current Tool usage used by Hermes and makes for an untransparent chatting experience. Would it be possible to also add the Responses type for direct connections? Thank you very much and have a great day, Joshua Krimmer ### Desired Solution you'd like Add the responses type for direct connection ### Alternatives Considered _No response_ ### Additional Context _No response_

GiteaMirror commented

2026-05-21 03:11:54 -05:00

@XidaoApi commented on GitHub (May 18, 2026):

This is a great feature request. A few technical notes that might help implementation:

The Responses API (/v1/responses) vs Chat Completions (/v1/chat/completions) have different request/response shapes:

Responses API uses input (string or array) instead of messages
Response objects have output (array of items) instead of choices
Tool use is surfaced as output items with type: "function_call" — which is why tool usage appears more transparent

Provider support landscape (as of May 2026):

OpenAI: Full support
Most OpenAI-compatible gateways: Increasingly supporting /v1/responses as a passthrough
Ollama: Chat Completions only (no Responses endpoint yet)
Hermes: Supports both via /v1/responses passthrough

For the direct connection use case, the challenge is that the Responses API response format is significantly different from Chat Completions, so the frontend rendering logic needs a separate code path. The output array can contain text, function calls, and tool results interleaved — it's not a simple choices[0].message extraction.

A pragmatic approach might be to detect the API type from the response shape (if it has output array → Responses format, if it has choices → Chat Completions) rather than requiring manual configuration per connection.

@XidaoApi commented on GitHub (May 18, 2026): This is a great feature request. A few technical notes that might help implementation: **The Responses API (`/v1/responses`) vs Chat Completions (`/v1/chat/completions`) have different request/response shapes:** - Responses API uses `input` (string or array) instead of `messages` - Response objects have `output` (array of items) instead of `choices` - Tool use is surfaced as `output` items with `type: "function_call"` — which is why tool usage appears more transparent **Provider support landscape (as of May 2026):** - OpenAI: Full support - Most OpenAI-compatible gateways: Increasingly supporting `/v1/responses` as a passthrough - Ollama: Chat Completions only (no Responses endpoint yet) - Hermes: Supports both via `/v1/responses` passthrough **For the direct connection use case**, the challenge is that the Responses API response format is significantly different from Chat Completions, so the frontend rendering logic needs a separate code path. The `output` array can contain text, function calls, and tool results interleaved — it's not a simple `choices[0].message` extraction. A pragmatic approach might be to detect the API type from the response shape (if it has `output` array → Responses format, if it has `choices` → Chat Completions) rather than requiring manual configuration per connection.

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#123724