The introduction described the mechanism before the purpose. It now
states what the plugin does, that it is meant for a local LLM server
speaking the OpenAI chat completions API, and -- the part that was
missing -- that the summary exists to condense the results the query
actually returned rather than to recite training data.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Furo renders its own page-local table of contents and reports an error
when a page adds one with contents::. No other page in the tree uses
that directive; these two now follow suit.
The plugin is named "AI Summary" where the name of the plugin is meant,
and "AI summary" where the generated text itself is meant. That also
fixes the entry in the plugin navigation, which takes its label from the
page title.
Two references to the configuration page rendered as its title, the bare
YAML key "ai_summary:", which reads as a typo in a sentence. They now
carry explicit link text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The documentation was written from the perspective of someone who had
just implemented the plugin: it opened with SSRF caveats and settings
keys, and explained decisions rather than usage.
The admin page now starts from what the feature is, followed by a
four-step quickstart (install Ollama, pull a model, configure, restart)
and a troubleshooting section for the failures that actually occur. The
quickstart repeats the default plugins because a plugins: block replaces
that list instead of merging into it -- following the short version of
the instructions would otherwise switch every other plugin off.
The developer page gains a rendered data flow diagram. The two-request
design -- placeholder first, streamed answer second -- is the part of
this plugin that is hard to convey in prose, and the SSE to NDJSON
change is easier to see than to read about.
The module docstring now describes the module and links to both pages,
instead of restating administration guidance.
Add Jason Witty to AUTHORS.rst.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Grounding is on by default, and it sends the top search results along
with the query. Which data leaves the instance depends on where the LLM
server runs -- per the privacy-by-design directive the reader has to be
able to see that from the documentation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The AI summary API key is a password input, the preferences stylesheet
only styled input[type="text"] -- the field rendered with the browser
default (white) instead of the theme background.
The description of the field is shortened to what a user needs to decide
whether to fill it in.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three changes to the ai_summary plugin:
- The *AI Summary* preferences tab is only rendered when the plugin is
activated in settings.yml. An instance that does not offer AI
summaries no longer shows an AI tab at all. The gate is the
administrator setting, not the user opt-out, because the per user
on/off switch lives inside that tab -- hiding it on opt-out would
leave no way to opt back in.
- Users can configure an API key for their own LLM server
(ai_summary_api_key). The administrator key is still only sent to
base_url and the user key only to a server the user configured, so
neither key can be captured through the other. The setting is marked
secret: credentials are excluded from the preferences URL, which users
copy around to transfer or share their preferences.
- Grounding summaries on the search results is now the default; the
extra cost of the longer prompt is moderate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
httpx derives an "Authorization: Basic" header from the userinfo of a
URL, so a user could make SearXNG send a header of their choosing to a
host of their choosing (e.g. to probe an internal service behind basic
auth). A user preference carrying credentials is now ignored and the
administrator default is used instead; credentials in the configured
base_url are untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Servers that require authentication (e.g. vLLM or llama.cpp started with
--api-key, or an LLM server behind an authenticating reverse proxy) can
now be configured with an ai_summary.api_key, sent as "Authorization:
Bearer".
The key is administrator configuration only: there is no preference for
it, and it is only sent to the configured base_url. Users can point the
ai_summary_server preference at a server of their own, and such a server
must not be handed the instance API key -- otherwise every user of the
instance could capture it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Talk to the LLM server via GET /v1/models and POST /v1/chat/completions
(SSE) instead of Ollama's native API. Any OpenAI compatible server now
works (Ollama, vLLM, llama.cpp, LM Studio, Hugging Face TGI, ...);
Ollama serves this API natively, existing setups keep working unchanged.
The Ollama specific keep_alive option is dropped, the ai_summary.grounding
setting is added as instance wide default of the grounding preference.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add an optional, disabled-by-default plugin that shows an AI generated
summary at the top of the result page, generated by a (local) Ollama
server:
- async: the result page is never delayed; a client plugin streams the
answer (NDJSON over a new /ai_summary endpoint) into a placeholder
answer with a typing indicator, collapsed behind a More button, with
an inline follow-up chat
- trigger: first page of general searches only, skipped when an infobox
or instant answer already answers the query
- grounding (per-user preference): send the top result snippets as
context, the model answers from them instead of its own knowledge
- configuration: new AI Summary preferences tab (server URL, model,
grounding) with instance defaults in a new ai_summary: settings
section; all three preferences can be locked for public instances
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The code used here has always been "bad" because `about` shouldn't be used
as data source, but the engine probably broke when type checks / dataclasses
for the about parameter in engines has been added with
<https://github.com/searxng/searxng/pull/6258>.
Error log:
```
WARNING searx.engines.public domain im: ErrorContext('searx/engines/public_domain_image_archive.py', 143, '\'url\': _clean_url(f"{about[\'website\']}/images/{result[\'objectID\']}"),', 'TypeError', None, ("'EngineAbout' object is not subscriptable",)) False
ERROR searx.engines.public domain im: exception : 'EngineAbout' object is not subscriptable
Traceback (most recent call last):
File "/home/bnyro/Projects/searxng/searx/search/processors/online.py", line 253, in search
search_results = self._search_basic(query, params)
File "/home/bnyro/Projects/searxng/searx/search/processors/online.py", line 239, in _search_basic
return self.engine.response(response)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
File "/home/bnyro/Projects/searxng/searx/engines/public_domain_image_archive.py", line 143, in response
'url': _clean_url(f"{about['website']}/images/{result['objectID']}"),
~~~~~^^^^^^^^^^^
TypeError: 'EngineAbout' object is not subscriptable
```
Qwant now requires a `datadome` cookie that it returns
in the first search response as a `Set-Cookie`.
This cookie has to be sent for all requests, otherwise they
will be blocked.
This means that now, the first search request is blocked (results in CAPTCHA),
and only the subsequent searches work (same happens on the Qwant website for me).
However, I don't think it's worth repeating the same
search request multiple times very quickly because
that also makes us more suspicious.
Some search engines encode domains that contain special characters
in the IDN format, i.e. by using Punycode (https://en.wikipedia.org/wiki/Punycode).
This means that domains formatted like that are not human readable
and thus very unintuive.
Also, as only some engines use Punycode, this often causes a result
to appear multiple times, once with a Punycode domain (e.g. xn--allestrungen-9ib.de),
and once with a normal domain (e.g. allestörungen.de).
Always formatting the domains nicely has the caveat that the official sites
are harder to distinguish from malicious clones that just swapped out some
characters by using Punycode, e.g. replaced `a` with `á`. I don't think
that will be much of an issue though - I don't think Punycode results
previously stopped users from clicking the link, and I also think that
most search engines filter out such bad results or don't even have them
indexed.
Changes:
- the `embed.js` request now requires a user agent header
- we include a user agent in the "actual" request (I dropped it by accident)
- we only send the first 4 decimal places of the location
instead of 7+ (not required, but harder to detect)
Refactor engines that parse ISO 8601 dates with strptime to use
fromisoformat instead. In most cases this is a direct replacement of
strptime(text, "format") with fromisoformat(text).
For engines where the source has a trailing "Z" that strptime consumed
as a literal (e.g. "%Y-%m-%dT%H:%M:%S.%fZ" in huggingface.py), add
rstrip("Z") to keep the output naive and preserve the existing behavior.
In sogou.py the date is extracted with a regular expression, which can
yield strings like "2026-7-11". strptime accepts this via its format
string, but fromisoformat does not. To preserve the existing behavior
and satisfy the format fromisoformat expects, add zero-padding for the
month and day.
Closes: #6098
---------
Signed-off-by: OneVth <onebrotravel@gmail.com>
* [mod] show img_load_error.svg if thumbnail fails to load (#6368)
Brave and a few other engines occasionally provide dead URLs for the thumbnails,
which looks pretty ugly in the UI. As already with the image search, in case of
an error img_load_error.svg should be displayed here.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
* [build] /static (#6368)
---------
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
`engines` only contains active engines. Since `google` was set to
inactive, it's no longer part of the , making the engine crash.
With this workaround, we directly load the engine traits from the data
dictionary instead of going the intermediate step with the Google engine.
I was testing the new Kagi engine and found for some queries I was getting a
`KeyError` exception from the result parsing.
This PR ensures we only assumes the `url` key exists, and we use `.get()` to
retrieve values for keys that may not be present.
Their API documentation [1] clarifies that only the `url` and `title` properties
are required/guaranteed in the search result object, but this is not correct:
File "/home/patrick/code/searxng/searx/engines/kagi.py", line 161, in response
title=html.unescape(result["title"]),
~~~~~~^^^^^^^^^
KeyError: 'title
Heard back from Kagi support:
> The image results "title' should be marked as optional, as many images likely
> don't have titles - as you've noticed. The only required field there should be
> the "url" field.
[1] https://kagi.redocly.app/api/docs/openapi/search/search#search/search/t=response&c=200&path=data/search
[2] https://github.com/searxng/searxng/issues/2247#issuecomment-4692976877
jasonwitty