Best Web Search Options for OpenCode in 2026: Built-in, ChatGPT Plugins, Tavily, Firecrawl & SearXNG

Aug 30, 2026 - Last update: Aug 30, 2026

Cowrie

Dev @ Bswen

Problem

OpenCode’s model is frozen at training time: it does not know the newest framework release, last week’s breaking change, or an API that shipped yesterday. To fix that you need real-time web search, and the real question is which option to wire in.

Short answer: for most users, start with the built-in websearch — it is the fastest path with no extra account. Add a community plugin only when you already have the auth relationship it reuses (a model provider’s bundled search, or a ChatGPT OAuth login). Move to an MCP backend (Tavily, Firecrawl, SearXNG) when the task needs extraction, crawling, or self-hosting. There is no universal winner — task type, the accounts you already pay for, and your privacy bar decide it — and the guide below maps most situations.

The 30-second decision guide

• I just want web search working, right now → built-in websearch. Zero setup, no extra account.
• I already use ChatGPT OAuth → opencode-chatgpt-websearch (community plugin). It reuses the login you already have — but verify it still works without extra fees; see the subscription-vs-API warning below.
• I want to reuse my model provider’s search → opencode-websearch (community plugin). Fewer keys, but search quality is locked to that provider.
• I need deep documentation research / crawling → Firecrawl, or Tavily’s crawl/extract for lighter jobs.
• I need self-hosting / privacy → SearXNG. Self-hosted, but not a privacy silver bullet (more below).
• I need real GitHub code examples → OpenCode’s sourcegraph tool. That is code search, not web search.

Rule of thumb: classify the task before choosing the tool — search, fetch, crawl, or code search. Most setups that fail pick a good tool for the wrong task.

Environment

This comparison is based on my setup:

• OpenCode CLI as the terminal coding agent
• Models via OpenAI/ChatGPT, Anthropic, or GitHub Copilot
• MCP servers configured in opencode.json

What is actually being compared

OpenCode web search options exist at different layers: built-in tools, community plugins, and external search backends connected through MCP.

My first pass at this article treated built-in websearch, opencode-websearch, opencode-chatgpt-websearch, and MCP providers as four parallel routes. They are not on the same level. It helps to separate five distinct things:

• OpenCode’s own tools — websearch, fetch, and code search (sourcegraph) ship with OpenCode. They are OpenCode capabilities, not plugins.
• Provider-native search — search functionality bundled by model providers (OpenAI/ChatGPT, Anthropic, GitHub Copilot). OpenCode does not provide it; the provider does.
• Community plugins — opencode-websearch and opencode-chatgpt-websearch are third-party plugins that bridge the two above: they let OpenCode call a provider’s native search or reuse a ChatGPT OAuth login. They are neither OpenCode built-ins nor MCP servers, and their behavior is community-plugin / implementation-dependent.
• MCP — the Model Context Protocol is an integration standard, not a search engine. It exposes external tools to OpenCode through opencode.json.
• Search/crawl backends — Tavily, Firecrawl, and SearXNG are actual search, extract, and crawl engines. You reach them via MCP servers.

Restated, there are really three routes:

1. Built-in search — OpenCode’s own websearch / fetch / code-search tools.
2. Provider-native and OAuth-reusing plugins — community plugins that reuse auth you already have.
3. External search backends via MCP — Tavily, Firecrawl, SearXNG, and the long tail.

This also explains the naming confusion: the two community plugins look like peers of built-in websearch, but they sit at the plugin layer, while Tavily/Firecrawl/SearXNG sit at the backend layer behind the MCP protocol.

Search, fetch, crawl, and code search are not the same thing

Choose the capability before choosing the provider: search finds pages, fetch reads one page, crawl reads many pages, and code search searches repositories.

This distinction caused most of my confusion, so it is worth making explicit:

• Search = give a query, get ranked relevant results. This is what Exa, Tavily, SearXNG, and native model search do.
• Fetch = retrieve a single known URL’s content. OpenCode has a built-in fetch tool for this.
• Crawl = systematically walk a site and extract content from many pages. This is what Firecrawl’s crawl and Tavily’s crawl do.
• Code search = search across code repositories. OpenCode’s sourcegraph tool does this, and it is not web search.

What each capability does

Query "latest React 19 docs"
          |
          v
[Search]      -> ranked list of links      (Exa, Tavily, SearXNG, native search)
[Fetch]       -> one URL, full content     (OpenCode built-in fetch tool)
[Crawl]       -> many pages, extracted     (Firecrawl, Tavily crawl)
[Code search] -> code inside repositories  (Sourcegraph - NOT web search)

Picking a “search” tool for a task that needs “crawl” will fail even though both look like web search at first glance. Map the task first, then the route:

Task example	Capability you need	Recommended option
”Find the latest release / breaking change”	Search, then Fetch the one changelog URL	Built-in websearch (or Tavily), then built-in fetch
”I already have the exact docs URL — read it”	Fetch	Built-in fetch, or Tavily Extract / Firecrawl scrape
”Analyze an entire documentation site”	Crawl	Firecrawl (or Tavily Crawl for lighter jobs)
“Find real GitHub examples of an API”	Code search	OpenCode sourcegraph tool — not web search

Route 1: built-in search

OpenCode’s built-in tools cover three of the four capabilities above: websearch (wired to providers such as Exa, and Parallel where supported), fetch, and sourcegraph for code search. The provider wiring for websearch changes between versions, so I re-verify it against the current OpenCode docs before every release instead of trusting old setup notes.

Why I like it:

• Lowest setup friction. If the provider wiring is already in place, there is no separate search account to create.
• Exa behaves like a search-and-retrieval engine for AI: relevant results plus content and highlights in one call, which maps well to coding research.

The trade-offs:

• Results go to whatever built-in provider OpenCode uses, so I have limited control over quality and privacy.
• The exact providers and tool behavior change over time, so this part is implementation-dependent at the cloud/provider layer.

For a quick on-ramp, this route is hard to beat. I use it when I need an answer fast and do not want to manage another account.

Route 2: community plugins that reuse provider search

These are third-party plugins, not OpenCode official features. Treat their supported providers, auth flows, and pricing as community-plugin behavior / implementation-dependent, and confirm each one in the plugin repo before relying on it.

opencode-websearch (provider-native search)

Wraps the search capability already native to your model provider (OpenAI/ChatGPT, Anthropic, or GitHub Copilot — provider support varies; verify in the plugin repo).

Why I like it:

• Reuses an existing subscription. If your provider bundles search, you do not need an extra API key.
• Fewer external providers in the stack, which means fewer keys and less billing to track.

The trade-offs:

• Provider lock-in. Quality and availability follow whatever the provider’s native search supports, and citation formats vary between providers.
• If the provider’s search is weak, the plugin cannot fix it.

opencode-chatgpt-websearch (ChatGPT OAuth reuse)

Aimed at users who already authenticate with ChatGPT OAuth. Reusing the existing login means no new API key or billing relationship if the plugin delivers on it.

Why I like it:

• Convenient entry point for existing ChatGPT users; the auth flow reuses the login you already have.
• No extra key to create if the OAuth path works.

The trade-offs:

• Narrowly scoped. It only helps ChatGPT users; it does nothing for Anthropic or other providers.
• Whether it truly reuses the subscription with no extra API fees is implementation-dependent — verify it against the plugin repo and current terms, because “I pay for ChatGPT” is not an automatic search entitlement everywhere.

ChatGPT subscription vs OpenAI API vs ChatGPT OAuth

These three are easy to conflate and are the source of most misunderstandings:

• ChatGPT Plus/Pro subscription — a consumer plan for the ChatGPT product. It is not OpenAI API credits, and it does not by itself create an API search quota.
• OpenAI API — the paid developer API with separate billing. Web search at the API level follows OpenAI’s current API/model offering.
• ChatGPT OAuth — the login flow against ChatGPT services. A plugin can reuse this to drive ChatGPT search on your behalf, but that reuse happens at the plugin layer (community behavior), not the API layer.

So a ChatGPT subscription can make a plugin path convenient, but it is not the same as having OpenAI API search credits wired into OpenCode.

Route 3: external search backends via MCP

This route separates the two layers cleanly: MCP is the protocol that exposes a backend’s tools to OpenCode; the backend (Tavily, Firecrawl, SearXNG) does the actual searching, extracting, or crawling.

Tavily

Tavily is a search engine optimized for AI agents. Its Search API does the whole job in one call: search, scrape, filter, and return ranked content ready for a model. It also offers Extract and Crawl endpoints for deeper work.

Good for: general-purpose, agent-optimized search and research on coding topics. Needs a Tavily API key; there is a free tier worth verifying before committing.

Firecrawl

Firecrawl is strongest at crawling and page extraction. Its search, scrape, and crawl endpoints return LLM-ready markdown — exactly what an agent needs when it must read and synthesize many pages of documentation.

Good for: research where the agent must actually read page content, not just return links. Needs a Firecrawl API key.

SearXNG

SearXNG is a free, open-source metasearch engine you self-host, and it does not track or profile its users. That is a real win, but “self-hosted” is not a synonym for “fully private”: SearXNG aggregates results from upstream search engines, and those upstream engines can still see your queries (and your IP, unless you also proxy or otherwise mitigate). For enterprise or sensitive work, evaluate the whole data path — where queries are sent, what gets logged, and who operates the upstream providers — instead of assuming self-hosting alone answers the privacy question.

Good for: self-hosting and privacy-conscious users and enterprises with sensitive repositories. The cost is infrastructure you operate yourself, usually with Docker.

Other MCP search providers

There are many more MCP search servers on the market. I evaluate each on the same dimensions: setup complexity, extra API key, extra cost, search quality, citations, provider lock-in, privacy, reliability, crawling ability, self-hosting, and fit for coding-agent research. If a provider cannot be checked against current official docs, I do not recommend it.

Wiring an MCP search backend into OpenCode

OpenCode reads MCP servers from the mcp key in opencode.json. A remote server with an auth header looks like this:

opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "tavily": {
      "type": "remote",
      "url": "https://your-tavily-mcp-endpoint",
      "enabled": true,
      "headers": {
        "Authorization": "Bearer YOUR_TAVILY_API_KEY"
      }
    }
  }
}

Heads-up: https://your-tavily-mcp-endpoint is a placeholder, and this is a generic remote-MCP example showing the shape of an opencode.json entry — not a Tavily-official endpoint. Copying it verbatim will not run. For a runnable setup, check Tavily’s current docs for an official MCP integration if one exists, or point url at your own MCP server (for example, a local Tavily MCP server you run), and verify the config keys against the current OpenCode docs before publishing.

Once wired, the model can call the tools exposed by the MCP server’s search and extract endpoints just like any other tool.

Decision matrix

The quick guide covers “what to pick”; this matrix covers “why”. Cells I could not confirm from official docs are marked Depends / Provider-dependent — check before you commit.

Dimension	Built-in (Exa/Parallel)	opencode-websearch (community)	opencode-chatgpt-websearch (community)	Tavily (MCP)	Firecrawl (MCP)	SearXNG (MCP, self-hosted)
Search quality / relevance	Depends on built-in provider	Provider-dependent (mirrors your model provider)	ChatGPT search quality (plugin-dependent)	High for agent queries	Good via search endpoint	Depends on configured upstream engines
Full-page extraction	Partial (Exa content; fetch for one URL)	Provider-dependent	Provider-dependent	Yes (Extract)	Yes (scrape → markdown)	Limited (link-level results)
Multi-page crawling	No	No	No	Yes (lighter crawl)	Yes (purpose-built)	No
Citation / source visibility	Depends on tool output	Provider-dependent	Provider-dependent	Yes (sources in results)	Yes (per-page source URLs)	Depends on upstream results
Extra API cost	Usually none (verify current wiring)	None if provider search is bundled	None via OAuth (verify plugin)	API key + usage	API key + usage	None — your infra only
OAuth / subscription reuse	No	Reuses model provider subscription	Reuses ChatGPT OAuth (verify)	No	No	No
Provider lock-in	Low	High (tied to provider search)	High (ChatGPT-only)	Low	Low	Low
Privacy / data exposure	Queries go to built-in provider	Queries go to your model provider	Handled via ChatGPT login (plugin-dependent)	Queries go to Tavily	Queries go to Firecrawl	Self-hosted, but queries still go to configured upstream engines
Self-hosting	No	No	No	No	No	Yes
Setup difficulty	Minimal	Low	Low	Medium	Medium	Higher (infra + MCP)

Three real OpenCode scenarios

1. Find the breaking changes in the newest React/Next.js release. Task type: Search + Fetch. You need the release announcement and the changelog, not the whole docs site. Start with built-in websearch (or Tavily) to find the release post, then built-in fetch (or Tavily Extract) to read that one URL. A crawler is overkill here; code search is the wrong level entirely.

2. Read an entire framework documentation section and propose a migration. Task type: Crawl. The agent must synthesize dozens of pages, so a ranked link list is useless — the content has to come back with the results. Use Firecrawl (crawl → LLM-ready markdown across the section), or Tavily Crawl for lighter jobs. Built-in search returns links and then stalls.

3. Find real-world GitHub examples of an unfamiliar API. Task type: Code search. Web search finds blog posts and docs; you want actual usage inside repositories. Use OpenCode’s sourcegraph tool — it is not web search, and this is exactly the case where confusing the capabilities costs you an afternoon.

Common mistakes

I made several of these myself before settling on a workflow:

1. Treating search as “enough” when the task actually needs crawling or extraction. A link list does not help if the agent must read 30 pages of docs.
2. Confusing code search (Sourcegraph) with web search. They solve different problems and belong in different mental models.
3. Assuming one route is best for everyone. The 30-second guide above maps most situations — the remaining work is matching the task to the capability.
4. Ignoring provider lock-in when choosing model-native search. The plugin is only as good as the provider’s search.
5. Treating “self-hosted SearXNG” as fully private. Upstream engines still see queries; evaluate the whole data path instead.
6. Assuming a ChatGPT subscription gives you OpenAI API search quota. Subscription, API, and OAuth are three different things — see Route 2.

Summary

Two habits matter more than any single tool choice: classify the task as search, fetch, crawl, or code search before picking a route, and re-verify plugin names, supported providers, and pricing against current official docs before publishing config — these change often. Built-in websearch is the fastest on-ramp; community plugins reuse auth you already have (implementation-dependent, so verify them); MCP backends cover extraction, crawling, and self-hosting when the built-ins are not enough.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

• 👨‍💻 OpenCode Docs: Configuration and MCP servers
• 👨‍💻 OpenCode Docs: Tools
• 👨‍💻 Tavily Docs: Search, Extract, and Crawl APIs
• 👨‍💻 Firecrawl Docs: Search, Scrape, and Crawl
• 👨‍💻 Exa Docs: AI search API
• 👨‍💻 SearXNG Docs: Self-hosted metasearch engine
• 👨‍💻 How to Enable Web Search in OpenCode CLI (Exa, Plugins & Troubleshooting)

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags:

• ai-coding
• ai-agents
• llm
• automation
• ai

Pi Agent + DeepSeek: Why the Harness Can Matter More Than the Model

How to Use Your ChatGPT Login for Web Search in OpenCode