AutoCLI: a Rust CLI that turns 55+ sites into one command

What AutoCLI actually replaces

The everyday problem is that reading a site programmatically usually means one of two things: signing up for an API and managing a token, or writing a scraper that breaks whenever the page changes. AutoCLI takes a third route. You install one binary, run a command shaped like `autocli <site> <action>`, and get the result as a table, JSON, YAML, CSV or Markdown.

The README lists coverage of 55 sites and 333 commands, naming Bilibili, Twitter, Reddit, Zhihu, Xiaohongshu, YouTube and Hacker News among them. It also positions the tool as a companion for AI agents: the README suggests putting `autocli list` into `AGENT.md` or `.cursorrules` so an agent can discover the available tools, and registering a local CLI with `autocli register mycli` so the agent can call those too.

So the audience is narrower than "anyone who wants data". It is people who are already comfortable in a shell, and people building agents that need a uniform way to reach many sites. If you want a hosted API with a schema and a support contract, this is not that.

The Rust workspace behind the single binary

The repository is a Cargo workspace, and the crate list is the clearest map of the architecture. Cargo.toml declares eight members: autocli-core, autocli-pipeline, autocli-browser, autocli-output, autocli-discovery, autocli-external, autocli-ai and autocli-cli. That split tells you the design intent: output formatting, browser control, discovery, external CLI passthrough and AI features are separate concerns rather than one large crate.

The README describes the scraping workflows themselves as a declarative YAML pipeline, with adapters living in the top-level adapters/ directory. The claim is that you can add a new adapter with zero code by describing the workflow in YAML. Two other pieces sit outside the Rust tree: extension/ holds the Chrome extension, and scripts/ holds the install script and the test harness referenced by the Makefile (test-adapters runs scripts/test-all-commands.sh).

The release profile is tuned for distribution rather than build speed: lto, codegen-units = 1, strip and panic = "abort". That is consistent with shipping a small static binary, and it is also why local release builds are slower than a debug build.

Install AutoCLI and fetch your first list

The README's one-line installer targets macOS and Linux, detects your architecture, downloads the matching binary and installs it to /usr/local/bin/.

curl -fsSL https://raw.githubusercontent.com/nashsu/autocli/main/scripts/install.sh | sh

On Windows the README gives a PowerShell sequence that downloads autocli-x86_64-pc-windows-msvc.zip from the latest release, expands it and moves autocli.exe into %LOCALAPPDATA%\Microsoft\WindowsApps\. There are also manual tarballs per platform, and a source build via git clone, cargo build --release, then copying target/release/autocli into your PATH.

Start with a public command, because it needs no browser and no login. The README's example pulls Hacker News top stories and prints them as JSON.

autocli hackernews top --limit 5 --format json

You should see a JSON array of stories rather than a table. Then run diagnostics:

autocli doctor

Browser-backed commands need the Chrome extension first. The README's steps are to download autocli-chrome-extension.zip from the releases page, extract it, open chrome://extensions, enable Developer mode, click Load unpacked and select the extracted folder. The extension then connects to the autocli daemon. Only after that does something like this work:

autocli bilibili hot --limit 5

For shell completion, the README shows `autocli completion bash >> ~/.bashrc` and equivalents for zsh and fish.

Browser session reuse is the design bet, and the main failure mode

Most of the interesting commands do not use an API key. They reuse a logged-in browser session through the Chrome extension. That removes token management entirely, which is genuinely convenient, and it also means the tool inherits every property of a browser session: it expires, it can be challenged, and it lives on one machine.

The README is explicit that public-mode commands (it names hackernews, devto and lobsters) work without the extension. Everything else needs the extension loaded and a session that is actually authenticated. The README does not document what happens when the session expires mid-run, nor does it describe a rollback path if an adapter starts returning empty results after a site change. The release notes for v0.3.2 describe a Chrome extension selector tool for visually picking elements and building CSS selectors, plus AI-powered generation through autocli.ai, which suggests the maintainers expect selectors to need rebuilding over time.

A second constraint is scope. The tool covers 55 sites and 333 commands; the README does not claim arbitrary coverage. The `explore`, `generate` and `cascade` commands are the intended answer for sites outside that set, and `generate --ai` depends on autocli.ai and an API token obtained through `autocli auth`. If you cannot or will not send data to that service, the AI path is closed to you.

How it compares with opencli and with plain HTTP clients

The most direct alternative is OpenCLI, the TypeScript project this one was rewritten from. The README states AutoCLI is a complete rewrite in pure Rust, feature-equivalent, and reports a comparison table: 15 MB versus 99 MB of memory for public commands, 9 MB versus 95 MB for browser commands, a 4.7 MB binary against roughly 50 MB of node_modules, and no runtime dependency against Node.js 20+. It also reports a test pass rate of 103/122 against 104/122, which is near parity rather than full parity.

The command timings in that table come from the project's own automated testing of 122 commands on macOS Apple Silicon, so treat them as the project's numbers, not an independent measurement. The relevant structural difference is that OpenCLI requires a Node.js runtime and AutoCLI does not, which matters on minimal containers and on machines where you cannot install a runtime.

The other alternative is not a CLI at all: a plain HTTP client plus your own parsing, or a general-purpose scraping framework. Those give you full control and no dependency on a browser extension, at the cost of writing and maintaining the extraction logic yourself. AutoCLI's YAML adapters are an attempt to make that maintenance cheap, but the adapters are still the part that breaks when a site changes.

Licence, releases and what upgrading costs

The workspace declares license = "Apache-2.0" under [workspace.package], and the repository carries both a LICENSE and a NOTICE file. Apache-2.0 is permissive and includes a patent grant; the NOTICE file exists because the licence asks redistributors to preserve attribution notices. If you vendor the binary or the adapters into a product, read the NOTICE alongside the LICENSE. This is a description of what the files say, not legal advice.

The project was renamed from opencli-rs to AutoCLI starting at v0.2.4, according to the README. That rename has a visible consequence in the build tooling: the Makefile's install and uninstall targets still copy and remove /usr/local/bin/opencli-rs, and the packaging target still looks for target/<triple>/release/opencli-rs. Anyone building from source through the Makefile rather than the install script should expect the old name in those paths.

Upgrade cost is low by design. The README says to re-run the install command or download the latest release to overwrite the existing binary. There is no migration step described, and no configuration file format is documented for the core tool. The releases listed are v0.3.6, v0.3.7 and v0.3.8, the last pushed on 2026-04-20, which is the most recent activity recorded for the repository.

Where AutoCLI is the wrong tool

If your requirement is reproducibility in a CI pipeline, the browser-session model is a poor fit. A build agent has no logged-in Chrome profile, and the README's setup steps assume an interactive browser. Public-mode commands are the exception, and the README names only a few site families in that category.

If you need a stable data contract, this is the wrong layer. The output formats are stable and well specified in the README (table, JSON, YAML, CSV, Markdown), but the extraction rules are adapters that track someone else's HTML and internal APIs. The v0.3.2 notes describe tooling for rebuilding selectors, which is an admission that selectors need rebuilding.

And if you need to run on a machine where you cannot install a Chrome extension, the majority of the 333 commands are simply unavailable. The README does not present a headless substitute for the extension. That is the boundary to test before you plan around this tool.

Editorial conclusion

Adopt AutoCLI if you already live in a terminal or you are wiring tools into an AI agent and want one binary that covers many sites without managing API tokens. Skip it if you need a supported, contract-backed data API, or if you cannot run Chrome with a logged-in profile on the machine doing the fetching. Before committing, run autocli doctor and autocli hackernews top --limit 5 to confirm the binary works, then test one browser-backed command such as autocli bilibili hot --limit 5 to see whether the extension and your session actually connect.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nashsu/AutoCLI on GitHub
4. README
5. Releases