# LLM Wiki: Let Your Agent Keep Its Own Notes (and When Real Memory Wins)

> Karpathy's LLM wiki lets an agent maintain its own markdown notes. I ran one against octobrain memory on the same sources. Here's where each one wins.

On September 1 I wrote a content plan for this blog. Under "sources verified during drafting" it says OpenAI prompt caching is 50% off. Seventeen days later I checked OpenAI's docs for the prompt caching post and found the real number: cached input bills at 0.1× on GPT-5.6 and later. Ninety percent off, not fifty. The post shipped with the right number. The planning note still says fifty, and nothing anywhere tells me the two disagree.

That's the problem every second brain eventually hits. Writing notes down is easy. Noticing that note 40 quietly contradicts note 12 is not.

**An LLM wiki is a folder of markdown pages that your agent writes and maintains from sources you give it — Andrej Karpathy's pattern from April 2026. It's the best AI second brain for a curated topic you'll read yourself. Real memory beats it when the agent needs recall by meaning across everything you've indexed, in two seconds, without a model rewriting files.**

I tested both on the same three documents, including that contradiction. Here's what happened, with the numbers.

## What is Karpathy's LLM wiki?

Karpathy's LLM wiki is a pattern, not a product: instead of retrieving chunks of raw documents at question time, an agent compiles your sources into a persistent, interlinked wiki and keeps it current. He published it on April 4, 2026 as a one-page [idea file on GitHub Gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f), on the theory that you share the idea and let your own agent build the version you need.

The pattern has three layers:

- **Raw sources** — articles, papers, data files. Immutable: the agent reads them and never edits them.
- **The wiki** — summaries, entity pages, concept pages. The agent owns this layer entirely.
- **The schema** — a file like `CLAUDE.md` that tells the agent how the wiki is structured and which workflows to follow.

And three operations. **Ingest** reads a source and updates every page it touches — he estimates 10–15 pages per source. **Query** answers from the wiki and files good answers back as new pages. **Lint** hunts for contradictions, stale claims, orphan pages and missing cross-references. Two special files hold it together: `index.md`, a catalog the agent updates on every ingest, and `log.md`, an append-only timeline.

The line that sold me: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." Karpathy keeps the agent open on one side and Obsidian on the other, and says the setup works "surprisingly well at moderate scale (~100 sources, ~hundreds of pages)" without any embedding infrastructure.

He's right about why it works. The tedious part of a knowledge base was never the reading. It was the maintenance, and agents don't get bored of updating cross-references.

## I built an LLM wiki in ten minutes

The setup is one schema file and one command. Octomind reads `AGENTS.md` from the working directory at the start of every session, so that file is the schema layer — no plugin required. Mine was 18 lines. The part that mattered:

```markdown
- **ingest <file>**: read the source, write or update every page it touches,
  cite the source file on each claim you add (`(source: raw/<file>)`), update
  index.md, append to log.md. If the new source contradicts an existing page,
  keep both claims, mark the conflict with `> CONFLICT:` and say which source
  is newer.
```

For raw sources I used three real documents from this site's repo: the "sources verified" section of that September 1 content plan (165 words), our context engineering post (1,095 words), and an excerpt of the prompt caching post (1,067 words). Then:

```bash
octomind run developer --format jsonl --sandbox < ingest.prompt.md
```

`--sandbox` keeps every write inside the wiki folder. The run took 69 seconds and cost $0.07. It produced seven pages, an `index.md` grouped into Concepts, Products and Technologies, and a three-line `log.md`: 1,195 words of wiki compiled from 2,327 words of sources.

And it caught both contradictions, at write time:

```text
> CONFLICT: raw/2026-09-01-content-plan-sources.md says OpenAI cached reads
  are "50% off"; the newer raw/2026-09-18-prompt-caching-post.md says 0.1×
  (90% off) on GPT-5.6 and later, model-specific before. Newer source wins.
> CONFLICT: raw/2026-09-01-content-plan-sources.md states Anthropic minimum
  1,024 tokens; raw/2026-09-18-prompt-caching-post.md says the minimum is
  per-model, 512–4,096 tokens [...] Newer source wins.
```

I hadn't even noticed the second one. My planning note had a stale Anthropic minimum too.

Then a query: "How much do cached input tokens cost on OpenAI, and is there anything in the wiki that disagrees?" The agent read `index.md`, opened exactly one page, answered "0.1× on GPT-5.6 and later", pointed out the older 50% claim, and logged the query. That took 55 seconds and $0.034. Nearly all the tokens in that call were the agent's own system prompt and tool definitions, served from cache. At this size, the wiki itself is cheap to read.

## The same sources in octobrain memory

[Octobrain](https://github.com/Muvon/octobrain) is the memory server we built for Octomind agents. It covers the wiki's two jobs with a different shape: a knowledge base that indexes documents into searchable chunks, and a memory store for distilled facts with types, tags, importance and relationships. I gave it the same three files:

```bash
octobrain knowledge index raw/2026-09-18-prompt-caching-post.md
✓ Indexed: file:///…/raw/2026-09-18-prompt-caching-post.md (2 chunks created)
```

Indexing took 1.0–1.4 seconds per file. Searches took 1.5–2.2 seconds with no chat-model call at all: one embedding of the query, then hybrid vector-plus-keyword ranking. Asking "how much does OpenAI charge for cached input tokens" returned the prompt caching post and, ranked first, a page from OpenAI's own model docs with the pricing table, which I'd indexed earlier for a different task. The wiki can only know what's in `raw/`. The memory server knew something I'd learned elsewhere.

Then I stored the two conflicting facts as memories, the way an agent would during real work:

```bash
octobrain memory memorize -t "OpenAI prompt caching discount (Sept 1 plan)" \
  -c "Content plan, 2026-09-01: OpenAI prompt caching gives 50% off cached input tokens."
octobrain memory memorize -t "OpenAI prompt caching price (verified Sept 18)" \
  -c "Verified against OpenAI docs 2026-09-18: on GPT-5.6 and later, cached input tokens bill at 0.1x the uncached rate (90% off)"
```

And asked: "what discount do we get on cached OpenAI tokens?"

```text
1. OpenAI prompt caching discount (Sept 1 plan)      Relevance: 0.88
2. OpenAI prompt caching price (verified Sept 18)    Relevance: 0.85
```

The stale fact came first. That isn't a ranking bug. Both memories match the question about equally well, and nothing told the store that one replaces the other. Vector search ranks; it doesn't adjudicate.

The fix is one edge. Octobrain has a `supersedes` relationship for exactly this:

```bash
octobrain memory relate <sept-18-id> <sept-1-id> -t supersedes \
  -d "Sept 18 verified price replaces Sept 1 plan figure"
```

Same question again:

```text
OpenAI prompt caching price (verified Sept 18)    Relevance: 0.85
OpenAI prompt caching discount (Sept 1 plan)      Relevance: 0.09  [superseded]
```

The old fact drops to a tenth of its score and stays queryable as history. It's the same outcome as the wiki's `CONFLICT` marker, except somebody has to create the edge. Octobrain's `memorize` tool already tells agents to link a correcting fact with `supersedes`; from the CLI, I did it by hand. In the wiki, the ingest step did that work because the schema told it to.

## LLM wiki vs memory server: where each one wins

The wiki does its maintenance at write time and pays for it with a model call. Memory makes reads nearly free and pushes maintenance onto whoever writes. Here's how the three setups compared in my run:

|                         | LLM wiki                                  | Octobrain knowledge (indexed docs) | Octobrain memory (distilled facts)         |
| ----------------------- | ----------------------------------------- | ---------------------------------- | ------------------------------------------ |
| Contradictions          | Flagged at ingest by the agent            | Not detected; ranking decides      | Ranked equally until a `supersedes` edge   |
| One lookup              | Agent call: 55 s, $0.034                  | 1.5–2.2 s, no chat-model call      | No chat-model call                         |
| Adding sources          | Agent call: 69 s, $0.07 for three sources | 1.0–1.4 s per file                 | One write per fact                         |
| What it can answer from | Only the `raw/` sources it compiled       | Everything you've ever indexed     | Everything you've ever memorized           |
| Human-readable          | Plain markdown, Obsidian graph view       | Chunks, through search             | Records, through search                    |
| Where it lives          | A folder you can diff in git              | A local LanceDB store              | The same store, scoped by project and role |

**The wiki wins when you are the reader.** A research topic you'll come back to, a domain you're learning, a project's decision history you want to browse as an Obsidian second brain. The synthesis compounds: every ingest leaves better pages behind, and contradictions surface while the agent writes rather than months later. It's also the most portable second brain AI setup I know of — plain files, versioned in git, readable with no tool at all.

**Memory wins when the agent is the reader.** Mid-task, an agent needs one fact in two seconds, not a 55-second detour through an index. It needs recall by meaning across every project and document you've indexed, not just the folder it's standing in. And it needs to write as it works — one memory, one edge — without rewriting a dozen pages every time it learns something. Pasting every note into the prompt instead doesn't scale either; long contexts degrade, which is [context rot](/blog/what-is-context-rot).

Neither one knows the world changed unless you feed it the new source. My September note was wrong for seventeen days in both systems, because nothing re-checked OpenAI's pricing page until I did.

## How to set up an LLM wiki with Obsidian

Point an Obsidian vault at the wiki folder, put the schema in your agent's instructions file, and keep the agent in a terminal beside it. That's Karpathy's whole setup.

1. Make a folder with `raw/`, `pages/`, `index.md` and `log.md`, and open it as an Obsidian vault.
2. Write the schema. With Octomind that's `AGENTS.md` in the folder root, loaded automatically. Spell out the three operations and a conflict rule — the conflict rule is what made my run catch both stale claims.
3. Drop a source into `raw/` and tell the agent to ingest it. Run with `--sandbox` so it can't write outside the vault.
4. Watch Obsidian's graph view. Karpathy calls it "the best way to see the shape of your wiki", and orphan pages show up as floating dots.
5. Run lint on a schedule, not when you happen to remember.
6. Commit the folder to git. `log.md` is the timeline; git is the undo button.

Obsidian is optional. The wiki is plain markdown, so any editor works.

## What I actually run

Both, for different readers. Octomind agents get octobrain through the `memory-read` and `memory-write` capabilities, so they keep decisions across sessions without me curating anything; I covered how that scoping works in [the octobrain integration post](/blog/octobrain-octomind-integration). Project rules live in [AGENTS.md](/blog/octomind-project-config-context), which the agent reads at every session start. For topics I want to understand myself, an agent-maintained wiki is now my default, with the conflict rule in the schema.

What this test changed for me is how I think about memory maintenance. When [Cloudflare launched agent memory](/blog/cloudflare-agent-memory), I argued that storage is the easy part and deciding what to remember and what to forget is the hard part. This run made the forgetting half concrete: it's knowing what to stop believing. A store that lets two contradicting facts sit side by side at equal rank is a pile, not a brain. The wiki's lint is the habit worth stealing.

## FAQ

### What is an LLM wiki?

An LLM wiki is a personal knowledge base of interlinked markdown pages that an AI agent writes and keeps current from source documents you curate. Andrej Karpathy described the pattern in an April 2026 gist: raw sources, an agent-owned wiki and a schema file, with ingest, query and lint as the three operations.

### Is Karpathy's LLM wiki better than RAG?

It's better when a human reads the result and the collection is moderate; Karpathy puts the comfortable range at around 100 sources and hundreds of pages. Retrieval over indexed documents is better for fast lookups across large or growing collections. In my test, a wiki query took 55 seconds as an agent call, and a search over indexed documents took about two seconds.

### Can I use an LLM wiki with Obsidian?

Yes, that's how Karpathy runs it: the agent in one window, Obsidian on the same folder in another. Obsidian adds the graph view, Web Clipper for turning web articles into markdown sources, and plugins like Dataview for querying page frontmatter. The wiki stays plain markdown, so Obsidian is a viewer, not a dependency.

### Is an LLM wiki a good AI second brain?

For knowledge you want to read and think with, yes. It's the most transparent AI second brain setup I know of, and the agent does the maintenance. For an agent's working memory during tasks, a memory server is faster and searches by meaning across everything. If you run agents daily, you'll likely want both.

If you build one this week, put the conflict rule in the schema before the first ingest. It's the one line in my setup that found a mistake I'd been carrying for a month.