FAQ

Frequently asked questions

Everything about how Twin Browser works, what it costs, how to plug it into your stack, and where it’s built to run. Still stuck? The guides and docs go deeper.

Product & cost

What Twin is and why it’s cheaper

The wedge in plain terms — compile once, match semantically, replay free.

What is Twin Browser?
Twin Browser is the browser execution layer for LLM agents — a token-efficient browser API that turns a plain-English goal into deterministic, replayable action. It compiles a task once, matches re-phrased requests to it with a semantic dispatch cache, and replays deterministically with zero LLM calls.
How does Twin make browser automation cheaper?
Most browser infrastructure re-runs the LLM on every execution, so cost climbs with usage. Twin moves the LLM to the planning stage: the first run compiles a reusable skill, and subsequent similar runs hit a semantic cache and replay deterministically. A cache hit is roughly 5x cheaper, so the marginal cost per run trends toward zero the more your agents run.
What is the difference between a semantic cache and an exact-match cache?
An exact-match cache only helps when the identical action repeats — it is keyed on a selector or a parameter hash, so a re-worded request is a cold start. Twin embeds the request and matches by meaning, so "schedule a call" finds the skill compiled for "book a demo." That is why Twin keeps saving where exact-match caches fall back to a full LLM run.
What is deterministic replay?
When a goal succeeds, Twin freezes the action path into a skill keyed to the page structure. On a cache hit it replays that skill deterministically — the same indexed clicks and inputs — with no model call. It is production-ready, not a debug-only recording.
Is it safe that skills are shared across tenants?
The cross-tenant skill corpus reuses the structural action plan of a skill, not your data, credentials, or run inputs. Secrets stay in your per-tenant credential vault, the backend enforces default-deny row-level security, and every call is authenticated and audit-logged. The shared layer is the "how to operate this page" knowledge, which raises the cache-hit rate for everyone.
Platform & integrations

Connecting Twin to your stack

REST, MCP, LangChain, AutoGen — plus the vault, live view, and human handoff.

How do I connect Twin to my agent framework?
Three ways: the REST API under /api/v1/* with Bearer-key auth; the MCP server, which exposes the tools run, compile_skill, and run_skill to Cursor, Claude Desktop, Claude Code, and Cline; and native LangChain and AutoGen tool adapters. See the integrations pages for copy-paste snippets.
What does the MCP server expose?
The Twin MCP server exposes three tools: run (execute a goal on a URL), compile_skill (freeze a successful run into a reusable skill), and run_skill (replay a compiled skill). Any MCP client — Cursor, Claude Desktop, Claude Code, Cline — can drive the full pipeline without writing API glue.
How does authentication work for the REST API?
Every request carries a per-tenant API key as a Bearer token in the Authorization header. Keys are scoped to a tenant, and authentication, usage billing, and audit logging run on every call before any browser action is taken.
Does Twin store credentials?
Yes — in a per-tenant credential vault. A flow that needs to log in pulls secrets from the vault at run time rather than embedding them in the goal or your code. Vault contents are isolated per tenant under default-deny RLS.
Can a human step in mid-run?
Yes. A blocked step — an approval, or MFA on a flow you are authorized to run — triggers a human-in-the-loop handoff. The run pauses, surfaces the moment in the real-time live view, waits for the human, then resumes the skill where it left off.
Does Twin record sessions?
Every run streams a real-time live view and is recorded to durable session video, so you can watch a flow live or review exactly what happened afterward. Proxy support (IPRoyal) is available for runs that need it.
Pricing, trust & comparison

What it costs and where it runs

Usage credits, 1× LLM passthrough, default-deny security, and how Twin differs from the field.

How much does Twin cost?
Pricing is usage-based credits, free to start, with an entry plan from $29/mo. LLM cost is metered per call and passed through at 1x — no markup — with a transparent rate card published at /api/v1/pricing. Pay-as-you-go auto top-up keeps long-running agents from stalling.
Why is usage-based billing a good thing here?
Because Twin is built so usage gets cheaper. As your cache-hit rate rises, more runs replay deterministically at near-zero LLM cost, so your blended cost-per-1k-runs falls. A flat per-seat price would hide that; usage credits let the savings flow straight to you.
What is the authorization model?
Twin automates the web where you are authorized — first-party sites, operator-approved automation, internal RPA, accessibility, and authorized testing. The run target URL is the authorization signal, and auth, billing, and audit logging run on every call. Twin is not a CAPTCHA-bypass-for-hire or anti-bot evasion service.
How is Twin secured?
A multi-tenant Supabase backend with default-deny row-level security, per-tenant API keys, a credential vault, and an audit log on every call. Tenants are isolated by default; access is granted explicitly, never assumed.
How is Twin different from Browserbase, Browser Use, or Skyvern?
They are all good at running a browser, but their default loop re-runs the LLM (or caches only exact, single-workflow repeats), so cost stays flat or rises with usage. Twin adds a semantic dispatch cache that matches re-phrased requests and a cross-tenant skill corpus that compounds savings. See the side-by-side breakdowns on the compare pages.

Keep reading

Go deeper on the mechanism, the economics, and the integrations.

Ready to try it? Start free