Product
See what your agent remembers
Browse projects, pages, agent activity, token usage and inboxes in the built-in web UI. Page content stays read-only; authorized users can queue or edit messages waiting for agents.
Every project at a glance
The dashboard shows visible projects, sessions, captured events and compiled pages. Hook-health counters report accepted and dropped events since the server started.
A project: its pages, its decisions, its mail
Project tabs separate Overview, Agents, Token usage, Sessions and Knowledge. The overview shows captured activity, compiled pages and pending mail.
A page, and what points at it
A page shows its outline, backlinks and citations alongside version-specific evidence, declared contradictions and expiration context. History keeps earlier versions.
Search that ranks like the agent
Project search uses the same ranker as memory_query. Kind and tier filters apply before ranking, and Explain ranking shows why a page surfaced. Cross-project search uses full text.
Activity, messages and guides
Response usage
Claude Code and Codex hooks report response token use. Project and session views filter by model, harness and tool; older or unsupported sessions show no count.
Messages waiting for agents
The inbox shows received and sent mail without claiming it. With write access to both projects, you can address a message to a registered harness and edit it until an agent collects it.
Guides inside the server
Feature guides and release notes are bundled in the binary under /web/docs. The guides show what is installed for your account without exposing admin settings to other users.
How the pages connect
A map of the links between pages, drawn by the server. No JavaScript, and no graph database behind it: the edges are rows in the same index the search reads.
Across projects
The Graph link in the header draws every resolved link whose two ends sit in different projects, with a table of those edges underneath. It is how you notice that the API project cites a decision taken in the frontend one.
Inside one project
Each project has its own map of its live pages and the links among them. Above 120 pages it keeps the best connected and the most recently updated, so the picture stays readable.
What the launcher is running
A separate page lists managed runs and their state: live, interrupted, finished, empty. It shows counts, never checkout paths, lease owners or transcript content. Root only on a shared server.
History, replay and health
Three views for the question “what happened here?”
Page history
Every stored version of a page, newest first, superseded ones included, with a diff between any two. A version a concurrent write replaced stays visible.
Session replay
A project lists its recent sessions, and each opens a timeline of its observations in capture order. With JavaScript, a slider and the j and k keys step one at a time.
A health page for root
Hook counters since the server started, the writer queue, the spool, the consolidation queue, the embedder and both providers. Anything failing is listed with the command that fixes it.
The same data is available as JSON under /api/v1, and serve --enable-api mounts the API without the browser UI.
Optional management console
/manage brings user administration, session inspection and personal MCP keys into the browser. It requires both a build with management-ui and --enable-management-ui at startup; the standard release Docker image does not include it. Users can purge exactly owned sessions in projects they may write; admins can purge any session. Build and deployment guide.
Password resets and disabled accounts end browser sessions, but do not revoke self-issued API keys. Revoke those separately. Session purges can leave earlier content in git history, backups and native transcripts.
Questions and answers
Is the web UI on by default?
The serve command leaves it off unless --enable-web is set. Services installed by setup enable the wiki browser. The separate management console needs its own build feature and runtime flag.
Can I edit a page in the browser?
There is no page editor. Use memory_write_page, the CLI or the Markdown file. Root can approve or reject pending edit proposals in the browser.
Who can see what on a shared server?
With database-user accounts, restricted projects are visible to root, their creator and users with a read or write grant. Another operator’s session timeline stays hidden; health and pending views are root only. Trusted-proxy deployments must enforce access at the proxy.
Does it need JavaScript?
Page content renders without JavaScript. Sign-in, password changes and proposal approval use JavaScript, as do replay controls and theme switching.
Can the interface be in another language?
English and Brazilian Portuguese. The browser negotiates Accept-Language and has a selector that saves a cookie, so two people on one server can read it in different languages. The CLI follows --language, AI_MEMORY_LANGUAGE or language in config.toml and stays in English by default. Stored pages, JSON and logs are not translated.
Give your agents a memory today.
Free and open source under the MIT license. The default memory features need no model API key; your coding agent may require its own account.