AI-Coding-Agents im Großbetrieb: Wie Fleet Parallelität wirklich steuert

Moderne KI-Modelle sind leistungsstark. Der eigentliche Engpass liegt aber meist in der Koordination. Wer einmal 50 Claude-Code-Sessions gleichzeitig laufen ließ, merkte schnell: Ohne zentrale Steuerung entsteht Chaos statt Geschwindigkeit.

Fleet ist ein schlanker Python-Supervisor, der genau diese Lücke schließt.

Das klassische Koordinationsproblem

Mehrere KI-Agenten parallel zu betreiben klingt einfach. In der Praxis scheitert es an drei Punkten: Aufgabenverteilung, Konfliktvermeidung und Token-Verbrauch. Wer nur separate Verzeichnisse mit eigenen Claude-Instanzen startet, verliert schnell den Überblick.

Was fehlt, ist eine zentrale Instanz, die Abhängigkeiten kennt, Prioritäten verwaltet und den Zustand des gesamten Projekts im Blick behält.

Fleet im Kern: Einfachheit durch Zentralisierung

Fleet löst das mit drei gezielten Design-Entscheidungen.

Eine zentrale Aufgabenliste

Alle Tasks landen in einer Git-basierten Datenbank unter ~/.fleet. Mit fleet bd create wird nicht nur der Auftrag gespeichert, sondern auch das Arbeitsverzeichnis. Jeder Agent startet genau dort, wo er gebraucht wird. Dadurch arbeiten mehrere Agenten unabhängig voneinander, ohne dass Merge-Konflikte oder doppelte Arbeit entstehen.

Beliebige Modelle und Anbieter

Fleet ist nicht auf Claude festgelegt. Unterstützt werden aktuell Claude (stabil), Agy/Antigravity (kurz getestet) und Codex (implementiert, aber noch nicht erprobt). Neue Agenten lassen sich in wenigen Minuten anbinden. Das erlaubt es, je nach Aufgabe das passende Modell zu wählen.

Begrenzte Parallelität, automatisches Queueing

Standardmäßig laufen maximal drei Agenten gleichzeitig. Über fleet config set max_concurrent=10 lässt sich die Zahl erhöhen. Fleet kümmert sich um die Warteschlange. Der echte Limitierer bleibt fast immer das eigene Token-Kontingent.

Praktische Befehle statt Dashboards

Die CLI bleibt bewusst schlank:

• fleet tasks zeigt laufende Jobs, aktiven Coder und Token-Verbrauch
• fleet task <id> log liefert die konkrete Arbeitsausgabe
• fleet task <id> plan gibt Einblick in die geplante Vorgehensweise
• fleet task <id> knowledge listet den verfügbaren Kontext auf

Keine unnötigen Oberflächen – nur die Infos, die wirklich zählen.

Token-Budget statt Agenten-Anzahl

Wer intensiv mit Fleet arbeitet, stößt schnell auf die gleiche Erkenntnis: Nicht die Agenten-Kapazität ist der Flaschenhals, sondern die Token-Limits. Viele Nutzer drehen sich daher mehrere Claude-Accounts parallel und achten streng auf schlanke Kontexte. Dazu gehört auch, doppelt geladene Dateien in CLAUDE.md oder Plugin-Verzeichnissen zu entfernen – oft spart das mehr als ein zusätzlicher Agent.

Was Fleet für die eigene Architektur ändert

Statt einzelne KI-Tools zu nutzen, entsteht ein koordiniertes Team:

• Specs lassen sich in Teilaufgaben zerlegen und automatisch verteilen
• Jeder Agent erhält nur den Kontext, der für seine Aufgabe relevant ist
• Verschiedene Modelle können parallel auf dieselbe Spezifikation losgelassen und direkt verglichen werden

Technisch überraschend einfach

Ursprünglich war Fleet nur eine Bash-Schleife, die eine Queue überwacht hat. Die Python-Version ergänzt nur das Nötigste: Abhängigkeiten, Prioritäten, Concurrency-Limits und Lebenszyklus-Management. Der schwierige Teil liegt nicht in der Technik, sondern darin, Aufgaben sinnvoll zu zerlegen und Token effizient einzusetzen.

Fazit

Fleet zeigt: Mehrere KI-Coder parallel zu betreiben ist machbar. Der echte Gewinn entsteht aber erst durch drei Faktoren zusammen – parallele Ausführung (Fleet), sinnvolle Task-Aufteilung (du) und konsequentes Token-Management (du). Wer an dem Punkt ist, an dem ein einzelner Agent nicht mehr reicht, findet hier ein Werkzeug, das genau diese Lücke schließt.