Tabstack vs. search APIs
Ollama Web Search, Brave Search, and SearXNG return results for your model to work through. Tabstack returns the finished result. What each one hands back, and when search is the better choice.
A search API is usually the first thing people add when their own model needs the web. It is cheap, fast, and easy to wire up. It is also where the work starts rather than ends.
This page compares Tabstack with three common choices: Ollama Web Search, Brave Search, and self-hosted SearXNG. Details are as documented at publication time.
What each one hands back
Section titled “What each one hands back”Ollama Web Search is POST https://ollama.com/api/web_search. The response is a results array of title, url, and content, where content is a relevant snippet from the page. A companion POST /api/web_fetch takes a URL and returns title, content, and the links on the page. Both need an API key from a free Ollama account. Neither endpoint synthesizes or cites; Ollama’s own documentation frames building the search agent as your job, and suggests raising the model’s context to around 32,000 tokens to hold what comes back.
Brave Search returns a web.results array of title, url, description, and up to five extra_snippets per result. Snippets, not page content. Brave positions its Web Search API as intended for human consumption and points agent builders at a separate LLM Context endpoint, with cited answers available through a separate Answers API.
SearXNG is self-hosted metasearch. It aggregates result metadata from whichever upstream engines an instance has enabled and returns it as JSON, CSV, or RSS. It does not fetch or return page content. Worth knowing before you plan around it: JSON output is off by default, many public instances disable it, and requesting an unset format returns 403.
Tabstack /research takes a question and returns a synthesized report plus the sources it cited (in balanced mode, with the claims each source supports). Query planning, source selection, page fetching, gap checks, follow-up queries, and citation assembly all happen inside the call.
Feature comparison
Section titled “Feature comparison”| Feature | Tabstack | Ollama Web Search | Brave Search | SearXNG |
|---|---|---|---|---|
| Ranked result list | No | Yes | Yes | Yes |
| Snippets | No | Yes | Yes | From upstream engines |
| Full page content | Yes, /extract/markdown | Yes, /api/web_fetch | No | No |
| Synthesized answer | Yes, /research | No | Separate Answers API | No |
| Claim-level citations | Yes, in balanced mode | No | Via Answers API | No |
| Decides what to search for | Yes, inside the call | Your model | Your model | Your model |
| Iterates to close a gap | Yes, inside the call | Your model | Your model | Your model |
| Self-hostable | No, hosted API | No, hosted API | No, hosted API | Yes, that is the point |
| Streams progress | Yes, SSE | No | No | No |
What the difference costs you
Section titled “What the difference costs you”With a search API, the steps between “question” and “answer” belong to your model and your code: choose which results are worth reading, fetch them, recover readable text, judge relevance, notice what is missing, search again, reconcile sources that disagree, synthesize, and attach sources to claims.
That is not impossible. It is a loop whose quality depends on how reliably your model calls tools several times in the right order, and whose cost shows up as tool calls, tokens, latency, and context spent on raw page content rather than on your application. See Search versus research for the step-by-step breakdown.
When a search API is the right choice
Section titled “When a search API is the right choice”- You want the links themselves, for example to show a result list to a person.
- Your model genuinely needs the raw material because reasoning over it is your product.
- You need ranked discovery across the whole web rather than an answer. Tabstack has no ranked search endpoint.
- Cost per call dominates. A search call is cheaper than a
/researchcall, which runs several actions and bills for each. See Pricing. - You require self-hosting for the search layer. SearXNG runs on your infrastructure; the Tabstack API does not.
When Tabstack is the right choice
Section titled “When Tabstack is the right choice”- You want an answer your application can use directly, with sources attached to claims.
- You would rather not spend your model’s context window on page content.
- You want the same integration to cover reading a known URL (
/extract) and completing a public web task (/automate). - You need matching JSON rather than text to post-process.
Honest gaps
Section titled “Honest gaps”Tabstack limitations vs. search APIs: No ranked search endpoint, so this is not a drop-in replacement for a search box. No self-hosting of the API. Higher cost per call. /research always streams, so a client that expects one JSON response needs a small change.
Search API limitations for this job: Results and snippets are not an answer. Citations, gap detection, and reconciliation stay with your model. Brave’s cited answers and LLM-oriented context come from separate endpoints rather than the Web Search API. SearXNG needs an instance you run, with JSON explicitly enabled.
Related
Section titled “Related”- Search versus research: which steps run where.
- Tabstack vs. Tavily: the closest comparison if you want an answer endpoint.
- Tabstack vs. building it yourself: when owning the loop is the right call.