All posts

tryingopen

How web search works on tryingopen

The three ways a reply on tryingopen can search the web, why each one is capped, where search stays off, and how it sits outside zero retention.

Some questions need the web as it is today: last night's score, a price, a model released this week. On tryingopen, a reply can look things up in three ways, depending on which model answers and where it runs. Each way has a cap, a few models never search, and every search goes to a search provider outside our zero-retention requirement.

The three paths at a glance

Where you areWhat searchesWho decidesResults
A cloud model on the ordinary pageOpenRouter's web-search server toolThe modelOne search per answer, up to 10 results
An edge-device pick, on a turn the small model answersOpenRouter's web plugin with the Exa engine, run by our serverd1One search, up to 5 results
Self Chat with a model on your computerThe same Exa lookup, run by our serverYou, with the search switchOne lookup per message, up to 5 results

Self Chat with a cloud model uses the first path once you switch search on.

Cloud models: the model decides

When you pick a cloud model that takes tools, our server attaches OpenRouter's web-search server tool to every request it sends through OpenRouter. We tell the model to search when the answer depends on current events or facts it isn't sure of, and to skip it otherwise. A question the model answers from memory never reaches a search provider. Results are cited in a "Found on the web" list under the reply.

OpenRouter's web search docs say server tools give "the model control over when and how often to search". We leave the model in charge of when, and cap how often, for two reasons.

  1. Reasoning models failed mid-stream. At up to ten searches per answer, reasoning models that took several reliably died as the second batch of results landed, with no text and no file. With one search, the same requests finish.
  2. Each search is billed. OpenRouter bills each search separately, and tryingopen is free for you.

The tool runs inside OpenRouter, so it works only on requests that go through OpenRouter. Our privacy policy explains that some models are reached through an AI gateway run by ngrok "unless you pick a provider for them". Those turns answer without search. That includes GLM 5.3 Flash, the default pick's cloud fallback, until you pick a provider for it. Picking a provider in the composer sends the message through OpenRouter, search tool included, unless that provider's endpoint takes no tools (a few don't).

Opened directly, Gemma 4 31B, Gemma 4 26B and GPT-OSS 120B start on CoreWeave. Gemma 4 31B and GPT-OSS 120B can search there. CoreWeave's Gemma 4 26B endpoint takes no tools, so that model needs another provider to search. "Let OpenRouter choose", which a switch from the home page keeps, sends all three to Amazon Bedrock through the ngrok gateway, without search.

The default pick: d1 decides

The default pick, LFM2.5-VL 3B, runs on Offline Base's own edge devices and takes no tools, so our server searches for it. The Gemma 4 E2B edge entry works the same way.

Liquid AI's d1, the small decision model that reads each message first (how d1 routes), scores several things in one call, including the one shown under "Learn more" as "Needs the web". Our server tells d1 that a search can run before the small model answers, so a quick lookup can stay on the edge device.

When d1 says a turn needs the web, our server runs one search through OpenRouter's web plugin with the Exa engine before the small model starts:

  • The query is your latest message, trimmed to 400 characters.
  • It asks for up to 5 results and cuts each to 1,500 characters, which keeps the small model's prompt short.
  • A search that hasn't come back within 12 seconds is dropped.

The plugin has to ride on a model request, so our server wraps the query in a short request to GLM 5.3 Flash, sent through OpenRouter under the zero-retention requirement, and throws that model's reply away.

The results go into the small model's prompt as numbered sources to cite as [1], [2], and under the reply as links. The reply's note reads "Answered by the small model on an Offline Base edge device, after a web search", and the route drawing adds a small globe.

If the search fails, times out or finds nothing, the small model answers from what it knows. A turn d1 sends to the cloud follows the cloud model's rules, so with the default GLM 5.3 Flash fallback and no provider picked, it answers without search.

Where search stays off

  • The side-by-side. Your first two questions to a cloud model also go to the small model for the side-by-side. That copy never searches: "on recent events it answers from what it already knows."
  • Qwen3.8 Flash. Its only OpenRouter endpoint, Alibaba's, doesn't run OpenRouter's server tool. Given the tool, the model called it as an ordinary function that nothing executed, and the turn stopped before answering, so we leave it off.
  • Nemotron 3.5 Lightning. On its endpoints it never called a tool unless forced to, so on tryingopen it takes no tools: no search, no files.
  • Self Chat, until you switch it on. Self Chat starts with search off. The switch in the composer explains itself: "Turn it on to let the model look things up; searches go to a search provider, outside zero retention."
  • Compare. When you press Compare, the closed model gets the same web results the open model had and runs no search of its own.

Since October 14, 2026, LFM2.5 24B searches through the same server tool as the other cloud models. Its post explains the fix.

A model on your own computer

In Self Chat you can talk to a model running in Ollama, LM Studio, llama.cpp or Jan (the guide). Those messages go straight from your browser to your machine.

With search switched on, every message is looked up first, through the same one-shot Exa lookup. The privacy policy puts it this way: "your latest message is sent to our server to be looked up, and only the results go back to your computer." The results go into the local model's prompt and onto the reply as sources.

Lookups have their own hourly allowance. When it runs out, the page says so, and switching search off lets you keep chatting.

Privacy

On every path, search sits outside our zero-retention requirement. The privacy policy says: "When a reply needs the web, the search query goes to a search provider through OpenRouter. This sits outside the zero-retention requirement."

OpenRouter's zero-data-retention docs draw the same line from their side: "ZDR enforcement only applies to provider routing for inference requests. It does not apply to plugins and tools you choose to enable, such as web search." The flag governs which company runs the model, and the search provider works under its own terms.

To see whether a search ran, look for the "Found on the web" list under a reply. An edge-device reply's note also says "after a web search".

What zero data retention covers, and where it stops goes through the other exceptions, including PDFs.