Skip to main content
Deterministic rerun lets you run a task once with the full agent, save the learned workflow as a Python script, then rerun that script with new parameters. Cache hits skip the full agent and can drop LLM cost to zero when the script succeeds without auto-healing or explicit LLM calls. The cached script still fetches the website or API again. It does not replay the first run’s output, so updated page/API content is reflected on reruns.

Quick start

Use @{{double brackets}} around values that can change between runs. The first call runs the full agent and creates a script in your workspace. Every subsequent call with the same template runs that script with the new parameter values.
On the cached run, result2.output comes from a new request to httpbin.org with item=beta. In live testing this path returned 0 input tokens, 0 output tokens, and llmCostUsd: 0.

How it works

1

You send a task with @{{brackets}}

The brackets mark which parts are parameters:
  • @{{example.com}} → parameter 1
  • @{{electronics}} → parameter 2
The system strips the values to create a template: "Get prices from @{{}} for @{{}}".
2

System hashes the template

Template "Get prices from @{{}} for @{{}}" is normalized, hashed, and stored as a 16-character script filename like scripts/a7f3b2c19d4e8f01.py.The cache key ignores parameter values. It is based on the template after values are replaced with @{{}}, whitespace is collapsed, and the template is lowercased.
3

Cache miss → agent creates script

If no script exists, the full agent runs your task. After completing it, the agent saves a standalone Python script that can reproduce the workflow with new parameters.
4

Cache hit → script executes directly

If the script exists, it runs directly with the new parameter values. This skips the full browser agent. The script can use a browser, or it can use Browser Use’s fetch helper for direct HTTP requests when a browser is unnecessary.
Keep each @{{...}} value on one line, and do not put }} inside a parameter value. Changing only parameter values reuses the script; changing the wording or the number/order of parameters creates a different script.

Auto-detection

Caching activates automatically when both conditions are met:
  • The task contains @{{ and }}
  • A workspace_id is provided
No extra flags needed. You can override with cache_script:
cacheScript applies to create-and-run calls. Follow-up dispatches to an existing sessionId currently run as normal agent tasks, even if the task contains @{{...}}.

Examples

Parameterized scraping

Run once, then loop over different keywords. Cache hits skip the full agent:

Fresh content on rerun

The cached script fetches the source again. It is useful for extraction jobs where the target page or API changes over time.
For browser-required pages, parameterize the URL or search terms:
The second run returns content from the new URL, not a replay of the first page.

No parameters — cache the exact task

Append empty brackets @{{}} to signal “cache this exact task”:

Multiple parameters

Force enable / disable

Inspecting cached scripts

You can download and inspect the scripts the agent created:

Auto-healing

Cached scripts can break when a website changes its layout, adds new elements, or alters its structure. Auto-healing detects these failures and automatically regenerates the script.

How it works

When a cached script runs, the system validates its output:
  1. Fast checks (no LLM) — detects empty results, error fields in JSON, or exception keywords in output.
  2. LLM judge — if fast checks pass, a lightweight model validates whether the output looks correct for the original task.
  3. Heal — if validation fails, the full agent re-runs the task and saves an updated script.
Auto-healing is limited to 1 attempt per run to prevent runaway costs. If the healed script also fails, the output is returned as-is.

Disable auto-healing

If you want the cached path to return the raw script output and avoid validation/healing LLM calls, disable auto-healing:

Cost impact

Auto-healing is enabled by default for all cached scripts.

Browser, fetch, and recordings

Cached scripts do not always use a browser. During the first run, the agent may discover that the fastest reliable implementation is a direct HTTP request with Browser Use’s fetch helper instead of browser navigation. That is expected for JSON APIs and many data-extraction tasks. If you pass enableRecording: true, recordingUrls are returned only when a browser session actually records and the MP4 is ready. Direct-HTTP cached runs may have no recording because there was no useful browser interaction to record. On cache hits, isTaskSuccessful can be null even when status is stopped and output is correct, because the full agent success judge was skipped. For deterministic reruns, treat the returned output and your own validation/schema checks as the source of truth.

Cost comparison

Cached calls can still have small infrastructure cost. If the script uses direct HTTP only, there may be no browser recording even with recording enabled.