LLM-Wiki 2026: Vom Gist zum Ökosystem – Obsidian-Plugin, Enterprise-Adaption und sechs Monate Community-Praxis

Sechs Monate ist es her, dass Andrej Karpathy auf GitHub einen unscheinbaren Gist veröffentlichte – ein paar hundert Zeilen Prompt-Pattern, kein Installer, kein Repository. Die Idee: Statt bei jeder Frage Dokumente neu zu durchsuchen wie bei RAG, baut ein KI-Agent aus den Quellen eine dauerhafte, verknüpfte Wissensbasis in Markdown auf – das „LLM Wiki". Was damals wie ein Experiment für KI-Enthusiasten wirkte, hat sich zu einem der meistdiskutierten Patterns im persönlichen Wissensmanagement entwickelt. 5.000 Sterne und ebenso viele Forks später wird klar: Hier entsteht ein Ökosystem.

Vom Prompt-Pattern zur Plattform: Das Obsidian-Plugin

Die einflussreichste Weiterentwicklung des Karpathy-Patterns ist ein Obsidian-Plugin, das den Gist in einen vollwertigen Editor integriert. Entwickelt von gd4ai und Greener-Dalii, erreichte das Plugin innerhalb von fünf Monaten 45.000 Downloads und liegt aktuell in Version 1.27.1 vor. Der entscheidende Unterschied zu anderen Implementierungen: Es ist ein reines Obsidian-Plugin ohne externe Abhängigkeiten. Kein Python-Laufzeit, kein Vektor-Embedding-Modell, keine separate Desktop-App – der gesamte Workflow lebt innerhalb des Editors.

Die Architektur setzt auf PPR (Personalized PageRank) plus Monte-Carlo-Suche über das [[wiki-link]]-Graph statt auf herkömmliches RAG. Das Plugin unterstützt über 16 KI-Anbieter (Anthropic, OpenAI, Gemini, DeepSeek, Qwen, Ollama, LM Studio, OpenRouter u. a.), und die Daten verlassen das Gerät nie, wenn ein lokales Modell zum Einsatz kommt. PDFs, Office-Dokumente und Bilder werden nativ verarbeitet. Die Community hat das Plugin inzwischen in elf Sprachen übersetzt.

Die 200-Dateien-Grenze und ihre Lösung

Eine der interessantesten Erkenntnisse aus der monatelangen Praxis stammt von Kunal Ganglani, der das Karpathy-Pattern drei Monate lang täglich nutzte und seine Erfahrungen detailliert dokumentierte. Sein zentraler Befund: Sobald das Wiki rund 150 bis 200 Dateien überschreitet, können die meisten KI-Agenten den vollständigen Graph nicht mehr im Kontext halten. Die Qualität der Verknüpfungen und Aktualisierungen leidet spürbar.

Die Community hat dafür einen pragmatischen Workaround entwickelt: einen Master-Index, der jede Seite mit einer einzeiligen Zusammenfassung auflistet. Der Agent liest zuerst den Index, lädt dann nur diejenigen Seiten selektiv, die für eine bestimmte Aktualisierung relevant sind. In der Praxis erweitert dieser Ansatz die Kapazität auf über 300 Seiten. Für noch größere Wissensbasen existiert mit qmd ein CLI-Tool, das lokale hybride Suche (BM25 plus Vektor mit Re-Ranking) als MCP-Server anbietet – quasi RAG über dem Wiki, wenn das Wiki selbst zu groß wird.

Enterprise-Adaption: Wenn das Pattern auf die Organisation trifft

Die natürliche Frage nach sechs Monaten: Lässt sich das persönliche Pattern auf Unternehmen übertragen? Falconer, ein auf Wissensmanagement spezialisiertes Unternehmen, hat sich dieser Frage angenommen und die vier Eigenschaften identifiziert, die Karpathys Wiki erfolgreich machen: Erfassen (Capture), Verknüpfen (Link), Kumulieren (Compound) und Aktualisieren (Stay Current).

Die Analyse zeigt: Keine dieser Eigenschaften lässt sich direkt auf Unternehmensgröße skalieren. Der persönliche raw/-Ordner, in dem der Nutzer Quellen manuell kuratiert, hat in einem Unternehmen keine Entsprechung. Die relevanten Quellen verteilen sich über GitHub, Slack, Linear, Confluence, Google Drive und Dutzende weiterer Tools. Bidirektionale Verknüpfungen müssten über Tool-Grenzen hinweg funktionieren – ein Slack-Entscheid müsste mit dem umsetzenden PR, dem Linear-Ticket und dem Meeting-Transkript verknüpft sein. Und die automatischen Health-Checks, die Karpathy regelmäßig auf seinem persönlichen Wiki laufen lässt, müssten in einer Organisation ohne manuellen Kurator auskommen.

Y Combinator hat dieses fehlende Fundament im Spring‑2026‑RFS explizit benannt: „Ein Company Brain, das KI-Agenten tatsächlich nutzen können" – eine Infrastruktur, die es heute noch nicht gibt. Der Stack Overflow Developer Survey 2024 belegt die Dringlichkeit: Über 60 % der Entwickler verbringen täglich mindestens 30 Minuten mit der Suche nach Lösungen, und 68 % stoßen mindestens einmal pro Woche auf ein Wissenssilo. Bei Führungskräften steigt der Wert auf 73 %.

Vergleich der Implementierungen

Das LLM-Wiki-Ökosystem hat in sechs Monaten mehrere konkurrierende Ansätze hervorgebracht: SamurAIGPT/llm-wiki-agent (rund 3.300 GitHub-Sterne, als Claude‑Code/Codex-Skill) setzt auf Louvain-Community-Detection und SHA256-Caching, nashsu/llm_wiki (10.000+ Sterne) liefert eine Tauri-Desktop-App, und der atomicstrata/llm-wiki-compiler arbeitet als TypeScript-CLI mit BM25 plus semantischer Suche über Chunks. Das Obsidian-Plugin bleibt das einzige, das ohne zusätzliche Laufzeit auskommt.

Fazit

Das LLM Wiki hat den Proof of Concept hinter sich gelassen. Das Obsidian-Plugin mit 45.000 Downloads beweist, dass das Pattern für den Einzelanwender produktiv funktioniert – mit Einschränkungen ab 200 Dateien, die jedoch durch Community-Lösungen adressiert werden. Die spannendere Frage ist die Enterprise-Adaption: Hier fehlt noch die Infrastruktur, um die vier Erfolgseigenschaften automatisiert auf Unternehmensgröße zu skalieren. Y Combinator hat den Bedarf erkannt – ob und wann die erste befriedigende Lösung kommt, wird eines der interessantesten Themen der kommenden Monate sein.

Quellen

• LLM Wiki Setup: Karpathy’s Knowledge Base [2026 Guide] – Kunal Ganglani — Drei-Monats-Praxisbericht mit 200-Dateien-Grenze und Workarounds
• Karpathy LLM Wiki – Obsidian Plugin — Plugin-Dokumentation mit Vergleichstabelle und Architekturbeschreibung
• The Enterprise LLM Wiki – Falconer Guides — Analyse der vier Eigenschaften und ihrer Skalierbarkeit auf Unternehmen
• Karpathy’s LLM Wiki Gist — Original-Prompt-Pattern (5.000+ Sterne, 5.000+ Forks)
• Stack Overflow Developer Survey 2024 — Nutzerdaten zu Wissenssilos und Suchzeiten