Ein Second Brain mit Obsidian und KI funktioniert am besten, wenn das Sprachmodell Ihre Notizen nicht nur durchsucht, sondern selbst ein Wiki daraus pflegt. Sie legen Quellen in einen Ordner, ein Agent wie Claude Code oder Codex liest sie und schreibt verlinkte Markdown-Seiten mit Quellenangaben, und Obsidian zeigt das Ergebnis mit Links und Graph an. Eine kurze Regeldatei legt fest, wie die Seiten aussehen und dass jede Aussage auf ihre Quelle verweist. Für ein persönliches Wissensarchiv mit bis zu etwa hundert Quellen brauchen Sie dafür weder Vektordatenbank noch Plugin. Sobald Kundendaten hineinkommen, gehört das Modell unter einen Geschäftsvertrag oder auf den eigenen Rechner.
Die Methode hat Andrej Karpathy im April 2026 als LLM-Wiki beschrieben, ausdrücklich als Idee und nicht als fertiges Produkt. Die Angaben zu Obsidian, Claude Code und Codex stammen aus den offiziellen Dokumentationen. Für diesen Artikel haben wir das Verfahren selbst ausprobiert: Codex CLI hat fünf unserer eigenen Fachartikel in ein Wiki übernommen, danach haben wir Links, Quellen und Zahlen maschinell geprüft. Die Quellenangaben hielt das Modell sofort ein, ein verlinktes Wiki entstand erst mit genaueren Regeln. Stand: 21. Oktober 2026.
Das LLM-Wiki auf einen Blick
| Ordner oder Datei | Wer schreibt | Inhalt |
|---|---|---|
| raw | Sie | Artikel, PDFs, Protokolle und Notizen; das Modell liest nur |
| wiki | Das Sprachmodell | Seiten zu Begriffen und Entscheidungen, dazu index.md und log.md |
| AGENTS.md | Sie, einmal | Ordner, Seitenformat, Quellenpflicht und Abläufe |
Was ein LLM-Wiki anders macht als ein Chat mit den Notizen
Viele KI-Plugins für Obsidian suchen bei jeder Frage passende Stellen in den Notizen und übergeben sie dem Modell. Das Wissen wird jedes Mal neu zusammengesetzt, und zwischen zwei Fragen bleibt nichts zurück. Beim LLM-Wiki erledigt das Modell diese Arbeit einmal, wenn eine Quelle hinzukommt: Es fasst zusammen, ergänzt bestehende Seiten und vermerkt Widersprüche. Karpathy beschreibt das Ergebnis als dauerhaftes Werk, das mit jeder Quelle wächst.
Für Sie hat das zwei Folgen. Sie können das Wissen selbst lesen, als normale Seiten in Obsidian, statt einer Suchmaschine zu vertrauen, deren Treffer Sie nicht sehen. Und ein Widerspruch kann schon auffallen, wenn die neue Quelle hinzukommt, nicht erst, wenn jemand eine Frage stellt. Ob das gelingt, hängt an der Regeldatei, wie unser Test zeigt. Wann dagegen eine Suche über viele Dokumente die bessere Wahl ist, erklären wir in RAG einfach erklärt.
Einrichtung in fünf Schritten
- Obsidian installieren und einen Vault anlegen. Ein Vault ist ein gewöhnlicher Ordner auf Ihrem Rechner, die Notizen sind Markdown-Textdateien, wie die Obsidian-Hilfe beschreibt. Seit Februar 2025 ist Obsidian auch für die berufliche Nutzung kostenlos.
- Im Vault die Ordner raw und wiki anlegen. Wenn Sie Git kennen, machen Sie den Vault zum Repository; dann lässt sich jede Änderung des Modells nachvollziehen und zurücknehmen.
- Die Regeldatei AGENTS.md in den Vault legen, ein Beispiel folgt unten. Codex liest AGENTS.md bei jedem Start, so die Dokumentation von OpenAI. Claude Code liest sie ebenfalls, solange keine CLAUDE.md daneben liegt, laut Anthropic.
- Quellen sammeln. Der kostenlose Obsidian Web Clipper speichert Webseiten als Markdown im Vault. PDFs, Protokolle und eigene Notizen legen Sie direkt in raw ab.
- Den Agenten im Vault-Ordner starten und die erste Quelle übergeben, zum Beispiel mit dem Satz „Nimm raw/angebot-2026.md in das Wiki auf. Halte dich an AGENTS.md.“
Die Regeldatei: zwanzig Zeilen bestimmen das Ergebnis
Diese Datei ist die zweite Fassung aus unserem Test. Sie ist bewusst kurz, denn das Modell liest sie bei jedem Start, und jede Regel soll sich prüfen lassen.
# Regeln für dieses Wiki
## Ordner
- raw/: Quellen. Nur lesen, nie ändern.
- wiki/: Seiten, die du pflegst. Eine Seite pro Begriff, Produkt, Regel oder Entscheidung, nicht pro Quelle.
- wiki/index.md: Katalog aller Seiten, je eine Zeile Beschreibung.
- wiki/log.md: Protokoll. Nur anhängen, nie umschreiben.
## Seiten
- Dateiname klein mit Bindestrichen, zum Beispiel wiki/rag.md.
- Oben zwei Sätze Zusammenfassung.
- Jede Tatsachenaussage endet mit der Quelle als [[raw/dateiname]].
- Verweise auf andere Seiten als [[seitenname]]. Jede Seite verlinkt mindestens zwei andere Seiten.
- Widersprechen sich Quellen, entscheide nicht selbst. Notiere beides unter "Offene Fragen".
## Abläufe
- Aufnehmen: Lies zuerst index.md. Ergänze bestehende Seiten, bevor du neue anlegst. Lege für jeden Begriff, der in der Quelle wichtig ist, eine eigene Seite an oder ergänze sie. Aktualisiere index.md und log.md und nenne im Log alle geänderten Seiten.
- Fragen: zuerst index.md lesen, dann die Seiten. Antwort mit Quellen. Was im Wiki fehlt, als Lücke nennen.
- Prüfen: tote Links, Seiten ohne eingehende Links, Aussagen ohne Quelle und Widersprüche auflisten. Nichts löschen.
Die wichtigste Zeile ist die Quellenpflicht. Sie macht aus einer Zusammenfassung eine Aussage, die Sie in einer Minute nachprüfen können, und sie ist die Grundlage für die automatische Prüfung weiter unten. Die Regel zum Aufnehmen haben wir erst nach dem ersten Durchlauf so ausführlich formuliert: zuerst index.md lesen, bestehende Seiten ergänzen, eine Seite pro Begriff statt pro Quelle. Ohne diese Sätze ist bei uns kein Wiki entstanden, sondern ein Ordner mit Zusammenfassungen.
Aufnehmen, Fragen, Prüfen: die drei Abläufe
Beim Aufnehmen geben Sie eine Quelle nach der anderen hinein und lesen kurz, was sich geändert hat. Laut Karpathy kann eine einzige Quelle 10 bis 15 Seiten berühren, weil sie bestehende Einträge ergänzt oder ihnen widerspricht. Wie viele es bei uns waren, zeigt der Test unten.
Beim Fragen liest das Modell zuerst index.md und dann die passenden Seiten und antwortet mit Quellen. Eine gute Antwort, etwa ein Vergleich zweier Angebote, kann es als neue Seite ablegen. So wächst das Wiki auch durch Ihre Fragen.
Beim Prüfen sucht das Modell regelmäßig nach toten Links, Seiten ohne Verweise, Aussagen ohne Quelle und Widersprüchen. Einen Teil davon erledigt Obsidian ohne Sprachmodell: Die Obsidian CLI ab Version 1.12 listet mit den Befehlen unresolved, orphans und deadends nicht aufgelöste Links und unverbundene Seiten. Solche festen Prüfungen sind billiger und zuverlässiger als ein Modell, das sich selbst kontrolliert.
Unser Test: fünf Fachartikel, zwei Fassungen der Regeln
Als Quellen dienten fünf eigene Journal-Artikel mit zusammen rund 6.400 Wörtern, zu RAG, Kosten von KI-Assistenten, DSGVO bei Chatbots, Halluzinationen und EU-Hosting. Codex CLI mit dem Modell GPT-5.6 Terra hat sie nacheinander aufgenommen, einmal mit einer ersten, kürzeren Fassung der Regeldatei und einmal mit der Fassung oben. Danach haben wir Links, Quellenangaben und Zahlen mit einem kleinen Skript gezählt und je zehn zufällig gezogene Aussagen von Hand mit der Quelle verglichen. Die Zeiten enthalten eine Prüfung auf Zugangsdaten, die unsere Umgebung vor jedem Dateizugriff vorschreibt.
| Messung | Erste Fassung | Zweite Fassung |
|---|---|---|
| Dauer pro Quelle | 36 bis 74 Sekunden | 68 bis 178 Sekunden |
| Geänderte Dateien pro Quelle | 3 | 6 bis 13 |
| Inhaltsseiten nach fünf Quellen | 5 | 30 |
| Links zwischen Inhaltsseiten | 1 | 105 |
| Tatsachenaussagen mit Quelle | 106 von 106 | 175 von 175 |
| Zahlen, die so in der Quelle stehen | 40 von 40 | 28 von 28 |
| Stichprobe, von der Quelle gedeckt | 10 von 10 | 10 von 10 |
Die Quellenpflicht hat das Modell in beiden Durchläufen lückenlos eingehalten, und in den Stichproben war keine Aussage erfunden. Ein Wiki ist mit der ersten Fassung trotzdem nicht entstanden. Jede Quelle wurde zu genau einer Zusammenfassung, keine Aufnahme hat eine bestehende Seite ergänzt, und zwischen den fünf Seiten gab es einen einzigen Link. Die Regel „eine Seite pro Begriff“ legte das Modell großzügig aus: Für den Artikel über RAG war RAG der eine Begriff. Mit der zweiten Fassung entstanden 30 Seiten, von denen sieben Aussagen aus zwei Quellen zusammenführen, etwa zu Datenwegen, KI-Transparenz und technischem Betrieb. Das dauerte etwa doppelt so lange.
Danach haben wir eine erfundene Gesprächsnotiz hinzugefügt: Ein Anbieter richte einen einfachen Website-Assistenten für 900 Euro ein, unsere Planungsannahme liegt bei 1.500 bis 5.000 Euro. Mit der ersten Fassung landete das Angebot auf einer eigenen Seite, auf die keine andere Seite verweist. Mit der zweiten stand es auf der Seite zum Einrichtungsbudget direkt unter der Planungsannahme, wo der Abstand ins Auge fällt. Als Widerspruch unter „Offene Fragen“ notiert hat es keine der beiden Fassungen, denn das Modell wertete ein konkretes Angebot und eine Planungsannahme als verschiedene Dinge. Wenn Sie Abweichungen bei Preisen oder Fristen sehen wollen, schreiben Sie genau das als Regel in die Datei.
Frage und Prüfung liefen auf dem Wiki der ersten Fassung. Auf die Frage nach Kosten und DSGVO las das Modell zuerst index.md, dann drei Seiten und zur Kontrolle die Quellen. Es nannte beide Preisangaben nebeneinander mit korrekten Verweisen, fasste aber einmal zwei getrennte Spannen der Quelle zu einer eigenen Monatssumme zusammen, die rechnerisch stimmt, so aber nirgends steht. Die Prüfung durch das Modell meldete keine Befunde. Unser Skript fand vier Inhaltsseiten, auf die keine andere Inhaltsseite verweist; das Modell hatte die Links aus dem Index mitgezählt. Für solche Zählungen sind ein Skript oder die Obsidian CLI verlässlicher als das Modell.
Welches Modell passt: Cloud-Agent oder lokal
Damit das Wiki funktioniert, muss das Modell Dateien lesen und schreiben können. Dafür eignen sich Agenten für die Kommandozeile wie Claude Code oder Codex, die direkt im Vault-Ordner arbeiten. Ein gewöhnliches Chatfenster kann keine Seiten im Vault ändern und taugt deshalb nur für einzelne Fragen.
Wer die Notizen nicht aus dem Haus geben will, kann Codex mit einem lokalen Modell betreiben. Ollama beschreibt dafür den Befehl ollama launch codex und empfiehlt ein Kontextfenster von mindestens 64.000 Tokens. Ob ein lokales Modell die Regeldatei so zuverlässig einhält wie ein Cloud-Modell, haben wir nicht getestet. Prüfen Sie es mit denselben Messungen wie in unserem Test.
Datenschutz: Was der Agent liest, sieht auch der Anbieter
Obsidian speichert Ihre Notizen lokal. Der Agent schickt aber den Inhalt jeder Datei, die er liest, an den Modellanbieter. Bei Anthropic etwa entscheiden Nutzer der Tarife Free, Pro und Max seit der Änderung der Verbraucherbedingungen im August 2025, ob ihre Chats und Claude-Code-Sitzungen zum Training verwendet werden dürfen. Mit Zustimmung werden die Daten fünf Jahre gespeichert, sonst 30 Tage; Team, Enterprise und die API sind von dieser Regel ausgenommen, wie Anthropic mitteilt.
Daraus folgt eine einfache Grenze. Eigene Notizen und öffentliche Quellen können Sie mit einem privaten Konto verarbeiten, wenn das Training abgeschaltet ist. Kundendaten, Personalunterlagen und Verträge gehören nach unserer Empfehlung nur in einen Vault, dessen Modell unter einem Geschäftsvertrag mit Auftragsverarbeitung nach Art. 28 DSGVO oder lokal läuft. Was ein solcher Vertrag enthalten muss, steht in unserer DSGVO-Checkliste für Website-Chatbots, die Hosting-Fragen in KI in der EU betreiben.
Grenzen der Methode
Die Größe ist die erste Grenze. Karpathy schreibt, das Inhaltsverzeichnis trage bei etwa 100 Quellen und einigen hundert Seiten erstaunlich gut. Darüber braucht das Modell eine Suche, Karpathy nennt dafür die lokale Suchmaschine qmd mit Volltext- und Vektorsuche, und Sie sind wieder bei einer Form von RAG.
Die zweite Grenze sind Fehler, die sich fortpflanzen. Ein falscher Satz im Wiki wird zur Grundlage späterer Seiten und Antworten, und anders als im Chat steht er dort dauerhaft. Quellenpflicht, Git und regelmäßige Prüfungen fangen das ab, ersetzen aber nicht Ihren Blick auf die Seiten, die Sie für Entscheidungen nutzen. Warum Sprachmodelle überzeugend Falsches schreiben, erklärt unser Artikel zu Halluzinationen im Kundenservice.
Die dritte Grenze ist das Team. Ein Vault ist ein Ordner ohne Rollen, Freigaben oder Zugriffsrechte pro Seite. Für eine Person funktioniert das sehr gut, für ein Team mit vertraulichen Bereichen nicht.
Häufige Fragen
Brauche ich Obsidian für ein LLM-Wiki?
Nein. Das Wiki besteht aus Markdown-Dateien in einem Ordner, die jeder Editor öffnet. Obsidian ist der bequemste Leser dafür, weil Links, Rückverweise und Graph ohne Einrichtung funktionieren.
Was kostet ein Second Brain mit Obsidian und KI?
Obsidian selbst ist kostenlos, die Synchronisation über mehrere Geräte mit Obsidian Sync kostet laut Preisliste 4 US-Dollar im Monat bei jährlicher Zahlung. Hinzu kommt das Sprachmodell, entweder über ein Abo mit Claude Code oder Codex oder nach Verbrauch über die API.
Geht das auch mit ChatGPT?
Mit Codex CLI von OpenAI ja: Es liest AGENTS.md und arbeitet direkt im Vault, unser Test lief damit. Das Chatfenster von ChatGPT kann keine Dateien im Vault ändern und eignet sich nur für einzelne Fragen.
Ist ein LLM-Wiki besser als RAG?
Es löst eine andere Aufgabe. Das Wiki eignet sich für eine überschaubare Sammlung, die eine Person verstehen und pflegen will. RAG eignet sich für große, oft geänderte Dokumentbestände und für Anwendungen, in denen viele Nutzer Fragen stellen, etwa einen Kundenchat.
Das Muster aus Quellen, gepflegten Seiten, Quellenpflicht und festen Prüfungen trägt auch über das persönliche Second Brain hinaus, etwa für Angebote, Handbücher oder Projektentscheidungen im Unternehmen. Dann kommen Zugriffsrechte, Hosting in der EU und klare Zuständigkeiten hinzu. Wenn Sie das für Ihr Team prüfen möchten, sprechen Sie mit uns über KI-Automatisierung mit LindenTech. Bringen Sie 20 typische Dokumente und zehn Fragen mit, die Ihr Team heute zu oft stellt.