Dev built a read-later app that mirrors Karpathy's LLM data model
Fisher Shen built a read-later app called Burn 451 and discovered its three-layer data architecture independently mirrors the personal LLM knowledge system Andrej Karpathy described in a viral gist with 16M views in 48 hours.
Score breakdown
Developers building personal knowledge or read-later tools can adopt this three-layer, no-RAG architecture and expose it via MCP to give AI coding assistants like Claude and Cursor direct, full-context access to curated content without setting up vector databases or embedding pipelines.
- 01Andrej Karpathy published a gist describing a three-folder LLM knowledge system (`raw/`, `wiki/`, `outputs/`) that received 16M views in 48 hours.
- 02Karpathy's system uses no vector database, no embeddings, and no chunking — the LLM reads markdown directly in its context window.
- 03Karpathy's own wiki on one research topic spans around 100 articles and 400K words.
Fisher Shen describes building Burn 451, a read-later app, and discovering after the fact that its data model mirrors the personal LLM knowledge architecture Andrej Karpathy published in a gist that received 16M views in 48 hours. Karpathy's system uses three layers: `raw/` holds immutable source material the model reads but never writes to; `wiki/` holds LLM-authored markdown files, one per concept, with backlinks and provenance tracked in git; and `outputs/` holds synthesized answers the model writes after a query. Karpathy frames this as a compiler analogy — raw is source code, wiki is the compiled binary, outputs is runtime. His own wiki on a single research topic spans around 100 articles and 400K words. The top Hacker News thread on the gist reached 296 points, with the main objection being model collapse from iterative LLM-generated notes; Karpathy's response was that he uses already-trained models to curate, not to retrain, making curation a one-way compounding flow.
In Burn 451, the `bookmarks` table in Supabase is the raw layer — append-only rows with full fetched text, canonical URL, and timestamp.
In Burn 451, the `bookmarks` table in Supabase is the raw layer — append-only rows with full fetched text, canonical URL, and timestamp. The `collections` table is the wiki layer, with each collection representing a topic and holding curated bookmark IDs plus AI-written summaries and three-bullet digests per article. The compiled output lives at `website/data/vault-content/` and currently holds 140 markdown files and 263,000 words. Static vault pages regenerated hourly form the outputs layer. The key difference from Karpathy's manual approach is automated ingest: when a user saves an article, it is fetched through a clean-reader pipeline, deduped, summarized, and filed. This pipeline is exposed as `burn-mcp-server` on npm, offering 26 tools for Claude and Cursor to query the vault in real time.
The post also demonstrates the no-RAG, full-context approach using a 25-essay Tiago Forte vault (~40K words, well under Claude's 200K context ceiling) loaded into a Claude Project. Three example queries show the pattern's strengths: synthesizing Forte's CODE method across multiple essays, contrasting PARA with Zettelkasten by drawing from three different essays simultaneously, and tracing how Forte's views on AI evolved from 2022 to 2026. The author acknowledges the pattern has real limits — directory walking is O(n) and strains at 1,000 pages and breaks at 10,000, and vector embeddings remain more cost-effective for large arbitrary corpora — but argues the envelope of constraints (small corpus, stable content, one human owner, 200K+ context window) is precisely the shape of a personal read-later archive.
Key facts
- 01Andrej Karpathy published a gist describing a three-folder LLM knowledge system (`raw/`, `wiki/`, `outputs/`) that received 16M views in 48 hours.