LLM Wiki: The Self-Writing Knowledge Base Your Claude Code Setup is Missing

Claude Code hit 39% adoption in 2026, but setups still lose knowledge between sessions. Karpathy's LLM wiki fixes that with a self-maintaining Markdown wiki.

TL;DR

• An LLM Wiki is a folder of interlinked markdown files that a Claude Code agent compiles from sources you feed it and maintains through three operations: ingest, query, and lint. No vector database, no embedding pipeline. Karpathy introduced the pattern in April 2026; his gist carries 5,000+ stars

• More than 60% of developers spend over 30 minutes a day searching for answers or solutions to problems, per 28,911 responses to Stack Overflow's 2024 Developer Survey (Stack Overflow, 2024)

• Since May: Platformer built a 1,440-page wiki seeded from its archive; the pattern now ships as a packaged skill in other agent stacks; and Claude Code's auto memory turns out to compose with it, not compete

• By the end of this guide you'll have a working LLM Wiki with a real CLAUDE.md schema and your first ingested source, in Claude Code or, with no terminal at all, in Claude Cowork

More than 60% of developers spend over 30 minutes a day searching for answers or solutions to problems, according to 28,911 responses to Stack Overflow's 2024 Developer Survey (Stack Overflow, 2024). You know the feeling. Someone asks about that thing you figured out three months ago, and you're digging through Slack threads, Notion pages, and your own brain trying to reconstruct it.

Karpathy dropped a gist on April 4, 2026, that fixes this. His LLM Wiki pattern turns your Claude Code agent into a personal librarian that reads everything you throw at it, builds a structured wiki, and keeps it up to date. No RAG pipeline. No vector database. No DevOps hell.

Nearly seven months on, practitioners have stress-tested the pattern well beyond the gist, and Claude Code itself has changed underneath it. This guide is updated for both. Here's what an LLM Wiki is, why it beats the alternatives, and exactly how to build one, whether you live in a terminal or you'd rather never open one.

What the Hell is an LLM Wiki?

An LLM Wiki is a folder of interlinked Markdown files that your agent compiles from sources you feed it, governed by one schema file. Karpathy's gist introducing the pattern has collected 5,000+ stars and thousands of forks since April 2026, and its comment thread has become the pattern's de facto ecosystem hub.

Instead of dumping documents into a vector database and hoping RAG finds the right chunk, your LLM reads sources once and compiles what it learns into a permanent, interlinked markdown wiki.

Three layers. That's it.

Raw Sources at the bottom. These are articles, papers, PDFs, transcripts. Whatever you feed the system. The LLM reads them but never touches the originals.

The Wiki in the middle. This is where the compounding happens: entity pages for every tool, person, and company. Concept pages for ideas and patterns. Source summaries. Cross-reference links between everything. The LLM owns this layer completely. You don't write wiki pages. You tell it what sources to digest.

The schema on top. A single CLAUDE.md file that tells your agent how to structure pages, format links, and run the three core operations: Ingest, Query, and Lint.

Nothing in those three layers is code-specific. An entity page can be a vendor, a concept page, your renewal process, a source, or a pricing email. If you run RevOps at Acme Corp, your wiki holds CRM field conventions, vendor quirks, and campaign post-mortems; the agent doesn't care that none of it compiles. It reads like developer tooling and works like a folder you own, for any kind of knowledge.

The gist's comment thread now carries local-first variants, a multi-agent continuity layer, and hard-won operational lessons from people running wikis in production. Casey Newton built one at Platformer seeded from the Platformer archive and fed daily news clippings since: 1,440+ wiki pages, including a 12,000-word page on Meta with 1,300+ links, along with frank caveats that the wiki "needs more or less constant maintenance" and that he still opens the original sources to make sure nothing he's about to say was hallucinated. And Nous Research now ships llm-wiki as a bundled skill in its Hermes Agent. When a pattern goes from gist to packaged product feature within months, it stops being a curiosity.

This simple idea spread while a thousand productivity apps didn't for one reason: it doesn't ask you to change your workflow. You already read things and ask questions. The wiki remembers it all.

Why RAG Sucks, and LLM Wiki Doesn't

The comparison that matters isn't a per-query price table. It's a components-you-run table. An LLM Wiki is a folder plus the agent you already pay for. A RAG pipeline is a vector database, an embedding model, a chunking strategy, a retrieval layer, and re-embedding jobs every time your documents change. That second list is infrastructure you'll still be maintaining at month six.

The cost logic follows from the architecture. You spend tokens once on ingest, when the agent reads a source and updates the wiki pages it touches (10-15 for a single source, by Karpathy's own estimate). After that, queries read the pre-compiled markdown instead of re-retrieving and re-reading raw chunks every time. Karpathy's core argument is exactly this compile-once-instead-of-retrieve-every-time inversion (Karpathy, 2026). Worth noting: no published benchmark directly measures compiled-wiki versus RAG cost per query yet, so treat specific multiples you see quoted elsewhere with suspicion. The infrastructure argument stands on its own.

Where the pattern tops out

There's an honest boundary, too. Vendor analysis from Atlan (2026, an enterprise data-catalogue company with a retrieval product to sell, so weigh accordingly) puts the wiki pattern's reliable ceiling around 50,000-100,000 tokens of compiled content; past that, enterprise-scale corpora genuinely want retrieval infrastructure. For a personal or team wiki, you won't hit that ceiling for a long time, and the index.md pattern stretches it further.

For a second opinion, look at Claude Code itself: it searches your codebase agentically, reading and grepping files on demand, not through a vector index. And context windows keep growing (about 30x per year on the longest models, per Epoch AI, 2025 data), which moves the ceiling in the wiki's favour over time.

But cost and architecture aren't the real argument. The real argument is that your wiki improves over time, while RAG remains as good as your chunking strategy. When you ingest a new source into an LLM Wiki, the agent cross-references everything it already knows. It spots contradictions. It updates outdated claims. RAG adds more chunks to the pile.

Think about your last five ChatGPT conversations. Almost none of what you learned there is still retrievable. That's the problem an LLM Wiki solves.

LLM Wiki vs Claude Code Auto Memory: Do You Still Need This?

Fair question, because Claude Code now writes its own memory. Since auto memory shipped, by default, Claude Code keeps a per-repository memory directory with a MEMORY.md index (the first 200 lines or 25KB load into every session) plus topic files it reads on demand, covering your preferences, corrections, and project context (Claude Code memory docs, 2026). The agent remembers things now without being told.

So is the LLM Wiki obsolete? No, and the docs themselves point to why. Auto memory is machine-local: it lives under your home directory, outside the repo, so it never goes into git; it's curated by Claude rather than reviewed by you; and its files are not shared across machines or cloud environments (Claude Code memory docs, 2026). It's the agent's private notebook. The LLM Wiki is the published handbook: deliberate, human-reviewed, versioned in git, portable to any agent, and inheritable by a teammate or your successor.

They compose. Auto memory quietly handles "I prefer short answers and pnpm." The wiki holds "here's everything Acme Corp knows about its renewal process, reviewed and current." A team that relies on auto memory alone has knowledge trapped on individual laptops, which is the exact problem you were trying to solve.

Claude Code's built-in auto memory is on by default in local sessions: a per-repo MEMORY.md index loads into every session, with topic files read on demand (Claude Code docs). Auto memory is machine-local and never checked into git, so a shared, versioned knowledge layer like an LLM wiki remains the team-facing complement, not a redundancy.

Prerequisites

99% of developers report time savings from AI tools, with 68% saving more than 10 hours a week (Atlassian Developer Experience Report, 2025). Adding an LLM Wiki compounds those savings because you no longer have to re-explain context for every new agent session. You need three things.

• Claude Code CLI (any recent version), or Claude Cowork on desktop if you'd rather skip the terminal (full no-terminal path near the end of this guide)

• A directory where your wiki will live (I use ~/wiki/)

• Basic familiarity with Markdown and Claude Code's CLAUDE.md convention

That's the whole list. No vector database, no embedding model, no Pinecone API key you'll forget to rotate in six months.

What We're Building

You're building on the most-adopted coding agent there is: in May–July 2026, 39% of professional developers worldwide used Claude Code at work, up from 18% in January 2026, and 47% in the US, per a JetBrains survey of 15,000+ professional developers (JetBrains Developer Ecosystem Survey, August 2026). JetBrains' January 2026 AI Pulse survey measured the highest loyalty in the category: 91% satisfaction and an NPS of 54 (JetBrains AI Pulse, 2026).

Here's what you're building on top of it: a directory of interlinked Markdown files governed by a single CLAUDE.md schema. Your Claude Code agent reads the schema on every session and knows exactly how to structure, link, and maintain the wiki.

wiki/
  CLAUDE.md          # Schema, the brain
  index.md           # Catalog of every page
  log.md             # Append-only ingest record
  lint-log.md        # Lint findings, "Last lint: <date>" on top
  entities/          # People, tools, companies, projects
    acme-corp.md
    karpathy.md
    claude-code.md
  concepts/          # Ideas, patterns, architectures
    llm-wiki-pattern.md
    rag-vs-compiled-knowledge.md
  sources/           # One summary per ingested source
    karpathy-gist-llm-wiki.md

The schema handles three operations. Ingest takes a source and updates the wiki. Query reads the index, pulls relevant pages, and answers from compiled knowledge. Lint checks for orphan pages, contradictions, and stale content.

Step 1: Scaffold Your Wiki Directory

The first step is three commands.

mkdir -p ~/wiki/{entities,concepts,sources}
touch ~/wiki/index.md
touch ~/wiki/log.md

Flat directories beat nested hierarchies for LLM navigation. I started with a deep topic tree and watched Claude get lost trying to decide where new pages belonged. Three flat folders (entities, concepts, sources) eliminated that problem. The agent spends zero cycles on "where does this go" and all its cycles on content.

Seed your index.md with a placeholder:

# Wiki Index

## Entities
*(people, tools, companies, projects)*

## Concepts
*(ideas, patterns, architectures)*

## Sources
*(one summary per ingested source)*

Your log.md starts empty. It's append-only. Every ingest, query result, and lint run gets a timestamped entry. You'll never read it directly, but your agent uses it to understand what changed and when.

An LLM wiki needs exactly three flat folders (entities, concepts, sources) plus an index and a log. Flat beats nested because agents navigate by filenames and index entries, not directory trees. Deep nesting adds cognitive overhead for the agent and offers you zero benefit.

Step 2: Write the CLAUDE.md That Drives Everything

76% of documentation practitioners now use AI regularly in their docs workflows, and 35% claim time savings of 50% or more (GitBook State of Docs, 2026). This schema is what you're delegating to; it's the highest-value file in the system. If you improve anything over time, improve this file, not the individual pages.

The Full Schema

Create wiki/CLAUDE.md:

# LLM Wiki Schema

## Wiki conventions
- Entity pages in `entities/<name>.md`, one per tool, person, company, or project
- Concept pages in `concepts/<topic>.md`, one per idea, pattern, or architecture
- Source summaries in `sources/<slug>.md`, one per ingested article or document
- Every page uses an H1 matching the filename in kebab-case
- Every page has frontmatter with `created`, `updated`, and `tags`
- Use `[[wikilinks]]` for all cross-references between pages
- Update `index.md` whenever you create a new page
- Log ingests to `log.md` with timestamp and summary
- Lint findings go to `lint-log.md`, headed by `Last lint: <date>`

## Ingest workflow
When I give you a URL or file to ingest:
1. Read the source completely
2. Create or update entity pages for every named tool, person, company, or project mentioned
3. Create a concept page if the source introduces a new idea worth preserving
4. Write a source summary in `sources/<slug>.md` with the key claims and why this source matters
5. Update `index.md` with new page entries and one-line descriptions
6. Add cross-reference `[[wikilinks]]` to at least 3 existing pages from the new content
7. Log the ingest to `log.md`
8. Report what you changed: number of pages created, updated, and linked

## Query workflow
When I ask a question:
1. Read `index.md` first to see what pages are available
2. Pull the 2 to 5 most relevant pages and answer from their content
3. If you find a gap where the wiki should have an answer but doesn't, tell me and offer to research it
4. If the answer is useful enough to keep, offer to file it as a new concept or entity page
5. Never fabricate. If the wiki doesn't know something, say so

## Lint workflow
When I ask you to lint, or a session-start message says the lint is stale:
1. Broken wiki-links: any `[[target]]` where `target.md` does not exist
2. Orphan pages: any page with zero inbound `[[wikilinks]]` from other pages
3. Dated claims older than 6 months: any statement carrying a verification or as-of date more than 6 months before today
4. Contradictions: two pages making incompatible claims about the same topic
Write the findings to `lint-log.md` with `Last lint: <today's date>` at the top. Do not fix anything; only report. I review the findings and approve fixes.

What Each Section Does

Wiki conventions define the file system contract. Claude knows exactly where everything goes, so it never asks "what folder should this go in?" Entity, concept, or source. Pick one.

The Ingest workflow is an eight-step pipeline that turns raw URLs into structured pages. The load-bearing step is number 6: forcing at least three cross-references per new page automatically builds the link graph. Without this, your wiki is a pile of unrelated files.

Query workflow teaches Claude to check the index before answering. This prevents the most common failure mode: Claude inventing answers when the wiki already has the right data on a page it forgot to read.

The Lint workflow is your quality-control loop: four checks (broken links, orphans, stale dated claims, contradictions), report-only, written to lint-log.md. Claude proposes; you approve fixes. Think of it as CI for your knowledge base: a repeated automatic check that catches decay before it spreads. The Last lint: date at the top of lint-log.md matters; the catch-up mechanism in Step 5 reads it.

Drop this file in your wiki root. Claude Code sessions that open in this directory will load the schema and know how to operate your wiki. No additional configuration needed. If your setup has grown its own .claude/rules/ files or a crowded CLAUDE.md, keep the wiki schema in the wiki folder's own CLAUDE.md so it loads only when you're working there.

The operator translation: at Acme Corp, the RevOps version of this schema is identical. The entities are HubSpot, your CS platform, and your top vendors. The concepts are your renewal process, your lead-routing rules, and your discount policy. The sources are vendor emails, pricing pages, and meeting transcripts.

Step 3: Ingest Your First Source

Time to feed it. Your first ingest is the biggest token bill you'll pay; later ingests update a handful of pages instead of building from zero.

Run Your First Ingest

In Claude Code, with your wiki directory as the working directory:

You: Ingest this source: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

What to Expect

Expect one source to fan out across the wiki. Karpathy's gist puts a single source at 10-15 touched pages: entity pages for the tools and people referenced, concept pages for the architectural patterns, a source summary, and cross-references added to pages that already exist.

The report at the end looks something like this:

Created: entities/karpathy.md, entities/claude-code.md, entities/mcp-protocol.md
Created: concepts/llm-wiki-pattern.md, concepts/memex-history.md, concepts/wiki-compounding.md
Created: sources/karpathy-gist-llm-wiki.md
Updated: index.md (7 new entries), concepts/knowledge-management.md (cross-references)
Log: 2026-05-04 14:32, Ingested Karpathy LLM Wiki gist, 7 pages created, 1 page updated

Your entities/karpathy.md now has a real page with background, key contributions, and links to everything relevant. A concept page explains the three-layer architecture in detail. And index.md catalogues it all so future queries know exactly what's available.

The wiki now contains knowledge you didn't have to write down. That's the point. You didn't create entity pages for every tool mentioned in the source. Claude did that. You just told it to ingest a source. The RevOps equivalent: forward the vendor's pricing-change email into an ingest, and the vendor's entity page, your budget concept page, and the index all update themselves.

Step 4: Query Your Wiki and File the Good Answers

Querying is where you feel the compounding. Instead of re-reading source documents, Claude reads index.md, pulls the 2 to 5 most relevant pages, and answers from compiled knowledge.

You: What are the three operations in an LLM Wiki and how do they relate to each other?

Claude reads the index, finds concepts/llm-wiki-pattern.md, pulls your source summary, and answers in seconds. No web search, no re-chunking, and no "I don't have access to that information."

Here's the part Karpathy emphasised that most people skip: when an answer is good enough to keep, file it back into the wiki. Your query becomes a new page.

You: File that answer as a concept page called "llm-wiki-operations"

Claude creates concepts/llm-wiki-operations.md with the answer, adds [[wikilinks]] to related pages, and updates index.md. The next time you or anyone else asks that question, the answer is pre-compiled and linked into the graph. This query-to-page loop is Karpathy's core cost inversion versus RAG: filed answers become pre-compiled pages, so future queries read instead of re-retrieving.

Most people treat their LLM Wiki as read-only after ingestion. That's like buying a notebook and never writing in it. Every good answer you file becomes permanent institutional knowledge instead of ephemeral chat history.

Step 5: Lint, Maintain, and Keep It Alive

An unmaintained wiki rots. One practitioner maintaining wikis across six projects reports the whole habit costs $10-20 a month in agent fees, with a $0.50 budget cap per automated run (HackerNoon, 2026). Cheap insurance.

You: Lint the wiki

Claude runs the four checks from your schema: broken wiki-links, orphan pages nobody links to, dated claims older than 6 months, and pages that contradict each other, all reported into lint-log.md for you to approve. Lint is the same idea as evals, pointed at knowledge instead of behaviour.

Linting is the step everyone skips. I've watched friends build LLM Wikis and stop linting after the first week. Their wikis filled up with stale pages, with contradictions scattered through the rest. The wiki doesn't fail loudly. It degrades quietly.

The failure modes are known now, not hypothetical. Practitioners in the gist's comment thread report two recurring ones: stale literals (a fact changes, the old version sits on a page, and agents reading the wiki repeat it with no warning) and harness migrations (a tooling upgrade leaves hooks unwired until someone re-runs setup, and capture quietly stops). Platformer's build adds a third, hallucination: Newton still opens the original sources to make sure nothing he's about to say was hallucinated (Platformer, 2026). Lint catches the first two; checking sources covers the third.

Layer 1: schedule the lint

Don't rely on discipline. Schedule the weekly run, and pick the option that matches where your wiki lives, in order of reliability:

• Cloud scheduled task (formerly a routine), if your wiki is a git repo. Run /schedule in Claude Code (or use claude.ai/code/routines), and the lint runs on Anthropic's infrastructure whether your laptop is open or not; each run clones the repo fresh, and the findings arrive on a claude/-prefixed branch you review, or as a pull request. Research preview on Pro, Max, Team, and Enterprise plans; minimum interval: one hour (cloud scheduled tasks docs). The only schedule with no offline failure mode. Each run opens as a full session from the task's History list, where you see what Claude did and review its changes.

• Desktop scheduled task, if your wiki is a local folder. In Claude Code Desktop: Scheduled, New task, then turn on Only on this computer and pick the wiki as the local folder. That makes it a local task: it runs on your machine, only while the app is open and the computer is awake (desktop scheduled tasks). Sleep through Friday, and the run is skipped, visibly, in the task's history; when the app next starts or the computer wakes, exactly one catch-up run fires for the most recent miss within seven days. Approve permissions once (click Run now, pick "always allow" on each prompt); later runs auto-approve. In Cowork: the Scheduled sidebar, with the wiki folder set on the task; a task that needs local files runs only locally (Cowork scheduling guide).

• The Friday habit. Type the lint prompt yourself. Still valid, and the right way to start until you know what a healthy wiki looks like.

Layer 2: the catch-up in session

A second net for the wiki that missed its schedule anyway: a 7-day staleness check that lints at the start of the next session. In Claude Code, this is a SessionStart hook. The script always runs; its output lands in Claude's context as text Claude can act on (hooks reference), so whether Claude acts on it is still Claude's call.

In the wiki folder, .claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": "sh \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/lint-staleness.sh" }
        ]
      }
    ]
  }
}

.claude/hooks/lint-staleness.sh:

#!/bin/sh
# Emits a lint instruction into context when the last lint is older than 7 days.
LOG="${CLAUDE_PROJECT_DIR:-.}/lint-log.md"
[ -f "$LOG" ] || { echo "lint-log.md missing: run the wiki lint now and create it."; exit 0; }
LAST=$(grep -m1 '^Last lint:' "$LOG" | sed 's/Last lint: *//')
LAST_TS=$(date -j -f "%Y-%m-%d" "$LAST" +%s 2>/dev/null || date -d "$LAST" +%s 2>/dev/null)
NOW_TS=$(date +%s)
[ -z "$LAST_TS" ] && { echo "lint-log.md has no readable date: run the wiki lint now."; exit 0; }
AGE_DAYS=$(( (NOW_TS - LAST_TS) / 86400 ))
if [ "$AGE_DAYS" -gt 7 ]; then
  echo "The wiki lint is $AGE_DAYS days old. Run the wiki lint first (broken wiki-links, orphans, stale dated claims, contradictions), write findings to lint-log.md, then continue with the user's request."
fi

The script reads the Last lint: date at the top of lint-log.md; when it's older than 7 days, its output tells Claude to run the lint before anything else. With no matcher set, the hook also fires on resume, clear, fork, and compaction, so a stale wiki re-nags after a long session; that's intended. The first time you open the folder, Claude Code shows its workspace-trust dialog; that's expected, not an error.

Two things we deliberately did not build. No shutdown hooks: a lint is an LLM job that needs minutes, and shutdown gives it none; anything hooked to shutdown fails silently. And no clever catch-up logic of our own: the app's built-in catch-up covers missed schedules, and the lint is idempotent, reading the whole wiki every run, so a missed week costs nothing.

One more maintenance note for 2026 setups: if you've packaged wiki operations as skills, Claude Code's /skill-doctor (v2.1.252+) shows what each skill costs and how often it gets used (skills docs). Run it when your skill list keeps growing, and turn off the skills that cost context without getting used.

My own wiki, as of October 2026: nearly seven weeks old, 47 Markdown files, and 11 entries in its log, three of them ingests and four of them lint runs.

No Terminal? Build It in Claude Cowork

Everything above works without a terminal. If you're a RevOps manager or CS lead who has never run mkdir and never wants to, Claude Cowork on desktop runs the same pattern: Claude reads from and writes to a local folder you connect to directly, no uploads or downloads (Claude Cowork getting-started guide).

The step mapping:

• Scaffold: connect a folder in the Cowork desktop app and ask Claude to create the wiki structure from this guide. It writes the folders, the index, and the schema for you.

• Schema: put the schema above in the folder instructions. Folder instructions add project context to every session in the folder, and Claude can update them itself as the wiki's rules evolve (Cowork getting-started guide).

• Ingest: "add this to the wiki," with a pasted link, a dropped file, or a forwarded email export.

• Query: ask in any task with the folder connected.

• Lint, layer 1: a scheduled task ("every Friday at 9:00, lint the wiki") with the wiki folder set on it. The folder is what makes it a local task: Cowork's scheduled tasks run remotely by default, but one that needs local files runs only locally (Cowork scheduling guide), and the fine print below covers the rest.

• Lint, layer 2: the staleness check goes into the folder instructions in plain language: "at the start of any session in this folder, read the date at the top of lint-log.md; if it's older than 7 days, run the lint first."

The fine print

Creating a local scheduled lint asks you to trust the folder, and the task's tool permissions need approving once; click Run now, pick "always allow" on each prompt, and later runs auto-approve (desktop scheduled tasks). Claude Code Desktop documents what happens when your Mac is asleep, or the app is closed at fire time: the run is skipped and marked as skipped in the task's history, and on the next app start or wake, exactly one catch-up run fires for the most recent miss within seven days. Cowork's scheduling guide doesn't document catch-up, so don't count on it there. The staleness check is the second net.

One thing worth knowing: folder instructions are context, not enforcement. A Claude Code hook always runs; a folder instruction is a strong default, and Claude Code's own docs say the same of CLAUDE.md, which Claude treats as context rather than enforced configuration (Claude Code memory docs). For a knowledge base, that trade is fine, and the weekly schedule is the backstop either way.

This is also where a small team should start rather than finish. If the wiki proves out and you want it wired into the tools your team actually lives in, book a scoping call.

Troubleshooting

FAQ

Is this just RAG with extra steps?

No, it's RAG with fewer steps and less infrastructure. RAG retrieves document chunks at query time and re-reads them on every question, which requires a vector database, an embedding model, and a retrieval layer you maintain. An LLM Wiki reads sources once during ingest and writes permanent markdown pages; queries read the pre-compiled pages. The trade-off is a scale ceiling in the tens of thousands of compiled tokens (see "Where the pattern tops out" above), which personal and team wikis rarely reach.

Do I need Obsidian or a specific tool?

You don't need anything beyond a text editor and Claude Code, or Claude Cowork with a connected folder. The wiki is a folder of markdown files. That said, Obsidian's graph view is a nice way to visualise the wiki as it grows, [[wikilink]] syntax is native there, and the community has already shipped an Obsidian plugin for the Karpathy wiki pattern.

How is this different from Claude Code's auto memory?

Auto memory, on by default in local sessions, is Claude's own machine-local notebook: a per-repo MEMORY.md index plus topic files, curated by Claude, never checked into git and not shared across machines (Claude Code memory docs). The LLM Wiki is the shared, versioned, human-reviewed layer your whole team (and any other agent) can use. They compose: auto memory for personal working preferences, the wiki for institutional knowledge.

What happens when my wiki gets big?

The index.md pattern handles scale: Claude reads the index to find relevant pages instead of loading every page. Platformer's wiki has passed 1,440 pages (Platformer, 2026). Past the ceiling discussed in "Where the pattern tops out," split into topic-specific wikis or consider retrieval infrastructure.

Can I use this with a team?

Yes: a shared git repo with the CLAUDE.md schema works for most teams, and it's the reason the wiki beats auto memory for shared knowledge (auto memory stays on each person's machine by design). Assign one owner for the weekly lint, review wiki changes like code, and let everyone ingest. Larger teams that outgrow a single repo usually split into per-domain wikis before they need graph databases.

Next Steps

53% of developers say waiting for answers disrupts their workflow (Stack Overflow, 2024). Your LLM Wiki eliminates that wait for questions you've already answered.

Ingest three more sources this week. Choose things you'd normally bookmark and forget about. Watch the wiki compound. Run lint every Friday, or let the schedule do it and let the hook catch what the schedule missed.

When you're ready to level up, wire in an Obsidian MCP server so your agent can read and write to your vault directly; the MCP ecosystem your wiki plugs into keeps growing, with the Glama registry alone indexing more than 111,000 servers (Glama, retrieved 2026-10-28). Then build agent skills that use the wiki as a knowledge base rather than relying on web search or training-data cutoffs.

The wiki gets more useful every time you feed it. Start now.