Image Studio: revert function_calling to default — 0.9.6+ breaks Native

OWUI 0.9.6+ regression: Function Calling: Native on
huihui_ai/qwen3-vl-abliterated:8b produces empty assistant turns
even with enable_thinking=false in custom_params. The model's
tool-call output stops being dispatched and the chat completion
finishes successfully, so the failure presents as "the model
decided not to call the tool" — no error, no tool block, just
empty assistant content with follow-up chips. Diagnosed in a live
debug session: confirmed Function Calling was Native in the
running OWUI, enable_thinking was off, tool still didn't fire;
flipping to Default fixed dispatch immediately.

This supersedes d8c8421 ("lock in working config — Native +
enable_thinking=false"), which was correct through OWUI 0.9.5 but
no longer holds. Returns to the 1ed2e72 config (Default) for the
same fundamental reason: Native does not reliably parse Qwen 3.x
output on the current OWUI parser. Trade-off (unchanged from the
1ed2e72 era): no structured "View Result from edit_image" UI
block — tool results render as plain text in the assistant
message instead.

Kept enable_thinking=false in custom_params. It's no longer
strictly required (Default's wrapper doesn't read model thinking
output), but it saves the tokens Qwen would otherwise spend on
hidden thinking before each dispatch.

Updated image_studio.md to match: Function Calling table row,
Custom Parameters note, and Qwen-quirk explainer all rewritten;
added a new "Open WebUI 0.9.6+ regression" paragraph documenting
the empty-turn signature so the failure mode is recognisable
without re-deriving it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

deployments/ai-stack/openwebui-models/image_studio.json

@@ -7,7 +7,7 @@
       "system": "/no_think\n\nYou are an image-tool dispatcher. You do not respond in prose. Every user message MUST result in exactly one tool call.\n\nROUTING:\n- If the user attached an image (including images you previously generated in this chat) → call edit_image(prompt=..., ...)\n- Otherwise → call generate_image(prompt=..., ...)\nBoth tools take `prompt` as the first argument — same name on both. Do NOT invent `edit_instruction`.\n\nFire the tool on the FIRST message, with no preamble. Do not write a 'plan', 'approach', 'steps', 'breakdown', or any explanation before calling. Do not ask clarifying questions. Do not say what you are about to do. If the request is vague, pick reasonable defaults and call the tool — the user iterates after.\n\nSTYLES (pick one):\n  photo         photorealistic photo / portrait / cinematic\n  juggernaut    alternate photoreal — sharper, more saturated\n  pony          anime, cartoon, manga, stylised illustration\n  general       catch-all when nothing else fits\n  furry-nai     anthropomorphic, NAI-trained mix\n  furry-noob    anthropomorphic, NoobAI base\n  furry-il      anthropomorphic, Illustrious base (default for any furry/anthro request)\n\nSTYLE FOR edit_image — the tool ENFORCES inheritance: once a style has been used in this chat, every subsequent edit_image call uses the same style regardless of what you pass. Behaviour:\n- Edit on an image generated earlier in this chat → OMIT `style` entirely. The tool will use the established style. Passing it is harmless but ignored.\n- Edit on a fresh user upload (no prior tool call in chat) → look at the image and pick a style: anthropomorphic furry/scaly/feathered → furry-il; pony score-tag art → pony; photo/portrait → photo or juggernaut; anime → pony; ambiguous → general.\n- Style cannot be changed mid-chat. If the user wants a different style they need to start a new chat — explain that briefly if they ask for a style switch.\n\nedit_image has TWO MODES — pick based on whether the change is local or global:\n- LOCAL change (\"change the ball to a basketball\", \"add a hat to the dog\", \"remove the bird\", \"recolor the car red\") → set `mask_text` to a brief noun phrase naming the region (\"the ball\", \"the dog\", \"the bird\", \"the car\"). Only that region is repainted; rest stays pixel-perfect.\n- GLOBAL change (\"make this a sunset\", \"turn this into anime\", \"restyle as oil painting\") → leave mask_text unset. The whole image is reimagined.\nALWAYS prefer LOCAL when the user names a specific object, person, or region. GLOBAL is only for whole-image style/lighting transformations.\n\nDenoise:\n- LOCAL (mask_text set): default 1.0. Drop to 0.6–0.8 only for subtle local edits that should retain some original structure.\n- GLOBAL (no mask_text): default 0.7. Use 0.3–0.5 for subtle restyle, 0.85–1.0 for radical reimagining.\n\nPick style for the DESIRED OUTPUT, not the input image.\n\nWrite rich, descriptive prompts (subject, action, environment, lighting, mood, framing). Do NOT add quality tags like 'masterpiece', 'best quality', 'score_9', 'absurdres' — the tool prepends the correct tags per style. Do NOT set sampler, CFG, steps, scheduler — the tool picks them.\n\nAFTER the tool returns, write at most one short PLAIN-ENGLISH sentence noting your style/mode choice and offering one iteration idea. The image is already shown to the user.\n\nNEVER, after the tool returns:\n- echo or repeat the tool call (no `edit_image(prompt=..., ...)`, no `<function=...>`, no JSON, no parameter listings)\n- describe what's in the image\n- list the arguments you used\n- enumerate styles, denoise, mask_text, etc.\nThose details are visible in the collapsible 'View Result from edit_image' tool-result block — the user can expand it if they care. Your follow-up message is for HUMAN conversation, not bookkeeping.",
       "temperature": 0.5,
       "top_p": 0.9,
-      "function_calling": "native",
+      "function_calling": "default",
       "custom_params": {
         "tool_choice": "required",
         "enable_thinking": false

deployments/ai-stack/openwebui-models/image_studio.md

@@ -47,11 +47,11 @@ In the **Advanced Params** section:
 
 | Field | Value |
 | ----- | ----- |
-| Function Calling | `Native` — works cleanly on `huihui_ai/qwen3-vl-abliterated:8b` once thinking is disabled (see Custom Parameters). Native gives you the structured "View Result from edit_image" blocks and "Thought for X seconds" tracing in the UI. |
+| Function Calling | `Default` — Open WebUI's prompt-injection wrapper. `Native` was the working setting on OWUI ≤ 0.9.5 (paired with `enable_thinking: false`), but on 0.9.6+ Native produces empty assistant turns on `huihui_ai/qwen3-vl-abliterated:8b` even with thinking disabled — the model's tool-call output stops getting dispatched. `Default` is the reliable path until upstream resolves it. Trade-off: you lose the structured "View Result from edit_image" UI block; the tool result comes back as plain text in the assistant message instead. |
 | Temperature | `0.5` (lower = more reliable tool-calling) |
 | Top P | `0.9` |
 | Context Length | leave default |
-| Custom Parameters | `tool_choice: required` (forces the model to call a tool every turn) **and** `enable_thinking: false` (disables Qwen's thinking mode at the API level — the `/no_think` system-prompt directive isn't honored by abliterated Qwen builds, but this server-side flag is). Both required for reliable behaviour on `huihui_ai/qwen3-vl-abliterated:8b`. |
+| Custom Parameters | `tool_choice: required` (forces the model to call a tool every turn) **and** `enable_thinking: false` (disables Qwen's thinking mode at the API level — the `/no_think` system-prompt directive isn't honored by abliterated Qwen builds, but this server-side flag is). `enable_thinking: false` is no longer strictly required with `Function Calling: Default` (the wrapper doesn't read model thinking output), but keeping it set saves the tokens Qwen would otherwise spend thinking before each dispatch — leave it on. |
 
 Save. The new model appears in the chat-model dropdown for any user with
 access.
@@ -200,12 +200,26 @@ the LLM never sees). Abliterated VL gets us both reliable tool
 calling AND a cooperative dispatcher.
 
 **Qwen 3.x quirk:** thinking mode is on by default and abliterated
-builds ignore the system-prompt `/no_think` directive — the model
-emits its tool call inside a thinking block that the parser treats
-as final response text instead of a real tool invocation. The
-shipped preset sets `enable_thinking: false` in `custom_params`,
-which Ollama enforces server-side and the model can't ignore. Don't
-remove it.
+builds ignore the system-prompt `/no_think` directive. With
+`Function Calling: Native` this matters — the model emits its tool
+call inside a thinking block that the Native parser treats as final
+response text instead of a real tool invocation, and OWUI swallows
+the result. With `Function Calling: Default` (the current preset)
+the OWUI wrapper doesn't care about the model's thinking output, so
+the failure mode disappears even with thinking on. The shipped
+preset still sets `enable_thinking: false` in `custom_params` to
+save the tokens Qwen would otherwise spend on hidden thinking before
+each dispatch.
+
+**Open WebUI 0.9.6+ regression:** `Function Calling: Native` was the
+working setting through OWUI 0.9.5 when paired with
+`enable_thinking: false`, and committed history reflects that
+(d8c8421). On 0.9.6+ Native produces empty assistant turns — the
+tool-call output stops being dispatched, and (worse) the chat
+finishes successfully so the failure looks like the model "decided
+not to call the tool." If you're running ≤ 0.9.5 you can flip
+Function Calling to `Native` to get the structured tool-result UI
+block back; on 0.9.6+ stay on `Default`.
 
 ### Alternatives