CAPABILITY · CACHE

A cache that matches what you meant, not what you typed

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.

POST /api/v1/dispatch → { "mode": "cache-hit" }

Capability

Inside semantic dispatch cache

Most browser infrastructure re-runs the model on every execution, so cost scales linearly with usage. Dispatch does not. It embeds the incoming request, vector-matches it against this tenant's compiled skills for the same host, gates the best candidate on true intent, and then forks: a hit blind-replays the cached action path with no model in the loop, a miss runs live discovery and caches the verified path so the next similar request is a hit.

Meaning, not string match

The request is embedded and compared by cosine similarity against skill embeddings for the same host, so "export the May invoices" and "download last month's bills" reach the same compiled skill.

An intent gate above the vector match

A near-match is not trusted on distance alone: below the decisive threshold, a model call gates whether the candidate really means the same thing. Above it, the match is taken with no gate call at all.

Three outcomes, all priced differently

A hit replays for 2 credits, a cross-tenant adapt (a shared scaffold plus the delta) for 5, and a genuine miss compiles for 10 — the same as an uncached run.

The response says which happened

Every dispatch returns a `mode` field — cache-hit, cache-adapt or cache-miss-compiled — plus the skill name, its version, the action path and credits_charged. Provenance is in the body, not a header.

How it works

The mechanism, in execution order

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

SEMANTIC DISPATCH“book the 9am”“reserve the morning”same intent, different wordsembed→ vectorcheckout.flowexport.flowbook-slot@v30.94 · over thresholdhitmissDeterministic replay0 LLM calls · ~5× cheaperCold run · compilethe planner runs oncethe new skill goes into the library
  1. 1Embed the requestThe goal text (the `prompt` of an ad-hoc call, or the `goal` of a named one) is embedded into the dispatch space.
  2. 2Match on hostThe top candidates among this tenant's compiled skills for the SAME host are retrieved by vector similarity.
  3. 3Gate on intentA decisive cosine score is taken as a hit outright; a merely-close one is confirmed by an intent-match model call before it is trusted.
  4. 4Replay, adapt or compileA hit blind-replays the stored path. No tenant match but a close shared one adapts it. Nothing close enough runs live discovery, minimizes the result, and stores it with its embedding for next time.

In practice

A call you can paste and run

A re-phrased goal matches a skill compiled from a different wording — mode: "cache-hit", 2 credits, no planner call.

dispatch.shbash
curl -X POST https://twin-browser.com/api/v1/dispatch \
  -H "Authorization: Bearer $TWIN_API_KEY" \
  -H "content-type: application/json" \
  -d '{"url":"https://app.example.com/invoices",
      "prompt":"download the invoices for the previous month as PDF",
      "success":{"kind":"urlIncludes","value":"/invoices/export"}}'

# {
#   "mode": "cache-hit",
#   "skill": "export-invoices",
#   "version": 3,
#   "success": true,
#   "steps": 4,
#   "path": [ /* the replayed actions */ ],
#   "runId": "…",
#   "credits_charged": 2
# }
api.twin-browser.com
  1. Embed the requestdone
  2. Match on hostrunning
  3. Gate on intentqueued
  4. Replay, adapt or compilequeued

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.

2 credits on a hit · 10 on a miss

Dispatch reserves the worst case (10) and settles down to what actually happened: 2 for a deterministic hit, 5 for a cross-tenant adapt, 10 for a compile. Every figure is a FLOOR — the settle is higher-of(floor, metered model + compute + egress) — so a hit that made no model call bills the floor and a long compile bills what it consumed. A failed replay or failed discovery is refunded.

Full rate card

Turning it on

  1. 1Nothing to switch onDispatch is a public endpoint on every plan. There is no flag and no per-tenant enablement step.
  2. 2Point your agent at /dispatch instead of /runThe body is identical — { url, prompt, success } for free text, { target, goal } for a registry goal. Only the caching behaviour differs.
  3. 3Let the first call missThe first request for a new intent compiles and stores a skill with its embedding. That miss is what makes the next one a hit.
  4. 4Watch the hit rateGET /api/v1/cache/stats returns per-mode counts, a hit_rate and estimated_credits_saved over a rolling window. It is free and does not reserve credits.

At a glance

The contract, in the fewest rows that say it

PropertyTwin Browser
EndpointPOST /api/v1/dispatch
Match basisEmbedding similarity, scoped to the host
ConfirmationIntent-match model call below the decisive score
ScopeYour tenant, then the shared corpus
Outcomescache-hit · cache-adapt · cache-miss-compiled
Provenance`mode` + `skill` + `version` in the response body

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

  • Matching is scoped to the HOST. A skill compiled on app.example.com is never offered for a goal on example.org.
  • The cache is per tenant for your own skills; only the sanitized cross-tenant corpus crosses that boundary, and only as an adapt.
  • A named `goal` must be a registry identifier (login, search, extract, reply, like). Free text belongs in `prompt` with an explicit `success` condition.
  • A hit still opens a real browser and executes the path — it skips the planner, not the browser.

What it does not do

  • It does not cache RESPONSES. There is no stored answer to hand back; a hit re-executes the compiled path against the live page, so the data you get is current.
  • It does not expose a tunable similarity threshold as a request parameter. The decisive and floor scores are server-side constants, not per-call knobs.
  • It does not set any x-twin-* response header. Cache provenance is the `mode` field in the JSON body.
  • It does not guarantee a hit for a semantically similar goal on a page that has structurally changed — a replay that fails returns mode: "cache-hit-failed" rather than silently re-planning.

FAQ

Questions about semantic dispatch cache

How is this different from a normal response cache?
A response cache keys on an exact request and returns stored bytes. Dispatch keys on the MEANING of the request and returns a fresh execution: it matches your goal to a compiled action path and replays that path against the live page. You get current data, without paying a planner to re-derive how to get it.
What happens on a cache miss?
The call runs live discovery, minimizes the successful trace into a skill, embeds its intent and stores both — so the miss pays for itself by making the next similar request a 2-credit hit. The response is mode: "cache-miss-compiled" and carries the new skill name and version.
How do I tell a hit from a miss?
Read the `mode` field of the JSON response: cache-hit, cache-adapt, cache-miss-compiled, or one of the failure modes. There is no response header to read — the routes set content-type and nothing else.
Can I measure what the cache is saving me?
Yes. GET /api/v1/cache/stats reduces a rolling window of your runs into per-mode counts, a hit_rate of (skill + adapt) / (skill + adapt + compile), total credits_charged, and estimated_credits_saved versus cold compiles. It is free and read-only.

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.