MoAI-ADK: ein Harness, das Claude Code einen Prüfpfad gibt

Das Problem ist der Kontext, nicht das Modell

Das README formuliert die Ausgangslage in einem Satz, der sich zitieren lässt: das Modell sei ein stochastischer Arbeiter, der Token für Token voranschreitet und sich von Zug zu Zug nicht merken könne, was es verbraucht hat, ob das Ergebnis taugt oder wie weit die letzte Sitzung kam. Ein Harness erzwingt diese drei Dinge von außen. Genau dort setzt MoAI-ADK an, und die Zielgruppe ist eng umrissen: Teams und Einzelentwickler, die Claude Code nicht für einzelne Prompts verwenden, sondern für Arbeitseinheiten, die als SPEC beschrieben sind. Wer nur gelegentlich eine Funktion generieren lässt, braucht dieses Werkzeug nicht. Wer dagegen wiederholt an derselben Spezifikation arbeitet, kennt das Problem: eine lange SPEC füllt das Kontextfenster, und danach trägt jede Phase die Last aller vorherigen mit sich. Der Plan, den man beim Review nicht mehr braucht, liegt weiter im Fenster, während das Review läuft, und das Review liegt noch dort, während die Dokumentation entsteht. Der übliche Ausweg ist /clear, und der wirft den Faden zusammen mit dem Ballast weg.

Vier Terminals, vier Kontexte, ein Backend pro Spalte

Der Kanban-Modus ab Version 3.1 verteilt eine Arbeitseinheit auf vier Terminals statt auf eines. Eine Lead-Session treibt die Kette, drei Companion-Sessions besitzen je eine Spalte: plan, run, sync. Jede Companion-Session trägt ausschließlich den Kontext ihrer Spalte. Das Review ist ausdrücklich keine eigene Spalte, sondern wird vom sync-Gate absorbiert, das die Review-Perspektiven selbst durchläuft, um zum Urteil zu kommen. Wichtig ist, was das nicht ist: keine Aufhebung des Kontextlimits. Jede Session hat weiterhin ihr eigenes Limit. Geändert hat sich nur, dass keine Session drei Phasen Geschichte mit sich herumträgt, weshalb dasselbe Budget weiter reicht und eine abgeschlossene Phase geräumt werden kann, ohne die Karte zu verlieren. Das Board hat fünf Spalten: backlog, plan, run, sync, done. backlog besitzt bewusst keine Session, Arbeit gelangt also nur durch eine explizite Handlung auf das Board. Die Lead-Session rückt eine Karte nur auf Grundlage von Belegen vor, die sie aus der progress.md der Karte gelesen hat, nicht auf Grundlage der Antwort einer Companion-Session, denn eine Antwort ist eine Behauptung. Das ist der architektonische Kern: der Fortschritt hängt an einer Datei, nicht an einer Nachricht zwischen Sitzungen.

Der Start: eine Zeile pro Terminal

Die Einrichtung folgt dem Muster einer Lead-Session plus benannter Companions. Das README zeigt vier Befehle. Der Lead startet mit moai cc -k und kündigt eine run-id an. Die drei Companions folgen in eigenen Terminals: moai cc -k --name plan, moai cc -k --name run, moai cc -k --name sync. Companions werden von Hand gestartet, eine Session erzeugt nie eine andere. Die Benennung ist an eine Regel gebunden: Companions tragen ihren bloßen Rollennamen, die run-id bleibt der Lead-Session vorbehalten und wandert nie in einen Companion-Namen. Beansprucht eine zweite lebende Session dieselbe Rolle, bekommt sie die nächste freie Nummer. Wer eine Spalte auf das GLM-Backend legen will, ersetzt in genau dieser Zeile moai cc durch moai glm. Der Factory-Modus folgt einer anderen Syntax: moai cc -f öffnet einen Lead mit einer Lane, moai cc -f 4 einen Lead mit vier Lanes, moai cc -f lane-1 eine einzelne Lane im eigenen Terminal, moai glm -f lane-3 dieselbe Lane auf GLM. Eine Lane lässt sich mit moai cc -f lane-<n> einzeln nachziehen. Diese Form benennt die Lane bereits, weshalb --name oder -n daneben ein Fehler ist. Ebenfalls ein Fehler ist die Kombination von -k und -f, weil ein Start genau einen Einstiegs-Token verbraucht, und moai cg verweigert den Factory-Modus ganz.

Die Backend-Empfehlung ist eine Kostenentscheidung

Beim Öffnen eines Kanban-Laufs liefert der Bootstrap-Hinweis eine Standardempfehlung, die zuerst auf die Token-Verfügbarkeit schaut: Lead auf moai glm -k, plan auf moai cc -k --name plan, run auf moai glm -k --name run, sync auf moai cc -k --name sync. Die Begründung im README ist die Art des Denkens, die eine Spur braucht. Plan und sync verlangen Urteilsvermögen und Review, also sitzen sie auf Claude. run ist implementierungslastig, dort hält GLM die Kosten niedrig. Der Lead rendert keine Urteile, sondern beobachtet die Warteschlange und bewegt Karten, weshalb ein billig wartendes GLM passt. Braucht man unter einem GLM-Lead dennoch ein Claude-Urteil, führt der Weg über eine Session namens judge. Das ist laut README die einzige Route, auf der ein GLM-Lead Claude nutzt. Stößt ein Konto an 429-Antworten, ist das Verteilen der Spuren über mehrere Konten der praktikable Zug. Diese Mischung ist ausdrücklich nur der Standard. Eine andere Kombination oder eine Vereinheitlichung aller Sessions auf ein Backend ist ebenso zulässig. Bemerkenswert ist die Offenheit: das Werkzeug verkauft keine bestimmte Verteilung als richtig.

Factory Mode: viele Karten, ganze Lanes, harte Grenzen

Der Factory-Modus ist die zweite Form des Kanban-Betriebs und unterscheidet sich in der Bewegung der Arbeit. Eine Kanban-Karte hüpft zwischen Spalten. Eine Factory-Karte geht ganz an eine Lane, und diese Lane führt sie seriell durch plan, run, sync, wobei jede Phase als Agent()-Subagent erzeugt wird. Lanes heißen lane-1 bis lane-N. Eine Lane fährt bis zu 10 gleichzeitige Agent()-Subagents, und schreibfähige Spawns werden in einem eigenen Worktree isoliert. Karten werden nie über Lanes aufgeteilt. Die Verwaltung der Nummern ist der wunde Punkt: eine Nummer wird nur übersprungen, solange eine lebende Session sie hält. Eine tote Lane gibt ihre Nummer frei, und sie wird wiederverwendet. Welche Nummern gehalten werden, steht in .moai/state/factory/workers.json, und genau dort werden veraltete Ansprüche bereinigt. Das README gibt außerdem eine Betriebsanweisung, die man als Warnung lesen sollte: niemals alle Lanes auf einmal hochfahren. Erst die erste starten, bestätigen, dass sie tatsächlich Ausgabe produziert, dann die übrigen aktivieren. Wer diese Reihenfolge ignoriert, arbeitet gegen die Zustandsdatei statt mit ihr.

Grenzen: vier Terminals sind Bedienaufwand

Der Kanban-Modus löst ein Kontextproblem und erzeugt ein Bedienproblem. Vier Terminals, vier Sessions, eine run-id, die nur im Lead lebt, und Nummernvergabe, die von lebenden Sitzungen abhängt. Das ist keine Kleinigkeit für einen einzelnen Entwickler an einem Laptop. Dazu kommt, dass die Companion-Sessions von Hand gestartet werden müssen. Es gibt keine Automatik, die einem die Terminals aufspannt. Ein weiterer Punkt, der aus dem Material klar hervorgeht: der Fortschritt hängt an progress.md. Das ist bewusst so gebaut, weil eine Antwort nur eine Behauptung ist, aber es bedeutet auch, dass die Karte ohne gepflegte Datei stehen bleibt. Der Factory-Modus verschärft das, weil Zustand in .moai/state/factory/workers.json liegt und ein abgebrochener Lauf dort Spuren hinterlässt. Und schließlich die Kostenlogik: die Empfehlung beruht auf Token-Verfügbarkeit. Wer ein einziges Konto mit knappem Kontingent hat, für den ist die Mischung aus Claude und GLM kein Sparmodell, sondern eine Verteilung desselben knappen Vorrats. Falsch ist das Werkzeug für alle, die eine einzelne Sitzung mit klarem Faden bevorzugen. Der Kontextgewinn wird mit Koordinationsaufwand bezahlt, und bei kurzen Aufgaben überwiegt der Aufwand.

Alternative: eine Session mit klarer Spezifikation

Die naheliegende Alternative ist der Verzicht auf das Harness und die Arbeit in einer einzigen Claude-Code-Session mit einer diszipliniert kurzen SPEC. Der Unterschied liegt nicht im Modell, sondern in der Zustandsführung. MoAI-ADK verlagert den Fortschritt in Dateien und Spalten und erzwingt das Vorrücken über Belege aus progress.md. Die Einzelsession verlässt sich darauf, dass der Entwickler selbst erkennt, wann der Kontext voll ist, und dann bewusst neu ansetzt. Das ist weniger Infrastruktur und weniger Zustand, den man pflegen muss, aber es gibt auch keine Instanz, die eine Behauptung des Modells von einem gelesenen Beleg unterscheidet. Genau diese Unterscheidung ist der Beitrag von MoAI-ADK. Wer bereits mit /clear arbeitet und dabei den Faden verliert, für den ist der Wechsel eine Verbesserung. Wer mit /clear gut zurechtkommt, gewinnt durch vier Terminals nichts. Eine zweite Abgrenzung betrifft das Modell-Routing: wer ohnehin nur ein Backend nutzt, für den entfällt der Hauptgrund für die Spaltenaufteilung, und damit ein guter Teil des Nutzens.

Pflege, Lizenz und was vor dem ersten Lauf zu klären ist

Das Projekt steht unter Apache-2.0, was die kommerzielle Nutzung und Änderung erlaubt und eine Weitergabe der Lizenz sowie Hinweise auf Änderungen verlangt. Das ist keine Rechtsberatung, sondern nur die Einordnung der Lizenzkennung aus dem Repository. Zur Pflege: die letzten veröffentlichten Versionen sind v3.1.2 vom 21. August 2026, v3.1.1 vom 20. August 2026 und v3.1.0 vom 15. August 2026, der letzte Push datiert auf den 10. September 2026. Die Abstände zwischen v3.1.0 und v3.1.2 betragen wenige Tage, was auf eine Phase mit häufigen Korrekturen hindeutet. Wer dem main-Branch folgt, sollte mit schnellen Patch-Versionen rechnen. Das README nennt Go 1.26+ als Anforderung, und die Beschreibung spricht von einer einzelnen Go-Binärdatei ohne Abhängigkeiten. Der Upgrade-Aufwand liegt damit beim Binary, nicht bei einem Paketbaum. Ein Punkt bleibt offen: das README ist an der Stelle abgeschnitten, an der es um die zweite Regel für ein ehrliches Board geht, und der Satz zur Zustellung zwischen Sitzungen endet mitten im Wort. Wer die vollständigen Regeln braucht, muss die verlinkte Dokumentation unter adk.mo.ai.kr lesen. Das Repository enthält außerdem Workflows für CI und CodeQL sowie eine Codecov-Anbindung, was auf eine geprüfte Codebasis hindeutet, aber nichts über die Qualität der Ausgaben aussagt.

Redaktionelles Fazit

Wer Claude Code bereits produktiv nutzt, lange SPECs kennt und die Modellwahl pro Arbeitsphase steuern will, findet in MoAI-ADK einen konkreten Mechanismus statt einer Versprechung: vier Terminals, vier Kontexte, ein Backend pro Spalte. Wer eine einzelne Session bevorzugt oder keine Bereitschaft hat, den Ablauf über vier Terminals zu bedienen, sollte es nicht adoptieren. Vor dem ersten Lauf zu prüfen sind drei Dinge: ob die eigene Go-Version zu Go 1.26+ passt, ob `.moai/state/factory/workers.json` nach einem abgebrochenen Lauf alte Lane-Nummern freigibt, und ob die Spaltenbelegung aus der Bootstrap-Empfehlung zum eigenen Kontingent passt. Der Kostenhebel liegt nicht im Modell, sondern in der Spaltenzuordnung.

Offizielle Quellen

1. License: Apache-2.0
2. modu-ai/moai-adk on GitHub
3. Project website
4. README
5. Releases