ModSearch: free web and X search for agents without native web access

The gap ModSearch is filling

The README states the problem in one line: models like DeepSeek and GLM have no web access, or a weak one, and ModSearch is a plug-in that strengthens web search, X search and single-page fetch. The framing in the header is sharper still, that in the chat app your model can search the web but on the API it cannot.

The pitch is that it works the moment it lands. The default engine is Firecrawl's keyless tier, which the README links to a post describing 1,000 free credits every month, with no account, no API key and no card. That is the differentiator against paid search APIs: a developer evaluating whether web search helps their agent does not have to sign up for anything.

The package itself is a Node CLI published to npm as @liustack/modsearch, written in TypeScript, with a binary named modsearch pointing at ./dist/main.js. The engines field in package.json requires Node 22.13 or above, and the package exports a dsh entry point for the DeepSeek Harness integration, a client export, and the package manifest itself.

Two things follow from the design. First, this is infrastructure for agent harnesses rather than a library you import into an application, so the install path is a harness command rather than a dependency line. Second, the value is in the chain of providers rather than in any one of them.

Installing into DeepSeek Harness and the other agents

The DeepSeek Harness install is a single command, given with the profile and a pinned version.

npx -y @deepseek-ai/dsh plugin --profile web add @liustack/[email protected]

The README adds a specific warning for the desktop app: in the Add plugin dialog you enter @liustack/modsearch, not the GitHub URL. That is the kind of detail that costs an afternoon if you assume otherwise, and it is why the plugin profile is named web rather than added as a general extension.

Other harnesses are covered by the same package, with the README listing Claude Code, Codex, Pi and OpenCode under install once, use everywhere. The repository topics name the same set plus agent-skills, claude-skills, dsh-plugin, codex, hermes-agent, openclaw and pi-agent.

The repository is built for that kind of deployment. There is a dsh/ directory holding the harness integration, a cordis.patch.yml that the package.json dsh section points at as the bundle patch, a skills/modsearch/ directory with a SKILL.md, scripts and references, and an evals/ directory with its own runner. The published files list in package.json ships dist, docs, the skill files, the changelog, the security policy, the dsh directory and the patch configuration, so the skill travels with the plugin rather than needing a separate install.

The docs directory in the repository carries the reference material the README links to: harness setup, troubleshooting, security, and the configuration and output contract references under skills/modsearch/references.

The engine chain and how failover works

Seven engines are listed, and the table is the clearest description of the project.

Firecrawl is the default and does web search plus page fetch, with a keyless tier of 1,000 free credits per month and no signup, and a free key adding another 1,000 per month. Keenable does web search, keyless with 1,000 requests per hour per IP, a figure the README notes is shared by everyone on that IP, and a free key gives 100,000 requests per month of your own. Antigravity CLI does both search and fetch and needs a browser sign-in, with the install being the agy command. Tavily does web search with 1,000 credits per month. Exa does web search with roughly 1,400 searches on a $10 monthly recurring credit. Grok Build handles X search and rides a SuperGrok or X Premium subscription. The local engine does page fetch and is built in, with nothing to install.

Two behaviours sit on top of the list. When a channel fails or exhausts its quota, the next one takes over, so multiple engines configured means automatic failover, best first. And per-engine key rotation lets you give Tavily, Exa, Firecrawl or Keenable multiple comma-separated keys, where an authentication, rate-limit or quota failure rotates to the next key before the engine chain falls back at all.

The X capability is the one no web index can replicate. With Grok Build installed, ModSearch queries the corpus that web indexes cannot reach, which for a topic like a product launch or a security advisory is often the only place the first report appears.

Configuring keys and the local CLI

Keys live in ~/.modsearch/config.json, which the README says is written with 0600 permissions and masked when shown. The per-engine commands follow a consistent pattern.

modsearch config set tavily.apiKey <key>
modsearch config set exa.apiKey <key>

The same keys can come from the environment instead, through TAVILY_API_KEY, EXA_API_KEY, FIRECRAWL_API_KEY and KEENABLE_API_KEY. One engine can hold several keys as a comma-separated value, either in the config file or in its environment variable, which is what the rotation behaviour consumes.

The local engine deserves a note because it is the one that is always there. It does page fetch, it is built in and there is nothing to install, so a setup that never touches an account still has a working fetch path, and only search needs a remote engine.

The package is built with Vite and tested with Vitest, and the scripts in package.json show the working commands.

    "dev": "vite build --watch",
    "build": "vite build",
    "typecheck": "tsc --noEmit",
    "test": "vitest run",

Linting and formatting go through Biome rather than ESLint and Prettier, which is why a biome.json sits at the root instead of an ESLint configuration. A separate eval runner lives under evals/, invoked as node evals/run.mjs.

Structured output, sources and the uncertainty field

The screenshots in the README are described as unedited runs, and what they show is the shape of a result rather than a chat transcript.

A summarisation request against a blog link comes back as a structured summary of the whole post with no browser involved. An open-ended question returns six sourced stories with a closing note about which details came from aggregation and deserve a second look, and the README says that note comes from the uncertainty field. The native search tool row in the dsh web interface runs straight on the modsearch engine chain and returns three stories, each with a source link.

The multi-page case is the one to look at closely. Asking which Node.js line is still in maintenance makes read_page read the release page and the release schedule in turn, and the result arrives with a version status table and sources at the end. Two pages, two fetches, one answer, and the sources at the bottom rather than a citation in the middle of a paragraph.

That output contract is documented separately in skills/modsearch/references/output-schema.md, so a developer building on the plugin can code against the shape rather than guessing. The stated timings, twenty-five seconds, thirty-six seconds, eighteen seconds and sixty seconds in the four examples, are from the project's own demo runs on the author's hardware and should not be treated as a service level.

Where ModSearch is the wrong choice

The first limitation is the free tier, and it is the one that decides whether this works for you. Keenable's keyless quota is 1,000 requests per hour per IP and is shared by everyone on that address, so a shared office or a cloud instance gets a fraction of that. Firecrawl's 1,000 credits per month is generous for evaluation and thin for a production agent. The answer is a paid key, and at that point the comparison is with Tavily or Exa directly, where ModSearch's contribution is the failover chain and the X access rather than the search itself.

The second limitation is that the default engines scrape on your behalf. Every search and fetch passes through a third-party service, and the project does not describe in the README what a provider may retain. A team with a compliance requirement around what URLs leave the network, or a policy about fetching internal hosts, needs to read docs/security.md and the configuration reference rather than trusting the defaults.

The third is the dependency on other people's CLIs for two of the engines. Antigravity CLI needs agy installed and signed in through a browser, and Grok Build needs grok installed and signed in. Those are two more moving parts to install, authenticate and keep alive, on a machine where an agent may run unattended.

The fourth is that the plugin is young and moves fast. Three releases landed on a single day in the version history, v5.10.8, v5.10.9 and v5.10.10, and the version number in the install command is pinned in the README, which suggests pinning is expected. It also means the behaviour of a given engine can change under you when the chain is reordered.

Licence, maintenance and what it costs to run

The package is under the MIT licence, with the LICENSE file at the root, and the author is listed as Leon Liu. The README also carries a badge noting the project is not backed by Y Combinator, and one reading the number of users, which is deliberately unknown.

The repository is not archived and the last push was on 2026-10-18, the same day as the v5.10.10 release, and the release notes say new versions land on X first. Releases are frequent enough that a version pin in your configuration becomes a routine maintenance item rather than a one-off decision.

The running cost depends entirely on which engine is answering. A keyless Firecrawl setup costs nothing and covers 1,000 fetches a month. A paid key shifts that to a monthly subscription on whichever provider you pick, and the Exa tier is described as a $10 monthly recurring credit for roughly 1,400 searches. The X engine rides a subscription you already hold, if you hold one.

The operational cost is smaller than the financial one: a config file with 0600 permissions, keys in the environment if you prefer that, and a chain that hides which provider actually answered. If you need per-provider attribution in your logs, that is worth checking before you rely on the failover behaviour, since the point of failover is that the provider changes underneath you.

Editorial conclusion

ModSearch suits anyone running a model with weak or missing web access who needs sourced results with citations and an uncertainty field, and the keyless default means a first run needs no account or card. It does not suit a workflow that needs guaranteed quota, because the free tiers are small and shared, so production use wants a paid key configured deliberately. Verify the engine chain and the config file location first, at ~/.modsearch/config.json, and check which harness you are on since the DeepSeek Harness install is a different command from the other agents.

Frequently asked questions

Official sources

1. License: MIT
2. liustack/modsearch on GitHub
3. Project website
4. README
5. Releases