Why it mattersRewriting an old message breaks the provider's prompt cache. A screenshot-heavy agent run paid the full input price on almost every step, which is where the saving came from.
An AI agent that drives a browser has to keep sending the model what it just saw. In browser-use, that has meant sending a screenshot back to the model every step. Older screenshots then get pruned to keep the context from growing. The pruning was also where most of the cost came from. The maintainers now say they have found the reason.
browser-use published release 1.0.4 on GitHub. The release notes state the change. The agent now drops old screenshots in one batch. The batch runs when 20 tool results carry a screenshot. The old agent pruned on every new screenshot.
What was going wrong
The old behaviour pruned a screenshot each step. Each prune rewrote the earlier message. The provider's prompt cache keys on exact prior content, so rewriting that message broke the cache. The release notes say "screenshot-heavy runs paid full input price on almost every step".
They cite one concrete run on BU Bench 1.0.3. A 705-step task read 27.8 million input tokens. Only 1.6 million came from cache. That is a hit rate below 6 percent. A workload like this should sit near the top of the cache's useful range.
The number that came out
On BU Bench v2.1, a 200-task benchmark the project runs itself, version 1.0.4 scored 76.1 against 76.0 for version 1.0.3. The cost per task went from $0.434 to $0.208. That is a 52 percent drop at the same score. These are the maintainers' own figures on their own benchmark. The saving a team sees on their own workload may differ.
Two smaller fixes
The notes also list two fixes. Issue #6387: callers using the BU_NAME option now get their own Chromium when the system Chrome cannot be used. Issue #6388: a browser setup error that a newer release may fix now gets a clear message. The CLI and the MCP server tell the agent to upgrade, instead of returning a bare error.
What a reader can take from this
A prompt cache breaks silently. The model keeps answering, the agent keeps working, and the invoice arrives as normal. The browser-use maintainers only noticed by looking at the tokens-read-from-cache figure on one long run. A team running an agent against a provider with prompt caching can do the same check. The question is whether the cache hit rate is close to the fraction of context that should be reusable. A screenshot-heavy run with a stable system prompt should cache most of the context after the first few steps.
The specific cause in browser-use was pruning old content from the middle of the message list. The same risk sits in any agent that edits an earlier turn. The same risk sits in any agent that replaces a tool result after the fact, or re-orders messages. The fix has two parts. Do the edit once, in a batch, far enough back that the provider will not re-cache it anyway. Or drop the edit and let the context grow until a larger prune.
Source
- browser-use 1.0.4 release notes, browser-use on GitHub.
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.
