[GH-ISSUE #21371] issue: Built-in search_web tool ignores WEB_SEARCH_RESULT_COUNT admin setting (hardcoded count=5) #34987

New Issue

GiteaMirror · 2026-04-25T09:12:07-05:00

GiteaMirror commented

2026-04-25 09:12:07 -05:00

Originally created by @sewasti on GitHub (Feb 13, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21371

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

0.8.0

Ollama Version (if applicable)

No response

Operating System

Linux (Debian 11 bullseye)

Browser (if applicable)

Version 144.0.7559.133

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

The built-in search_web tool (used in Native Function Calling mode) should respect
the admin setting WEB_SEARCH_RESULT_COUNT (Admin → Settings → Web Search →
Search Result Count). When set to 10, web searches should return 10 results.

Actual Behavior

The built-in search_web tool always returns exactly 5 results, regardless of
the admin WEB_SEARCH_RESULT_COUNT setting.

Confirmed via API that the admin setting IS correctly stored:

GET /api/v1/retrieval/config → WEB_SEARCH_RESULT_COUNT: 10 ✅

But in Native Function Calling mode, only 5 sources are ever returned.

Steps to Reproduce

Install Open WebUI v0.8.0 via Docker.
Configure a web search engine (e.g. Tavily with API key in Admin → Settings → Web Search).
Set Search Result Count to 10 in Admin → Settings → Web Search.
Verify setting via API:
curl -H "Authorization: Bearer " http://localhost:8080/api/v1/retrieval/config | jq '.web.WEB_SEARCH_RESULT_COUNT'
→ should return 10.
Configure a model to use Native Function Calling mode:
Admin → Chat Controls → Function Calling Mode → "Native".
Start a new chat and ask the model to search the web for any topic, e.g.:
"Search the web for the latest news about AI regulation in the EU"
Observe: the model returns exactly 5 sources, not the configured 10.
This is 100% reproducible — every single web search returns exactly 5 results.

Logs & Screenshots

No runtime errors in browser console or Docker logs. The bug is in the source code.

Root Cause in open_webui/tools/builtin.py (lines ~148-173):

async def search_web(
    query: str,
    count: int = 5,   # ← hardcoded default, ignores admin WEB_SEARCH_RESULT_COUNT
    __request__: Request = None,
    __user__: dict = None,
) -> str:
    ...
    results = await asyncio.to_thread(_search_web, __request__, engine, query, user)
    results = results[:count]  # ← re-truncates results to 5

The underlying _search_web() in routers/retrieval.py correctly uses the admin setting
request.app.state.config.WEB_SEARCH_RESULT_COUNT for the search engine API call
(e.g. Tavily receives max_results=10 and returns 10 results).

But then builtin.py re-truncates with results[:count], where count defaults to 5
because LLMs typically call search_web(query="...") without passing the count parameter.

This is a double-truncation bug: the backend fetches the correct number, but the
tool function silently discards the extra results.

Additional Information

Suggested Fix

Option A (simplest): Remove the [:count] truncation in builtin.py, since
_search_web() already applies the admin limit via the search engine API:

results = await asyncio.to_thread(_search_web, __request__, engine, query, user)
# results = results[:count]  ← remove this line, backend already limits

Option B: Use the admin config as the effective default:

if __request__:
    admin_count = getattr(__request__.app.state.config, 'WEB_SEARCH_RESULT_COUNT', 5)
    count = max(count, admin_count)
results = results[:count]

Scope

Only affects the Native Function Calling path (built-in tools in builtin.py).
Classic web search (middleware-based chat_web_search_handler) correctly uses the admin setting.
Tested with Tavily search engine; the issue is engine-agnostic (same code path for all engines).

Workaround

Add a system prompt instruction: "When using the search_web tool, always pass count=10."
This forces the LLM to explicitly pass the parameter instead of using the hardcoded default.

Originally created by @sewasti on GitHub (Feb 13, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/21371 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version 0.8.0 ### Ollama Version (if applicable) _No response_ ### Operating System Linux (Debian 11 bullseye) ### Browser (if applicable) Version 144.0.7559.133 ### 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 The built-in `search_web` tool (used in Native Function Calling mode) should respect the admin setting `WEB_SEARCH_RESULT_COUNT` (Admin → Settings → Web Search → Search Result Count). When set to 10, web searches should return 10 results. ### Actual Behavior The built-in `search_web` tool always returns exactly **5 results**, regardless of the admin `WEB_SEARCH_RESULT_COUNT` setting. Confirmed via API that the admin setting IS correctly stored: GET /api/v1/retrieval/config → WEB_SEARCH_RESULT_COUNT: 10 ✅ But in Native Function Calling mode, only 5 sources are ever returned. ### Steps to Reproduce 1. Install Open WebUI v0.8.0 via Docker. 2. Configure a web search engine (e.g. Tavily with API key in Admin → Settings → Web Search). 3. Set **Search Result Count** to `10` in Admin → Settings → Web Search. 4. Verify setting via API: curl -H "Authorization: Bearer <token>" http://localhost:8080/api/v1/retrieval/config | jq '.web.WEB_SEARCH_RESULT_COUNT' → should return `10`. 5. Configure a model to use **Native Function Calling** mode: Admin → Chat Controls → Function Calling Mode → "Native". 6. Start a new chat and ask the model to search the web for any topic, e.g.: "Search the web for the latest news about AI regulation in the EU" 7. Observe: the model returns exactly **5 sources**, not the configured 10. 8. This is 100% reproducible — every single web search returns exactly 5 results. ### Logs & Screenshots No runtime errors in browser console or Docker logs. The bug is in the source code. Root Cause in `open_webui/tools/builtin.py` (lines ~148-173): async def search_web( query: str, count: int = 5, # ← hardcoded default, ignores admin WEB_SEARCH_RESULT_COUNT __request__: Request = None, __user__: dict = None, ) -> str: ... results = await asyncio.to_thread(_search_web, __request__, engine, query, user) results = results[:count] # ← re-truncates results to 5 The underlying `_search_web()` in `routers/retrieval.py` correctly uses the admin setting `request.app.state.config.WEB_SEARCH_RESULT_COUNT` for the search engine API call (e.g. Tavily receives `max_results=10` and returns 10 results). But then `builtin.py` re-truncates with `results[:count]`, where `count` defaults to 5 because LLMs typically call `search_web(query="...")` without passing the `count` parameter. This is a double-truncation bug: the backend fetches the correct number, but the tool function silently discards the extra results. ### Additional Information ### Suggested Fix **Option A** (simplest): Remove the `[:count]` truncation in `builtin.py`, since `_search_web()` already applies the admin limit via the search engine API: results = await asyncio.to_thread(_search_web, __request__, engine, query, user) # results = results[:count] ← remove this line, backend already limits **Option B**: Use the admin config as the effective default: if __request__: admin_count = getattr(__request__.app.state.config, 'WEB_SEARCH_RESULT_COUNT', 5) count = max(count, admin_count) results = results[:count] ### Scope - Only affects the **Native Function Calling** path (built-in tools in `builtin.py`). - Classic web search (middleware-based `chat_web_search_handler`) correctly uses the admin setting. - Tested with Tavily search engine; the issue is engine-agnostic (same code path for all engines). ### Workaround Add a system prompt instruction: "When using the search_web tool, always pass count=10." This forces the LLM to explicitly pass the parameter instead of using the hardcoded default.

GiteaMirror added the bug label 2026-04-25 09:12:07 -05:00

GiteaMirror closed this issue

2026-04-25 09:12:09 -05:00

GiteaMirror commented

2026-04-25 09:12:09 -05:00

@Classic298 commented on GitHub (Feb 13, 2026):

the model decides the amount of sources it wants to retrieve. when the model doesnt specify a number it defaults to 5. the model can also say it wants 10 or 15.

@Classic298 commented on GitHub (Feb 13, 2026): the model decides the amount of sources it wants to retrieve. when the model doesnt specify a number it defaults to 5. the model can also say it wants 10 or 15.

GiteaMirror commented

2026-04-25 09:12:10 -05:00

@Classic298 commented on GitHub (Feb 13, 2026):

may add an additional check to use the admin config value if configured and only then default back to 5.

@Classic298 commented on GitHub (Feb 13, 2026): may add an additional check to use the admin config value if configured and only then default back to 5.

GiteaMirror commented

2026-04-25 09:12:11 -05:00

@Classic298 commented on GitHub (Feb 13, 2026):

https://github.com/open-webui/open-webui/pull/21373

@Classic298 commented on GitHub (Feb 13, 2026): https://github.com/open-webui/open-webui/pull/21373

GiteaMirror commented

2026-04-25 09:12:12 -05:00

@Ithanil commented on GitHub (Feb 13, 2026):

#21373

Personally, I would have preferred that the admin setting is enforced, i.e. not offered as an option to the LLM. This would make the native/non-native search consistent and depending on the setup, one might have to limit search results (with content snippets) to make sure it fits the context windows.
But of course there is also the argument to be made to keep the option for flexible control via user/system prompting.

@Ithanil commented on GitHub (Feb 13, 2026): > [#21373](https://github.com/open-webui/open-webui/pull/21373) Personally, I would have preferred that the admin setting is enforced, i.e. not offered as an option to the LLM. This would make the native/non-native search consistent and depending on the setup, one might have to limit search results (with content snippets) to make sure it fits the context windows. But of course there is also the argument to be made to keep the option for flexible control via user/system prompting.

GiteaMirror commented

2026-04-25 09:12:12 -05:00

@Classic298 commented on GitHub (Feb 13, 2026):

@Ithanil the snippets are quite short by default and i think open webui even has a hardcoded maximum cutoff for web fetch and the snippets length.

@Classic298 commented on GitHub (Feb 13, 2026): @Ithanil the snippets are quite short by default and i think open webui even has a hardcoded maximum cutoff for web fetch and the snippets length.

GiteaMirror commented

2026-04-25 09:12:13 -05:00

@Classic298 commented on GitHub (Feb 13, 2026):

And the setups don't necessarily have to be consistent

The entire point is to give the LLM a bit more control over how it uses these tools to get better results :)

@Classic298 commented on GitHub (Feb 13, 2026): And the setups don't necessarily have to be consistent The entire point is to give the LLM a bit more control over how it uses these tools to get better results :)

GiteaMirror commented

2026-04-25 09:12:13 -05:00

@Classic298 commented on GitHub (Feb 13, 2026):

The default tool calling exists for weak task models that don't even see the full chat context and shouldn't and can't decide how much to search

Native tool calling, strong models that have the full context in mind can decide how much to search for

@Classic298 commented on GitHub (Feb 13, 2026): The default tool calling exists for weak task models that don't even see the full chat context and shouldn't and can't decide how much to search Native tool calling, strong models that have the full context in mind can decide how much to search for

GiteaMirror commented

2026-04-25 09:12:14 -05:00

@Ithanil commented on GitHub (Feb 13, 2026):

It's OK. I'm using modified Tavily search that returns full chunks of relevant content. But I'm also able to change this feature as I see fit. ;-)

@Ithanil commented on GitHub (Feb 13, 2026): It's OK. I'm using modified Tavily search that returns full chunks of relevant content. But I'm also able to change this feature as I see fit. ;-)

GiteaMirror commented

2026-04-25 09:12:15 -05:00

@Ithanil commented on GitHub (Feb 13, 2026):

@Classic298 Ummm... wait a second. Looking at the code, the builtin search_web tool uses the search_web router (without passing the count option), which in turn uses the admin-configured result count. Thus, the result count specified by the model will only serve as an upper limit.

Not sure if that's the intended behavior, but my arguments are pointless in that case.

@Ithanil commented on GitHub (Feb 13, 2026): @Classic298 Ummm... wait a second. Looking at the code, the builtin search_web tool uses the search_web router (without passing the count option), which in turn uses the admin-configured result count. Thus, the result count specified by the model will only serve as an upper limit. Not sure if that's the intended behavior, but my arguments are pointless in that case.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#34987