Webcmd Says It Cuts Browser-Agent Tokens by 90%. Its Own Site Calls That Number a Placeholder.

The top trending repo this morning is browser infrastructure that learns from agent runs. The architecture is right. The headline number is not measured yet, and the project says so.

The GitHub description for agentrhq/webcmd reads "The Browser Infra that learns and cuts token spend by upto 90%." The homepage repeats it in the hero: "Browser-agent token spend drops by up to 90%."

Scroll that same homepage to the chart the number comes from and the label above it says Illustrative benchmark. The caption underneath says the figures are a "Modeled repeat-run index for the same known six-step website task" and then, without flinching: "Directional placeholder, to be replaced with observed benchmark runs."

Same project, same page, same morning. The headline is a claim and the fine print is a confession, and I have rarely seen a repo put both within one scroll of each other.

Webcmd took the number one slot on Trendshift's daily board today at roughly 1.2k stars, with 768 forks, 22 open issues, and 17 open pull requests on the repository page. It deserves the attention. I want to spend this piece on what you are actually installing, because the gap between "cuts token spend by 90%" and what happens in your terminal on day one is wide, and the project has been honest enough about it that pretending otherwise would be lazy.

The idea is correct even if the number is not proven

Browser agents are good explorers and terrible repeaters. Ask an agent to pull your bookmarks from a site today, and it navigates, screenshots, reads the DOM, reasons about which element is the list, and extracts. Ask it again tomorrow and it does the identical work from zero. You are paying reasoning-model prices to rediscover a page layout that has not changed since yesterday.

Webcmd's answer is to promote knowledge up a ladder until the browser is no longer in the loop. The homepage calls it four layers.

Control is live browser work: inspect, click, type, extract, capture network calls in a real browser with structured feedback. This is the layer every browser agent already has.

Remember captures an agent-facing sitemap of observed pages, states, actions, workflows, APIs, pitfalls, and fallback paths. The agent stops rediscovering the shape of the site.

Author turns a verified workflow into a reusable site adapter with explicit arguments, a strategy tag, and consistent output.

Execute extends that adapter with tailored commands. webcmd hackernews top --limit 3 -f json instead of a browser session.

The concepts doc states the rule the agent follows in one line: "reuse what already exists before exploring." Load the webcmd-usage skill, look for an adapter that already satisfies the request, browse only when the surface is unfamiliar or broken, retain sitemap knowledge when it will help later, author or repair an adapter when the workflow should become repeatable.

That is a genuinely good design. It matches how a competent human automates a chore.

Where the 90% actually comes from

The modeled index on the homepage lists four rows for input tokens, normalized to a fresh browser replay at 100: sitemap-guided at 58, reusable adapter at 24, tailored command at 10. Agent turns per run go 9.0, 6.0, 2.0, 1.0 across the same four rows.

So the "90% lower token index" and "8x fewer agent turns" headlines compare layer four against layer one. Tailored command versus fresh browser replay, best case against worst case, by construction.

Two things follow, and both matter more than the percentage.

The first is that the baseline is a browser agent that caches nothing and re-derives everything on every run. If your stack already has any form of page memory, prompt caching, or hand-written scraper for the sites you hit most, your real delta shrinks, possibly a lot.

The second is the one the docs are blunt about. To reach layer four you have to author the adapter. From the authoring page: "A private plugin is the default for personal workflows; Webcmd core does not bundle site adapters." The concepts page says it again: "Site adapters are installed as plugins; the core package bundles none."

npm install -g @agentrhq/webcmd gives you the compiler. It does not give you anything compiled. The saving is the reward for work you do, not a property of the install, and the number on the homepage describes the state after that work is finished.

The part I found most interesting

Webcmd exposes five execution strategies, and the agent picks which one to use rather than the human. PUBLIC uses public pages or APIs with no browser. COOKIE uses a logged-in browser profile for authenticated requests. INTERCEPT captures request context from the browser and then replays a useful request directly. UI drives the live page. LOCAL talks to a local app or CLI.

INTERCEPT is where the interesting engineering lives. It is the difference between clicking through a page to reach data and learning what request the page fires, then firing that request yourself. It is also where adapters break most often, because it depends on internal endpoints that no site promises to keep stable. The docs include a whole workflow for this, and the verb they use is telling: heal. "Heal webcmd acme part ABC-123. It used to return price and stock, but now stock is null." The repair path exists because commands rot.

On the local side, PRIVACY.md is short and specific. The managed CloakBrowser runtime talks only to a local Webcmd daemon on localhost:9777. Trace artifacts, cache files, plugins, user adapters, and site memory live under ~/.webcmd. "Webcmd does not send browser data to AgentR. Commands run locally, and command output is printed to the local CLI process."

Put this into practice

The lowest-friction version of this takes about ten minutes to install and one working session to get a real answer.

1. Install. npm install -g @agentrhq/webcmd then webcmd skills add. You need Node 20.6.0 or newer; the npm package pins engines.node >= 20.6.0. Codex users can instead add the plugin marketplace agentrhq/webcmd and install Webcmd from there. Pick one path. The docs warn against installing both the Codex plugin and the standalone skill links.

2. Pick a workflow you genuinely repeat. Not a demo site. A dashboard, a supplier portal, a ticket queue, something you or your agent hit weekly. The whole value model depends on repetition, so a one-off task will show you nothing.

3. Run it once through raw browser control and write down two numbers. Input tokens and agent turns for that run. This is your baseline and it is the only honest one, because it is yours.

4. Have the agent author a private adapter. Name the command, name the JSON fields, and say explicitly that field names should stay stable. The docs are right that stable output keys are the contract other agents consume, and renaming them later breaks every caller.

5. Run the identical task through the command and compare. That ratio is your number. It will not be 90% and it does not need to be.

6. For login-gated sites, use a named profile. Create one, log in interactively once including any 2FA, and let the session persist. Do not hardcode credentials into an adapter.

If you want to skip the manual comparison, the repo ships its own evaluation harness. The package.json includes "benchmark": "uv run python benchmarks/scripts/run_eval.py", which means you can argue with the homepage number using the project's own tooling rather than a spreadsheet.

Honest limitations

The headline number is modeled, not observed, and the project labels it that way. Any writeup that quotes 90% without that sentence attached is misreading the source.

The core bundles no site adapters. Beyond a small number of community plugins, the adapters that produce the saving are yours to write and yours to maintain. Budget for that, because the "heal" workflow in the docs exists for a reason.

Installation brings a background daemon on port 9777 and a postinstall script. There is also a preuninstall hook that POSTs to 127.0.0.1:9777/shutdown on removal. None of that is alarming, all of it is normal for a tool of this shape, and you should know it is there before it appears in a lsof output at an awkward moment.

The COOKIE and INTERCEPT strategies mean an agent holding a live authenticated browser session and replaying requests derived from it. The privacy document says nothing leaves your machine, and I believe it, but "the agent has your logged-in session" is a decision you should make deliberately rather than discover.

Version skew is worth noting. The npm registry serves @agentrhq/webcmd at 0.7.4 while the website footer still reads v0.3.4. The npm release is Apache-2.0, ships 883 files at roughly 5.2 MB unpacked, carries an npm provenance attestation, and depends on playwright-core 1.61.1. Software moving faster than its own marketing page is a normal condition for a repo at this stage, and it is also a reminder that the docs you read this week may describe last month's behavior.

Finally, this is 0.x software with 22 open issues and 17 open pull requests. Adopt accordingly.

What is actually worth doing here

I keep coming back to the fact that the project published a placeholder and labeled it a placeholder. That is a small act of professional honesty that most repos at 1.2k stars would not bother with, and it earns more of my trust than the 90% would have on its own.

The thing worth doing is not deciding whether Webcmd's number is right. It is finding out whether the number applies to you at all. Nearly every team running browser agents at volume has never measured what fraction of a session goes to rediscovering an interface versus doing the task. Run one workflow twice, once raw and once through a command, and you will know something about your own stack that no vendor benchmark can tell you.

If you get a ratio that is nowhere near theirs in either direction, I would like to know what the workflow was.

Sources: agentrhq/webcmd on GitHub; Webcmd homepage and modeled benchmark; Webcmd docs, "How Webcmd Works"; Webcmd docs, "Create and Maintain CLIs"; Webcmd docs, "X to CLI"; webcmd PRIVACY.md; @agentrhq/webcmd on npm.