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_
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.
<!-- gh-comment-id:4478468833 -->
@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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @JKGeovision on GitHub (May 17, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24855
Check Existing Issues
Verify Feature Scope
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
@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:input(string or array) instead ofmessagesoutput(array of items) instead ofchoicesoutputitems withtype: "function_call"— which is why tool usage appears more transparentProvider support landscape (as of May 2026):
/v1/responsesas a passthrough/v1/responsespassthroughFor 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
outputarray can contain text, function calls, and tool results interleaved — it's not a simplechoices[0].messageextraction.A pragmatic approach might be to detect the API type from the response shape (if it has
outputarray → Responses format, if it haschoices→ Chat Completions) rather than requiring manual configuration per connection.