AnySearch Skill: A Search CLI for AI Agents, Wrapped Around a Hosted API
Unified real-time search engine skill for AI agents. Supports general web search, vertical domain search, parallel batch search, and full-page content extraction.
At a glance
- What is it?
- AnySearch Skill packages web search, vertical domain search, batch search and full-page extraction into a single CLI that an agent can call. The client is Apache-2.0, but every query goes to api.anysearch.com, so adoption is a decision about a service, not just a script.
- Who is it for?
- Adopt AnySearch Skill if your agent already runs shell commands and you want one interface for web search, vertical search and page extraction without writing a client per provider. Skip it if you need offline operation, a self-hosted search backend, or if your agent platform cannot execute a CLI at all.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Integration Problem AnySearch Skill Actually Addresses
An agent that needs current information has to talk to a search provider. Doing that directly means writing request code, parsing results into a shape the model can read, handling rate limits, and repeating the whole exercise when a second provider or a vertical source is added. AnySearch Skill exists to collapse that into one callable surface. The README describes it as a unified real-time search engine skill supporting general web search, vertical domain search, parallel batch search and full-page content extraction. The unit of distribution is a skill directory, not a library, which tells you the intended consumer: an agent runtime that loads skills from a known path such as ~/.claude/skills/anysearch or ~/.config/opencode/skills/anysearch. The repository also lists ~/.agents/skills/ as a shared location read by Codex, Cursor and OpenClaw, so one install can serve several tools. If you are building a conventional Python service that calls a search API, this project is the wrong shape. If you are wiring an assistant that already executes local commands, it fits without an SDK.
One CLI, Three Runtimes, and a Hosted Endpoint Behind All of Them
The mechanism is deliberately thin. The skill ships parallel entry points: scripts/anysearch_cli.py, scripts/anysearch_cli.js, scripts/anysearch_cli.ps1 and a bash variant. Each exposes the same subcommands, with doc used as the entry test, and the release notes for v3.1.0 describe the shift to a direct HTTP CLI that is REST-native. The client does not index anything locally. Search requests leave the machine and are answered by api.anysearch.com, which is visible in the registration example hitting /v1/auth/email/register. That design keeps the install small and the update story simple, and it means behaviour is governed by the remote service rather than by the code you downloaded. The batch capability is the part worth noting: parallel batch search is listed as a first-class feature rather than something the caller orchestrates, which matters when an agent needs results from several queries before it can answer. Full-page extraction is the other half. Search returns references; extraction pulls page content. Keeping both behind one CLI avoids a second tool and a second credential in the agent's environment.
Installing It and Getting an API Key Without Leaving the Agent
Installation is a download and a move. The README recommends a pinned release archive, for example curl -L -o anysearch-skill.zip https://github.com/anysearch-ai/anysearch-skill/archive/refs/tags/v3.1.1.zip, then unzip, then move the extracted directory into the skill path and rename it to anysearch. The README warns that the unzipped directory carries the ref in its name (anysearch-skill-3.1.1), so the mv command has to match the tag you chose. Registration is the more unusual part. A single POST to https://api.anysearch.com/v1/auth/email/register with a JSON body containing a real email address returns code 0 and a one-time plaintext key in data.api_key.key. The README instructs the agent to write that value to .env as ANYSEARCH_API_KEY=<key> and to tell the user their username, which is the email, plus the login_url. There is no verification code step. The README is explicit that the key is shown once, though it can be retrieved later from the dashboard. Errors always return code -1 and are branched on the message string: email_already_registered means stop and sign in, a message containing Rate limited carries the retry seconds, and a message starting with Key creation failed means the account exists but the key does not, so the user signs in manually. That is a clean contract for an automated flow, and it is also a reminder that the agent is being trusted with an account creation call. Key resolution order is documented as --api_key flag, then .env, then environment variable, then anonymous.
Anonymous Access, Rate Limits and the Quota Field You Should Read
The API key is described as optional but strongly recommended. Without one, the README states that all search features remain available through anonymous access at lower rate limits and quota. That is a real constraint, not a footnote: an agent that searches on every turn will hit the anonymous ceiling quickly, and the failure will surface as a rate limit rather than as a missing feature. The registration response includes rate_limit and quota_limit fields on the key object, and in the documented example rate_limit is 100 while quota_limit is 0. The README does not explain what a quota_limit of 0 means, and I cannot confirm from the supplied material whether 0 signals unlimited, unset, or a separate billing tier. Treat that as something to verify against the console at anysearch.com/console/api-keys before you depend on it. The same applies to expires_at, which the example shows as null. The README also states that registration and anonymous use are mutually exclusive and that once a user picks one, the flow should not switch mid-stream, which is a practical warning for agents that retry.
Runtime Detection Is Where Installs Usually Fail
The post-install section is the most operationally useful part of the README, because it assumes the environment is hostile. Priority is Python, then Node.js, then shell. Python requires version 3.6 or newer and the requests library; Node.js requires version 12 or newer with no external dependencies; the shell fallback needs PowerShell 5.1 or newer on Windows, or bash 3.2 or newer on Linux and macOS, plus jq and curl. The README warns directly that python may not exist and that python3 is the correct executable on many macOS systems, and it tells you to check both. Verification is the doc subcommand run against each runtime you have, watching for errors or warnings. That is a sensible test because it exercises the CLI without consuming a search query, but it does not validate the API key, the network path to api.anysearch.com, or the anonymous quota. An install that passes doc can still fail on the first real search. The dependency asymmetry is worth weighing too: the Python path needs requests installed, while the Node.js path needs nothing. On a locked-down machine where you cannot add packages, the Node.js CLI may be the only one that runs.
What You Give Up, and What to Compare It Against
The clearest limitation is architectural. Every search and extraction call depends on a third-party endpoint, so the skill is unusable offline, in an air-gapped environment, or in any setting where queries cannot leave the network. There is no documented self-hosted mode in the material provided. A second limitation is that the client is a client: result quality, index coverage and vertical domain support are properties of the service, and nothing in the repository lets you inspect or change them. If you need to control the index, compare against SearxNG. SearxNG is a self-hosted metasearch engine that aggregates results from upstream engines you configure and exposes them over its own HTTP API. The difference in approach is where the work sits. AnySearch Skill keeps a thin Apache-2.0 client on your machine and pushes retrieval to a hosted service with an account and a key; SearxNG asks you to run and maintain the aggregator yourself, and in exchange the queries stay inside your infrastructure and the engine list is yours to edit. Neither is strictly better. The choice is between accepting a hosted dependency with a documented rate limit and owning an instance you have to patch. A third option, calling a search provider's API directly, removes the abstraction layer but puts the parsing and multi-provider handling back in your code.
Licence, Maintenance and Upgrade Cost
The repository is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved and any modified files are marked. The licence covers the code in the repository. It does not cover the hosted service, and the material here does not state terms for the API beyond the rate_limit and quota_limit fields returned at registration, so the service terms are a separate question to check rather than something the Apache-2.0 grant settles. I am not giving legal advice; read the licence text and the service terms yourself. On maintenance, the release cadence looks active: v3.0.1 in July 2026, v3.1.0 in August 2026, and v3.1.1 in September 2026. The v3.1.0 notes describe a move to a direct HTTP CLI and REST-native search, and v3.0.1 mentions flattened sub_domain_params and CLI hardening. Parameter reshaping between minor versions is the kind of change that can break an agent's stored command templates, so pinning to a tag rather than tracking main is the safer default, and the README already recommends the pinned archive. Upgrading means replacing the skill directory and re-running the entry test; there is no package manager step and no migration tooling described.
Editorial conclusion
Adopt AnySearch Skill if your agent already runs shell commands and you want one interface for web search, vertical search and page extraction without writing a client per provider. Skip it if you need offline operation, a self-hosted search backend, or if your agent platform cannot execute a CLI at all. Before committing, run the entry test with each runtime you have (python3 <skill_dir>/scripts/anysearch_cli.py doc), confirm which of Python, Node.js or shell actually works on your machines, and read the rate_limit and quota_limit fields returned in the registration response, because those numbers define your real ceiling.
Community notes