I read Andrej Karpathy’s persistent-wiki gist back in April and immediately wanted to implement it — not as an abstract exercise, but as the fix for a specific problem I’d been living with for a while.

I code in two environments. At work, I have a job with a specific stack, team conventions, and a deploy pipeline everyone has agreed on. At home I do a lot of side-project work on different infrastructure, different languages on different days, different tools. Two laptops, two stacks, one person. The tools are different. The coder isn’t — the judgment about what makes a good pattern, the instincts for what’s worth reaching for, the taste for what correct code looks like, the standards I hold myself to. None of that is supposed to change between contexts. If I’m going to ship high-quality code at work, I should ship high-quality code at home too. Same engineer, same bar.

But knowledge doesn’t travel with me automatically. I’d figure out a cleaner approach to secrets management at work, come home a week later, and fall back to whatever I’d been doing six months ago because I’d forgotten I’d improved things. Or I’d spend a weekend at home working out a better pattern for handling something tricky, get to Monday, and have to re-derive the whole thing because nothing carried over. I kept solving the same problems twice. Cross-environment inconsistency isn’t a tool problem — it’s a memory problem. I wanted to write the same quality of code in both places, and that meant decisions I made in one context had to propagate to the other.

Karpathy’s gist clicked because it described exactly that substrate: a structured, interlinked wiki the LLM maintains, sitting between me and the code I’m writing, existing outside either laptop’s tool chain. If both environments point the same agent at the same wiki, the wiki becomes the place my engineering standards live. Decisions compound. Patterns cross over. I stop re-deriving the same things.

Seventeen million views and five thousand GitHub stars later, a lot of people had the same reaction I did. So I started building.

The problem with taking a gist at face value

Karpathy was explicit that the gist was an “idea file” — not an implementation. He was sharing a pattern for other people’s agents to instantiate. Which is a genuinely forward-thinking way to share software in the agent era, but it also means there’s a gap between “this idea is compelling” and “this actually works in my daily life for six months.”

Before I wrote any code, I sat down with Claude and worked through the pattern as a structured Signal & Noise analysis. Not “help me implement this,” but “let’s figure out where this holds up and where it needs help.” We went through seven real strengths (it’s token-efficient at personal scale, the wiki is fully auditable markdown, errors are at least visible, it self-heals via periodic lint passes) and seven places where the core idea needs an engineering layer to become practical:

  1. Errors persist and compound — unlike RAG, a wrong claim at ingest time sticks around.
  2. Hard ~50K-token ceiling — Karpathy’s own wiki is at ~400K words, right at the limit.
  3. Manual cross-checking returns in precision-critical domains.
  4. Knowledge staleness is the #1 failure mode — community analysis of 120+ comments on the gist converged on the same finding: most people who try this pattern end up with wikis that slowly rot because they stop feeding them. Six-week half-life is typical.
  5. Cognitive outsourcing — the bookkeeping is where some of the understanding forms.
  6. Weaker semantic retrieval than RAG at scale.
  7. No access control, no multi-user, no concurrency handling.

The analysis became a standalone interactive page — tabs for pros/cons, vs RAG, best/worst fit use cases, signal breakdown, mitigations, and the MemPalace integration that followed. If you’re wondering whether to build on Karpathy’s pattern yourself, I’d start there. It’s honest about what the pattern gets right and what it doesn’t solve, and every automation component I built maps directly back to one of the mitigations the analysis identified.

Building the engineering layer

I called the result memex — after Vannevar Bush’s 1945 essay “As We May Think”, where he described a theoretical machine that would store and cross-reference a lifetime of personal knowledge via “associative trails.” Eighty years later, LLMs make the memex finally buildable. The associative trails Bush imagined are the related: frontmatter fields and wikilinks the agent maintains. It felt like the right name.

Memex is a synthesis of three things with an automation layer on top:

  • Karpathy’s pattern — compile at ingest time, markdown files, CLAUDE.md as the schema that disciplines the agent.
  • milla-jovovich/mempalace — the wing / room / hall / closet / drawer / tunnel taxonomy that turns a flat corpus into something you can navigate without reading everything. Wings are projects or people. Rooms are topics within a wing. Halls are memory types (fact, discovery, preference, advice, event, tooling). The taxonomy gets a documented +34% retrieval boost over flat search because you can structurally filter before you semantically search.
  • Automation layer — my part. Eleven scripts and four state files that make the above run day-to-day without requiring me to remember to do anything.

The short version of what memex adds:

What Why
Time-decaying confidence — pages earn trust through reinforcement and fade without it Errors become visible aging warnings, not permanent silent landmines
qmd search from day one (BM25 + vector + LLM re-ranking) Scales past the ~50K token ceiling
Traceable sources for every claim Every page traces back to either a raw harvested file or specific conversation IDs
Daily + weekly cron pipeline Removes “I forgot to lint” as the #1 failure mode
Human-in-the-loop staging Automated content waits in staging/ until I approve it — the only human step, and it’s fast because the AI already wrote the page
Hybrid retrieval (structural wing/room + semantic) Best of both worlds without a full vector DB
Git-based cross-machine sync with merge=union on markdown Works across my laptop, workstation, and server without merge hell

The whole thing runs on a daily cron at 3am and a weekly full-hygiene pass at 4am on Sundays. I don’t touch it.

Closing the MemPalace loop

Seven extensions got me most of the way there. Then I noticed something while using it: the mining pipeline was diligently extracting every Claude Code session I had, classifying the bullets into halls, tagging topics, making everything searchable via qmd. But the knowledge inside the conversations was never becoming wiki pages. A decision I made in a debugging session, a root cause I found, a pattern I spotted in review — these stayed in the conversation summaries forever, findable but not synthesized.

That’s the eighth extension, and the one that turned the MemPalace integration from “a searchable archive sitting beside the wiki” into “a real ingest pipeline for the wiki itself.” I called it conversation distillation (wiki-distill.py). The mechanic is narrow-today with wide history:

  1. Every day, look at the topics appearing in today’s summarized conversations.
  2. For each one of those topics, roll up every conversation across history that shares that topic.
  3. Extract the hall_facts, hall_discoveries, and hall_advice bullets from all of them (the high-signal halls — skip events, preferences, tooling).
  4. Send the rollup to claude -p with the current wiki index and ask it to produce new pages or updates to existing ones.
  5. Output lands in staging, waiting for me to approve.

Processing scope stays narrow (only today’s topics). LLM context stays wide (all history for those topics). And it has a useful emergent property: dormant topics wake up automatically when they resurface. If I discussed database-migrations three months ago and never mentioned it again, it’s not in the daily scope. But the day it comes up again in any session, that topic enters today’s set, the rollup pulls in all three months of historical discussion, and the wiki page gets updated with fresh synthesis across the full history. I don’t have to remember to say “hey, is there a wiki page for X?” — the next time X shows up in a session, distill handles it.

A concrete example

The first non-trivial test run distilled a topic called zoho-api from two conversations across my archive (one from March, one from April). Total: 34 high-signal hall bullets.

Claude produced staging/patterns/zoho-crm-integration.md — a proper pattern page with:

  • A What section summarizing the integration shape
  • A Why section explaining why these limitations exist and referencing the specific dates the issues surfaced
  • Known Limitations section with four enumerated items, each tied to a concrete incident
  • Proper frontmatter: title, type: pattern, confidence: high, last_compiled, last_verified, the two source conversations in sources:, and a related: list linking to database-migrations.md and activity-event-auditing.md
  • Full distill provenance in staging metadata: staged_by: wiki-distill, distill_topic: zoho-api, distill_source_conversations: conversations/general/2026-04-06-...md,conversations/mc/2026-03-30-...md, and a compilation note explaining why it had decided to create this page

I reviewed it in staging, promoted it with one command, and now I have a canonical pattern page that captures two separate production incidents worth of learned knowledge — without having written a word of it myself.

That’s the compounding loop actually closing.

What’s next

Memex is live, tested (192 unit/integration tests), documented, and running on cron. The repo is here and the MIT-licensed code should be straightforward to adapt for other agents — the Karpathy pattern is agent-agnostic; only the mining/summarization/distillation scripts are Claude Code-specific, and each has a clear seam for swapping in OpenAI, Gemini, Ollama, or a local LLM.

If you’re thinking about building on Karpathy’s gist, I’d recommend this order of operations:

  1. Read the gist. Get the idea.
  2. Read the Signal & Noise analysis before writing code. The gist is compelling; the analysis will save you from two or three weeks of discovering the gaps yourself.
  3. Start small. Path A (just the wiki, no automation) from memex’s README is the Karpathy-gist version — works great for a few dozen pages and doesn’t need any of the automation layer.
  4. Add the automation layer only when the manual upkeep starts failing you. That’s what the scripts are for. If you’re building a weekend research wiki, you probably don’t need conversation distillation. If you’re building a living engineering knowledge base that you want to come back to in two years, you do.

The thing I’m most excited about isn’t the scripts — the scripts are just scripts. It’s the reframing: Karpathy’s gist landed as an “idea file” for other people’s agents to instantiate, and that model of sharing software actually works. You read a description, you sit down with your agent, you work through the signal and noise together, you decide what layers you need, and you build. memex is what that process produced for me. Your version will look different.

And the wiki keeps getting richer.

Links: