Efter 5 dagar, 16 miljoner tweet-visningar och 15+ GitHub-implementationer: en praktisk guide till att replikera Karpathys LLM-wiki-workflow med de exakta verktyg, scheman och mönster som fungerar.

Fem dagar efter att Andrej Karpathy skrev om sin "LLM-wiki"-workflow hade internet redan producerat mer än femton fungerande implementationer, en fallstudie från en dagbok med 2 500 inlägg och en pågående debatt om huruvida allt detta bara är RAG med extra steg. Tweeten ligger på sexton miljoner visningar. Den uppföljande gist-filen har passerat femtusen stjärnor och 1 483 forks. Folk läser inte detta som en kommentar — de läser det som en instruktion.

Den här guiden är för läsare i det andra lägret. Den går igenom vad Karpathy faktiskt byggde, de exakta verktyg han nämnde, katalogstrukturen som håller ihop hela saken, community-implementationerna som driver idén i användbara riktningar, och de ställen där den i tysthet faller ihop. Den utgår från att du vill bygga en själv.

Vad Karpathy faktiskt byggde

Den 2 april 2026 publicerade Karpathy ett kort inlägg på X och en längre gist som beskrev en personlig kunskapsworkflow. Inramningen spelade lika stor roll som innehållet. Han skrev att "en stor del av min senaste token-genomströmning går mindre till att manipulera kod, och mer till att manipulera kunskap" — ett anmärkningsvärt erkännande från någon vars offentliga identitet är byggd på att skriva några av det senaste decenniets mest lästa deep learning-kod.

Kärnbeskrivningen, från gisten, är en mening som är värd att citera exakt:

"I index source documents into a raw/ directory, then I use an LLM to incrementally 'compile' a wiki, which is just a collection of .md files in a directory structure."

Det är hela mekanismen. Råa indata hamnar i en mapp. En LLM läser dem och skickar länkade markdown-filer till en annan mapp. LLM:en är ansvarig för korsreferenserna, indexet, rubrikerna, formateringen, och — kritiskt — för att gå tillbaka och uppdatera tidigare sidor när ny information kommer in. Människan opererar wikin via Obsidian, inte via ett eget gränssnitt.

Karpathy ramade in det som ett "vibe-kodat" personligt system, inte en produkt. Den inramningen är en del av varför det spreds: det var uppenbart reproducerbart för vem som helst med en terminal och en LLM-nyckel. Inom 48 timmar forkade folk gisten och pushade fungerande repon. Inom fem dagar hade ekosystemet tillräckligt med variation för att prata om best practices.

De exakta verktyg Karpathy använder

Karpathy var specifik om sin stack. Det är värt att lista delarna i sin helhet eftersom en hel del av den sekundära kommentaren har varit slarvig på den här punkten.

Obsidian — frontend och IDE. Karpathy bläddrar, frågar och redigerar wikin via Obsidians markdown-native gränssnitt. Han byggde inte ett eget UI. Detta är en medveten separation: AI:n skriver filerna, Obsidian läser dem.
Obsidian Web Clipper — ingångsvägen för webbartiklar. Den konverterar sidor till ren markdown som landar i raw/ utan manuell copy-paste.
Ett eget, vibe-kodat CLI/webbsökverktyg — Karpathy nämner ett litet söklager han skrev själv för att hitta källdokument. Han släppte det aldrig. Det är en egenartad bit som de flesta återimplementationer ersätter med ripgrep eller en tredjepartssök.
qmd av Tobi Lütke — Shopifys VD skeppade ett hybrid BM25 + vector search-verktyg som Karpathy lyfte fram som skalningsvägen när en wiki växer ur en enda indexfil. qmd är svaret på "vad gör jag när index.md inte längre får plats i kontexten."
Marp — markdown till slides. Karpathy använder sin wiki som sanningskälla för föredrag. En presentation är bara ett till kompilerat utdata från samma innehåll.
Dataview — ett Obsidian-plugin för att fråga mot frontmatter. Om varje sida har ett confidence: 0.7- eller stale: true-fält förvandlar Dataview valvet till en frågbar databas utan att lämna markdown.
matplotlib — Karpathy låter LLM:en generera Python-plottar från strukturerad data i wikin och rendera dem som bilder bredvid texten. Diagram är kompilerade, inte handritade.
Git — versionshantering för både raw/ och wiki/. Varje LLM-redigering blir en commit, vilket innebär att du kan diffa vad modellen gjorde och rulla tillbaka när den hallucinerar.

Han nämnde ingen specifik LLM. Men schemafilen i hans gist heter CLAUDE.md, vilket är konventionen som används av Claude Code. Communityt har tolkat detta som en stark antydan om att den primära drivaren är Claude Code som opererar på en lokal katalog.

Arkitekturen: raw/ vs wiki/

Katalogstrukturen är den bärande idén. Nästan varje misstag i de tidiga återimplementationerna kan spåras till att de suddade ut gränsen mellan de två mapparna.

knowledge/
├── raw/           # immutable source documents (never edited by LLM)
│   ├── articles/
│   ├── papers/
│   ├── notes/
│   └── transcripts/
├── wiki/          # LLM-owned markdown (rewritten on every ingest)
│   ├── index.md
│   ├── people/
│   ├── concepts/
│   └── projects/
└── CLAUDE.md      # schema, conventions, instructions for the agent

raw/ är oföränderlig. Du släpper in filer, LLM:en läser dem, inget skriver tillbaka. Om du redigerar en rå fil redigerar du dina källor, och wikin blir en lögn. Behandla den som ett read-only arkiv. De flesta implementationer upprätthåller detta med en git pre-commit-hook eller ett enkelt chmod.

wiki/ ägs av LLM:en. Du redigerar inte wiki-sidor för hand. Gör du det kommer nästa ingest tyst att skriva över dina ändringar. Om du vill rätta något fixar du antingen det underliggande rådokumentet eller lägger till en instruktion i CLAUDE.md. Det här känns strikt, och det är det, men det är det enda sättet som "självunderhållande"-egenskapen håller.

CLAUDE.md (eller AGENTS.md) är schemafilen. Den talar om för agenten vilka konventioner som gäller: hur filer ska namnges, vilka frontmatter-fält som krävs, vilken stil texten ska vara i, hur motsägelser hanteras, när en ny sida ska skapas kontra när en befintlig ska uppdateras. Den här filen är det närmaste workflowen kommer ett konfigurationslager.

Tre operationer körs mot den här strukturen:

Ingest — en ny fil landar i raw/. Agenten läser den, identifierar vilka befintliga wiki-sidor den berör, och uppdaterar ungefär tio till femton sidor i en enda omgång: den nya ämnessidan, indexet, korsrefererade koncept, relevanta personsidor. Det här är den dyra operationen. Det är här "kompileringen" sker.
Query — du ställer en fråga. Agenten läser wiki/index.md, bestämmer vilka sidor som är relevanta, öppnar dessa sidor och syntetiserar ett svar. Avgörande är att den frågar mot den kompilerade wikin, inte mot råarkivet. Kompileringsarbetet betalar sig här.
Lint — körs schemalagt eller på begäran. Agenten granskar wikin efter motsägelser ("sida A säger X, sida B säger inte-X"), föräldralösa sidor (som inget länkar till), och inaktuella påståenden (vars källa i raw/ har ersatts). Det är den operation som förhindrar förruttnelse.

Vad folk faktiskt bygger

Inom fem dagar efter originalinlägget hade GitHub mer än femton återimplementationer. En handfull är substantiella nog att lära sig av.

Ar9av/obsidian-wiki behandlar agentlagret som pluggbart. Samma wiki kan drivas av Claude Code, Codex, Cursor, Windsurf, Copilot eller Gemini, växlade via en skills-baserad arkitektur som omsluter varje leverantör. Det är användbart om du vill undvika att satsa hela setupen på en leverantörs prissättningskurva.

nvk/llm-wiki kommer från NVK, en långvarig Bitcoin-utvecklare, och är den mest åsiktsstarka implementationen så här långt. Den introducerar tre nivåer av frågedjup (fast, deep, exhaustive), explicit confidence-poäng på varje påstående, och dual-linking — varje wiki-sida länkar både till de råkällor den byggts från och till andra wiki-sidor den relaterar till. Dual-linkingen är idén värd att sno.

ussumant/llm-wiki-compiler publicerade den enda riktiga benchmarken än så länge. Testad på ett korpus med 383 markdown-filer (13,1 MB) rapporterar den ungefär 84 % färre tokens per frågesession jämfört med att ladda rå-filerna direkt — runt 3 200 rader kontext per session som faller till omkring 330. Detta är det empiriska resultat ingen har lyft fram prominent, och det är det starkaste kvantitativa argumentet för hela ansatsen.

kenhuangus/llm-wiki kör hela pipelinen på lokala modeller — LM Studio som serverar Gemma 4 — och lägger till automatiserad övervakning av arXiv- och CVE-flöden som kontinuerliga ingest-källor. Ingen molntjänst, inga API-räkningar, och wikin uppdaterar sig själv över natten medan maskinen står stilla.

iamsashank09/llm-wiki-kit återimplementerar hela grejen som en MCP-server. Istället för att köra agenten som ett CLI exponerar den ingest/query/lint som MCP-verktyg som Cursor eller Claude Code kan anropa direkt. Det är förmodligen dit ekosystemet är på väg.

swarajbachu/cachezero var den första Show HN-lanseringen i området och sålde in sig som "Karpathys LLM wiki-idé som en NPM-install." Det är det mest friktionsfria sättet att prova mönstret om du vill få ett fungerande valv igång på under tio minuter.

Farzapedia-fallstudien

Det mest slående utövar-exemplet kommer från Farza Majeed (@FarzaTV). Farza matade ungefär 2 500 inlägg från sin personliga dagbok, Apple Notes och iMessage-konversationer in i en Karpathy-liknande pipeline och kallade resultatet "Farzapedia". Utdata blev runt 400 sammanlänkade wiki-artiklar som täckte vänner, tidigare startups, forskningsintressen och — eftersom det här är Farza — flera anime-djupdykningar.

Det som gör Farzapedia intressant är källmaterialet. Det är inte ett forskningskorpus. Det är den oordnade omgivande datan från ett liv: sms, slängda anteckningar, daterade dagboksinlägg. Kompileringssteget drog in allt detta i något navigerbart. Karpathy själv retweetade det och kallade det resulterande minnesartefakten "explicit och navigerbar" — en noggrann fras. Poängen är inte att wikin vet mer än Farzas anteckningar gjorde. Det är att wikin går att vandra i.

Det är det hittills mest övertygande existensbeviset för att mönstret generaliserar bortom Karpathys egen forskningsworkflow.

Best practices som växte fram på dagar

Trots den korta tidslinjen har en grov konsensus formats kring vad som fungerar.

YAML-frontmatter med confidence och staleness. Varje wiki-sida får en header som:

---
title: "Pipeline v2 architecture"
confidence: 0.8
last_ingested: 2026-04-06
sources: [raw/notes/2026-03-22-sync.md, raw/articles/pipeline-blog.md]
content_hash: 8f3a...
stale: false
---

Dataview-queries lyfter sedan fram sidor med låg confidence, inaktuella sidor eller föräldralösa direkt i Obsidian.

Strikt separation mellan raw/ och wiki/. Redan täckt ovan, men det är den praxis som oftast bryts i tidiga forks, och den med värst failure mode.

Steph Angos vault-separationsmönster. Steph Ango (@Kepano), Obsidians VD, skrev under veckan att agenter bör "make a mess in their own space" snarare än att redigera människans personliga valv. Hans rekommendation är att behålla dina handskrivna Obsidian-anteckningar i ett valv och peka LLM-wikin mot ett separat, uppoffrat valv. Det förhindrar vad han kallar hallucinationskontaminering — situationen där en modell hittar på ett faktum, skriver in det i dina betrodda anteckningar och sen läser tillbaka det nästa vecka som om det vore sanning. När en hallucinerad länk väl är i din graf förstärks den vid varje följande ingest.

Content hash-detektering. Hasha varje rå fil vid ingest. Om hashen ändras, flagga varje wiki-sida som citerade den som inaktuell. Det är det billigaste möjliga lint-steget och fångar det mesta av förruttnelsen.

qmd för att skala sök. Single-index-file-mönstret fungerar upp till runt 100–150 artiklar. Bortom det blir index.md själv större än ett bekvämt kontextfönster, och agenten börjar tugga. Tobi Lütkes qmd ger dig ett hybrid BM25/vector retrieval-lager som agenten kan anropa som verktyg, så indexet blir ett API-anrop istället för en filläsning. Det är den enda rena skalningsväg någon har publicerat.

Schemafiler som konventioner. CLAUDE.md och AGENTS.md konvergerar som de två filnamn agenter letar efter. Lägg din stilguide, dina obligatoriska frontmatter-fält, dina korslänkningsregler och dina disambigueringsregler i en av de här filerna. Allt annat följer.

Där det brister

Det här är den del av workflowen som det mesta av entusiastbevakningen hoppar över. Mönstret är bra. Det är inte färdigt.

Indexet växer ur kontextfönstret. Bortom några hundra artiklar blir wiki/index.md ohanterligt. Du kan komprimera, sharda eller byta till qmd, men inget av det är gratis. Varje skalningslösning introducerar retrieval, och retrieval är det som mönstret skulle ersätta. Vid någon korpusstorlek blir workflowen i tysthet RAG-över-kompilerad-markdown, vilket är försvarbart men värt att medge.

Citatprecisionen är svag. Wikin kan säga "det här beslutet togs den 22 mars" och citera raw/notes/2026-03-22-sync.md, men den kan inte enkelt citera "sida 47, stycke 3". För forskningsarbete där proveniens spelar roll är det en lucka. Den enda kända lösningen så här långt är att förbehandla rå-filer till tillräckligt små chunks så att filnamnet blir tillräckligt precist — vilket, återigen, börjar likna chunking.

Hallucinationskontaminering är verklig. Om LLM:en hittar på en länk vid ingest består den länken. Vid nästa ingest läser modellen sin egen påhittighet som källmaterial och förstärker den. Steph Angos separat-valv-mönster mildrar detta; lint-steg fångar en del av det; men ingen har en principiell lösning. Wikin kan glida bort från råarkivet och det finns ingen automatisk varning.

Token-kostnader i skala är opublicerade. Ingen som kör en wiki i produktion har lagt ut riktiga siffror. Ingest-operationen rör vid tio till femton sidor per nytt dokument, varje gång full-läsning-och-omskrivning. Till Claude Sonnet-priser kan en upptagen kunskapsarbetare bränna meningsfulla pengar per månad, men vi vet inte än om det rör sig om tio dollar eller tvåhundra. ussumant-benchmarken handlar om besparingar vid frågetid, inte kostnader vid ingest-tid.

"Det här är bara RAG"-debatten. En betydande del av den tekniska kommentaren är någon variant av "kompilera markdown och fråga mot det är bokstavligen retrieval-augmented generation". Den distinktion som är värd att bevara är att kompilering är lossy och åsiktsstark — LLM:en gör redaktionella beslut vid ingest som klassisk RAG skjuter till query-tid. Om det räknas som ett nytt paradigm eller en omplacering av samma arbete är ett definitionsargument, och det kommer inte att avgöras av en tweet.

Möjligheten med mötestranskript

Karpathy listade flera källtyper i gisten. En rad är värd att citera i sin helhet eftersom den pekar på den lucka ingen har fyllt:

"Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. The wiki stays current because the LLM does the maintenance that no one on the team wants to do."

Den meningen innehåller den outtalade tesen för varje möte-AI-verktyg på marknaden. Mötestranskript är det högsta-avkastnings-inputtet för en Karpathy-liknande wiki: de genereras automatiskt, de är relationella, de ackumuleras och ingen vill underhålla dem för hand. De är precis den typ av dokument som gynnas av kompilering snarare än lagring.

Och ändå, i skrivande stund, finns det ingen produkt som automatiskt matar mötessamtal in i en ackumulerande Karpathy-stil-wiki. De närmaste närstående verktygen stannar vid sammanfattningar per möte. Gapet mellan "här är en sammanfattning av dagens samtal" och "här är en underhållen wiki-sida för Q3-prissättningsbeslutet, uppdaterad över de sju möten där det kom upp" är stort, och det är fortfarande mestadels tomt.

Proudfrog tänker på det här problemet, och den tidigare texten om Karpathys wiki och möteskunskap går djupare in i de arkitektoniska implikationerna. För det bredare argumentet om hur en kompilerad möteskunskaps-graf ser ut i daglig användning, se knowledge worker-workflowen, feature-sidan eller pricing.

Kortversionen: Karpathy visade hur destinationen ser ut. Det intressanta arbetet nu är att dra rörledningarna till de ställen där råmaterialet redan produceras.

Vanliga frågor

Vilken LLM använder Karpathy för sin wiki?

Karpathy namngav ingen modell explicit i originalinlägget eller gisten. Schemafilen i hans publicerade katalogstruktur heter dock CLAUDE.md, vilket är konventionen som används av Anthropics Claude Code. Community-konsensus är att den primära drivaren är Claude Code som körs mot en lokal katalog, även om implementationer har publicerats med GPT-baserad Codex, Gemini, Cursor och lokala modeller via LM Studio. Workflowen är modellagnostisk — det som spelar roll är att agenten kan läsa och skriva filer i en katalog.

Måste jag vara utvecklare för att bygga min egen LLM-wiki?

Du behöver vara bekväm med en terminal, git och en LLM-kodagent som Claude Code eller Cursor. Du behöver inte skriva kod från grunden — flera återimplementationer (cachezero, llm-wiki-kit, obsidian-wiki) installerar på några minuter och ger dig ett fungerande valv. Det fortgående arbetet är att kurera schemafilen, bestämma vad som ska in i raw/ och granska det agenten skriver. Tänk på det som att driva ett system snarare än att bygga ett.

Hur skiljer sig detta från RAG?

Klassisk RAG chunkar dokument, embeddar dem och hämtar liknande chunks vid frågetid. Hämtningen är likhetsbaserad och sker när du ställer en fråga. Karpathys wiki kompilerar rådokument till strukturerad, länkad markdown vid ingest-tid, och LLM:en gör redaktionella beslut — vad som spelar roll, vad som länkar till vad, vad som ska uppdateras — innan någon fråga ställts. Vid frågetid läser modellen den kompilerade wikin, inte råarkivet. Bortom några hundra artiklar blir distinktionen suddigare eftersom indexet självt måste sökas, men i personlig skala bär kompileringssteget meningsfull information som ren likhetssökning kastar bort.

Vad händer när wikin blir för stor för kontextfönstret?

Single-index-file-mönstret bryts runt 100–150 artiklar, när wiki/index.md slutar få plats bekvämt i kontexten. Den renaste skalningsväg som publicerats så här långt är qmd av Tobi Lütke, ett hybrid BM25- och vector search-verktyg som agenten anropar som ett retrieval-steg. Bortom det börjar du sharda wikin efter ämne eller tidsperiod. Det är den ärliga platsen där mönstret återinför retrieval, och det är värt att planera för om ditt korpus växer.

Kan jag använda det här med mina mötestranskript?

I princip ja — släpp transkript i raw/transcripts/ och låt agenten kompilera dem. I praktiken är mötestranskript stökiga, talar-attribuerade och tidsstämplade, och en generisk wiki-agent vet inte hur den ska väga beslut, extrahera action items eller dubblett-detektera återkommande diskussioner. Det är gapet Proudfrog jobbar på. För en djupare behandling av hur en mötes-native kompilerad wiki skulle se ut, se Karpathys LLM-wiki och vad det betyder för möteskunskap.

Vad är skillnaden mellan raw/ och wiki/?

raw/ håller dina källdokument — artiklar, papers, anteckningar, transkript — och är oföränderlig. LLM:en läser från den men skriver aldrig tillbaka. wiki/ håller kompilerad markdown som LLM:en äger helt: den skapar, uppdaterar och omstrukturerar sidor när nya källor kommer in. Du handredigerar inte wiki/-filer, eftersom nästa ingest skriver över dem. Om du behöver rätta något fixar du den underliggande källan i raw/ eller uppdaterar reglerna i CLAUDE.md. Att hålla de två mapparna strikt separerade är den enskilt viktigaste konventionen i workflowen, och det är den som oftast bryts i tidiga forks.

Den kompletta guiden till Karpathys LLM-wiki-workflow