Originally created by @aleprj on GitHub (Aug 22, 2025).
Check Existing Issues
I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.
Installation Method
Git Clone
Open WebUI Version
0.6.25
Ollama Version (if applicable)
No response
Operating System
Windows 11
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
When using a streming model, the chat should be saved in the database only after the full message is received, unless ENABLE_REALTIME_CHAT_SAVE is set to TRUE.
Actual Behavior
In multiple scenarios (for instance when using a custom pipe) the chat is saved to the database on every token received, even with ENABLE_REALTIME_CHAT_SAVE set to false.
It doesn't seem to be something bad, but I'm dealing with "large" files (actually a 3MB Excel file, I wouldn't call it large) and It makes the pipe unusable unless we turn off streaming.
Steps to Reproduce
1 - Make sure ENABLE_REALTIME_CHAT_SAVE is set to false
2 - Make a custom Function that uses streaming
3 - Start a chat in your custom modem
4 - Add a very large prompt (or a file)
5- Enjoy the slow motion streaming of the answer. Also, the whole system becomes slow for all users as a very large json is being updated in the database multiple times in a row.
Logs & Screenshots
No logs
Additional Information
I will be adding a PR to fix this. In my test it reduced the answer from ~300s to ~5s.
Originally created by @aleprj on GitHub (Aug 22, 2025).
### Check Existing Issues
- [x] I have searched the existing issues and discussions.
- [x] I am using the latest version of Open WebUI.
### Installation Method
Git Clone
### Open WebUI Version
0.6.25
### Ollama Version (if applicable)
_No response_
### Operating System
Windows 11
### 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
When using a streming model, the chat should be saved in the database only after the full message is received, unless ENABLE_REALTIME_CHAT_SAVE is set to TRUE.
### Actual Behavior
In multiple scenarios (for instance when using a custom pipe) the chat is saved to the database on every token received, even with ENABLE_REALTIME_CHAT_SAVE set to false.
It doesn't seem to be something bad, but I'm dealing with "large" files (actually a 3MB Excel file, I wouldn't call it large) and It makes the pipe unusable unless we turn off streaming.
### Steps to Reproduce
1 - Make sure ENABLE_REALTIME_CHAT_SAVE is set to false
2 - Make a custom Function that uses streaming
3 - Start a chat in your custom modem
4 - Add a very large prompt (or a file)
5- Enjoy the slow motion streaming of the answer. Also, the whole system becomes slow for all users as a very large json is being updated in the database multiple times in a row.
### Logs & Screenshots
No logs
### Additional Information
I will be adding a PR to fix this. In my test it reduced the answer from ~300s to ~5s.
GiteaMirror
added the bug label 2025-11-11 16:47:20 -06:00
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 @aleprj on GitHub (Aug 22, 2025).
Check Existing Issues
Installation Method
Git Clone
Open WebUI Version
0.6.25
Ollama Version (if applicable)
No response
Operating System
Windows 11
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
When using a streming model, the chat should be saved in the database only after the full message is received, unless ENABLE_REALTIME_CHAT_SAVE is set to TRUE.
Actual Behavior
In multiple scenarios (for instance when using a custom pipe) the chat is saved to the database on every token received, even with ENABLE_REALTIME_CHAT_SAVE set to false.
It doesn't seem to be something bad, but I'm dealing with "large" files (actually a 3MB Excel file, I wouldn't call it large) and It makes the pipe unusable unless we turn off streaming.
Steps to Reproduce
1 - Make sure ENABLE_REALTIME_CHAT_SAVE is set to false
2 - Make a custom Function that uses streaming
3 - Start a chat in your custom modem
4 - Add a very large prompt (or a file)
5- Enjoy the slow motion streaming of the answer. Also, the whole system becomes slow for all users as a very large json is being updated in the database multiple times in a row.
Logs & Screenshots
No logs
Additional Information
I will be adding a PR to fix this. In my test it reduced the answer from ~300s to ~5s.
@tjbck commented on GitHub (Aug 26, 2025):
You can techinically use
chat:message:deltaevent instead ofmessage, keep us updated.