How Web Tasks work

This page explains what happens when you call the Web Tasks API: how the agent decides between AI and code, how reuseKey evolves over time, and the rules that govern concurrent runs.

Execution model

When you submit a task, Intuned spins up a browser on managed infrastructure, then runs an agent that mixes AI exploration with generated code.

Submit task → load reusable code (if reuseKey)
            → agent explores / runs code
            → write or refine code (if reuseKey)
            → return result

Load: if you provided a reuseKey, the system loads any code previously saved under that key. If you didn’t, the server mints a fresh wtr_-prefixed key and uses it for this run; the key comes back in reuse.key so you can reuse the same automation on later calls.
Execute: the agent runs the task. If saved code exists and works, it is used directly. Otherwise the AI explores the site, decides which parts of the task benefit from being code, and writes that code as it goes.
Save: on success, the improved code is saved under the key (whether you provided it or the server generated it). On failure, the previous code is left untouched so a bad run can’t poison a working automation.
Return: the result is returned inline or as a file, along with reuse, cost, and timing metadata.

The first run for a new key is the “figuring it out” run: slower, more expensive, AI-heavy. Subsequent runs mostly execute saved code, making them fast, cheap, and consistent. The same applies when the site changes: the AI repairs the code, the next run is back to fast and cheap.

Rejection

Before the agent starts, the system checks if the task is eligible for Web Tasks. If not, the request is rejected. Common reasons for rejection include:

Illegal activity, harassment, targeted harm and other violations of our Terms of Service.
Tasks that are not web automation (for example, “Write a poem about the sea”).
Tasks that are impossible, incoherent or self-contradictory.

Model selection

Every run uses an Anthropic model, controlled by the model request field: haiku (default), sonnet, or opus. Heavier models cost more but help on harder tasks, such as complex multi-step flows and fiddly extraction. Most repeat runs that just execute saved code work well with haiku.

Reuse rules

Same key, same automation

A reuseKey identifies one reusable automation. Two runs with the same key share code, regardless of startUrl or parameters:

// Both runs use the same reusable automation: "companies"
{
  "task": "Scrape YC companies",
  "startUrl": "https://www.ycombinator.com/companies",
  "reuseKey": "companies"
}
{
  "task": "Scrape Wellfound companies",
  "startUrl": "https://wellfound.com/companies",
  "reuseKey": "companies"
}

If you want separate automations, use separate keys (yc_companies, wellfound_companies). The system does not create hidden per-URL memories.

Failed runs do not update code

If outcome is failed, reuse.updated is always false. A failed attempt cannot overwrite a working automation.

The `reuse` response

When you provide a reuseKey, the result includes a reuse object describing what happened to the saved code:

Field	Meaning
`key`	The `reuseKey` you sent.
`used`	`true` if existing saved code was loaded and executed.
`created`	`true` if this run created the first saved code for this key.
`updated`	`true` if this run improved or repaired the saved code. Always `false` on failure.
`revision_id`	ID of the Web Task run whose code is currently saved under this key.
`revision_timestamp`	When the saved code was last updated.

Three common shapes:

// First successful run for a new key
{ "reuse": { "key": "yc_companies", "used": false, "created": true,  "updated": true } }

// Later run, saved code worked as-is
{ "reuse": { "key": "yc_companies", "used": true,  "created": false, "updated": false } }

// Later run that repaired or improved the saved code
{ "reuse": { "key": "yc_companies", "used": true,  "created": false, "updated": true } }

Cost dynamics

Costs are reported per run as aiUsd (model spend) and compute.amount in hours. Expect cost to follow this shape:

First run for a key: high AI cost, longer compute.
Steady-state runs: low AI cost, short compute.
Repair runs: moderate AI cost when the saved code needs updating (for example, after a site change).

This is the central tradeoff Web Tasks make: pay AI cost up front to generate code, then amortize it across many cheap repeat runs.

​Execution model

​Rejection

​Model selection

​Reuse rules

​Same key, same automation

​Failed runs do not update code

​The reuse response

​Cost dynamics