Browser agent memory: why your agent re-reads every website

Blog·By Rohit Kashyap·Published 18 October 2026

I build Dejo, so read this with that in mind. Every number below comes from benchmark runs you can repeat, and I'll show where Dejo loses too.

Every new chat, your AI agent learns the same website from scratch. It opens the page, reads it, decides, clicks, reads again. Tomorrow it does all of that again. In our test, Playwright MCP spent about 283,000 tokens per session from its fourth run onwards, which is more than its first run cost. An agent that remembered the route spent about 104,000.

What happens in a new chat

We gave Claude the same small job ten times, each time in a brand-new session: open github.com/microsoft/playwright, go to Issues, and say how many are open.

This is the list of tool calls from the third session with Playwright MCP. It is copied from the raw results, nothing added:

ToolSearch, browser_navigate, browser_snapshot, ToolSearch,
browser_find, browser_find, browser_find, ToolSearch,
browser_evaluate, browser_evaluate, browser_evaluate,
browser_find, browser_find,
browser_evaluate, browser_evaluate, browser_evaluate,
browser_evaluate, browser_evaluate

Eighteen calls and about 726,000 tokens to read one number. The agent got the right answer in the end. It just had no idea it had done this exact task twice already.

Here is the second session with Dejo on the same job:

ToolSearch, dejo_run

Two calls, about 104,000 tokens. The first call is Claude finding the tool; the second is Dejo replaying the route it saved in session one. No page reading and no model calls inside Dejo.

What forgetting costs, measured

Same three tasks, ten fresh Claude sessions each, three tools. Averaged per session:

Look at the second row for Playwright MCP and Chrome DevTools MCP. Run 10 costs what run 1 cost. Nothing they learned carried over.

Over all 30 sessions per tool, Claude Code reported $3.69 at list price for Playwright MCP, $3.76 for Chrome DevTools MCP and $1.65 for Dejo. Wall time was 960, 684 and 533 seconds.

Most of the 104K tokens in a warm Dejo session are not page text at all. They are Claude Code's own instructions and tool list, which every session loads. That floor is the same for every tool, which is why the saving tops out near half instead of 90%.

Two kinds of memory

People mean two different things when they say a browser agent "remembers" a site.

The first is your login. Playwright MCP already does this: its browser profile persists between sessions by default, so cookies survive and you stay signed in. Chrome DevTools MCP does the same with its own profile folder. That saves you from signing in again. It does not save a single page read.

The second is knowing how to do the task: which page, which control, what to check. Some agent-memory tools call this procedural memory. None of the browser tools we measured keep it. Each session starts with a blank plan, so the agent pays to read pages it has seen before.

Someone in a Claude Code thread on Reddit described the fix from their own setup: "keeping Playwright scripts as the 'executor' and letting the agent only plan the steps reduced hangs a lot." That's the same idea. Let the model work out the route once, then let plain code walk it.

What a saved route holds

In Dejo, the first session explores the site the normal way. When the task works, the agent calls dejo_save and every step it took is stored with three things:

1. What the step was for, in plain words, like "open the Issues tab".
2. Up to nine ways to find the control: test id, link target, label, role, placeholder, alt text, title, visible text and CSS. They're ranked by which ones have actually worked.
3. A check that proves the step landed: the address changed, the file downloaded, the field holds what was typed.

The check is what keeps this from being a macro recorder. A recorder clicks and hopes. If a click does nothing, Dejo notices and stops.

The next session calls dejo_run. Dejo walks the route in plain Python and hands back the answer. If the task was "count the open issues", the result is the count.

When the website changes

A saved route is only useful if it survives a redesign. This is the part people usually mean by "self-healing".

Most changes cost nothing, because a step has several ways to find its control. Lose the CSS id and the label still works. When every way to one control is gone, Dejo stops at that step and shows your agent the controls that are on the page now. The agent picks the right one, calls dejo_repair, and only that step is rewritten. The rest of the route stays as it was.

Here is a scripted week on the small demo site in the Dejo repo, with the site changed on Thursday:

If more than half the steps break, the site was rebuilt, and patching one step at a time makes no sense. Dejo drops the route, keeps what it knew about the site (it needs a login, it sends a code to your phone), and the agent learns it again.

Where remembering doesn't help

Memory has weak spots, and they show up in the same data:

• The first run costs more. Dejo's first session averaged 415K tokens, more than either other tool, because the agent does the job and saves the route. You get it back from the second run.
• One page, one line: "open this page and read the title" takes two or three calls with any tool. In our one-page tests on six sites, Dejo used fewer tokens than Playwright MCP on pkg.go.dev and more on the other five.
• Tasks you'll never repeat save nothing.

The rule I use: if your agent does the same thing on the same site more than once (checking a dashboard every morning, downloading an invoice every month), memory pays. If every task is new, pick the tool that reads pages cheapest.

Other ways people cut the cost

Memory isn't the only fix, and the others are worth knowing:

• Smaller snapshots. Microsoft's Playwright CLI writes page snapshots to files instead of pushing them into the model, which its README calls "more token-efficient". We haven't measured it yet; it's next on our list.
• Ask for less. "Reply with only the number" keeps the model from summarizing the page back to you.

Both help with the first run, and you can use them alongside memory, which helps with every run after it.

How we tested

Claude Code in headless mode (claude -p), Claude Sonnet 5 at medium effort. Each session could use only the browser tool under test; WebFetch and other shortcuts were blocked. Ten brand-new sessions per tool per task, three tasks, 90 sessions in total, recorded on 5 September 2026 with @playwright/mcp@0.0.80 and chrome-devtools-mcp@1.8.0. Tokens include cache reads and writes, as Claude Code reports them.

Every tool answered in all of its sessions. On the GitHub task the page showed two open-issue counts at the time (155 and 157), and the replies differ for that reason; the details are on the benchmark page. The script and the raw JSON are in the Dejo repository. The results file uses Dejo's old name, so it says cairn where it means Dejo.

FAQ