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.
This is not a versus post
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.
What Claude for Chrome is genuinely good at
Claude for Chrome drives your real, logged-in Chrome. That's the right design for a whole class of work:
- Exploration. "Open this dashboard and tell me what's on it." The page is new, the structure is unknown, you want the model to look and react. Interactive reasoning is exactly what you want here.
- One-off tasks. "Fill out this form once," "find the export button on this admin panel," "check whether this listing went through." You'll do it once and never again. Paying for one model pass is a rounding error.
- Anything that needs judgment mid-flow. "Reply to these, but skip anything that looks like a complaint." The decision has to happen live, on content the model is seeing for the first time.
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.
The seam: the task you do again
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:
- Every Monday's run spends model tokens re-deciding steps it already decided last Monday. Heavy users of Claude for Chrome notice this — browser tasks draw down your subscription limits faster than a normal chat, because each task is a full agent loop.
- The task only fires while Chrome is open and your machine is awake. A scheduled browser task is still, under the hood, "wake up and reason through it again."
- Saving the workflow helps, but what's saved is essentially a reusable prompt — the assistant still re-interprets it each run. The steps are remembered; the reasoning isn't compiled away.
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.
What Tap adds: compile the run, replay it for free
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:
- Replay costs zero LLM tokens. The plan is mechanical data. Running it doesn't call a model. Your Monday numbers-pull, run 2 through run 200, is free.
- It runs unattended, locally. A compiled plan can fire on a local schedule without waking an agent or holding a chat session open. No per-run reasoning to pay for or supervise.
- It carries its own check. Each plan can declare what "this actually worked" means (a value that must be present, a page that must say the right thing), so a silently-broken run surfaces as a real error instead of landing empty and looking fine.
- Credentials never leave your machine. Tap's extension reuses the session already in your real Chrome. Nothing crosses a trust boundary, by architecture.
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.
How they fit together
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:
- Explore interactively. Use Claude for Chrome (or Claude Code driving your browser) to get the task working once, live, with full reasoning. This is the part that needs a brain.
- Compile it. Once it works, capture the flow as a Tap plan. The agent that just did it also knows how to write it down as explicit steps — that's the compile.
- Replay for free. From then on, the plan runs deterministically at zero tokens, on a schedule if you want. The reasoning was paid for once, not every week.
You don't retire the assistant. You stop paying it to re-solve a solved problem.
How to pick, task by task
- Is this a one-time or exploratory task? → Interactive assistant. Don't bother compiling something you'll never run again.
- Does the task need fresh judgment on content each run? → Keep it interactive. The decision can't be compiled if it depends on what the page says today.
- Are the steps stable and will you run it repeatedly? → Get it working once interactively, then compile it into a Tap plan. Every run after the first is free.
- Do you want it to run on a schedule, unattended? → Tap. A compiled plan fires without waking an agent; an interactive task needs the session live.
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.
The honest boundaries
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.
Setup
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.
Top comments (0)