Wer täglich mit KI-Coding-Agenten arbeitet, merkt schnell eine Sache: Ein einziges starkes Modell für wirklich jede Aufgabe einzusetzen, ist teuer und oft langsamer als nötig. Die spannende Frage ist nämlich nicht, welches Modell das beste ist, sondern welche Aufgabe überhaupt an welches Modell gehört. Genau hier setzt das Orchestrator-Executor-Prinzip an. In diesem Beitrag zeige ich, wie wir im KI-Zentrum mit Claude Code ein Hauptmodell als Orchestrator und mehrere günstige Subagents als Executor kombinieren, wie das Modell-Routing im Alltag aussieht und wann sich der Ultracode-Modus für einen kompletten Sicherheits- und Performance-Audit lohnt.
Das Wichtigste in Kürze
- Das Hauptmodell plant und delegiert, es führt nicht jede Zeile selbst aus. Es agiert als Orchestrator.
- Günstige, spezialisierte Subagents übernehmen die Routinearbeit: Code lesen, Boilerplate schreiben, Tests ausführen.
- Jeder Subagent bekommt ein fest verdrahtetes Modell, damit die Kosten planbar bleiben, statt teuer zu erben.
- Für große, gut parallelisierbare Aufgaben wie einen Codebase-Audit gibt es den Ultracode-Modus mit vielen Agents im Hintergrund.
- Der Orchestrator prüft jedes Ergebnis, bevor er es akzeptiert. Ergebnissen von Subagents wird nicht blind vertraut.
Warum ein Modell für alles die falsche Wahl ist
Ein starkes Modell ist gut darin, schwierige Entscheidungen zu treffen. Aber ein großer Teil der täglichen Arbeit besteht gar nicht aus schwierigen Entscheidungen. Dateien finden, Boilerplate schreiben, Tests ausführen, Formatierung anpassen: Das sind Aufgaben, die ein günstiges Modell genauso zuverlässig erledigt, nur eben schneller und zu einem Bruchteil der Kosten.
Man würde auch keinen erfahrenen Entwickler den ganzen Tag Akten kopieren lassen. Wenn ein einziges Spitzenmodell jede Kleinigkeit selbst macht, liest es sich durch hunderte Dateien, füllt seinen Kontext mit Details und wird dabei langsamer und teurer, ohne dass die Qualität an den entscheidenden Stellen besser wird.
Was ist das Orchestrator-Executor-Prinzip?
Das Orchestrator-Executor-Prinzip trennt Denken von Ausführen. Ein starkes Hauptmodell, der Orchestrator, versteht die Aufgabe, plant sie, zerlegt sie in klar umrissene Teilaufgaben und delegiert diese an günstigere Modelle, die Executor. Danach prüft der Orchestrator die Ergebnisse gegen den Plan und fügt sie zusammen. Das Hauptmodell führt also selbst nur das aus, was echtes Urteil verlangt.
Der Vergleich mit einem gut geführten Team passt hier gut. Die erfahrene Person verteilt die Arbeit, gibt klare Anweisungen und prüft am Ende, ob das Ergebnis stimmt. Sie macht nicht jede Aufgabe selbst, aber sie trägt die Verantwortung für das Ganze.
Die drei Subagents, die den Unterschied machen
In der Praxis reichen drei kleine, spezialisierte Subagents, um den Großteil der Routinearbeit sinnvoll auszulagern. In Claude Code definierst du sie als Markdown-Dateien im Ordner .claude/agents. Jeder Subagent bekommt eine enge Rolle, ein festes Modell und nur die Werkzeuge, die er wirklich braucht.
code-scout, der Kundschafter
Der code-scout läuft auf einem günstigen Modell und darf ausschließlich lesen. Er bekommt nur die Werkzeuge Read, Glob und Grep, also nichts zum Schreiben oder Ausführen. Seine Aufgabe ist es, das Repo zu erkunden, Dateien und Code-Stellen zu finden und die Architektur kurz zusammenzufassen. Er gibt immer Dateipfade mit Zeilennummern zurück und ändert niemals etwas.
fast-worker, der Umsetzer
Der fast-worker läuft auf einem mittleren Modell und darf schreiben. Er setzt klar definierte Aufgaben um: Boilerplate, Tests, Refactorings nach Vorgabe und mechanische Änderungen über mehrere Dateien. Was er bewusst nicht tut, sind Architekturentscheidungen. Wenn eine Aufgabe unklar ist oder ein Design-Urteil verlangt, bricht er ab und meldet das zurück, statt zu raten.
test-runner, der Prüfer
Der test-runner läuft ebenfalls günstig und führt Tests und Linter aus. Statt den kompletten Output zurückzugeben, meldet er nur die fehlgeschlagenen Tests mit Fehlermeldung und betroffener Datei. Das hält den Kontext des Orchestrators schlank und die Rückmeldung präzise.
Tipp: Setze in jedem Subagent das Modell-Feld ausdrücklich. Fehlt die Angabe, erbt der Subagent automatisch das Modell der Hauptsession, und der ganze Spareffekt ist dahin. Genau dieses eine Feld entscheidet, ob dein Setup günstig oder teuer läuft.
Wie sieht das Modell-Routing in der Praxis aus?
Sobald die Subagents stehen, folgt das eigentliche Routing fast von selbst. Die Faustregel: Alles, was klar umrissen ist, wird delegiert, alles, was echtes Urteil verlangt, bleibt beim Orchestrator.
- Erkunden und Suchen im Code, also reine Leseaufgaben, gehen an code-scout auf dem günstigen Modell.
- Klar spezifizierte Implementierung, Boilerplate, Tests und mechanische Multi-File-Edits gehen an fast-worker auf dem mittleren Modell.
- Test- und Lint-Läufe gehen an test-runner auf dem günstigen Modell.
- Architekturentscheidungen, Migrationsplanung, komplexes Debugging, sicherheitskritische Änderungen und das finale Review macht der Orchestrator selbst.
Ein Detail ist dabei entscheidend. Bevor der Orchestrator etwas delegiert, schreibt er eine präzise, in sich geschlossene Spezifikation. Denn Subagents sehen die laufende Konversation nicht, sie kennen nur den Prompt, den sie bekommen. Je klarer dieser Auftrag ist, desto besser das Ergebnis.
Was ist Ultracode und wann lohnt es sich?
Ultracode ist ein Effort-Setting in Claude Code, das du mit dem Befehl /effort ultracode einschaltest. Es macht zwei Dinge gleichzeitig: Jede Nachricht wird mit dem höchsten Reasoning-Level bearbeitet, und Claude bekommt die stehende Erlaubnis, für größere Aufgaben selbstständig sogenannte Dynamic Workflows zu orchestrieren, statt dich jedes Mal manuell danach zu fragen.
Ein Dynamic Workflow ist ein Skript, das Claude spontan schreibt und das viele Subagents parallel im Hintergrund laufen lässt. Die vielen Zwischenergebnisse, etwa hunderte gelesene Dateien, bleiben im Skript und fluten nicht deinen Kontext, nur das Endergebnis landet im Gespräch. Technisch laufen bis zu 16 Agents gleichzeitig und bis zu 1000 pro Lauf. Genau diese Parallelisierung macht Ultracode stark bei Aufgaben, die sich sauber aufteilen lassen, etwa einem Audit oder einer großen Migration.
Achtung bei den Kosten: Jeder Agent in einem Workflow nutzt das Modell deiner Session, sofern das Skript eine Stage nicht ausdrücklich auf ein anderes Modell routet. Läuft deine Session auf einem teuren Modell, arbeiten also potenziell Dutzende Agents parallel zu diesem Tarif. Lege deshalb im Prompt fest, dass die breiten Scan-Stages auf günstige Modelle gehen.
Praxis: ein kompletter Security- und Performance-Audit in drei Phasen
Ein Sicherheits- und Performance-Audit über die gesamte Codebase ist der Paradefall für dieses Vorgehen, weil er sich sauber parallelisieren lässt. Jede Datei und jedes Modul kann unabhängig geprüft werden. Wir fahren so einen Audit in drei Phasen.
Phase 1: der Audit, nur lesend
In der ersten Phase liest Claude die gesamte Codebase, ändert aber nichts. Der Auftrag lautet: Verschaffe dir zuerst einen Überblick über Struktur, Stack und die Kernflows und prüfe dann systematisch auf drei Ebenen.
- Security: Injection (SQL, Command, Template), fehlende oder fehlerhafte Auth- und Berechtigungsprüfungen, Secrets im Code, unvalidierte Eingaben, unsichere Deserialisierung, XSS und CSRF, zu freizügige CORS-Regeln, veraltete Dependencies und sensible Daten in Logs.
- Performance: N+1-Queries und ineffiziente Datenbankzugriffe, fehlende Indizes, blockierende Calls an Stellen die asynchron sein sollten, unnötige Schleifen und Allokationen in Hot Paths, fehlendes Caching und nicht geschlossene Ressourcen.
- Funktionale Logik: Lücken und Widersprüche in der Geschäftslogik, ungültige Statusübergänge, fehlende Validierung und die Frage, ob Frontend- und Backend-Prüfungen wirklich zusammenpassen.
Wichtig ist die Anweisung, jedes Finding gegen den tatsächlichen Code zu verifizieren, bevor es in den Report kommt. So landen keine spekulativen Treffer im Ergebnis. Das Resultat ist ein priorisierter Report mit Datei, Zeilennummer, Schweregrad und einem konkreten Fix-Vorschlag.
Phase 2: der Plan
In der zweiten Phase geht es zurück in eine normale Session. Der Orchestrator nimmt den Report und entscheidet, was in welcher Reihenfolge behoben wird, was zusammenhängt und wo ein Fix das Risiko eines Breaking Change trägt. Das ist klassische Planungsarbeit und braucht keine Workflows.
Phase 3: die Umsetzung
In der dritten Phase folgt die Umsetzung. Die klar umrissenen Fixes gehen an fast-worker, nach jedem Block prüft test-runner die Tests. Die wenigen heiklen Stellen, etwa Auth-Logik oder Änderungen an der Architektur, übernimmt der Orchestrator selbst. Am Ende steht ein finales Review gegen den ursprünglichen Report.
Multi-Agent-Workflows verbrauchen ein Mehrfaches einer normalen Session. Bei einem echten Audit ist das gerechtfertigt, aber teste den Verbrauch zuerst an einem einzelnen Verzeichnis und arbeite auf einem eigenen Branch oder mit Git-Worktrees, damit du sauber zurücksetzen kannst.
Worauf du achten solltest
- Setze das Modell-Feld in jedem Subagent explizit. Ohne Angabe erbt der Subagent automatisch das Hauptmodell, und genau das willst du bei Routinearbeit vermeiden.
- Vertraue Ergebnissen von Subagents nicht blind. Der Orchestrator prüft jedes Ergebnis, bevor er es übernimmt.
- Eine Aufgabe pro Subagent-Aufruf. Fokussierte Prompts liefern bessere Ergebnisse als ein überladener Auftrag.
- Schreibe die Spezifikation in sich geschlossen. Subagents kennen nur, was im Prompt steht, nicht die laufende Konversation.
- Formuliere Sicherheitsarbeit defensiv, also finde und behebe Schwachstellen in meinem Code. Das beschreibt die Aufgabe ehrlich und vermeidet unnötige Rückfragen.
- Arbeite auf einem eigenen Branch oder mit Git-Worktrees. Ein Audit-Upgrade fasst viele Dateien an, und du willst sauber zurücksetzen können.
- Checke das Setup ins Git ein. Dann nutzt das ganze Team dasselbe Routing statt jeder seine eigene Konfiguration.
Fazit
Der Kern ist einfach: Trenne Denken von Ausführen. Ein starkes Hauptmodell plant, delegiert und prüft, günstige Subagents erledigen die Routinearbeit, und für die großen, gut teilbaren Aufgaben schaltest du gezielt Ultracode dazu. So wird die Arbeit mit KI-Agenten nicht nur günstiger, sondern auch schneller und nachvollziehbarer. Wichtig bleibt der letzte Schritt in jeder Delegation: prüfen, bevor du ein Ergebnis übernimmst.
Ihr wollt KI nicht nur ausprobieren, sondern sauber und kosteneffizient in eure Entwicklung einbauen? Genau dabei unterstützen wir euch. Schreibt uns, und wir schauen gemeinsam, wo sich der Einsatz bei euch am meisten lohnt.
Häufige Fragen
Brauche ich für das Orchestrator-Executor-Setup zusätzliche Tools oder Abos?
Nein. Das ganze Prinzip läuft innerhalb von Claude Code über Subagents und Modell-Routing. Du definierst die Subagents als Markdown-Dateien im Ordner .claude/agents und legst pro Subagent fest, welches Modell und welche Werkzeuge er nutzen darf.
Verliere ich die Kontrolle, wenn Subagents automatisch arbeiten?
Nein. Der Orchestrator prüft jedes Ergebnis, bevor er es übernimmt, und du kannst jeden Subagent auch gezielt selbst anstoßen. Die Delegation nimmt dir Routinearbeit ab, die Entscheidungen bleiben bei dir.
Wann lohnt sich der Ultracode-Modus?
Ultracode lohnt sich bei großen, gut parallelisierbaren Aufgaben wie einem kompletten Codebase-Audit oder einer größeren Migration. Für alltägliche Routinearbeit ist ein normaler Effort-Level günstiger und vollkommen ausreichend.
Wie halte ich die Kosten im Griff?
Setze pro Subagent ein festes, günstiges Modell für die breite Arbeit und reserviere das starke Modell für Urteil und Review. In Workflows routest du die reinen Scan-Stages auf günstige Modelle. Und du testest den Verbrauch vorab an einem einzelnen Verzeichnis, bevor du das ganze Repo laufen lässt.