TL;DR. Claude for Chrome is a genuinely good interactive browser assistant — it explores a page, fills a form, handles a one-off task in your own logged-in Chrome. But it reasons through the task every time it runs, which means a chore you repeat every week keeps spending model tokens on every run and needs your machine awake to fire. Tap is the other half: once you've gotten a browser flow working, Tap compiles it into a .tap.json
plan that replays deterministically at zero LLM tokens, on a local schedule. They're two MCP servers in the same Claude Code. Claude for Chrome is the hand that figures it out the first time; Tap is the muscle memory that does it for free forever after.
Most "X vs Y" browser-automation comparisons pit tools trying to do the same job. This isn't that. Claude for Chrome and Tap live in the same Claude Code session, as two separate MCP servers, and they're good at two different phases of the same work. If you're using one, the other is probably the missing half — not the replacement.
So let's be fair to each.
Claude for Chrome drives your real, logged-in Chrome. That's the right design for a whole class of work:
For all of that, an assistant that thinks its way through the page in your own browser session is the correct tool. Tap does not try to be that assistant.
Here's where a real gap opens, and it's not a flaw in Claude for Chrome — it's a consequence of what it is. An interactive assistant reasons through the task on every run, because that's how it stays adaptive. That's great the first time. It's expensive the fiftieth time.
Consider a genuinely boring, genuinely real chore: every Monday, log into three dashboards and pull this week's numbers into a note. The steps never change. But run it through a reasoning assistant and:
None of that is Claude for Chrome doing something wrong. It's an interactive assistant behaving like an interactive assistant. It just means the repeat case wants a different shape.
Tap's whole premise is that a browser flow you've already gotten working is a thing you should be able to compile, not re-derive. The first successful run — done however you like, including by an interactive assistant — becomes a .tap.json
plan: a small, explicit list of steps. After that:
What Tap deliberately does not do is be the thing that figures the task out in the first place. It has no model of its own. The intelligence lives in the connected agent at compile time — which is exactly where Claude for Chrome, or Claude Code itself, comes in.
Because both are MCP servers inside Claude Code, they compose in one session. The natural division of labor:
Claude for Chrome is the hand that works it out. Tap is the muscle memory that repeats it for free.
The flow looks like:
You don't retire the assistant. You stop paying it to re-solve a solved problem.
Most real workloads are a mix: an exploratory phase that's genuinely interactive, sitting on top of a repetitive core that shouldn't be. Use each tool for the phase it fits.
Two things Tap is not, so this stays fair:
Compiling only pays off if you repeat. Turning a run into a plan costs one interactive pass up front. For a task you'll run twice, that's not worth it — just do it interactively both times. Tap earns its keep on the flows you run weekly, daily, or on a trigger. The economics are the point: the first run is the expensive one, and Tap only makes sense when you amortize it.
Tap runs where your browser runs. It's local by design — the session lives in your real Chrome on your real machine. If you need cloud-scale orchestration spinning up dozens of parallel headless sessions, that's a different tool's job. Tap is for the "automate the things I already do, in the browser I already use" cohort.
Tap installs as an MCP server alongside whatever else you have in Claude Code:
/plugin marketplace add LeonTing1010/taprun
/plugin install tap@taprun
All features are free during v0.x. Once installed, Tap exposes four meta verbs (capture
/ verify
/ mark
/ run
) plus every saved plan as a callable resource. AI participates only at capture
time; replay is mechanical and token-free.
Then the workflow is the one above: let the interactive assistant get a browser task working, and when you notice you're about to do the same thing again next week — compile it, and stop paying for the repeat.
Originally published at taprun.dev.