Dejo

Dejo

A browser your AI agent remembers.

It learns a website once. Every run after that is one tool call, with zero model calls.

Website · Install · Benchmark · Tools · What it can do · Compared · Contributing

Your AI can use websites. But it forgets how, every single time. Dejo makes it remember.

Dejo gives Claude Code, Codex, Cursor or any MCP client a browser with a memory. Your agent walks a website once: signing in, clicking, reading. Dejo writes down the route. Every run after that follows the route instead: one tool call, no page reading, zero model calls. When the site changes, Dejo repairs the one step that moved and keeps the rest.

Install

Python 3.11 or newer.

pip install dejo-mcp

playwright install chromium # the browser, a separate download of about 150 MB

Then connect it to your agent:

| Codex | ~/.codex/config.toml | [mcp_servers.dejo] command = "dejo-mcp" | | Cursor | ~/.cursor/mcp.json | { "mcpServers": { "dejo": { "command": "dejo-mcp" } } } | | anything else | as a stdio server | dejo-mcp |

Dejo is one stdio server with no arguments, so any agent that can run an MCP server can use it.

No API key, no account. Dejo never calls a model. Your agent does the thinking, and the memory is a local file on your machine.

Check the install at any time. It names anything missing and the command that fixes it:

dejo doctor

Quick start

Ask your agent for something on a website, in your own words:

Go to github.com/microsoft/playwright and tell me how many open issues it has.

The first time, your agent learns it: Dejo opens the page and shows it, one line per control, and your agent sends the steps back in one call (click link "Issues", then read ... as open issues). The read is what Dejo saves. Ask again tomorrow, in a brand-new chat, and it is one call:

done: "count open issues" on github.com (profile default), 2 steps replayed in 1391 ms, no page reading.

open issues = 117 next: report the answer exactly as read and stop. Every step was checked as it ran.

Prefer a terminal? Everything works without an MCP client:

dejo sites                                            # what it remembers

dejo run "count open issues" --site github.com # replay, no model involved dejo run "count open issues" --site github.com --json # one JSON line, for cron and scripts dejo show github.com # the route, step by step dejo forget --site github.com # make it forget

How it works

What a route is

Not a recording, and not notes. Each step keeps:

• what it was for, in plain words: "open this month's invoice"
• up to nine ways to find the control: test id, link target, label, role, placeholder, alt text, title, visible text, CSS. Ranked by which have actually worked.
• a check that proves it landed: the address changed, the file downloaded, the field holds what was typed, the row count is what it should be.

The checks are the difference between this and a macro recorder. A recorder clicks and hopes. Dejo notices when a click did nothing, and says the site changed.

The nine locators are why most redesigns cost nothing: lose the CSS id, keep the label, and the step still lands. If more than half the steps break, the site was rebuilt rather than adjusted. Dejo throws the route away but keeps what it knows about the site (needs a login, sends a code to your phone), so relearning is cheaper than the first visit.

The map

A route is one path through a site. Dejo also keeps a map: every page it has looked at, and the controls that were on it. It costs nothing to keep, because the page had already been read.

dejo map github.com                    # every page it has seen

dejo map github.com --path /issues # the controls that were on one of them

Ask for something new on a site Dejo has walked, and your agent is handed the pages it already knows before it starts hunting. Each control comes back as a step target such as button "Sign in", which works in a step without looking at the page first. A page Dejo has already walked costs no reading at all. This matters most where one site carries many tasks: an end-to-end test suite, an admin console, a portal you work in every day.

The map says when each page was seen. It is what was there last time, not a promise about now.

Measured on the demo site in this repo (python benchmarks/benchmark.py):

                time  tool calls  page reads  model calls

Monday 1.4s 9 3 0 learning the site Tuesday 1.7s 1 0 0 from memory Wednesday 1.9s 1 0 0 from memory Thursday 12.6s 3 0 0 the site changed, one step repaired Friday 1.9s 1 0 0 from memory

The time is mostly Dejo waiting for the site to finish after the last click (this task ends in a download). A task that ends by reading its answer does not pay that wait.

Benchmark

19 tasks on 12 lesser-known websites, the kind a model cannot answer from memory: a college course catalog, the Debian package directory, the RFC Editor, a museum's collection, a Dart package registry, a small shop. Every right answer was written down before any tool ran. Claude Sonnet 5 (medium), one fresh session per run, @playwright/mcp@0.0.80.

• First run: 38% fewer tokens than Playwright MCP, 55% fewer than Playwright CLI.
• Every run after: 78% fewer tokens than Playwright MCP, and 17 of 19 repeats were a single tool call. The same task run 10 times costs 74% fewer tokens.

Three things the table should also tell you, because they are true:

• On a typical task the first run costs about the same as Playwright MCP (median 216k vs 257k). The first-run savings come from the hard sites: 324k against 1.36M on the college catalog, 398k against 983k on the museum's filters.
• 6 more tasks were on sites that block automated browsers (Cloudflare checks, plain 403s). Dejo and Playwright MCP were stopped on all six; Playwright CLI got through two of them at 1.2M and 1.7M tokens. They are in the results file, not in the table.
• Dejo's numbers are from the release code, after fixing what this benchmark found; the Playwright rows are from the same tasks and model, one day earlier.

Tasks: benchmarks/real_tasks.py. Results: benchmarks/benchmark-real-2026-10-21.json (all three tools), -10-23.json and -10-23-fixes.json (Dejo after the fixes). Run it yourself: python benchmarks/benchmark_learning.py --bench real --tools dejo,playwright --runs 1.

Earlier: the same job ten times (Dejo 0.1.2)

The same job, done 10 times, each time in a brand-new chat. Three multi-step tasks on well-known sites, three MCP browser tools, 90 fresh Claude sessions (Sonnet 5, medium): @playwright/mcp@0.0.80, chrome-devtools-mcp@1.8.0.

52% fewer tool calls and 47% fewer tokens than Playwright MCP. Against Chrome DevTools MCP: 36% fewer calls, 35% fewer tokens. Every tool answered in all 30 of its sessions.

The GitHub task, run by run:

run              1   2   3   4   5   6   7   8   9  10

Dejo 10 2 2 2 2 2 2 2 2 2 Playwright MCP 8 8 18 7 9 9 7 6 5 6

Dejo pays once to learn the route, then costs two calls however many steps that route has.

Two things this table should also tell you, because they are true:

• Dejo costs the most on run 1. It does the job *and* learns the site. That is the trade.
• On a single page with a one-line answer, Dejo is not cheaper. Opening one page and reading one line costs every tool two or three calls, and there is nothing left for memory to save.

Run it yourself: python benchmarks/benchmark_agents.py --journeys --runs 10. These results were recorded while Dejo was still called Cairn, so the files say cairn where they mean Dejo.

Signing in

You sign in to a site once, by hand, in a real window:

dejo login --site posthog.com

Sign in however the site asks: a password, Google, a code on your phone. Dejo never types a password for you and never automates an SSO button. When you say you are done, Dejo checks the window first: if it still shows a sign-in page, it says so rather than pretending. The session is kept, so you stay signed in.

A task learned while signed out keeps its sign-in steps. Replayed once you are signed in, the site skips its sign-in page, so Dejo skips those steps too, says so, and runs the rest of the task. A task that is only a sign-in answers that there is nothing to do.

Passwords never go into memory. A step that needs one records only *that* a password goes there. The value is read at run time from an environment variable (DEJO_SECRET_BILLING_ACME_COM_PASSWORD) or from ~/.dejo/secrets.json:

{ "billing.acme.com": { "password": "..." } }

More than one identity at once

A profile is a whole signed-in browser: its own cookies, its own session. Keep as many as you need, side by side:

dejo --profile vendor login --site shop.example.com

dejo --pro