I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.
Installation Method
Docker
Open WebUI Version
0.9.5
Ollama Version (if applicable)
No response
Operating System
Linux
Browser (if applicable)
No response
Confirmation
I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.
Expected Behavior
Default settings / Main Model should take precedence over custom model settings
Actual Behavior
Custom model settings override Default Settings / Main Model
Steps to Reproduce
Set default parameters to 256 max_tokens
Set model parameters to 256 max_tokens
Create a custom model under Workspace and set it to 2048 max_tokens
User can still modify max_tokens to any number on the custom model
The backend receives the modified max_tokens from the end user, and is not limited by the default settings & main model.
Logs & Screenshots
Backend:
Additional Information
This is a problem since some of my users are setting max_tokens to 10k+
Originally created by @frenzybiscuit on GitHub (May 17, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24830
### Check Existing Issues
- [x] I have searched for any existing and/or related issues.
- [x] I have searched for any existing and/or related discussions.
- [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
0.9.5
### Ollama Version (if applicable)
_No response_
### Operating System
Linux
### Browser (if applicable)
_No response_
### Confirmation
- [x] I have read and followed all instructions in `README.md`.
- [x] I am using the latest version of **both** Open WebUI and Ollama.
- [x] I have included the browser console logs.
- [x] I have included the Docker container logs.
- [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.**
- [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
- [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps:
- Start with the initial platform/version/OS and dependencies used,
- Specify exact install/launch/configure commands,
- List URLs visited, user input (incl. example values/emails/passwords if needed),
- Describe all options and toggles enabled or changed,
- Include any files or environmental changes,
- Identify the expected and actual result at each stage,
- Ensure any reasonably skilled user can follow and hit the same issue.
### Expected Behavior
Default settings / Main Model should take precedence over custom model settings
### Actual Behavior
Custom model settings override Default Settings / Main Model
### Steps to Reproduce
Set default parameters to 256 max_tokens
Set model parameters to 256 max_tokens
Create a custom model under Workspace and set it to 2048 max_tokens
User can still modify max_tokens to any number on the custom model
The backend receives the modified max_tokens from the end user, and is not limited by the default settings & main model.
### Logs & Screenshots
Backend:
<img width="488" height="438" alt="Image" src="https://github.com/user-attachments/assets/7ff5e8e8-57ae-416d-8c71-25524c7380a2" />
### Additional Information
This is a problem since some of my users are setting max_tokens to 10k+
GiteaMirror
added the bug label 2026-05-18 06:12:37 -05:00
@owui-terminator[bot] commented on GitHub (May 17, 2026):
🔍Related Issues Found
I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:
🟣#19214issue: default model params take precedence over user-specified model params This is the closest match: it reports the same precedence bug where default/model admin parameters override user-specified values. The new issue is about default/main model settings overriding custom workspace model settings for max_tokens, which is the same kind of parameter-precedence problem. by Simon-Stone · bug
🟣#17151issue: user setting overrules model settings for websearch This issue shows the same general override pattern for model-specific restrictions being bypassed by a global setting. While it concerns websearch rather than token limits, it is related because both describe workspace/model configuration being overridden by higher-level defaults in an unexpected way. by Maximilian-Pichler · bug
🟣#18619issue: Nested options.max_tokens in model parameters not recursively converted to num_predict This is related because it involves max_tokens in workspace/model parameters and how those settings are transformed before being sent downstream. It may not be the exact same precedence bug, but it is directly adjacent to the max_tokens handling involved in the new report. by elazar · bug
🟣#13149issue: 400: Invalid 'stop': array too long when using Workspace model specifically This issue is workspace-model-specific and shows that model-level configuration can behave differently when a model is wrapped in Workspace. Even though the symptom is about stop arrays, it is relevant as another workspace-model configuration bug affecting request payloads. by theprezz87 · bug
💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.
This comment was generated automatically. React with 👍 if helpful, 👎 if not.
<!-- gh-comment-id:4470160359 -->
@owui-terminator[bot] commented on GitHub (May 17, 2026):
<!-- terminator-bot:related-issues-reply -->
🔍 **Related Issues Found**
I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:
1. 🟣 [#19214](https://github.com/open-webui/open-webui/issues/19214) **issue: default model params take precedence over user-specified model params**
*This is the closest match: it reports the same precedence bug where default/model admin parameters override user-specified values. The new issue is about default/main model settings overriding custom workspace model settings for `max_tokens`, which is the same kind of parameter-precedence problem.*
*by Simon-Stone · `bug`*
2. 🟣 [#17151](https://github.com/open-webui/open-webui/issues/17151) **issue: user setting overrules model settings for websearch**
*This issue shows the same general override pattern for model-specific restrictions being bypassed by a global setting. While it concerns websearch rather than token limits, it is related because both describe workspace/model configuration being overridden by higher-level defaults in an unexpected way.*
*by Maximilian-Pichler · `bug`*
3. 🟣 [#18619](https://github.com/open-webui/open-webui/issues/18619) **issue: Nested `options.max_tokens` in model parameters not recursively converted to `num_predict`**
*This is related because it involves `max_tokens` in workspace/model parameters and how those settings are transformed before being sent downstream. It may not be the exact same precedence bug, but it is directly adjacent to the `max_tokens` handling involved in the new report.*
*by elazar · `bug`*
4. 🟣 [#13149](https://github.com/open-webui/open-webui/issues/13149) **issue: 400: Invalid 'stop': array too long when using Workspace model specifically**
*This issue is workspace-model-specific and shows that model-level configuration can behave differently when a model is wrapped in Workspace. Even though the symptom is about `stop` arrays, it is relevant as another workspace-model configuration bug affecting request payloads.*
*by theprezz87 · `bug`*
---
💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.
*This comment was generated automatically.* React with 👍 if helpful, 👎 if not.
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 @frenzybiscuit on GitHub (May 17, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24830
Check Existing Issues
Installation Method
Docker
Open WebUI Version
0.9.5
Ollama Version (if applicable)
No response
Operating System
Linux
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
Default settings / Main Model should take precedence over custom model settings
Actual Behavior
Custom model settings override Default Settings / Main Model
Steps to Reproduce
Set default parameters to 256 max_tokens
Set model parameters to 256 max_tokens
Create a custom model under Workspace and set it to 2048 max_tokens
User can still modify max_tokens to any number on the custom model
The backend receives the modified max_tokens from the end user, and is not limited by the default settings & main model.
Logs & Screenshots
Backend:
Additional Information
This is a problem since some of my users are setting max_tokens to 10k+
@owui-terminator[bot] commented on GitHub (May 17, 2026):
🔍 Related Issues Found
I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:
🟣 #19214 issue: default model params take precedence over user-specified model params
This is the closest match: it reports the same precedence bug where default/model admin parameters override user-specified values. The new issue is about default/main model settings overriding custom workspace model settings for
max_tokens, which is the same kind of parameter-precedence problem.by Simon-Stone ·
bug🟣 #17151 issue: user setting overrules model settings for websearch
This issue shows the same general override pattern for model-specific restrictions being bypassed by a global setting. While it concerns websearch rather than token limits, it is related because both describe workspace/model configuration being overridden by higher-level defaults in an unexpected way.
by Maximilian-Pichler ·
bug🟣 #18619 issue: Nested
options.max_tokensin model parameters not recursively converted tonum_predictThis is related because it involves
max_tokensin workspace/model parameters and how those settings are transformed before being sent downstream. It may not be the exact same precedence bug, but it is directly adjacent to themax_tokenshandling involved in the new report.by elazar ·
bug🟣 #13149 issue: 400: Invalid 'stop': array too long when using Workspace model specifically
This issue is workspace-model-specific and shows that model-level configuration can behave differently when a model is wrapped in Workspace. Even though the symptom is about
stoparrays, it is relevant as another workspace-model configuration bug affecting request payloads.by theprezz87 ·
bug💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.
This comment was generated automatically. React with 👍 if helpful, 👎 if not.