Lexicon

The vocabulary the docs, the dashboard, and the API responses all share — what a dispatch verdict means, how a skill differs from a brick, what parks a run, and what you're actually charged. Every entry is anchor-linkable.

Runs and how you steer them

The words that describe a single unit of browser work — from launch to a paused 2FA wall.

Run: One authorized browser task: a URL (the authorization signal), a natural-language prompt, and a structured success condition the engine must satisfy. POST /api/v1/run is synchronous and returns the verified action path plus exactly what was charged.Develop · first run →
Success condition: The structured predicate a run must satisfy to count as done — one of urlIncludes, textVisible, statusText, extracted, or allOf/anyOf combinations. Success is checked by the engine, never assumed.
Dispatch: The same body as /run, fronted by the semantic cache: your request is vector-matched against the skills already compiled for that host before any live planning. Default to dispatch for anything you will ask twice.Develop · dispatch vs. run →
Job: A run submitted asynchronously: POST /api/v1/jobs returns 202 with a jobId — poll it, stream SSE status frames, or receive an HMAC-signed completion webhook. Cancelling refunds the reserved credits.
Live view: The Server-Sent-Events screencast of a running browser — /api/v1/live streams JPEG frames while the run executes, and POST /runs/{id}/input lets you click, fill, and scroll it yourself mid-run.
HITL / parked run: Human-in-the-loop. A sign-in run that hits a 2FA or approval wall parks instead of failing: resume it with POST /runs/{id}/resume and a code, drive the browser through the live view, or hand the sign-in to your end-user with a connect link. Set hitl:false to opt out.
Mode: A console entry point on the dashboard Home — Agent (the live agent), Search, Scrape, Map, Crawl, Screenshot, Capture login, or Monitor. Each mode maps to one API surface, so anything you do in the console you can also do from code.

How work compounds

The cache vocabulary — what a verdict means, and the reusable assets behind it.

Semantic cache: The per-host store of compiled skills, matched by embedding rather than exact text — a re-phrased request still finds the skill. Every dispatch gets a verdict: HIT, ADAPT, or MISS.Skills & cache →
HIT: Cache verdict: your request matched an already-compiled skill for that host — deterministic blind replay of the verified path, no LLM in the loop (~2 credits).
ADAPT: Cache verdict: a near-match — an existing skill (possibly from the sanitized cross-tenant corpus) is adapted to your request instead of planned from scratch. Cheaper than a MISS; you always replay your own skills, and only ever adapt others'.
MISS: Cache verdict: nothing matched — live discovery plans the path, then the result is compiled and cached with its embedding so the next similar request is a HIT (~10 credits).
Skill: A compiled, versioned, replayable action path bound to a site. Replaying one is deterministic — no LLM, about 1 credit. Compile explicitly (POST /api/v1/skills) or implicitly through dispatch; your skills live in the dashboard Library.
Brick: The per-action reusable unit inside a skill — one named action with its parameter contract. The Library's registry groups bricks by brand, and the agent composes them automatically when a goal matches.
Template: A per-host extraction recipe (or a generic JSON-LD / OpenGraph reader) that returns structured data deterministically — zero LLM, zero metered cost. GET /api/v1/templates lists them; /extract uses one automatically when it matches.
Teach mode: Demonstrate a flow once in the dashboard console — a macro recorder captures your actions — and it becomes a named skill you can replay forever. Pick Teach a skill in the console's mode menu.

Logins without holding passwords

Everything about how runs authenticate — and what Twin does and does not store.

Connected session: A captured, encrypted browser session (the cookie jar) reused by later runs so they skip sign-in entirely — the response then carries sessionRestored: true. Managed under Keys & secrets → Sessions; forgetting one just means the next run re-authenticates.
Connect link: A one-time hosted URL (POST /api/v1/connect/sessions) your end-user opens to sign in by hand — password, 2FA, CAPTCHA — inside a Twin-hosted browser. The session is captured; the password is never stored. OAuth-shaped, for sites without OAuth.Develop · end-user logins →
Capture extension: A browser extension that ships a session from your own local browser — for popup-OAuth sign-ins (“Continue with Google”) that only complete there. It POSTs to /api/v1/sessions/import: cookies only, never a password.Extension setup →
Login account: A saved email+password for one website, encrypted, with a label — you can hold several per site. Pass the label as account on any run and that login and its saved session apply.
Secret: An encrypted, write-only value a run references as {{secret:NAME}} — saved automatically at sign-in (or added manually) and redacted from every log and stream. The value never leaves the vault except at fill-time inside the browser.
2FA autofill: A connected email inbox (Google/Microsoft OAuth, or IMAP with an app password) or your own Twilio number that a run reads a verification code from — so 2FA logins finish without a human. Configured under Keys & secrets → 2FA autofill.

Beyond one-shot runs

The request shapes that return data rather than drive a flow — and the ones that keep running.

Extract / scrape: POST /api/v1/extract reads one page and returns JSON matching the fields or schema you ask for (~5-credit floor). When a template matches, extraction is deterministic and free of metered cost.
Crawl & Map: Map discovers every URL on a site in one call; Crawl walks a whole site in the background as an async job, charged per page. Both take a start URL and respect a page budget.
Monitor: A standing watch on a page: the platform cron re-checks it on your cadence and POSTs to your callback URL when it changes. Check types: extract, observe, or a named skill. Your monitors are listed on the dashboard Home.
ETL: The extract → chunk → embed → load pipeline as one API: scrape a page into a named, semantically-queryable collection (POST /api/v1/etl, then query it). The console's Scrape mode with Store & make searchable is the same thing.
Recording: An opt-in video of a run, stored durably against a plan-tiered storage cap (over the cap, runs still execute — they just skip recording). Replayable under History → Recordings or GET /runs/{id}/video.

Who pays, and for what

The metering vocabulary behind every response's credits_charged.

Credit: The metering unit. Every action has a flat floor (run ~10, dispatch HIT ~2, skill replay ~1, extract ~5) plus metered passthrough, and every response states credits_charged. Prepaid, with optional auto top-up.
Rate card: The live table of per-action credit floors and per-model passthrough rates — the same numbers your Billing tab bills against, rendered on Develop and machine-readable at GET /api/v1/pricing.
Tenant & subtenant: A tenant is the workspace — keys, credits, skills, sessions, and the audit log are all scoped to it, and the tenant is always derived from the key, never from the request body. Resellers provision child tenants (subtenants) via POST /api/v1/tenants, each with its own billing mode and scoped keys.