Guide
Karpathy's LLM Wiki: What It Is and How to Build One
Karpathy's LLM Wiki explained: add documents, build linked pages, ask questions with sources, and check what changes when evidence is updated.
01
An LLM wiki is a folder of Markdown pages that an AI keeps up to date from your sources, so answers build on earlier work instead of starting over.
02
It has three layers (sources, wiki, schema) and three jobs (ingest, query, lint).
03
Try one complete workflow: add documents, build pages, ask with sources, then review an update.
01
What Karpathy's LLM Wiki is
In April 2026 Andrej Karpathy published a GitHub gist called LLM Wiki. The pattern is to ingest sources into linked Markdown pages, so later questions can start from a maintained synthesis instead of searching the whole collection from scratch. When a source changes, it still needs to be read again and affected pages checked; answers may also need to return to cited sources.
The gist is an idea file, not an app or a required setup. The starter rules and retry-policy exercise below are our teaching examples; shared rules across AI tools are optional. This article cites Karpathy's public note as the source of the pattern; it does not imply that Karpathy endorses Wenlan.
Schema
CLAUDE.md or AGENTS.md: how the wiki is organized
instructions for the agent; review its changes
Raw sources
articles, papers, notes, files
read-only
Wiki
one Markdown page per topic, with links
index.md · log.md
Answer
with links to the pages and sources used
lint: find contradictions, stale claims, orphan pages
02
The three jobs: ingest, query, lint
Karpathy describes three recurring activities: ingest, query and lint. A useful answer can become a new page. These instructions guide the agent; you still review its changes.
- Ingest: read a new source, write its summary page, update the pages it affects, then update index.md and log.md.
- Query: read index.md, open only the pages needed, and answer with links. A good answer can be saved as a page.
- Lint: look for contradictions, claims a newer source replaced, pages nothing links to, and topics with no page yet.
03
LLM wiki vs RAG
RAG and an LLM wiki can work together. The wiki stores a maintained synthesis in linked pages; RAG retrieves relevant source chunks, including passages from wiki pages, to help answer a question. Use a wiki when you want that synthesis to remain readable and editable between questions. Retrieval still helps find the right evidence, and changed sources still need ingestion and review.
RAG
- Question
- Search source chunks
- Answer
The source collection stays available; chunks may recur.
LLM wiki
- Source
- Ingest into maintained pages
- Question
- Start from pages
Update pages when sources change.
04
LLM wiki implementations you can use
Most people start from an existing project. GitHub lists more than 6,400 repositories with "llm-wiki" in the name or description, most created since April 2026. The two most-starred, nashsu/llm_wiki and claude-obsidian, each have more than 15,000 stars (October 2026).
| Project | What it is | Good fit if you |
|---|---|---|
| Karpathy's gist | The original note: a description, not software | want to write your own setup (below) |
| nashsu/llm_wiki | Cross-platform desktop app | want a standalone app for your documents |
| AgriciDaniel/claude-obsidian | Claude Code + Obsidian setup | already keep your notes in Obsidian |
| Astro-Han/karpathy-llm-wiki | Agent Skills package for Claude Code, Cursor, and Codex | want the pattern as an agent skill |
| Wenlan | Desktop app with an MCP server | use several AI tools and want pages kept current without losing your edits |
05
Build an LLM wiki with Claude Code or Codex
You need an AI tool that can edit local files, such as Claude Code or Codex, and an empty folder. Create this layout and run git init. Use Obsidian or any Markdown editor to read the pages.
my-wiki/
CLAUDE.md # Claude Code; use AGENTS.md for Codex
raw/ # your sources; the agent never edits these
wiki/
index.md # one line per page
log.md # one line per ingest, query, or lint
sources/ # one summary page per source
topics/ # one page per topic, person, or idea06
Add documents, build the wiki, then check an answer
Use the fictional source packet below for your first run. The prompts go into your AI conversation, not the terminal.
1. Add the documents
Save api-v1.md, decision-07.md and runbook-v1.md from the source packet below in raw/. Save the rules below for your chosen tool, then review and commit these initial files before the agent writes.
2. Have the AI build the wiki
Start Claude Code or Codex in my-wiki and ask it to confirm which rules it loaded. Enter these prompts one at a time. Check that it creates source summaries and linked topic pages, updates index.md and log.md, and leaves raw/ unchanged.
AI conversation — organize the documents ingest raw/api-v1.md ingest raw/decision-07.md ingest raw/runbook-v1.md3. Ask a question and open its sources
Expect 3 retries after the first attempt: 4 attempts total, supported by api-v1.md and decision-07.md. Open both cited files and check the wording. The timeout is unspecified; the AI must not invent a value.
AI conversation — ask with evidence query What is our GET retry policy? Cite the sources and list what is still unknown.4. Add an update and check what changed
Save the replacement text below as raw/api-v2.md, keeping v1 for history. The new source allows 1 retry, while decision-07.md still says 3. The wiki should flag the conflict, not silently choose a winner. Review every proposed edit before accepting it.
AI conversation — review the update Ingest raw/api-v2.md. Treat api-v1.md as historical only. query What changed in the GET retry policy? Cite both current sources and flag unresolved conflicts. lint
07
Wiki rules for your chosen tool
Save the rules below as CLAUDE.md for Claude Code, or AGENTS.md for Codex. Choose one tool to start; no cross-tool setup is needed.
# LLM Wiki
This folder is a wiki you maintain from my sources.
## Layout
- raw/: my sources. Read them. Never edit, move, or delete them.
- wiki/sources/: one summary page per source, named after the source.
- wiki/topics/: one page per topic, person, or idea.
- wiki/index.md: every page, one line each: [[page]] - summary.
- wiki/log.md: one line per job: ## [YYYY-MM-DD] ingest | <title>
## Page rules
- Start each page with a two- or three-sentence summary.
- Every claim links to the source page it came from.
- Link related pages with [[wiki links]].
- If a new source contradicts a page, say so on the page and cite both.
- Never rewrite text under a "## My notes" heading. I write that part.
## Jobs
- ingest <file>: summarize it, update affected topic pages,
update index.md, and log it.
- query <question>: read index.md first, open only the pages you need,
and answer with links. Offer to save a useful answer as a page.
- lint: list contradictions, outdated claims, orphan pages, and
missing pages. Fix only what I approve.08
Try a complete example before installing anything
Can your wiki answer a project question, show its evidence, and notice when that answer stops being safe to reuse? Try this small, fictional source packet with your existing AI tool first. These are authored teaching inputs and reference answers, not a Wenlan run, a customer result, or a performance comparison.
Save the three blocks below as separate Markdown files with the displayed filenames in a new, disposable folder. Give your agent read-only access to those files. Keep any generated answer in a separate wiki file; do not let it edit the sources.
Ask: “Using only api-v1.md, decision-07.md, and runbook-v1.md, write a short retry-policy wiki page. Cite the filename for every rule, distinguish retries from total attempts, and list unanswered questions. Do not fill gaps from general knowledge.”
# api-v1.md — fictional API specification, revision 1
GET /reports: after a failed first attempt, allow up to 3 retries.
POST /payments: do not retry automatically.
# decision-07.md — fictional client decision
Use the API's GET retry cap of 3 to limit repeated requests.
Automatic POST retries are disabled because duplicate payments are unsafe.
# runbook-v1.md — fictional operator note
Record the endpoint, attempt number, and final failure in the local test log.
The request timeout has not been decided.09
Check the answer, then change one source
Compare your result with this reference. The point is not matching the wording: all four claims must have the right support, and the timeout must stay unknown. Open each cited file yourself; a plausible citation is not evidence that it supports the sentence.
Next add api-v2.md using the replacement text below, so it replaces api-v1.md. For the second question, ask: “Using api-v2.md, decision-07.md, and runbook-v1.md as the current sources, with api-v1.md as a historical reference only, compare the prior wiki answer with the current evidence. Identify any stale conclusion, preserve the unresolved 1-versus-3 retry conflict, and do not silently modify decision-07.md or settle the conflict.”
If plain files and your agent already handle this clearly, keep that simpler workflow. Consider Wenlan when maintaining source-linked pages and shared lookup across your AI tools is recurring work. Its source links do not verify meaning, and adding a replacement source is not the same as updating an already linked source: review the actual page state. This exercise does not establish Wenlan's accuracy, time savings, automatic maintenance, or your later reuse.
# Request retry policy — reference answer, revision 1
GET: at most 3 retries after the first attempt (4 attempts total).
Source: api-v1.md; decision-07.md.
POST: no automatic retry.
Source: api-v1.md; decision-07.md.
Log: endpoint, attempt number, final failure.
Source: runbook-v1.md.
Timeout: not specified. Ask the owner; do not invent a value.
Source: runbook-v1.md.
# api-v2.md — fictional replacement for api-v1.md
GET /reports: after a failed first attempt, allow at most 1 retry.
POST /payments: do not retry automatically.
# Review note — before accepting a revised answer
The old GET answer is stale: api-v2.md now allows only 1 retry.
decision-07.md still says 3. Preserve and flag this conflict.
Do not report the old 3-retry policy as settled current guidance.
POST, logging, and the unknown timeout are unchanged.
Ask the decision owner to reconcile decision-07.md with api-v2.md.10
Review the files before keeping the update
Finally, run the commands below in your terminal. Open new files marked ?? separately: git diff does not show untracked files. Confirm raw/ and your own notes are unchanged; commit only reviewed files.
git status --short --untracked-files=all
git diff HEAD11
Where a do-it-yourself LLM wiki breaks
The folder setup leaves routine maintenance to you:
- When sources change, you need to rerun ingestion or lint and review affected pages.
- Check each update preserves your own notes; the schema is an instruction, not an enforced permission.
- Each client must load the shared schema and respect your source and editing boundaries.
- A large index needs selective loading or search; it cannot grow indefinitely in every prompt.
- You decide when to save chat decisions back into the files.
12
The LLM-wiki workflow in Wenlan
Wenlan brings source import, wiki pages, citations, and review into one app. With background AI enabled, eligible AI-maintained pages can refresh when their evidence changes; pages you authored or edited receive revision proposals. Connected tools read the same library, so you do not have to build that maintenance workflow yourself.
/capture saves a decision from the chat, /wenlan distill builds or refreshes a topic page, /wenlan pages opens it, and /brief and /recall load only what the next session needs.
/brief <topic>
/recall <question>
/capture <decision + why>
/handoff
/wenlan distill <topic>
/wenlan pages <topic>13
Optional: share the rules across Claude Code and Codex
Only needed if you switch between tools. Keep one AGENTS.md and put @AGENTS.md in CLAUDE.md as shown below for compatible rule loading. Check the loaded instructions in each session (Claude: /context; Codex: ask which instruction files it loaded).
Let one client finish writing before the other starts. They share the files, not the previous conversation.
@AGENTS.mdSide-by-side
Practical dimensions. Where DIY folder + wiki rules leads, we say so.
| Dimension | Wenlan | DIY folder + wiki rules |
|---|---|---|
| Setup | Install the app and connect your AI tool | A folder, a schema file, and git |
| When a source changes | Optional background AI refreshes eligible AI-maintained pages; your edited pages receive proposals | You rerun ingestion and review affected pages |
| Your own edits | Kept; refreshes do not overwrite pages you edited | Schema rules guide the agent; committed Git versions provide recovery |
| Several AI tools | One wiki shared by Claude Code, Codex, and other clients | One shared schema, loaded by each client |
| AI chats as sources | Decisions can be captured from the chat | Ask the agent to save a chat decision as a file, then review it |
Review wiki pages when sources change
Wenlan turns documents, notes, and AI chats into pages with source links. When linked sources change, affected pages can be flagged for review. Check a proposed refresh before accepting it.
Inspect a citation and a proposed revision in Wenlan
These are real Wenlan app recordings using Tally, a demonstration invoicing project. Enlarge the screens to follow a source reference and inspect a proposed page revision.
1. Follow the SQLite claim back to its source
The wiki says Tally uses SQLite for a single-user app. The open citation shows the source titled ‘SQLite for Single-User App’, its summary, and an ‘Open memory’ action. Compare the sentence with that source before reusing the decision.
2. Read the proposed change before approving it
The Project notes revision removes the undecided database wording and proposes a SQLite decision. Added and removed text, an earlier version, and Skip / Approve controls are visible. Check the revised wording and its sources before choosing what to keep.
FAQ