I built a live 3D view of my AI assistant's memory — and found where its tokens go

Description and use

memglow visualizes an AI assistant’s Markdown memory in a live 3D graph, revealing which notes are read, searched, or written, and suggests splitting large notes to reduce token usage.

Problem

The author could not determine which notes an AI coding assistant accessed, searched, or modified within its long‑term memory stored as Markdown files.

Outcome

The tool revealed that a few notes were repeatedly read and grew large, consuming many tokens. After splitting a 15,500‑token note, typical reads dropped to ~1,200 tokens for a summary or 4–6k for a topic note.

Workflow

• 1. Run npx memglow init to detect and install hooks for supported assistants.
• 2. For other clients, set up the MCP proxy or HTTP API to relay memory operations and report touched notes.
• 3. Launch memglow locally; it reads the memory folder and renders a 3D graph where nodes represent notes and edges represent wikilinks.
• 4. Observe note colors (cyan=read, violet=searched, red‑orange=written) and comets indicating traversal.
• 5. Use the Memory Cost panel to view tokens read per day, identify costly notes, and get suggested splits.
• 6. Copy the prompt to instruct the assistant to split a note if desired.

Evidence

My AI coding assistants keep their long‑term memory as plain Markdown notes (basic-memory, but an Obsidian vault works the same way).

Source

I built memglow: a small local web app that turns the memory folder into a live 3D graph.

Source

Hooks send note ids only, never content. memglow runs on localhost, only reads your notes, and has zero runtime dependencies.

Source

Once I could see the reading, a pattern jumped out: a handful of notes were read over and over, and some of them had quietly grown huge.

Source

On my own memory, the note tracking this very project had grown to ~15,500 tokens in two days and was read in full every time.

Source