There's a point in every serious agent or scraping pipeline where you stop asking "how do I get the data" and start asking a more expensive question: do I need a browser that remembers who I am, or do I just need the thing that browser would have fetched?
Anakin puts both options under the same API key. One is Browser Sessions. The other is Wire. They look related if you only read the marketing page. In practice they solve different problems, cost different amounts of money, and fail in completely different ways. Treating them as interchangeable is how you end up with slow, expensive agents that break for reasons that have nothing to do with the data you actually wanted.
The browser that stays logged in
A Browser Session is exactly what it sounds like: persistent authenticated state that survives across requests.
You log in once. Sometimes that means sitting in the dashboard and completing a normal login flow, including 2FA or a captcha. Sometimes it means connecting to the Browser API with Playwright, driving the login yourself, and passing ?save_session=<name> so the session saves when you disconnect. Either way, the cookies and localStorage are captured, encrypted with AES-256-GCM, and stored under a name or an ID.
From that point on, any scrape, crawl, monitor, or full browser script can say "use this session." The platform loads the saved state into a fresh browser before the work starts, and reuses the session's original exit IP on every load, so the site keeps seeing the same visitor. You don't re-authenticate on every call. The browser (or at least its storage) is the unit of work.
That buys you everything that only appears after you're "in":
- account-specific pricing
- dashboards behind login walls
- multi-step flows where the second page only makes sense because of what you did on the first
- anything that needs the site to treat you as a real logged-in user
It also means you inherit the cost and fragility of real browsers. Sessions expire. Cookies die. Anti-bot systems still care about fingerprints and behavior. Malicious bot traffic grew 124% between July 2025 and June 2026, nine times faster than human traffic, which is exactly the pressure that keeps fingerprinting and behavioral checks tightening. (DataDome 2026). You're paying for rendering and for the privilege of keeping state alive. That's fine when the alternative is not getting the data at all. It's a tax when the data was already available somewhere cleaner.
The call you just make
Wire is the opposite bet.
Almost every major site already has private APIs: the same XHR, GraphQL, and signed REST endpoints its own frontend uses. Wire builds on them. Wherever it can, an action calls those endpoints directly; where a site doesn't expose one, the action handles the rendering itself. Either way, Anakin maintains the action and exposes it as an ordinary REST call with documented parameters and a fixed output shape. You look up an action (or search by intent), send the params, and get structured JSON back. You never launch, drive, or babysit a browser, and there's no LLM in the runtime path deciding what to click next.
You submit a task with POST /v1/wire/task, get a job ID back, and collect the result by polling or through a webhook. Read-only actions can also run synchronously through POST /v1/wire-run, with no API key at all. Each action has a fixed credit cost, refunded automatically if the job fails, which is often dramatically cheaper than spinning up Chromium. When the site redesigns its frontend, Anakin patches the action. Your action_id doesn't change. The shape you get back stays the same.
curl -X POST https://api.anakin.io/v1/wire/task \
-H "Authorization: Bearer $ANAKIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"action_id": "amazon.search_products",
"params": { "query": "laptop" },
"credential_id": "cred_abc123"
}'
# 202 Accepted
{
"job_id": "wire_job_abc123",
"status": "pending",
"poll_url": "https://api.anakin.io/v1/wire/jobs/wire_job_abc123"
}
Auth, when it's required, is handled by named identities. You connect an account once: by signing in with a username and password, through a connected vault such as 1Password, or, for cookie-based sites, through the dashboard connect flow that captures the logged-in state. Later calls just pass a credential ID. The secret never comes back to you; the encrypted credential is applied at execution time. Most of the catalog doesn't need it at all: 929 of the 970 sites in Wire require no login.
Wire is a call you just make. The unit of work is an API call to a maintained action, not a browser instance that happens to be logged in.
Why the distinction matters more than it looks
People reach for browsers because browsers are general. You can always open a page, click around, and extract something. That generality is expensive. Every time you open a real browser you pay for rendering, anti-bot defense, session management, and the risk that the UI will change tomorrow. A realistic multi-step workflow, login included, runs $1.00 to $1.50 per completed call once that overhead is counted, well above the $0.12 to $0.24 floor for the bare browser session. (Supergood 2026)
Wire is narrower. It only works on sites that are in the catalog (970 of them as of October 2026) or ones you request: a build request generates, auto-tests, and publishes new actions, and refunds the credits if the build fails. In exchange you get something that feels like a normal API: fast, cheap, typed, and maintained by someone else. You stop caring about CSS selectors and start caring about the fields the action returns.
The practical decision usually collapses to two questions:
- Is the data (or the write) already available as a Wire action?
- Does the workflow actually require stateful interaction that no existing action covers?
If the answer to the first is yes, use Wire. If the answer to the second is yes, use a Browser Session (or the full Browser API on top of one). Everything else is usually a more expensive way of arriving at the same result.
They also compose cleanly. Capture a Browser Session once for a hard site that isn't in the catalog, and reuse it across scrapes, crawls, and monitors. For catalog sites that need a login, Wire's own connect flow captures the logged-in state as a credential, so catalog actions run authenticated without you running a browser. You keep state only where you need it and move to the network layer the moment an action exists.
The real difference
Browser Sessions keep state alive so a browser can continue acting as you. Wire takes the browser off your critical path and turns the site into a maintained API.
One is infrastructure you have to look after. The other is a remote procedure call. Most production systems end up needing both. The mistake is treating every authenticated need as a browser problem, or assuming every catalog site still requires a full render. Pick the layer that matches the actual bottleneck (state or structure) and the rest of the pipeline gets quieter.
Start with the Wire catalog to see if the action already exists, or capture a Browser Session for the sites that still need a real login.
Frequently Asked Questions
What's the difference between Browser Sessions and Wire?
Browser Sessions keep a logged-in browser's cookies and localStorage alive across requests, so a real browser can keep acting as you. Wire skips the browser and calls the site's own maintained API action directly, returning typed JSON with no browser or LLM deciding what to click.
Can Browser Sessions and Wire be used together?
Yes. They run under the same Anakin API key and compose cleanly: capture a Browser Session for a hard site that isn't in the Wire catalog yet, and use Wire for the sites it already covers. For catalog sites that still need a login, Wire's own connect flow captures that state as a credential, so no running browser is required.
Does Wire support sites that require a login?
Yes, through named identities. You connect an account once, by signing in directly, through a connected vault like 1Password, or through the dashboard's cookie-based connect flow, then pass a credential_id on later calls. Most of the catalog doesn't need this: 929 of Wire's 970 sites require no login at all.
Why does a Browser Session cost more than a Wire call?
A Browser Session pays for real browser overhead: rendering, anti-bot defense, and session management. A bare session floor runs $0.12 to $0.24 per call, and a realistic multi-step workflow with login runs $1.00 to $1.50 per completed call (Supergood, 2026). Wire charges a fixed, typically much lower credit cost per action, refunded automatically if the job fails.
What happens when a site Wire supports changes its frontend?
Anakin maintains the action on Wire's side. When a site redesigns, Anakin patches the underlying action - the action_id you call and the JSON shape you get back stay the same, so the integration doesn't break.
What if the site I need isn't in the Wire catalog yet?
Submit a build request. Wire auto-tests and publishes the new action, and refunds the credits if the build fails. Until it's ready, capture a Browser Session for that site directly.