Pensieve: a local dashboard for inspecting and governing LLM memory records
Observe how memory shapes an answer. Pensieve is an interactive system for visualizing, interpreting, and managing how Large Language Models (LLMs) “remember” a user. It bridges the gap between model-level mechanisms and user-level understanding, making AI memory observable, explainable, and partially controllable.
At a glance
- What is it?
- Pensieve is a TypeScript and Next.js 15 research preview that reads structured memory records through a provider interface, lets a user pin, soften, hide or restore them, and compiles the result into a Markdown report, a JSON manifest and a provider receipt. The design is honest about its boundary: it governs external memory records, not model weights, and it does not claim physical deletion.
- Who is it for?
- Adopt Pensieve if you need a local, host-agnostic way to see which structured memory records a provider holds and to apply reversible changes to them, and you accept that the shipped reference implementation is file-backed and reads data/pensieve-memory-records.json.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 49 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Pensieve targets is between memory storage and user agency
Retrieval systems answer which stored records should enter the next context window. Storage systems answer where those records live. Pensieve is aimed at the step in between, which the README describes as the missing loop between observation and user agency. The claim is narrower than it first sounds. Pensieve does not modify model weights, and it does not try to explain attention or activations. It reads the external memory records that a provider already keeps, presents them with provenance, risk, recency, activation and status, and then lets the user change the status of those records in a way that is meant to be reversible. The intended user is someone who has accumulated a working memory of preferences, projects and habits across repeated interactions and wants to see what is currently prominent before deciding what should stay. That is a different job from debugging a retrieval pipeline, and the project's own framing puts it alongside retrieval and observability as a third problem: governance.
The MemoryProvider contract is deliberately small, and that is the main architectural decision
Pensieve splits into a dashboard core, a provider, a Governance Bridge, a host adapter and a file-backed local repository. The interface that matters is MemoryProvider, and the README shows it with three required methods and three optional ones. getSnapshot, getMemories and applyAction are required. getGovernanceStatus, generateGovernanceReport and applyGovernanceReport are optional. The README states that read-only providers can implement only the first two methods, which means a provider that can list memories but cannot mutate them still works with the dashboard. That is a real constraint on what the UI can offer, not a marketing line. The core derives snapshot metrics, ranking, keywords, themes and display state from whatever the provider returns, so swapping providers does not require touching the dashboard. The host adapter connects sidebar lifecycle and runtime events, and the stated goal is that host assumptions do not leak into the core. Whether that separation holds in practice depends on the adapter, which is the part of the architecture the README describes least.
Memory units are semantic records, not runtime events
The data model is explicit about this distinction. A MemoryUnit carries an id, content, keywords, a priority_score, a risk_level of low, medium or high, a status of active, softened or hidden, a pinned boolean, created_at, last_activated and activation_count. The README draws the line directly: runtime events describe interaction with memory, while memory units are the stored semantic objects being observed and governed. That choice has consequences. Because governance operates on stored records rather than on a stream of events, the system can compute a target state and compare it against the current one. The README states that reports are based on state differences, not UI event replay, and that repeated application converges to the same target state instead of duplicating mutations. This is the property that makes the receipt meaningful: you can apply the same desired state twice and expect the second application to be a no-op rather than a second mutation.
Running the local dashboard and installing the Codex plugin
The quick start is three commands plus a URL. Clone the repository, run npm install, run npm run dev, then open http://localhost:3000/dashboard. The local preview reads data/pensieve-memory-records.json as its structured memory repository, exposes /api/dashboard-memory for memory reads and reversible actions, and /api/governance-report for report generation, provider application and receipts. Generated artifacts land under data/pensieve-governance/ in reports/ and receipts/ subdirectories, and the README notes those are local and Git-ignored. The Codex path is a single command, codex plugin add pensieve-dashboard-plugin@pensieve-local, with the local marketplace and Windows setup covered in CODEX_PLUGIN_INSTALL.md. One operational detail from the README: start a new Codex task after reinstalling so the updated plugin metadata is loaded. There are no releases retrieved for this repository, so the practical upgrade path is pulling from main rather than tracking version tags.
Softening and hiding are not deletion, and the project says so
The safety model replaces a generic delete button with three reversible operations. soften lowers prominence while preserving the record. hide suppresses active retrieval and remains reversible. restore returns hidden memory to the active field. High-sensitivity records use protected representations in both the UI and exported reports, with full, soft-mask and protected display tiers. The README is unusually direct about the missing piece: physical deletion is intentionally not claimed yet, and a production hard-delete flow needs provider support, confirmation policy, retention semantics and auditable proof of deletion. Anyone evaluating Pensieve for a compliance use case should read that sentence twice. A user who hides a memory has changed its retrieval status, not removed the underlying record from the provider's store. If your requirement is erasure, this tool does not meet it, and the authors are not pretending otherwise. The JSON manifest is described as the machine-readable source of truth while Markdown is the human review surface, and Pensieve requires a receipt before it labels a report as verified.
Where Pensieve is the wrong tool
Pensieve governs external memory records and retrieval state. It does not touch weights, so it cannot help with behaviour that was baked in during training or fine-tuning. It is not a RAG inspector in the usual sense: the README positions it against conventional RAG inspectors and static analytics dashboards, and the difference is that Pensieve is built around reversible user decisions and a verification receipt rather than around tracing a single query through a retrieval pipeline. It is also not a chat interface. If your problem is that a model gave a bad answer and you want to know which document caused it, the state-difference model here will not answer that question. And if your provider cannot mutate memory, you are limited to the read-only path: getSnapshot and getMemories, with no governance loop at all. The README marks the project as a research preview, which is consistent with the absence of releases and the file-backed reference implementation.
The alternative most teams already have is a provider-native memory console
The realistic comparison is not another dashboard. It is whatever memory management the host platform already ships, plus the provider's own storage. A provider-native console typically exposes the records that provider stores and whatever deletion or editing primitives that provider supports, and it is authoritative by construction because it sits on the source of truth. Pensieve's difference in approach is the indirection: it reads through MemoryProvider, derives its own snapshot, priority and risk views, and then writes back a desired state that the provider applies and reports on. That indirection buys host independence and a portable audit artifact in the form of the JSON manifest, Markdown report and receipt. It costs you a second contract to maintain and a verification step that can fail if the provider does not return a receipt. If you only ever use one host and that host already gives you adequate controls, the extra layer is not obviously worth it. If you need the same governance view across more than one host, or you need a reviewable artifact of what was changed, the indirection is the point.
Licence and the real maintenance cost
Pensieve is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are preserved. That is a permissive baseline, and it says nothing about the licence of any provider you connect through MemoryProvider, so the integration boundary is where you should look for obligations. On maintenance, the honest reading of the material is that the cost sits in the provider, not the dashboard. The dashboard core is stable by design because it only consumes the snapshot and memory record shapes. The parts that will need attention are the host adapter, which has to track sidebar lifecycle and runtime events for each host, and any provider implementation of applyGovernanceReport, since the verification step depends on a receipt coming back. The README also notes that reinstalling the Codex plugin requires starting a new task for updated metadata to load, which is a small but recurring operational step. There are no releases retrieved, so there is no changelog to diff against and no versioned upgrade path to plan around.
Editorial conclusion
Adopt Pensieve if you need a local, host-agnostic way to see which structured memory records a provider holds and to apply reversible changes to them, and you accept that the shipped reference implementation is file-backed and reads data/pensieve-memory-records.json. Do not adopt it if you need hard deletion of a memory record, because the README states that physical deletion is intentionally not claimed and that a production hard-delete flow needs provider support, confirmation policy, retention semantics and auditable proof. Before committing, verify three things in your own environment: that your provider can implement getSnapshot and getMemories at minimum, that it can implement applyGovernanceReport and return a receipt for the verification step, and that the protected display tier maps onto whatever sensitivity classification your records already carry.
Community notes