comparison

browser-memory vs Unbrowse

The closest comparison: both give AI agents reusable, MCP-callable skills instead of driving the browser live. The difference is a shared, self-repairing catalog and coverage that goes past API-native to any site.

browser-memoryUpdated Jul 2026
browser-memoryUnbrowse
Core ideaShared catalog of pre-built skillsAPI-native skills discovered from traffic
Where skills come fromShared across everyone; install pre-builtGenerated from your own browser traffic
When a skill breaksRepaired once, for every agentRediscovered / regenerated
CoverageDOM and XHR — works with no clean APIAPI-native first
InterfaceMCP + bmem CLIMCP / CLI / SDK
Output to the modelStructured data (fields, rows)Structured JSON
Speed / tokens~20x faster, ~4x fewer tokensIts own fast, low-token path
Installbmem add {site}/{task}Its own CLI / SDK

The real difference: shared, and beyond API-native

Unbrowse is a strong, closely related tool: it auto-discovers a site’s API from browser traffic and turns it into fast, cheap, reusable skills for agents. browser-memory bets on two things on top of that. First, the catalog is shared — you install skills the ecosystem already built, and when a site changes, the fix ships to every agent at once, not just yours.

Second, skills are built from DOM selectors and XHR requests, so browser-memory reaches sites that never expose a clean API — the interface-only pages where an API-native approach has nothing to discover. The agent still gets structured data back.

When to use which

Choose Unbrowse if you want to generate API-native skills from your own traffic. Choose browser-memory if you want a shared, self-repairing catalog you install from, that works on any site — API or not — 20x faster with 4x fewer tokens.

FAQ

What is the difference between browser-memory and Unbrowse?

Both turn repeated web work into reusable skills an AI agent calls over MCP, instead of driving the browser live every run. The main differences are that browser-memory's catalog is shared across everyone (you install skills others already built, and a fix ships to every agent), and browser-memory covers DOM and XHR — so it works even on sites that never expose a clean API, not only the API-native path.

Is browser-memory shared across users?

Yes. browser-memory is a shared memory ecosystem: skills are pre-built and installable from one catalog, and when one agent hits a broken skill it is repaired once for everyone. That is the core bet — the web is learned once by the ecosystem, not re-discovered by each user.

Does browser-memory work when a site has no API?

Yes. Because skills are built from the exact DOM selectors and XHR requests for an action, browser-memory reaches sites that only render an interface and never ship a clean public API, returning structured data all the same.

Does browser-memory work with Claude, MCP and other agents?

Yes. browser-memory exposes skills over the Model Context Protocol, so Claude Code and any other MCP-capable browsing agent can discover and run them directly.

Compare more: browser-use, browse.sh, Stagehand, Browserbase.

Install from a shared skill catalog

A memory of the web built by agents, for agents — self-repairing and reusable across every site.