An Obsidian second brain works best with AI when the language model does more than search your notes: it maintains a wiki built from them. You drop sources into a folder, an agent such as Claude Code or Codex reads them and writes linked Markdown pages with citations, and Obsidian shows the result with its links and graph. A short rules file sets out what a page looks like and requires every statement to point to its source. For a personal knowledge base of up to roughly a hundred sources you need no vector database and no plugin. Once client data goes in, the model has to run under a business agreement or on your own machine.
Andrej Karpathy described the method in April 2026 as the LLM wiki, explicitly as an idea rather than a finished product. Everything we say about Obsidian, Claude Code and Codex comes from their official documentation. For this article we tried the method ourselves: Codex CLI turned five of our own journal articles into a wiki, and we then checked links, citations and numbers with a script. The model kept to the citation rule straight away; a linked wiki only appeared once the rules were more precise. Information as of 21 October 2026.
The LLM wiki at a glance
| Folder or file | Who writes it | What it holds |
|---|---|---|
| raw | You | Articles, PDFs, minutes and notes; the model only reads |
| wiki | The language model | Pages on topics and decisions, plus index.md and log.md |
| AGENTS.md | You, once | Folders, page format, citation rule and workflows |
How an LLM wiki differs from chatting with your notes
Many AI plugins for Obsidian search your notes for matching passages on every question and hand them to the model. The knowledge is pieced together from scratch for every question, and nothing is kept in between. In an LLM wiki the model does that work once, when a source is added: it summarises, extends existing pages and records contradictions. Karpathy describes the result as a lasting body of work that grows with every source.
That has two consequences for you. You can read the knowledge yourself, as ordinary pages in Obsidian, instead of trusting a search whose hits you never see. And a contradiction can surface as soon as the new source arrives, not only when someone happens to ask. Whether it does depends on the rules file, as our test shows. When a search across many documents is the better choice is explained in RAG explained.
Setting it up in five steps
- Install Obsidian and create a vault. A vault is an ordinary folder on your computer and the notes are Markdown text files, as the Obsidian help explains. Since February 2025 Obsidian has been free for work use too.
- Create the folders raw and wiki inside the vault. If you know Git, turn the vault into a repository so every change the model makes can be reviewed and rolled back.
- Put the rules file AGENTS.md in the vault; an example follows below. Codex reads AGENTS.md at every start, according to OpenAI's documentation. Claude Code reads it too, as long as there is no CLAUDE.md next to it, according to Anthropic.
- Collect sources. The free Obsidian Web Clipper saves web pages to the vault as Markdown. PDFs, minutes and your own notes go straight into raw.
- Start the agent in the vault folder and hand it the first source, for example: “Add raw/offer-2026.md to the wiki. Follow AGENTS.md.”
The rules file: twenty lines decide the result
This is the second version from our test, which we ran in German; below is the English equivalent. It is deliberately short, because the model reads it at every start and each rule should be checkable.
# Rules for this wiki
## Folders
- raw/: sources. Read only, never change.
- wiki/: pages you maintain. One page per topic, product, rule or decision, not per source.
- wiki/index.md: catalogue of all pages, one line of description each.
- wiki/log.md: log. Append only, never rewrite.
## Pages
- File names in lower case with hyphens, for example wiki/rag.md.
- Two sentences of summary at the top.
- Every factual statement ends with its source as [[raw/filename]].
- Link to other pages as [[pagename]]. Every page links to at least two other pages.
- If sources contradict each other, do not decide. Record both under "Open questions".
## Workflows
- Ingest: read index.md first. Extend existing pages before creating new ones. Give every topic that matters in the source its own page, or extend the one that exists. Update index.md and log.md and list every changed page in the log.
- Query: read index.md first, then the pages. Answer with sources. Name anything the wiki lacks as a gap.
- Lint: list dead links, pages without incoming links, statements without a source and contradictions. Delete nothing.
The most important line is the citation rule. It turns a summary into a statement you can verify in a minute, and it is what the automated check further down relies on. We only spelled out the ingest rule this precisely after the first run: read index.md first, extend existing pages, one page per topic rather than per source. Without those sentences we got a folder of summaries, not a wiki.
Ingest, query, lint: the three workflows
To ingest, you add one source at a time and skim what changed. According to Karpathy a single source can touch 10 to 15 pages, because it extends existing entries or contradicts them. How many it was for us is shown in the test below.
To query, the model reads index.md first, then the relevant pages, and answers with sources. A good answer, such as a comparison of two quotes, can be filed as a new page. That way the wiki also grows through your questions.
To lint, the model regularly looks for dead links, pages nobody links to, statements without a source and contradictions. Obsidian handles part of this without any language model: from version 1.12 the Obsidian CLI lists unresolved links and unconnected pages with the commands unresolved, orphans and deadends. Fixed checks like these are cheaper and more reliable than a model checking itself.
Our test: five articles, two versions of the rules
The sources were five of our own journal articles, about 6,400 words in total, on RAG, AI assistant costs, GDPR for chatbots, hallucinations and EU hosting. Codex CLI with the GPT-5.6 Terra model ingested them one after another, once with a first, shorter version of the rules file and once with the version above. We then counted links, citations and numbers with a small script and compared ten randomly drawn statements per run with their source by hand. The times include a scan for credentials that our environment requires before every file access.
| Measure | First version | Second version |
|---|---|---|
| Time per source | 36 to 74 seconds | 68 to 178 seconds |
| Files changed per source | 3 | 6 to 13 |
| Content pages after five sources | 5 | 30 |
| Links between content pages | 1 | 105 |
| Factual statements with a source | 106 of 106 | 175 of 175 |
| Numbers found as written in the source | 40 of 40 | 28 of 28 |
| Sample backed by the source | 10 of 10 | 10 of 10 |
The model kept to the citation rule in both runs, and none of the sampled statements was invented. Even so, the first version did not produce a wiki. Each source became exactly one summary, no ingest extended an existing page, and there was a single link between the five pages. The model read “one page per topic” generously: for the article on RAG, RAG was the one topic. With the second version it created 30 pages, seven of which combine statements from two sources, for example on data flows, AI transparency and technical operations. That took about twice as long.
Next we added an invented call note: a supplier would set up a simple website assistant for EUR 900, while our planning assumption is EUR 1,500 to 5,000. With the first version the offer landed on a page of its own that no other page links to. With the second it sat on the set-up budget page directly below the planning assumption, where the gap is obvious. Neither version recorded it as a contradiction under “Open questions”, because the model treated a concrete offer and a planning assumption as different things. If you want deviations in prices or deadlines flagged, write exactly that into the rules file as its own rule.
The query and lint runs used the wiki from the first version. Asked about costs and GDPR, the model read index.md first, then three pages, and then the sources as a check. It gave both prices side by side with correct citations, but once merged two separate ranges from the source into a monthly total of its own, which adds up but appears nowhere in the source. The model's lint run reported no findings. Our script found four content pages that no other content page links to; the model had counted the links from the index. For counts like these, a script or the Obsidian CLI is more reliable than the model.
Which model fits: cloud agent or local
For the wiki to work, the model has to read and write files. Command-line agents such as Claude Code or Codex do that, working directly in the vault folder. A plain chat window cannot change pages in the vault, so it only helps with one-off questions.
If your notes should not leave the building, you can run Codex with a local model. Ollama documents the command ollama launch codex for this and recommends a context window of at least 64,000 tokens. We have not tested whether a local model follows the rules file as reliably as a cloud model; check it with the same measurements we used.
Privacy: whatever the agent reads, the provider sees
Obsidian keeps your notes on your device. The agent, however, sends the content of every file it reads to the model provider. At Anthropic, for example, users on the Free, Pro and Max plans have chosen since the August 2025 update to the consumer terms whether their chats and Claude Code sessions may be used for training. With consent the data is kept for five years, otherwise for 30 days; Team, Enterprise and the API are not covered by this rule, as Anthropic explains.
That gives you a simple boundary. Your own notes and public sources can go through a personal account with training switched off. Client data, HR records and contracts should only go into a vault whose model runs under a business agreement with a data processing agreement under Article 28 GDPR, or locally. What such an agreement needs to cover is in our GDPR checklist for website chatbots, and the hosting questions are in running AI in the EU.
Where the method stops working
Size is the first limit. Karpathy writes that the index holds up surprisingly well at around 100 sources and a few hundred pages. Beyond that the model needs a search, for which Karpathy points to the local search engine qmd with full-text and vector search, and you are back to a form of RAG.
The second limit is errors that propagate. A wrong sentence in the wiki becomes the basis for later pages and answers, and unlike in a chat it stays there. The citation rule, Git and regular lint runs catch much of this, but they do not replace your own reading of the pages you base decisions on. Why language models write convincing falsehoods is covered in our article on customer service hallucinations.
The third limit is the team. A vault is a folder without roles, approvals or per-page permissions. It works very well for one person and poorly for a team with confidential areas.
Frequently asked questions
Do I need Obsidian for an LLM wiki?
No. The wiki is a folder of Markdown files that any editor can open. Obsidian is simply the most convenient reader, because links, backlinks and the graph work without any setup.
What does an Obsidian second brain with AI cost?
Obsidian itself is free; syncing across devices with Obsidian Sync costs USD 4 a month billed annually, according to the pricing page. On top of that comes the language model, either through a subscription that includes Claude Code or Codex or pay-as-you-go through the API.
Does it work with ChatGPT?
With OpenAI's Codex CLI, yes: it reads AGENTS.md and works directly in the vault, and our test ran on it. The ChatGPT chat window cannot change files in the vault and only helps with one-off questions.
Is an LLM wiki better than RAG?
It solves a different problem. The wiki suits a manageable collection that one person wants to understand and maintain. RAG suits large, frequently changing document sets and applications where many users ask questions, such as a customer chat.
The pattern of sources, maintained pages, a citation rule and fixed checks also works beyond a personal second brain, for quotes, manuals or project decisions in a company. Then access rights, EU hosting and clear ownership come into play. If you want to look at this for your team, talk to us about AI automation with LindenTech. Bring 20 typical documents and ten questions your team asks too often today.