CAPABILITY · REPLAY
Compile a task once, replay it with zero model calls
A successful run is minimized into a named, versioned skill — an ordered action path with its variable parts lifted out — and replaying it is a program, not a prompt.
POST /api/v1/skills/{name}/runCapability
Inside deterministic replay
When the planner solves a task, the engine keeps the exact sequence of actions that worked and minimizes it: dead ends and retries are dropped, and the values that were specific to that one run are lifted out into late-bound tokens. What is left is a skill. Replaying it is deterministic execution against the live DOM — no planning call, a flat floor price, and the same steps every time.
No model in the loop
A replay is a blind execution of the stored path. There is no observe-plan-act cycle and no token bill, which is why the floor is 1 credit against 10 for a planned run.
Three kinds of late binding
A stored path can carry {{secret:NAME}} (resolved from the vault inside the browser at fill time), {{var:NAME}} (a per-tenant entity value, auto-captured), and {{param:NAME}} (a call argument you supply). A skill is only account-independent when all three are late-bound.
It refuses to run half-bound
If a token is still unresolved at call time the replay is rejected before it opens a browser, naming the parameter it wanted — instead of silently re-posting whatever literal the compile run happened to type.
Versioned, and pinnable
Every compile upserts a version on a stable skill name. You call a name; the run records the version that executed, so an audit can say exactly which program ran.
How it works
The mechanism, in execution order
4 stages, in the order the runtime performs them — not a summary of them.
- 1Solve onceA planned run (POST /run, or a dispatch miss) completes the goal on a live page and records every action.
- 2MinimizeThe engine drops the retries and dead ends, keeping the shortest path that reproduces the result.
- 3ParameterizeValues specific to that run become tokens: credentials as {{secret:NAME}}, tenant entities as {{var:NAME}}, call arguments as {{param:NAME}}.
- 4ReplayPOST /api/v1/skills/{name}/run with a target and any params. Unresolved tokens are refused; resolved ones are substituted and the path is executed straight through.
In practice
A call you can paste and run
A compiled skill is invoked by NAME with call-time params — four steps, no planner, a 1-credit floor.
curl -X POST https://twin-browser.com/api/v1/skills/export-invoices/run \
-H "Authorization: Bearer $TWIN_API_KEY" \
-H "content-type: application/json" \
-d '{"target":"https://app.example.com/invoices",
"params":{"month":"2026-05"}}'
# {
# "success": true,
# "steps": 4,
# "path": [ /* the executed actions, secret values redacted */ ],
# "runId": "…",
# "credits_charged": 1
# }- Solve oncedone
- Minimizerunning
- Parameterizequeued
- Replayqueued
What it costs, how to switch it on
Priced from the same rate card the API serves
Every credit figure on this page is read from the rate card behind GET /api/v1/pricing — it is not typed into the copy, so it cannot drift from what you are billed.
1 credit per replay
A replay bills a flat 1-credit floor. Compiling the skill that makes replay possible costs 50 credits once (POST /api/v1/skills). Against a planned run at 10 credits, compiling pays for itself at 6 runs of the same goal — that break-even is arithmetic over the rate card, not an estimate. A failed replay is refunded.
Turning it on
- 1Compile the flowPOST /api/v1/skills with { target, goal, as } for a registry goal, or { url, prompt, success, as } for free text. `as` names the skill.
- 2Check the contractGET /api/v1/catalog lists each compiled skill with the params it expects, the secrets it fills, and whether your stored auth is ready for its host.
- 3Replay by namePOST /api/v1/skills/{name}/run with a target and the params from the catalog.
- 4Or skip the namePOST /api/v1/dispatch with the goal in words and let the semantic cache pick the skill for you.
At a glance
The contract, in the fewest rows that say it
| Property | Twin Browser |
|---|---|
| Endpoint | POST /api/v1/skills/{name}/run |
| Required body | `target` (the authorized URL) |
| Call arguments | `params` → {{param:NAME}} / {name} |
| Addressed by | Skill NAME, not an id |
| Planner calls | None |
| Versioning | Stable name, upserted version |
Limits
Where it stops, and what it deliberately does not do
A capabilities page with no limits section is a brochure. These are the ceilings, the defaults that will surprise you, and the things this capability is not.
Limits and defaults
- A replay needs a `target` on every call — the skill stores the path, not the authorization to run it.
- Params are substituted literally into the stored path. A param value may not smuggle a {{secret:…}} or {{var:…}} token; those are resolved server-side only.
- A skill is compiled against one host. It is not portable to a different site that happens to look similar.
- A replay that no longer matches the page returns a failure rather than falling back to the planner — re-compile, or dispatch the goal so a miss recompiles it for you.
What it does not do
- It does not plan. A replay cannot improvise around an unexpected interstitial; that is the whole point, and it is why it is cheap.
- It does not take an `id`. The path parameter is the skill NAME you compiled it under.
- It does not return a token count you can budget against, because it makes no model call to count.
- It does not silently substitute a stale literal for a missing argument — an unresolved token is a refusal, before any credit is spent.
FAQ
Questions about deterministic replay
What is the difference between a run and a skill?
Is replay really zero model cost?
What if the website changes?
How do I pass different arguments each time?
Keep reading
The rest of the platform
The capabilities this one works with, the tools that expose it, the guides that use it end to end, and the vocabulary behind it.
Skill library & catalog
Every compiled skill is stored per tenant with a version and a run contract — the params it takes, the secrets it fills, and whether your stored auth is ready for its host.
Semantic dispatch cache
A re-phrased request is embedded, vector-matched against the skills you have already compiled, and replayed deterministically — so the second ask and every one after it skips the planner.
Cross-tenant skill corpus
Compiled paths are sanitized down to their action structure and pooled, so a first run on a widely-automated surface can start from a shared scaffold instead of a cold compile.
Tools that expose it
Related reading
Put your agent to work. Keep the decision.
Start free. Hand your agent a goal on a site you authorize, set the guardrails, and let the first successful run compile the skill every run after it replays.