The dominant pattern in agentic browser automation is to re-run the model on every execution: read the page, ask what to do, act, repeat. It works, and the bill scales linearly with usage — the ten-thousandth run costs what the first did. This guide explains where that cost comes from, the four levers that bend it, and the break-even arithmetic that tells you when to stop re-reasoning.
Why does browser automation get more expensive at scale?
Two costs dominate: model tokens and browser time. Browser time you can optimize with asset blocking and shorter flows. The tokens are the trap — if every step feeds page context to a model and asks for the next action, one multi-step flow burns thousands of tokens every time it runs. Run it a thousand times and you pay that bill a thousand times.
Lever 1 — shrink what the model sees
Raw HTML is mostly noise to a planner. The page is compiled into an indexed map of just its interactive elements, capped to a token budget, so a page that would be tens of thousands of tokens of markup becomes a short list of the things you can act on. That is a large saving before any caching, and it is not optional — it is how every run works.
- Only interactive elements survive: buttons, links, inputs, roles and their labels.
- Actions address elements by index, so a class rename does not break a compiled path.
- A hard token budget means a huge page costs about what a small one costs to plan against.
Lever 2 — compile the flow once
A successful run is minimized into a skill: the retries and dead ends are dropped, and run-specific values are lifted into late-bound tokens. Replaying that skill makes no planner call at all. This is the biggest lever because it converts a recurring per-run model cost into a one-time compile cost — 50 credits to compile, 1 credit to replay.
Lever 3 — match re-phrased requests, not identical ones
Naive replay only helps when the exact same request repeats, and real agents phrase things differently every time. Dispatch embeds the request and matches it by meaning against your compiled skills for the same host, so "export the May invoices" and "download last month's bills" reach the same skill. A hit costs 2 credits against 10 for a cold compile — and the response tells you which happened.
curl -X POST https://twin-browser.com/api/v1/dispatch \
-H "Authorization: Bearer $TWIN_API_KEY" \
-H "content-type: application/json" \
-d '{
"url": "https://app.example.com/invoices",
"prompt": "download last month'"'"'s bills as PDF",
"success": { "kind": "urlIncludes", "value": "/invoices/export" }
}'
# {
# "mode": "cache-hit", // ← cache-hit | cache-adapt | cache-miss-compiled
# "skill": "export-invoices",
# "version": 3,
# "steps": 4,
# "credits_charged": 2
# }Lever 4 — start warm on flows someone already solved
Compiled paths that can be sanitized down to pure action structure are pooled across tenants. A first run on a widely-automated surface with no match of your own but a close shared one runs a seeded compile — replay the scaffold, explore the delta — for 5 credits instead of 10. Searching that pool (GET /api/v1/library?q=…) is free, and worth doing before you pay for a compile.
When does compiling pay for itself?
It is arithmetic, not a guess. Re-reasoning n runs costs n × the run floor. Compiling once and replaying costs the compile floor + n × the replay floor. Compiling wins once n × 10 > 50 + n × 1 — that is n > 50 ÷ 9, so from the sixth run of the same goal onward. Below that, just run it.
How do I know whether it is working?
GET /api/v1/cache/stats reduces a rolling window of your runs into per-mode counts, a hit rate of (hits + adapts) ÷ (hits + adapts + compiles), total credits charged and an estimate of the credits the cache saved. It is free and reserves nothing. A hit rate that will not climb usually means your agents are genuinely doing new things each time — which is worth knowing before you optimize the wrong half.