CAPABILITY · STEALTH

For a run that is actually being turned away

A full desktop browser profile — real Chrome, human-calibrated timing, residential egress — behind a plan gate and an explicit authorization attestation, billed per success.

"stealth": true, "authorized": true

Capability

Inside stealth tier

Most runs do not need this, and the honest version of this page says so first. Stealth is for the case where an authorized run is being refused by a bot check — not a default posture. It is gated twice before any credit is reserved: a Pro or Enterprise plan, and an explicit attestation that you are authorized to access the target. If no stealth fleet is configured for the deployment, the request fails closed rather than running honestly and billing as premium.

A real desktop profile

Real Chrome with human-calibrated pointer, keystroke and step timing, and residential egress — rather than a headless browser with the timing of a machine.

Two gates, both before the reserve

A Pro or Enterprise plan (else 403 with code "plan_required") and authorized: true (else 400). A rejected stealth request costs nothing because nothing was reserved.

The attestation is the record

authorized: true is recorded against the run as a durable authorization artefact. It is your assertion, not an inferred one — and if you are acting for someone else, it is theirs to make.

Not the answer to every wall

A CHALLENGE the standard fleet could not clear is worth retrying on stealth. A reputation SCORE wall is not — no client-side lever reliably passes one, so that case routes to a human connect handoff instead.

How it works

The mechanism, in execution order

4 stages, in the order the runtime performs them — not a summary of them.

WHEN A SITE TURNS AN AGENT AWAYStandard runbot checkstealth: truedesktop profile · residentialPro + authorized: trueScore wallstealth won't pass itRun proceedsauthorized workConnect linka person, onceescalate only when a run is actually being turned away
  1. 1Try without itRun normally. Most targets do not challenge, and stealth costs more per success.
  2. 2Read the blockA blocked run names the vendor and classifies the wall. A challenge that did not clear is retryable on stealth; a score wall is not.
  3. 3Attest and retryRe-submit with stealth: true and authorized: true. The plan gate and the attestation are checked before anything is reserved.
  4. 4Or hand offOn a score wall the run returns code: "connect_required" with a ready connectUrl — a human sign-in carries trust that no fingerprint does.

In practice

A call you can paste and run

Both gates run before any credit is reserved, so a refused stealth request is free.

stealth.shbash
curl -X POST https://twin-browser.com/api/v1/run \
  -H "Authorization: Bearer $TWIN_API_KEY" \
  -H "content-type: application/json" \
  -d '{"url":"https://guarded.example.com/dashboard",
      "prompt":"open the account page and export the statement",
      "success":{"kind":"extracted"},
      "stealth":true,
      "authorized":true}'

# 403 { "error":"stealth is a premium tier …", "code":"plan_required", "plan":"free" }
# 400 when "authorized" is missing — the attestation is required, not inferred.
# 501 when no stealth fleet is configured — it fails closed rather than
#     running honestly and billing you as premium.
api.twin-browser.com
  1. Try without itdone
  2. Read the blockrunning
  3. Attest and retryqueued
  4. Or hand offqueued

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.

Run price plus a per-success surcharge

A stealth run bills like any other run — higher-of(10-credit floor, metered model + compute + egress) — plus a surcharge applied only on SUCCESS. The surcharge is a deployment setting rather than a published rate-card line, so read it from your own usage rather than from a number on a marketing page. A stealth run that fails is not surcharged, and a request rejected by either gate is never reserved at all.

Full rate card

Turning it on

  1. 1Be on a Pro or Enterprise planThe gate is enforced on the stealth path itself, so /run with stealth and the deprecated /agent alias behave identically.
  2. 2Send the attestationauthorized: true, from the party actually entitled to access the target.
  3. 3Use it as a retry, not a defaultReach for it when a run is refused. On a normal target it adds cost without adding capability.
  4. 4Know when to stopIf the response is code: "connect_required", stealth is not the answer — hand the connectUrl to a human.

At a glance

The contract, in the fewest rows that say it

PropertyTwin Browser
Request`stealth: true` + `authorized: true`
Plan gatePro / Enterprise (else 403 plan_required)
Missing attestation400
No fleet configured501 — fails closed
BillingRun floor + a per-SUCCESS surcharge
Deprecated aliasPOST /api/v1/agent

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

  • Pro or Enterprise only. A free or starter tenant gets 403 with code "plan_required".
  • authorized: true is required and is not inferred from anything else in the request.
  • If the deployment has no stealth fleet, the request answers 501 rather than silently downgrading.
  • The surcharge applies per success, so a flow that succeeds often is where the cost shows up.

What it does not do

  • It does not clear a reputation score wall. reCAPTCHA Enterprise, DataDome, PerimeterX, Kasada, Akamai and Imperva score walls are not passed by a better fingerprint — that case is a human handoff.
  • It does not authorize anything. The attestation records your claim; it does not grant a right you did not have.
  • It does not run silently when unavailable. No fleet means 501, not an honest run billed as premium.
  • It is not the default and should not be. Most authorized work runs fine without it.

FAQ

Questions about stealth tier

Should I turn stealth on for everything?
No. It costs more per success and adds nothing on a target that was not challenging you. Use it as a retry after a run has actually been turned away.
Why does it need an explicit attestation?
Because the product's ordinary model is that the target URL is the authorization signal, and stealth is the case where that deserves to be explicit. authorized: true is recorded against the run as a durable artefact. If you are acting on someone else's behalf, ask them first.
What if stealth does not get me through?
Then the wall is probably a score wall, and no client-side posture passes one. The run returns code: "connect_required" with a ready connectUrl — a real person signs in once, and every later run restores that session.
What happens if the stealth fleet is not deployed?
The request returns 501 and is not billed. It fails closed on purpose: running an honest browser and charging premium rates for it would be the worse outcome.

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.