Gemini 1.20.0: Open WebUI 0.12 features, shared chats, thinking levels per model

[owndev]

Why

After the Open WebUI 0.12 compatibility fixes (#199), the remaining 0.12 topics for the Gemini pipeline were:

• the new features (context compaction between tool rounds, Tool Search, model controls, per-chat streaming);
• the new shared chats with "Allow replies".

Checking them turned up two bugs and one gap. Two older weaknesses were found along the way.

Change (Google Gemini pipeline 1.19.1 → 1.20.0)

Open WebUI 0.12 features

• Tool Search:
  • Before: Gemini could not call a tool found through search_tools. Open WebUI leaves deferred tools out of body["tools"], so the call was rejected as undeclared.
  • Now: the pipe declares every deferred tool (metadata["deferred_tools"]) that a search_tools result in the conversation names, from the next round on and in later turns. Name mapping applies as usual.
• Context compaction: Open WebUI asks the chat model for the summary (task context_compaction).
  • Before: a failed or empty summary request returned the pipe's error text, e.g. Error generating content: 400 … or [No content generated]. Open WebUI then stored that text as the conversation summary (on 0.11 too).
  • Now: such an answer becomes empty, so Open WebUI uses its own summary, and one WARNING is logged.
  • Unchanged: compaction between tool rounds itself already produced valid Gemini requests (signatures, call/response pairing).
• Model controls: Open WebUI 0.12 refuses them on pipe models (HTTP 400). Custom params (reasoning_effort, thinking_budget, include_thoughts) still reach the pipe.
• Streaming: both per-chat and per-model "Stream Chat Response" work. The pipe's streamed tool round for stream=false chat requests is still needed on 0.11 and 0.12.

Shared chats with "Allow replies" (Open WebUI 0.12)

• Before: participants got neither the chat's earlier generated images nor the owner's uploads for image edits, and the pipeline's generated images showed as broken (404) for them. The pipeline never linked its images to the chat, as Open WebUI's own image generation does.
• Now the pipe uses Open WebUI's own checks:
  • Chats.get_accessible_chat_by_id(..., permission="write"): exactly what Open WebUI requires before it calls the pipe.
  • has_access_to_file(id, "read", user): the same as GET /api/v1/files/<id>/content.
  • Detection is by shape, not by version. On 0.11 the owner/admin rule is unchanged.
  • Generated images are linked to the chat (insert_chat_files), only for saved chats the user may continue.
• Security review findings, all LOW and all fixed:
  • A file named by another participant's message is read only if that author may read it too. This closes a confused deputy: a participant could name a private file of the owner and get the derived image.
  • Linking re-checks the chat.
  • At most max(4 × IMAGE_HISTORY_MAX_REFERENCES, 8) history images are checked per request.
  • The chat check accepts only the chat itself, not any truthy value.

Thinking

• Levels per Gemini 3 model, per Google's thinking docs:

  • gemini-3-flash, 3.5-flash-lite and 3.6-flash: minimal…high;
  • gemini-3.1-pro and 3.8-flash: low/medium/high;
  • gemini-3-pro: low/high.

  Before, every Gemini 3 text model was limited to low/high, so medium became high. Unknown Gemini 3 text models keep low/high.

• Invalid per-chat values: a reasoning_effort that is not a string, or a thinking_budget that is not a number, is ignored with a warning. Before, it silently dropped the whole thinking config, including include_thoughts. A number sent as a string ("1024") is accepted.

Docs: the Gemini guide (Tool Search, compaction, shared chats, thinking levels), README, docs/testing.md. CLAUDE.md now also counts valve types as public API: since 0.12, saving a function validates its stored valves.

Tests

• New gemini group owui012, 12 checks: compaction, compaction follow-up, summary error / empty / saved, Tool Search (also follow-up and mapped names), controls, custom params, per-chat and per-model streaming. On 0.11, a check of a 0.12 feature verifies what 0.11 does instead.
• New gemini group shared:
  • On 0.12: real shares through Open WebUI's API (participant, group member, Clone-only viewer with a read-only folder, outsider, admin).
  • A test-only filter hands the pipe other chat ids and injects helper errors.
  • Security checks: deputy, link-chat, history-cap, pipe-truthy.
  • On 0.11: unsupported and legacy.
• New in thinking: level-models, params-robust.
• check_owui_api.sh: the import of the submodule open_webui.utils.access_control.files failed the static check, which looked for files as a name in __init__.py. A submodule is now ok, and the functions called on it or its alias are checked like methods. A missing method that the function looks up with getattr first is a WARN, not a FAIL: Chats.get_accessible_chat_by_id on 0.11.x. Results: 0.12.0, 0.11.4 and 0.11.3 all ok.
• Mutation rounds: all mutants killed, both on the access logic (11) and on the security fixes (5).
• Every new check fails on the code it guards against:
  • 1.19.1: 6 owui012 checks and 10 shared checks;
  • the pre-review state: the 4 security checks;
  • the pre-fix state: the 2 thinking checks.

Verification

Run	Result
v0.12.0-slim, all suites, --strict-known	580 PASS, 0 FAIL, 0 KNOWN (1263 s)
v0.11.4-slim (default), all suites, --strict-known	565 PASS, 0 FAIL, 0 KNOWN (1213 s before the security fixes; 565/0/0 again after them)
v0.11.3-slim, all suites, --strict-known	565 PASS, 0 FAIL, 0 KNOWN (1786 s, host shared with other runs)
Meta-test (main 6b99dcf, E2E_MOCK_FAULT=500, gemini azure n8n infomaniak)	59 PASS, 402 FAIL, 0 KNOWN (595 s)
Smoke runner dry run (e2e Gemini mock)	15 PASS, 0 FAIL, 2 SKIP; key in no output
ruff format --check / ruff check (0.11.10)	clean
CI on dd31038: v0.11.4 E2E, meta-test, API check (latest = 0.12.0); dispatched E2E on v0.12.0-slim (0e72790)	all green

Known limits

• Images generated before 1.20.0 are not linked to their chat. Participants still can't see them, and they are not sent for participants.
• Open WebUI 0.12 lets a chat owner edit any message of a shared chat, or add one under a participant's user_id. A message forged that way counts as the participant's own. Closing this would also require the owner's access for participants' own messages; that is left as is.
• Not verified against the real Gemini API: that it rejects undeclared calls, and that it accepts a turn whose earlier rounds were compacted. The mock models both.

🤖 Generated with Claude Code