OpenWiki im Praxistest: Grounded Claims und ein komplett lokaler Lauf mit Ollama

Dokumentation verrottet, weil sie einmal geschrieben wird. Ein Gedächtnis bleibt nützlich, weil es ständig überschrieben wird. Das meiste, was als Doku durchgeht, ist in Wahrheit die erste Sorte im Gewand der zweiten – und genau deshalb veraltet es.

OpenWiki, ein Tool von LangChain, ist ein interessanter Versuch, das zu ändern. Im Folgenden wird erklärt, was es tut und wie sein Selbstkorrektur-Mechanismus funktioniert, gefolgt von einem Praxistest auf einem komplett quelloffenen Stack mit lokalen Modellen. Dieser Lauf brachte vier verschiedene Fehler, eine fast komische Rettung und ein Ergebnis, das besser ausfiel als erwartet.

Was OpenWiki ist

LangChain, das Team hinter einem großen Teil der Open-Source-Infrastruktur für KI-Apps, hat OpenWiki als kostenloses Kommandozeilenwerkzeug unter MIT-Lizenz veröffentlicht. Man richtet es auf ein Repo, ein Agent studiert den Code und schreibt untereinander verlinkte Markdown-Seiten in einen Ordner namens openwiki/. Mit neuen Commits werden die Seiten aktualisiert.

Menschen sind dabei nicht das Hauptpublikum, denn das Wiki ist für Agenten geschrieben. Das Tool fügt einen Verweis in AGENTS.md und CLAUDE.md ein – die Dateien, die Claude Code, Codex, Cursor und ähnliche Assistenten beim Start laden. Jeder Coding-Agent, der das Repo öffnet, findet so eine fertige Landkarte und spart sich die übliche Neuerkundung der Architektur. Eine Zusammenfassung zu überfliegen kostet weit weniger Tokens und Minuten, als den Quellcode erneut zu durchkämmen.

Aktualisierungen kommen aus der Versionsverwaltung. Das Tool prüft, welche Commits seit dem letzten Lauf hinzugekommen sind, liest die Diffs und schreibt nur die betroffenen Teile neu. Hängt man es an einen geplanten CI-Job, aktualisiert sich das Wiki täglich selbst und öffnet einen Pull Request, wie es ein menschlicher Kollege täte.

Grounded Claims: Fakten mit Belegen

Dokumentation erzeugen viele Tools. Was OpenWiki abhebt, ist ein Mechanismus namens Grounded Claims („belegte Aussagen“), und der verdient einen genauen Blick.

Jede wichtige Aussage lebt an zwei Orten. Sie ist Fließtext auf einer Wiki-Seite und zugleich ein strukturierter Eintrag in einer Begleitdatei, der auf die genauen Codezeilen verweist, die sie stützen, zusammen mit einem Hash dieser Zeilen in ihrem damaligen Zustand.

Hier ein Beispiel aus dem Testlauf. Eine Seite sagt, Events würden „persisted to the run_events table before any listeners are invoked“ (in der Tabelle run_events gespeichert, bevor irgendwelche Listener aufgerufen werden). Der zugehörige Eintrag verknüpft diesen Satz mit den Zeilen 9 bis 26 einer einzigen Datei. Ändert man diese Zeilen, passt der gespeicherte Hash nicht mehr, und die Aussage veraltet. Das zwingt beim nächsten Lauf zur Neugenerierung der Seite, selbst wenn der Update-Planer sie für in Ordnung hielt.

Das ist der Unterschied zwischen Dokumentation und Gedächtnis. Dokumentation wartet darauf, dass jemand bemerkt, dass sie falsch ist. Eine Aussage weiß selbst, wann sie falsch ist, und plant ihre eigene Reparatur. Die Doku beschreibt den Code nicht nur, sie lässt sich an ihm falsifizieren.

Woher die Idee stammt

OpenWiki kam nicht aus dem Nichts. Im April 2026 veröffentlichte Andrej Karpathy, Gründungsmitglied von OpenAI, einen kurzen Gist über ein „LLM Wiki“ mit drei Schichten: unveränderliche Rohquellen, ein Markdown-Wiki, das ein LLM daraus pflegt, und ein Schema, das die Organisation des Wikis beschreibt. Das Argument richtete sich gegen Retrieval-Augmented Generation, die übliche Praxis, Dokumente zum Zeitpunkt der Frage zu durchsuchen. Kompiliert man Wissen einmal in dauerhafte Seiten, so seine These, wächst es mit. Holt man jedes Mal Fragmente, verflüchtigt es sich.

Innerhalb weniger Tage knackte der Gist 5.000 Sterne, und LangChain nennt ihn als direkten Einfluss. So betrachtet ist OpenWiki die zum Produkt gewordene Skizze, plus Grounded Claims obendrauf. Die Ausgabe folgt Googles Open Knowledge Format in Version 0.2 (die OKF-Spezifikation liegt in Googles Repo knowledge-catalog), das jedem Agenten den Zugriff auf verpacktes Wissen ermöglichen soll. Markdown-Wikis als Agentengedächtnis werden leise zu einem gemeinsamen Muster, und OpenWiki ist dessen bislang vollständigste Form: 15.000 GitHub-Sterne in zwei Monaten, mit neuen Releases alle paar Tage. Das eigene Repository dokumentiert es selbst.

Der Praxistest: komplett Open Source

Folgt man der offiziellen Doku, erzeugt ein gehostetes Modell von OpenAI oder Anthropic laut Berichten aus der Community ein Wiki in rund drei Minuten für etwa zehn Cent. Der härtere Test ist, ob alles auf einem offenen Stack mit einem lokalen Modell läuft, sodass der gesamte Code auf dem Rechner bleibt.

Das Setup

Vier kostenlose, offene Bausteine:

• OpenWiki v0.4.0, global per npm install installiert.
• Ollama, um Modelle lokal bereitzustellen. Einen eingebauten Ollama-Provider gibt es nicht, aber OpenWiki kann jeden OpenAI-kompatiblen Endpunkt nutzen, und den stellt Ollama bereit.
• Zwei Open-Weight-Modelle: zuerst gpt-oss:20b von OpenAI (13 GB Download), dann Alibabas qwen3.5 4B (3,4 GB).
• Hardware: ein Laptop mit 24 GB Unified Memory, Mittelklasse und weit entfernt von einer Workstation.

Ziel war ein privater Prototyp namens Hangar, ein Server zur Agenten-Orchestrierung mit Web-UI. Er umfasst 58 TypeScript-Dateien, verteilt auf Server, Web-Client und Beispiele. Echter Code von bescheidener Größe, nichts Exotisches.

Die Provider-Konfiguration besteht aus ein paar Zeilen in ~/.openwiki/.env:

OPENWIKI_PROVIDER=openai-compatible
OPENAI_COMPATIBLE_API_KEY=ollama
OPENAI_COMPATIBLE_BASE_URL=http://localhost:11434/v1
OPENWIKI_MODEL_ID=gpt-oss:20b
OPENWIKI_TELEMETRY_DISABLED=1

Eine .openwikiignore-Datei im Repo-Root schloss node_modules, Build-Ausgaben, Lockfiles und Bilder aus. Sie wirkt als harte Grenze dafür, was gelesen wird, und bei einem lokalen Modell zählt das doppelt, weil alles, was der Agent liest, durch ein kleineres Fenster passen muss.

Dann wurde openwiki code --init --print ausgeführt – und scheiterte. Viermal, auf vier verschiedene Arten. Hinter jedem Fehler steckte eine Lektion, die der Fehlertext nie aussprach, denn dieser Text änderte sich von Mal zu Mal kaum.

Fehler 1: ein Fenster, das niemand erwähnte

Nach zwei Minuten endete der erste Lauf mit einer einzigen Zeile:

Repository planning worker exited without submit_plan.

Kein Trace, kein Grund. Die Ursache lag weit außerhalb von OpenWiki. Ollama startet jedes Modell mit einem Kontextfenster von 4.096 Tokens, dem Arbeitsgedächtnis, das das Modell auf einmal sehen kann. Der Prompt zum Scannen des Repos ist um ein Vielfaches größer. Ollama wirft bei einem Überlauf keinen Fehler. Es kürzt still den Anfang, sodass das Modell den Teil nie las, der erklärte, dass es ein Tool submit_plan gibt. ollama ps bestätigte das und listete das Modell mit CONTEXT 4096.

Die Lösung ist eine einzige Umgebungsvariable beim Start von Ollama. Wer das Experiment zu Hause nachstellt, braucht diese Zeile mehr als jede andere:

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Fehler 2: dieselbe Meldung, ein anderer Grund

Mit vergrößertem Fenster starb der Planer erneut – dieselbe Zeile nach denselben zwei Minuten. Hier wird das Debuggen lokaler KI-Stacks richtig schwer: ein Fehlertext, mehrere Ursachen und keine Telemetrie, um sie auseinanderzuhalten.

Der nächste Schritt war, die Schicht darunter zu testen. Eine von Hand gebaute Anfrage an Ollamas Endpunkt mit einem submit_plan-Tool-Schema würde zeigen, ob das Modell überhaupt einen strukturierten Tool-Aufruf zustande bringt:

curl http://localhost:11434/v1/chat/completions \
  -d '{"model":"gpt-oss:20b", "tools":[…submit_plan schema…], …}'

Sie lieferte einen tadellos geformten Tool-Aufruf, und zwar bei beiden Modellen. Isoliert funktionierte die Infrastruktur also, der Fehler lag im Transport zwischen OpenWiki und Ollama. OpenWiki sendet standardmäßig Anfragen ohne Streaming, und diese Pipeline brauchte Streaming. Eine weitere Zeile in der .env-Datei:

OPENWIKI_OPENAI_COMPATIBLE_STREAMING=true

Beim nächsten Lauf kam der Planer durch.

Fehler 3: ein starkes Modell, das nie abgab

Jetzt wurde es interessant. Mit funktionierender Planung machte sich das 20B-Modell an echte Arbeit. Die Aufrufe zogen sich von Sekunden auf über eine Minute, und nach acht Minuten lag eine echte Wiki-Seite auf der Platte: eine präzise Beschreibung von Hangars Event-Bus. Die Dateipfade stimmten, das Verhalten war korrekt beschrieben (erst persistieren, dann verteilen), und es gab eine ordentliche Feldreferenz-Tabelle. Das war kein Boilerplate. Das Modell hatte den Code verstanden.

Dann starb der Lauf trotzdem:

/openwiki/architecture/event_bus.md worker exited without submit_page.

Das Modell hatte den schwierigen Schreibteil erledigt und dann den formalen Tool-Aufruf ausgelassen, mit dem die Seite abgegeben wird. Die Pipeline verwarf eine Seite, die schon auf der Platte lag. Am Können lag es nicht. Es lag daran, am Ende eines langen Kontexts die Sache zu Ende zu bringen.

Fehler 4: auch das kleine Modell stolperte

Als Nächstes kam qwen3.5 4B an die Reihe, ein Modell mit einer der am besten getesteten Tool-Calling-Vorlagen in Ollama, jetzt mit einem Fenster von 65.536 Tokens. Es kam weiter und stellte die Event-Bus-Seite samt Claims-Begleitdatei fertig – die gesamte Pipeline hatte damit erstmals durchgängig funktioniert. Dann, nach 51 Minuten und mitten in Seite zwei, starb es mit der bekannten Meldung zu submit_page.

Jetzt war die Ursache klar. Ein Seiten-Worker häuft beim Arbeiten Kontext an: den Entwurf, die gelesenen Belege und den Verlauf der Tool-Aufrufe. Irgendwann fällt die abschließende Anweisung aus einem Fenster, das still abschneidet. Welches Modell lief, spielte keine Rolle. Entscheidend war, was die Serving-Schicht tut, wenn der Speicher ausgeht – und die Antwort lautet: nichts, ohne Warnung.

Die Rettung: eine Ralph-Schleife

Die Lösung war albern. Version 0.4.0 speichert den Fortschritt in einer dauerhaften Run-Datei, openwiki/.run.json, sodass eine unterbrochene Generierung dort weitermacht, wo sie aufgehört hat. Ein Tool, das alle paar Seiten abstürzt, lässt sich also reparieren, indem man es immer wieder startet, bis ein Lauf sauber endet.

Dieser Ansatz heißt Ralph-Schleife, nach dem liebenswert ahnungslosen Jungen aus den Simpsons: ein absichtlich dummes while-true, das dieselbe Anweisung wiederholt, bis die Arbeit erledigt ist. Dass es das Produkt eines anderen retten würde, hatte niemand erwartet. Der gesamte Harness besteht aus ein paar Zeilen Shell:

for i in 1 2 3 4 5 6 7 8; do
  if openwiki code --init --print; then
    echo "COMPLETE after $i iterations"; break
  fi
done

Ollamas Fenster wurde noch einmal vergrößert, auf 98.304 Tokens, für zusätzlichen Spielraum, und dann lief die Schleife.

Sechs Durchläufe und knapp drei Stunden später war es geschafft. Durchlauf eins sicherte vier fertige Seiten, Durchlauf zwei vier weitere. Die Durchläufe drei bis fünf blieben alle an einer schwierigen Seite hängen und sicherten nichts – der Punkt, an dem ein zuschauender Mensch vermutlich aufgegeben hätte. Durchlauf sechs kam durch, und die übrigen fünfzehn Seiten folgten in einem Rutsch, da Index- und Übersichtsseiten schnell geschrieben sind. Das Ergebnis: ein Wiki mit 23 Seiten und 18 belegten Aussagen, jeder Fakt an gehashte Belege gebunden, und Exit-Code null.

Am Modell hatte sich nichts verbessert. Fehler waren nur nicht mehr teuer, und das funktioniert nur, weil der Checkpoint fertige Arbeit sichert. Beharrlichkeit plus Speicherdatei schlägt zerbrechliche Raffinesse. Im fertigen Setup liegen Repo, Agent, Modellserver, Modell, Ausgaben und Wiederholungsschleife alle auf einer Maschine, und die einzige Leitung, die die Grenze überschreitet, ist die, die nie benutzt wird.

Ein ehrlicher Vergleich

Vergleichen wir die beiden Wege. Der Cloud-Weg dauert etwa drei Minuten und kostet rund zehn Cent ohne Ausgabenlimit, braucht keine besonderen Kenntnisse und schickt den Code aus dem Rechner hinaus. Der lokale Weg dauert insgesamt etwa vier Stunden und kostet nichts, verlangt aber, vier Fehlerschichten zu diagnostizieren und einen Retry-Harness zu bauen, und kein Byte verlässt den Computer.

Meistens lohnt sich der lokale Weg für die meisten Leute nicht. Die vierzigfache Dauer plus das Know-how, stille Fehler aufzuspüren, für zehn gesparte Cent – das ist ein schlechter Deal. Wenn Code das Gebäude aber nicht verlassen darf, ist es die einzige Wahl, und sie funktioniert eindeutig.

Wichtiger ist eine andere Erkenntnis. Jeder Fehler ging auf Konfiguration zurück, nicht auf Fähigkeiten. Die Modelle verstanden den Code, und das 20B-Modell schrieb präzise Architekturseiten. Kaputt ging jedes Mal die Infrastruktur: Standardfenster, die still abschneiden, Transporte, die Tool-Aufrufe verlieren, und Kontext, der ohne Warnung ausgeht. „Lokale Modelle sind nicht gut genug“ ist die falsche Lehre. Die richtige: Lokale Serving-Stacks scheitern noch immer still, und niemand macht das sichtbar. Das ist ein Engineering-Problem und keines der Modellgröße, und Engineering-Probleme werden gelöst.

Sollte man es ausprobieren?

Wenn der Code ohnehin über Cloud-APIs läuft, nur zu, und zwar jetzt. Die schnelle Variante liefert, die Seiten sind gut, und nichts anderes auf dem Markt hat etwas wie den Claims-Mechanismus. Ein paar Warnungen zu den scharfen Kanten: Erst committen, denn init löscht ein vorhandenes Wiki; die Kosten mit einem Key mit Verbrauchsabrechnung im Blick behalten, da nichts die Ausgaben deckelt und die Berichte stark schwanken; und daran denken, dass es ein frühes 0.x-Projekt ist, das sich schnell ändert.

Für komplett private Nutzung funktioniert es zum Zeitpunkt des Schreibens mit den Korrekturen oben und etwas Geduld. Vergrößern Sie vor allem anderen das Kontextfenster von Ollama.

Und für alle, die Wissen ohnehin in Markdown pflegen, lautet die größere Erkenntnis: Die Branche läuft von allen Seiten auf dieselbe Antwort zu – schlichte Textdateien, gepflegt von Agenten und korrigiert durch Belege. Das Wiki ist nicht das Produkt. Die Korrekturschleife ist es, und OpenWiki ist das erste Tool, das eine mit Belegen ausliefert.