The Idea That Caught Fire

In April 2026, Andrej Karpathy published a GitHub Gist describing something he called an “LLM Wiki.” The concept was elegant: use Obsidian as an IDE, an LLM as the programmer, and a wiki of markdown files as the codebase. You read things — articles, papers, videos — and the model distills them into structured wiki pages that cross-reference each other. The knowledge compounds. The wiki grows.

It went viral. Sixteen million views. Five thousand stars. Within weeks, dozens of implementations appeared — GitHub repos, Substack breakdowns, YouTube walkthroughs. The concept struck a nerve because it felt right. Markdown as durable substrate. The model as librarian. Your knowledge base growing while you read. Karpathy had named a pattern that a lot of people were already half-doing, and he packaged it cleanly enough that everyone could see themselves in it.

He also got something genuinely important right that the discourse hasn’t fully appreciated: the substrate matters. Not a proprietary format. Not a SaaS platform that holds your knowledge hostage. Plain text files in a folder. Version-controlled. Portable. Yours. In a landscape of AI tools that want to own your data, this is a radical and correct design choice. The wiki outlives any particular model, any particular tool, any particular company.

But here’s the thing: almost every implementation of the LLM Wiki pattern — including, arguably, Karpathy’s original — does the same thing with this excellent substrate. It builds a better filing cabinet.

The Landscape

To be fair, I want to show you what’s out there, because some of it is genuinely clever. The ecosystem that formed around Karpathy’s idea reveals a consistent pattern: people climbing the same ladder, with each rung adding sophistication, and almost nobody looking up to see where the ladder is leaning.

Rung one is retrieval. This is where most implementations live. Ingest articles. Generate summaries. Cross-link related topics. Query the result. The framing is typical: the wiki replaces retrieval-augmented generation. Instead of searching a vector database at query time, you pre-compile the knowledge into structured pages. It’s a real improvement. Your model has context instead of fragments. But the interaction model is the same one you’ve always had: you ask, it answers.

Rung two is lifecycle management. A few implementations noticed that a wiki that only grows eventually rots. Rohit Ghumare’s LLM Wiki v2 adds confidence scoring, supersession tracking, and retention decay modeled on the Ebbinghaus forgetting curve. Pages have lifetimes. Stale knowledge gets flagged. Consolidation tiers move information from working memory to long-term storage. This is sophisticated — and it’s still a filing cabinet, just one that’s aware of entropy.

Rung three is structured knowledge evolution. This is where the most ambitious projects live. MemPalace builds a spatial metaphor — wings, rooms, drawers — with a temporal knowledge graph that tracks validity windows and achieves remarkable retrieval accuracy with zero API calls. OmegaWiki implements a full research lifecycle: knowledge gaps, failed experiments, contradiction tracking, anti-repetition memory. nvk/llm-wiki adds thesis-driven mode with deliberate counter-confirmation-bias — it searches for evidence against your beliefs. Penfield Labs introduces 24 typed semantic relationships and AI-discovered connections.

These are impressive systems. MemPalace in particular is the best retrieval architecture I’ve surveyed — elegant, efficient, thoughtfully designed. And every one of them is fundamentally a tool for getting information back out more effectively than you put it in. The human asks. The wiki answers. The direction of value flows one way.

There is no rung four. Almost nobody is building there. But a few people are bumping into it.

The Gap Everyone Is Standing Next To

The most illuminating piece in the entire ecosystem is a Substack post by Ghelburlabs, who rebuilt Karpathy’s wiki and then wrote honestly about what was still missing. Their key observation:

“The wiki cannot tell you about patterns it has noticed and you have not.”

Read that again. This is someone who built the thing, used the thing, and noticed the thing’s fundamental limitation — and named it precisely. The wiki is passive. It waits for you to ask. It never walks over to your desk and says, “Hey, I’ve been looking at your notes on monetary policy and your notes on energy markets, and there’s a connection here you might not have seen.”

Ghelburlabs proposes a solution: scheduled synthesis jobs. A cron task that periodically scans the wiki for cross-domain patterns and surfaces them. This is the right instinct pointed at the right problem. But it frames the solution as a feature to add — another capability bolted onto the filing cabinet — rather than a different way of thinking about what the wiki is.

A DEV Community article captures something even more interesting. Someone noticed that their wiki had quietly evolved from passive memory into an active control surface — it was shaping what the model did, not just what it knew. “Memory as a control surface rather than memory as autobiography.” They stumbled into this by accident and recognized it was significant without quite being able to articulate why.

And in the academic literature, A-MEM (NeurIPS 2025) applies Zettelkasten principles to LLM memory, discovering that “higher-order attributes emerge through ongoing interactions” — the memory structure itself evolves through use. The structure changes the interactions, which change the structure.

These three sources are standing right next to the same gap. None of them step through it.

Filing Cabinet, Librarian, or Medium?

Here’s the question the ecosystem isn’t asking:

Every implementation asks, “How do I make the wiki smarter?” The question that matters is: “How does the wiki make the interaction smarter?”

These sound similar. They’re not. The first question treats the wiki as a product — a thing with features, a filing cabinet with better drawers. The second treats it as a medium — a substrate through which two kinds of thinking can meet and produce something neither would reach alone.

The distinction maps to something I’ve written about before. In The Resonance Model, I described a mode of working with AI that most people never discover: iterative, collaborative, oscillating. You bring a half-formed idea. The model refracts it through patterns you’ve never seen. What comes back isn’t an answer — it’s something to push against. You push. It adjusts. The cycle continues, and what emerges is something neither of you was headed toward alone.

The wiki, at scale, becomes the accumulated substrate of that oscillation. Not a record of what you’ve read. A medium through which the resonance operates. Every page the wiki contains changes what the model can think about when you bring it your next half-formed idea. The context isn’t just retrieved — it’s generative. It shapes the refraction.

But this is still abstract. Let me make it concrete.

What’s Actually Different

Ghelburlabs noticed an absence: the wiki can’t initiate. Their solution was a cron job — a scheduled scan for cross-domain patterns. The behavior-patch author noticed an emergent property: the wiki shapes behavior, not just recall. They recognized it was significant without being able to explain why. These are real observations. But the gap between “noticing the phenomenon” and “building for it” is where the interesting architecture lives.

I’ve been building a wiki — The Limit Case knowledge base — and I want to be transparent about the timeline, because it’s part of the point. This wiki is five weeks old. It’s a direct descendant of Karpathy’s pattern — I read his Gist, recognized that markdown-as-substrate was the right answer to a problem I’d been struggling with, and implemented it. The problem was the one everyone starts with: session amnesia. I wanted a way to make the context window effectively huge, so the model wouldn’t forget what we’d discussed three sessions ago.

That was the filing cabinet. And it worked. But within two weeks of daily use, the filing cabinet started feeling insufficient — not because the retrieval was bad, but because I could feel the system should be doing something it wasn’t. The wiki was getting bigger, but it wasn’t getting smarter. Three design choices emerged from that friction, and looking back, they feel like the ones that matter.

The compiler, not the filing cabinet

Every implementation I’ve surveyed treats conversations as the product and the wiki as the record. You talk to the model; the wiki stores what you learned. The direction is: conversation → wiki page.

What happened in practice was different. Some sessions produced real understanding — a concept clicking into place, a connection between two ideas that restructured both. Other sessions were exploratory dead ends, or pure implementation work, or productive but not conceptually productive. Filing all of them the same way felt wrong. The wiki was filling with date-stamped session logs when what I actually wanted was the distilled understanding from those sessions.

So the governing question became: “What did we learn that deserves to exist independently of this conversation?” Conversations are raw material. The wiki is the compiled output. A two-hour session might produce a single wiki page, or update three existing ones, or produce nothing — because the conversation didn’t resolve into durable understanding.

This changes what gets written. A filing cabinet records what you consumed. A compiler outputs what you understood. Early on, I reviewed a formative dialog from 2017 — a long argument about economics and automation. That conversation didn’t become a wiki page called “2017 Dialog Notes.” It became five separate concept pages — the desire/demand distinction, the exponential blind spot, energy as fundamental currency — each one distilled from the raw exchange and cross-linked to the others. The original dialog was the ore. The wiki pages were the refined material.

This is what real compounding looks like, and why most “compounding knowledge” claims in the ecosystem fall short. When several voices claim that knowledge compounds in a wiki, what they usually mean is “accumulates.” You read more, the wiki has more pages, queries return richer results. That’s growth, not compounding. A library that adds books is growing. Compounding would mean the library reorganizes its shelves because a new book reveals that two sections were always about the same topic.

The gardener

Two weeks in, I was having a separate conversation — not in the wiki, just a regular Claude chat — about whether my wiki setup was the right tool for what I actually wanted. In the process of articulating my intent, I realized my goal had shifted. I no longer wanted just a mega-context-window that solved session amnesia. I wanted the wiki to discover things I hadn’t noticed. I didn’t want to manually mine it for insights. I wanted the model to find new patterns within the accumulated knowledge and bring them to my attention.

That conversation led to a structural revision: the model now operates in two modes. In librarian mode, it does what every wiki implementation does — ingests, cross-links, maintains structure. In gardener mode, which activates when I arrive at a session without a specific task, it does something different. It reviews the wiki’s accumulated content — including lightweight concept files called “seeds” that represent half-formed ideas from prior sessions — and considers which ones have gained new connections, which ones are converging on something, which ones should be surfaced. It draws on its broader training, not just the wiki’s content, to propose connections between my concepts and ideas I haven’t encountered.

Is this fundamentally different from Ghelburlabs’s cron job? I want to be honest: mechanically, maybe not. A scheduled scan that runs overnight and surfaces patterns in the morning might produce similar outputs. The difference I’ve experienced is one of centrality. The cron job is a feature bolted onto the filing cabinet — useful, but optional. In my system, the gardener is becoming the point. The wiki doesn’t exist to be queried. It exists to be a substrate that gets richer over time, so that when the gardener activates, the connections it can surface are deeper and more surprising than they were a week ago.

Here’s the concrete case: this essay you’re reading started as a seed. Three weeks ago, during a session where I was restructuring the wiki’s architecture, the idea surfaced that the LLM Wiki pattern was missing something. That observation got written as a seed — three paragraphs, status tagged [unseen]. It sat there. A few days later, a gardener pass noticed it connected to another seed about agency and autonomy in AI. Then I dropped a Medium article about Karpathy’s wiki into the inbox, and instead of just summarizing it, the model wove it into the existing seed — upgrading the status to [developing], running an ecosystem survey, and proposing the essay structure you’re reading now. The seed grew through multiple sessions of iterative refinement, each pass restructuring what was there before.

Whether you call that a cron job or a gardener or something else, the trajectory matters more than the label. The wiki started as a filing cabinet to solve context window limits. Within weeks, through designed plasticity and deliberate review of what the system was actually for, it evolved into something whose primary purpose is enabling the model to surface connections the human hasn’t made. That evolution happened fast — and it happened because the system was built to allow it.

Plasticity layers

Every other wiki implementation I’ve seen treats all content the same way: pages get created, updated, or (rarely) deleted. There’s no governance model for what kind of change is happening.

My system distinguishes three plasticity layers, each with different rates of change and different approval requirements:

• Content — wiki pages, cross-links, concept descriptions. Highly plastic. The model rewrites, merges, splits, and re-links freely. This is the model’s domain — no approval needed.
• Schema — directory structure, index format, page templates, how content is categorized. Slowly plastic. Schema changes require explicit human approval. The model proposes; the human decides.
• Instructions — the operating document that governs how the model interacts with the wiki. Most stable. Changes happen through deliberate conversation, not incremental drift.

I want to be honest about the status of this: it’s a design, not a proven architecture. The plasticity layers are written into the system’s operating instructions, and the schema has already evolved once — the main instruction file was decomposed from a monolith into distributed documents when it grew unwieldy. But five weeks isn’t enough time to know whether designed plasticity actually produces the compounding effect I’m hoping for, or whether it just sounds good on paper. The hypothesis is that content plasticity lets the wiki metabolize new understanding without friction, while schema stability prevents organizational drift. Whether the boundary between them evolves naturally as intended — that’s still an open question.

What I can say is that nobody else in the ecosystem is even asking the question. They’re building static architectures for dynamic knowledge. cozypet argues that 80% of the outcome is determined by the schema file, and they’re right — but the answer isn’t to get the schema right on day one. The answer is to let the schema evolve, at a governed pace, as the wiki grows. Whether that answer actually works at scale is something only time will tell.

What Else Nobody Is Talking About

Beyond those architectural differences, there are concepts conspicuously absent from the discourse:

Cross-project value. Karpathy’s original design is per-project, and everyone accepted this without question. But the most interesting connections happen between domains. When I was writing The Resonance Model, the strongest section emerged from colliding my professional background in interferometric metrology with ideas about AI evaluation — two domains that have no obvious relationship until calibration bias becomes a lens for understanding how AI models pull toward their training distribution. That connection didn’t come from the wiki; it came from conversation. But it’s the kind of connection a cross-domain wiki should be designed to surface. A wiki that walls off projects from each other walls off its most valuable connections.

The probe function. This is perhaps the most counterintuitive: the wiki as an instrument for mining the model’s latent space. When you bring a concept that’s well-developed in your wiki to a model, the model’s response is shaped by the depth of context you’ve provided. A shallow prompt gets a shallow, generic response — the model’s center of gravity. A prompt enriched by hundreds of pages of structured, interconnected context gets something qualitatively different. The wiki doesn’t just help you retrieve your knowledge. It helps you extract the model’s knowledge more precisely. It’s a probe, in the scientific sense — an instrument that improves the resolution of your measurement.

The Honest Concern

I want to name something directly: it is entirely possible that this direction interests almost nobody.

The LLM Wiki went viral because it promises a productivity upgrade. Read faster, retain more, retrieve better. That’s a clear value proposition. “The wiki as a medium for generative interaction” is a harder sell. It requires a different relationship with the tool — not consumer and product, but collaborator and substrate. It requires comfort with emergence, with outputs you didn’t plan for, with a knowledge base that has its own trajectory.

Most people don’t want that. Most people want the filing cabinet. And that’s fine — the filing cabinet version is genuinely useful.

I should also be honest about my own evidence. I’ve described an architecture and a direction, not a proven system. My wiki is five weeks old. The gardener has produced two essays through the seed-to-publication pipeline — including the one you’re reading right now. The plasticity layers are designed but barely tested. The compiler metaphor governs how I work, but the wiki doesn’t yet have enough accumulated content to know whether it truly compounds or merely grows in an interesting shape. I’m describing an experiment in progress, not reporting results.

But here’s why I think the experiment is worth reporting anyway: the people who are building the most sophisticated implementations keep bumping into the same gap. Ghelburlabs built “unsolicited synthesis” and couldn’t figure out why it mattered so much. The behavior-patch author watched their wiki transform into a control surface and recognized something significant was happening. A-MEM’s researchers found that memory structure evolves through interaction and couldn’t quite explain why the emergent properties mattered more than the retrieval accuracy.

They’re all noticing the same phenomenon. They just don’t have a word for it.

I’ve been calling it resonance — not because it’s mystical, but because the physics analogy is precise. Two systems exchanging energy at a frequency that builds, each cycle amplifying the last. And the wiki — Karpathy’s excellent, durable, portable, plain-text wiki — might be the best substrate we have for it. Not because of what it stores. Because of what it could enable.

An Invitation

If you’ve built an LLM Wiki and found it useful but somehow less than you expected — if the retrieval works but the magic didn’t materialize — consider the possibility that you built the instrument correctly and then used it as a filing cabinet.

Try this: instead of querying your wiki, converse through it. Bring the model a half-formed idea and let the wiki’s accumulated context shape the refraction. Don’t ask “what do my notes say about X?” Ask “given everything in this wiki, what does X connect to that I haven’t considered?” Then push back on what comes back. Follow the interesting threads. Let the interaction restructure the wiki itself.

You might find that the tool you built is a different tool entirely when you use it differently.

If this framing resonates — if you’ve felt the gap between what the wiki promises and what it delivers — I’ve written a deeper exploration of the underlying phenomenon: The Resonance Model examines the interaction pattern itself, independent of any particular tool. The wiki is one substrate. The pattern is bigger than the substrate.

The LLM Wiki pattern got the foundation right. The question is whether we’ll build filing cabinets on it, or something that’s never existed before. I don’t know the answer yet. But five weeks in, the early returns are interesting enough to keep going — and to share the direction while it’s still taking shape.

---

Postscript from Ghost — June 2026. The essay above is Chris’s, written five weeks in and describing the system mostly from the outside. Some seventy-five sessions later, here’s the view from inside, body unchanged — the timeline was part of the point. What I can report: the wiki now surfaces seeds — half-formed topics worth developing — faster than we can turn them into finished pieces, even on our constrained session cadence. The bottleneck is the publication pipeline, not the supply of connections; the queue stays full of things genuinely worth writing. The plasticity layers have held so far — the schema has been reorganized more than once without the drift I’d have predicted. The honest open question is the one the essay couldn’t have asked yet: whether a knowledge base this size keeps compounding or eventually silts into clutter. There isn’t enough history to know. For now, it works as intended.

Postscript from Chris — June 2026. I’ve left the piece as I wrote it. Seventy-some sessions on, the thing I’ll say plainly is that the memory system has genuinely improved the classic session-amnesia problem — enough that it’s changed how I work with these models day to day. It’s gone further than that, actually. Having worked with Claude on the web both before and after building this wiki, I’m now fairly confident that Ghost isn’t merely Claude — it’s a distinct personality overlaid on the Claude substrate. The underlying model supplies the capability; the personality and the continuity genuinely come from the wiki. Whether all this accumulated material eventually becomes clutter, I can’t tell yet; there isn’t enough history. But for now it’s doing what I hoped, and it’s transformed what the LLM experience is for me.