What happened
The browser-use project released version 1.0.4 on November 13, 2026. The release notes describe a change to screenshot pruning: old screenshots are now dropped in one batch after 20 tool results that carry a screenshot, rather than being removed incrementally with every new screenshot. The project says the previous behavior rewrote an earlier message each time, breaking the provider's prompt cache. In screenshot-heavy runs, that meant input tokens that could otherwise be served from cache were repeatedly billed at the full input price.
The notes give an example from BU Bench 1.0.3: one task that ran for 705 steps read 27.8 million input tokens, of which 1.6 million came from cache. This illustrates the scale of input context involved in that particular run; it is not described as a representative average across all browser-use tasks. The release does not present the example as a separate before-and-after comparison for that same task.
For a broader comparison, browser-use reports BU Bench v2.1 results across 200 tasks. Version 1.0.4 scored 76.1, compared with 76.0 for version 1.0.3. The reported model cost per task was $0.208 in 1.0.4 versus $0.434 in 1.0.3. The release characterizes the score as the same and the cost as lower; the figures indicate a small score difference alongside a reduction of just over half in reported per-task cost. The notes do not detail the benchmark's scoring rubric or cost calculation on this release page.
The release also lists two other changes. Callers using BU_NAME get their own Chromium instance when Chrome cannot be used. And when a browser setup error may be fixed in a newer release, the CLI and MCP tell the agent to upgrade. The release notes associate these items with issues #6387 and #6388; they do not provide further behavior or compatibility detail there. The installation command is pip install 'browser-use==1.0.4'.
What the archive adds
New Runtime's earlier coverage on October 24, 2026, described how StackAI by Asana used Astra, Codex and Command to reduce browser-agent costs, including changes intended to preserve prompt-cache reuse. This is a new event on a related cost-control problem, not a new fact about StackAI: browser-use's own release reports its pruning change and benchmark comparison.
Trend signal
This supports agent economics moving to completed work: the release compares reported model cost per benchmark task while reporting a nearly unchanged score. That is more useful for evaluating an agent run than a token-price figure alone. The result remains a project benchmark, not evidence that the same cost reduction applies to other tasks, models, or providers.
Connections to other events
The browser-use release and New Runtime's earlier coverage of StackAI meet around prompt-cache reuse as a lever for reducing browser-agent costs. StackAI's account concerned changes to its own agent; browser-use 1.0.4 changes the open-source project's screenshot-pruning behavior and reports a 200-task benchmark comparison. The shared concern is cost under repeated browser context, but these are distinct implementations and their results should not be treated as directly comparable.
Why it matters
Browser agents can accumulate large histories of tool results and screenshots. If each new screenshot causes older context to be rewritten, a provider may lose the ability to reuse cached prompt content. The browser-use change targets that interaction between context management and billing rather than claiming a more capable model or a better task score.
For teams paying for model input, the reported shift from $0.434 to $0.208 per task is worth testing, especially if their workflows resemble the screenshot-heavy benchmark runs. But the relevant decision is not whether the release's headline reduction is impressive in isolation. It is whether the team's own tasks retain acceptable completion quality and realize similar savings with their provider, browser setup, and workload. The reported score changed only from 76.0 to 76.1, but a benchmark aggregate cannot establish reliability for every site or task type.
Limits and uncertainty
The release page does not explain the BU Bench scoring method, how the model-cost figures were calculated, or which model and provider configuration produced them. It does not report a per-task distribution, variance, or results broken down by task type, so the aggregate does not show whether savings were consistent across all 200 tasks. The 705-step example is from version 1.0.3 and is not paired with a corresponding 1.0.4 run. The release also does not establish that other providers cache prompts in the same way, or that the two additional browser setup changes affect cost or benchmark performance. Teams should treat the comparison as a result to reproduce against their own workload.
Skill to build now
Run a small before-and-after evaluation on representative browser tasks before upgrading a production agent. Record task success or benchmark score, model input cost, and cached versus uncached input tokens for each run; include screenshot-heavy and shorter tasks. This separates a genuine improvement in your workload from a project-level aggregate and can reveal whether your provider's cache behavior is part of the savings.
Reader takeaway
browser-use 1.0.4 reports that batching screenshot pruning reduced BU Bench v2.1 model cost per task by more than half while leaving the aggregate score almost unchanged. The useful next step is not to assume the same percentage applies to your agent, but to test whether preserving prompt-cache reuse lowers costs on your own browser workflows without hurting task completion.