mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-07 03:18:23 -05:00
[GH-ISSUE #21024] issue: Open WebUI does not distinguish the difference between image editing and image creation prompts. #58025
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#58025
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MattariOnline on GitHub (Jan 29, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21024
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.7.2
Ollama Version (if applicable)
0.15.1
Operating System
Windows 11
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
When requesting a new image, the image creation model (in this case, Z-image-Turbo) should be used.
When requesting changes or edits to an image, the image edit model should be used (such as Flux2-Klein).
Actual Behavior
When requesting image generation in a new conversation, it uses the image creation model.
For all subsequent image generation requests, even if requesting to "create a new picture" or "generate new picture," only the image edit model is used. There does not appear to be any manual override (ie. tool or button) to force the use of the image creation model over the edit model, aside from outright disabling the image edit model in the Admin settings.
Steps to Reproduce
The Token-Walkthrough for Environment Setup:
image_z_image_turbo.json
The Important Part:
Example prompts used to generate a picture, edit it, and request an entirely new one:
Logs & Screenshots
(No applicable browser console logs.)
Open WebUI Screenshot:
I made three prompts: create an image, edit that image, then create a new image.
It would be expected that it uses the creation model (Z-image-Turbo), the edit model (Flux2 Klein), then the creation model again.
ComfyUI Job Queue (newest at top):
As seen by the job queue, the creation model is used, then the edit model, then the edit model is subsequently used for that conversation. It will only revert back to the creation model for a new chat.
Additional Information
No response
@owui-terminator[bot] commented on GitHub (Jan 29, 2026):
🔍 Similar Issues Found
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
#20237 issue: Image editing stopped working
by tomasloksa • Dec 29, 2025 •
bug,confirmed issue#20754 issue: New upload of an image does not work with image editing
by iChristGit • Jan 17, 2026 •
bug#19339 issue: Multiple input images for image edit and generation are passed as separate instances instead of as a list
by eml-henn • Nov 21, 2025 •
bug#19187 issue: Image generation menu gone.
by calebrio02 • Nov 14, 2025 •
bug#20091 issue: image is regarded as binary in temp chat
by funnycups • Dec 22, 2025 •
bugShow 5 more related issues
#19750 issue: Image Edit does not distinguish between User and Assistant images
by eml-henn • Dec 04, 2025 •
bug,confirmed issue#18726 issue: web search and image generation
by allmazz • Oct 29, 2025 •
bug#18995 issue: image generation and edition doesn’t work on temporary chats
by futureshield • Nov 06, 2025 •
bug#19825 Image Generation and Web Search trigger on every message
by bcnation • Dec 08, 2025 •
bug#19987 issue: There is a lack of visual consistency between the home page and the chat interface.
by i-iooi-i • Dec 16, 2025 •
bug💡 Tips:
This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
@Classic298 commented on GitHub (Jan 29, 2026):
Very closely related
https://github.com/open-webui/open-webui/issues/20754
@MattariOnline commented on GitHub (Jan 31, 2026):
Potentially, however my primary issue is that Open WebUI does not understand when it needs to utilize the image generation tool rather than the image editing tool.
That said, I wouldn't rule out that it could be related to it fixating on editing the initial image; I'll be sure to watch that issue and test accordingly when a potential resolution is pushed for it. If it affects this, I'll be sure to note the observation and close if resolved.
Thanks for mentioning it!
@gitFox117 commented on GitHub (Feb 3, 2026):
When editing for the second time on the same page, this prompt appears—do you encounter this issue on your side?
""{"status": "success", "message": "The edited image has been successfully generated and is already visible to the user in the chat. You do not need to display or embed the image again - just acknowledge that it has been created.", "images": [{"url": "/api/v1/files/9f2e7b3a-4c1d-4e8f-b5a6-1d8c9e7f2a3b/content"}]}""
@MattariOnline commented on GitHub (Feb 3, 2026):
I haven't noticed anything like that, though honestly I reduce response times by removing the LLM response entirely.
(To be clear for anyone else looking into this issue as a whole; I have tested with several models with all default settings. When I'm not trying to troubleshoot image creation/editing, I use the zero-response setup for fast output, so this has nothing to do with the issue I'm reporting.)
@MattariOnline commented on GitHub (Feb 14, 2026):
Issue #20754 was reportedly fixed and closed with v0.8.0 about 20 hours ago, as of writing.
Tested the latest v0.8.1 and can confirm my issue still persists.
Explicitly asking it to "Create a new image of.." as suggested by the Open WebUI documentation does not trigger the use of the image creation API; it only continues to use the image editing API.
@Classic298 commented on GitHub (Feb 14, 2026):
I can now say as of 0.8.0 and 0.8.1 the model can handle user input for edits, assistant input for edits AND assitant+user input for edits just fine if using the default built in image edit function with for example an OpenAI or Gemini model.
OpenRouter direct integrations does not work as well. There, sometimes the model does not use it's own previously generated image . OpenRouter specific quirk it seems
@MattariOnline commented on GitHub (Feb 14, 2026):
Just in case the original post wasn't clear, it seems like you're focusing on edits, but the issue I'm reporting is it isn't possible to go from editing back to image creation within the same chat.
Editing works fine, but I'm concerned with returning to new/fresh image creation.
@Arjenlodder commented on GitHub (Mar 3, 2026):
Same issue here! Going back to creating a new image, results in editting the previous image.
@pfn commented on GitHub (Mar 9, 2026):
use native tool calling. this problem goes away.
@MattariOnline commented on GitHub (Mar 9, 2026):
That's not really a solution; at best, it's a work-around for non-local models or some cases with very large models.
Even the OWUI docs advise using things like GPT-5, Claude 4.5 Sonnet, etc. It does suggest large models such as Qwen 3 32B or Llama 3.3 70B could work, but advises results can vary significantly.
If it isn't possible to build in basic tool functionality to discern the difference between "Create an image" and "Edit an image," then there should at least be a button/toggle to facilitate the difference, such as "Edit previous image."
@pfn commented on GitHub (Mar 9, 2026):
Native tool calling is the solution. default tool calling mode is a mistake, imo.
Clearly, this is the behavior you want:
@MattariOnline commented on GitHub (Mar 10, 2026):
Well once figuring out how to force it to work, it's not bad for a solution, but definitely limits which models can work with it.
Thankfully, GPT-OSS:20b knows how to call both creation and editing, so that'll suit my needs. I still think a toggle for default (non-native) mode to "Edit previous image" or not would be a solid addition, especially if limited by VRAM. Thankfully Strix Halo doesn't care and will happily run both, but my old 24Gb GPU rig would've been touchier, and not all even have the benefit of a 24Gb dedicated GPU for an AI server.
@pfn commented on GitHub (Mar 10, 2026):
Just about no modern model worth using won't support native tool calling.
@MattariOnline commented on GitHub (Mar 10, 2026):
Subjective and definitely not true, as I've tested several decent models which didn't support it, but thankfully GPT-OSS:20b is supported which satisfies my needs.
@pfn commented on GitHub (Mar 10, 2026):
considering that you didn't bother naming them, they're probably not worth using.
@MattariOnline commented on GitHub (Mar 10, 2026):
A bit rude for github, much? Well it was several Llama 3.1/3.2 variants, Granite 4 iirc, some Qwen models, but I didn't have exact specifics and I'm currently clocking a high fever with a flu so I didn't want to do all the proper testing again so as to accurately reference them all.
Feel free to test which models do/don't work and report back; I'll concede to anything that works. Otherwise I'm gonna go back to fighting my flu thanks.
@pfn commented on GitHub (Mar 10, 2026):
out of the recent models that I've tried:
yes:
no:
take care of your flu
@MattariOnline commented on GitHub (Mar 10, 2026):
Ty sir, the fever finally broke just barely. Also weird that Llama 3.3 is a dud. Tried Claude 3.5 32b iirc, but weirdly Claude A3O 30b (or something like that) starts thinking..weirdly.
@Classic298 commented on GitHub (Apr 14, 2026):
native tool calling should be used, default tool calling is legacy and not reliable in this case and cannot fully detect all cases since its automated detection and cannot distinguish based on what the user wants. native tool calling can because the user decides.
Similar question was posted to discussion a month ago and was closed with this reason. Documentation has since long been updated to notify default tool calling as unrecommended and legacy. Native should be used