Replies: 2 comments 5 replies
-
|
I created the companion filter initially just for intercepting the search button:
As far as I researched, a filter plugin is the only way how I can disable the Open WebUI's search pipeline (prevent it from doing it's own search stuff) and signal my manifold pipe about the enabled feature. And after that I moved some other "extra" things there just to improve separation of concerns and keep the manifold pipe from growing too large. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I see. I didn’t expect it to work with the Open WebUI search button, as they function differently. I briefly tried the new version 1.17 with Companion 1.3, installed both, and turned on the global setting. However, the Companion didn’t work for me. The Open WebUI search still appears when the Web Search button is enabled. It could be an issue with some of my settings—I will check the log. Personally, I think the Gemini native web search doesn’t need an On/Off switch, as that implies a forced search, which it is not. |
Beta Was this translation helpful? Give feedback.
-
|
I did not get the Companion plug-in to work. It seems to be triggered only after the Open WebUI Search. My Open WebUI Search is set to use Google PSE, with Gpt-4o-mini as the Task Model (to generate queries). I am using Gemini 2.0 Flash and asking for "Today NBA games". If the Web Search button is enabled, the logs show that Open WebUI Search starts immediately. Only after the search is complete do I see logs from the Gemini_manifold pipe, and then logs from the Companion—which reports that it did not find grounding metadata. If I disable the Web Search button, here are the logs: |
Beta Was this translation helpful? Give feedback.
-
|
Hmm interesting. The companion filter's these are the ones I'm noticing that your logs are missing: Could you please add these lines to the companion filter and post the log output again? diff --git a/plugins/filters/gemini_manifold_companion.py b/plugins/filters/gemini_manifold_companion.py
index 557e938..503aded 100644
--- a/plugins/filters/gemini_manifold_companion.py
+++ b/plugins/filters/gemini_manifold_companion.py
@@ -128,6 +128,9 @@ class Filter:
if "gemini_manifold_google_genai." not in model_name or (
not is_grounding_model and not is_code_exec_model
): # Check if it supports *any* of the features we filter on
+ log.debug(
+ f"Exiting early. {model_name=}, {is_grounding_model=}, {is_code_exec_model=}"
+ )
return body
features = body.get("features", {}) |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the model_name is the issue. I imported the main PIPE plug-in under a different function name (with a version number, so I can keep two versions and switch more easily), and that wasn't an issue by itself, but it caused issue with the Companion. After importing again using the default name, it worked perfectly. Thank you for your help and for this great plugin! I will use the new version, hopefully Open WebUI will add the settings to set Web Search button always enabled for selective models. |
Beta Was this translation helpful? Give feedback.
-
|
Good! Glad we got it working! |
Beta Was this translation helpful? Give feedback.
-
|
Oh and we added "Code Interpreter" support too with this companion filter. If you press the "Code Interpreter" button then it will enable Gemini's "Code execution" API feature |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've been using the Gemini Manifold plugin since its early version, and it works great!
I have a question: why, after version 1.9, have the grounding search functions been separated from the main file and now work as a standalone filter? Given its exclusively working with the main plugin what are the benefits of separating them?
I'm still on version 1.9 for its simplicity as a single file and full functionality.
Beta Was this translation helpful? Give feedback.
All reactions