Artikel
Schluss mit blindem Fan-out: Claude Haiku 5.5 in einer 4-Schichten-Orchestrierung
Claude Haiku 5.5 ist extrem schnell und günstig. Wer aber alle Tasks blind parallel darauf wirft, potenziert Fehlinterpretationen, Reviewer Bias und Supply-Chain-Risiken. Dieser Artikel analysiert eine mehrschichtige Architektur: Fable für Architektur-Entscheidungen, Opus für Orchestrierung, Sonnet und Haiku für die Implementierung, CI zur Validierung und Opus zur Abnahme – inklusive Leitfaden, welche Aufgaben sich wirklich für Fan-out eignen.
· 6 Min. Lesezeit
Claude Haiku 5.5 ist am 7. Oktober 2026 erschienen. Bei Prompts unter 100.000 Tokens kostet das Modell nur ein Zwanzigstel von Sonnet 5.5 und bietet gleichzeitig die geringste Latenz der aktuellen Claude-Generation.
Günstig und schnell – da liegt die Versuchung nahe: Warum nicht einfach alle Coding-Tasks aufteilen, parallel an eine Gruppe von Haiku-Instanzen übergeben und abwarten?
Für reine Prototypen mag das funktionieren. In produktionsnahen Software-Engineering-Umgebungen stößt man damit jedoch sehr schnell auf drei grundlegende Probleme:
- Kleine Modelle sind anfällig für Ambiguitäten. Anthropic positioniert Haiku 5.5 primär für Klassifizierung, Extraktion, Routing und Subagent-Workflows – also Tasks mit hohem Durchsatz und minimaler Latenz. Enthalten die Anforderungen fachliche Unschärfen oder erfordern tiefes Kontextverständnis des Gesamtsystems, liefert das Modell oft Resultate, die oberflächlich solide wirken, fachlich aber völlig am Ziel vorbeigehen.
- Modelle als Reviewer erzeugen Reviewer Bias. Lässt man ein großes Modell Dutzende parallel generierte Implementierungen bewerten, neigt es dazu, die Variante zu bevorzugen, die strukturell am elegantesten aussieht – nicht zwingend diejenige, deren Logik und Ausführung tatsächlich fehlerfrei sind.
- Berechtigungen skalieren linear mit der Anzahl der Worker. Dürfen parallele Subagents eigenständig Dependencies installieren oder Konfigurationen manipulieren, öffnet jeder einzelne von N Workern ein zusätzliches Einfallstor für kompromittierte Third-Party-Packages.
Aus diesem Grund setze ich auf Hierarchical Orchestration: Jede Ebene übernimmt ausschließlich das, worin sie stark ist. Die parallele Skalierung von Haiku wird nur dort genutzt, wo sie echten Mehrwert bringt.
Das Fazit vorweg: Fable durchdenkt das System, Opus orchestriert und nimmt ab, Sonnet übernimmt die primäre Implementierung, und Haiku erledigt mechanische Tasks sowie explorative Aufgaben mit automatisierter Verifikation. Kandidaten durchlaufen erst die CI, bevor ein Modell sie überhaupt zu Gesicht bekommt.
Die 4-Schichten-Architektur: Beurteilung, Orchestrierung, Verifikation, Abnahme#
Anforderungs-Input
│
▼
[Entscheidungsebene] Fable: Architekturentscheidungen, Task-Splitting, Acceptance Criteria
│
▼
[Orchestrierungsebene] Opus Main Session: Nur Zuweisung, kein erneutes Aufteilen
├─► Pfad A: Komplex, aber klar abgegrenzt ──► Sonnet-Implementierung
├─► Pfad B: Mechanische Routineaufgaben ──► Einzelner Haiku
├─► Pfad C: Explorativ, mehrere Lösungsansätze ──► Mehrere Haiku-Instanzen, jeweils im eigenen Git Worktree
│
▼
[Verifikationsebene] Build, Type Check, Test, Benchmark (Pfad C: nur Top 2–3)
│
▼
[Abnahmeebene] Opus führt gemäß Acceptance Criteria zusammen
Eskalation bei Fehlern: Nach 2 gescheiterten Korrekturen durch Haiku ➔ Sonnet ➔ Zurück an Opus
Die Zuordnung der Modelle zu den jeweiligen Schichten basiert auf den offiziellen Spezifikationen und Kostenstrukturen von Anthropic (Stand: 8. Oktober 2026; Preise pro Million Tokens in USD):
| Modell |
Offizielle Ausrichtung |
Latenz |
Input / Output Preis |
| Claude Fable 5.1 |
Hochkomplexes Reasoning und langlaufende Agent-Workflows |
Eher langsam |
$10 / $50 |
| Claude Opus 5.5 |
Langlaufendes agentenbasiertes Coding und Knowledge Work |
Mittel |
$4 / $20 |
| Claude Sonnet 5.5 |
Optimale Balance aus Performance und Reasoning-Kapazität |
Schnell |
$2 / $10 |
| Claude Haiku 5.5 |
High-Throughput, Low-Latency für Klassifizierung, Routing und Subagents |
Extrem schnell |
Ab $0.10 / $0.50 |
Die Preisstruktur von Haiku 5.5 ist gestaffelt: Bei Prompts über 100.000 Tokens steigt der Preis auf $0.50 / $2.50.
Entscheidungsebene: Fable für Systemarchitektur und Acceptance Criteria#
Nicht jede Aufgabe rechtfertigt den Einsatz von Fable. Es ist die teuerste und langsamste Ebene; ich reserviere sie gezielt für mehrdeutige Requirements, systemübergreifende Integrationen oder fundamentale Architekturentscheidungen.
Fable muss am Ende drei konkrete Artefakte liefern:
- Das Lösungsdesign
- Das finale Task-Splitting
- Für jeden Subtask: Acceptance Criteria, die sich automatisiert über Tests validieren lassen
Reasoning und Dekonstruktion müssen auf derselben Ebene stattfinden. Nur wer die architektonischen Blind Spots des Gesamtsystems durchdringt, kann Subtasks mit sauberen Schnittstellen schneiden. Überlässt man das Systemdesign Modell A und das Task-Splitting Modell B, verwischen die Interface-Grenzen erfahrungsgemäß schnell.
Eine Ausnahme bilden Security-spezifische Aufgaben. Die aktuelle Claude-Generation verfügt über vorgeschaltete Sicherheitsklassifizierer. Wird ein Prompt abgelehnt, liefert das Modell stop_reason: "refusal" – was legitime Security-Workflows fälschlicherweise blockieren kann. Der Klassifizierer von Fable 5.1 filtert den Großteil sicherheitsrelevanter Kontexte heraus, da das Modell laut Dokumentation nicht für offensive oder defensive Security-Analysen ausgelegt ist. Opus 5.5 hingegen erlaubt die Analyse von Sourcecode auf Schwachstellen. Für die Behebung von Vulnerabilities übergebe ich die initiale Analyse daher direkt an Opus.
Orchestrierungsebene: Opus weist zu, spaltet nicht neu auf#
Opus fungiert als Main Session und übernimmt das Routing sowie das Dispatching. Diese Ebene stellt weder die Architektur infrage, noch zerlegt sie Aufgaben ein zweites Mal.
- Pfad A – Komplex, aber klar eingegrenzt: Logisch anspruchsvolle Aufgaben mit eindeutig definierten Interfaces gehen an Sonnet. Es ist das primäre Arbeitspferd für die Implementierung.
- Pfad B – Rein mechanische Routine-Tasks: Boilerplate-Code, Refactoring von Variablennamen, einfache Unit Tests oder Dokumentations-Updates übernimmt eine einzelne Haiku-Instanz.
- Pfad C – Explorative und optimierungsgetriebene Aufgaben: Performance-Tuning, iterative Entwürfe für komplexe SQL-Queries oder Regex-Pattern sowie das Isolieren von Flaky Tests. Genau hier zahlt sich Fan-out aus: Mehrere Haiku-Worker untersuchen parallel in jeweils isolierten Git Worktrees unterschiedliche Lösungswege.
Unabhängig vom gewählten Pfad muss jedes Arbeitsergebnis die Verifikationsebene durchlaufen.
Ein weit verbreiteter Anti-Pattern besteht darin, parallel erzeugten Code unbesehen an Opus oder Sonnet zu übergeben und via Prompt um ein Review zu bitten.
Modelle lassen sich bei Code-Reviews schnell von sauber formatiertem Layout und lückenlosen Typannotationen blenden – was keinerlei Aussagekraft darüber hat, ob der Code Edge Cases standhält. Kandidaten müssen sich daher zuerst vor der Maschine beweisen:
- Build und Type Check: Code muss kompilieren und das Type-Checking fehlerfrei passieren.
- Unit / Integration Tests: Alle Unit- und Integrationstests müssen grün sein.
- Benchmark / Profiling: Überprüfung von Durchsatz, Latenz und Memory-Footprint.
Alles, was automatisierte Checks nicht besteht, fliegt sofort raus. Bei Pfad C bekommt Opus ausschließlich die zwei bis drei besten Varianten vorgelegt, die alle Schranken genommen haben. Das schont Context Window und Tokens.
Abnahmeebene: Opus konsolidiert – mit klarer Escalation Path#
Zum Schluss führt Opus die Resultate anhand der zuvor definierten Acceptance Criteria zusammen. Gerät ein Worker in eine Sackgasse, greift eine strukturierte Escalation Path:
- Scheitert Haiku und schlagen zwei automatisierte Reparaturversuche fehl, wird der Loop rigoros abgebrochen.
- Sonnet übernimmt den Task zur Behebung.
- Kann auch Sonnet die Kriterien nicht erfüllen, deutet das meist auf einen Widerspruch im ursprünglichen Task-Splitting oder in den Grundannahmen hin. Der Task wird an Opus zurückgegeben; Opus entscheidet dann, ob die Aufgabe zur Neukonzeption zurück an Fable geht.
Drei Leitlinien für den Produktiveinsatz#
Kein unüberlegter Fan-out#
Triviale Tasks benötigen keine Flotte von Workern, und hochgradig mehrdeutige Anforderungen überfordern kleine Modelle. Fan-out über parallele Haiku-Instanzen lohnt sich nur dann, wenn der Lösungsraum groß ist und sich Ergebnisse in Sekundenschnelle per CI oder Test-Runner automatisiert validieren lassen.
Isolierte Umgebungen, unveränderliche Lockfiles#
Ein Git Worktree isoliert lediglich Code-Änderungen auf Dateiebene, damit parallele Worker sich nicht gegenseitig überschreiben. Er isoliert weder den Netzwerkzugriff noch die Ausführungsrechte auf Betriebssystemebene. Um sich vor einer Supply Chain Attack zu schützen, ist eine restriktive Sandbox zwingend erforderlich. Worker dürfen weder eigenmächtig ungeprüfte Packages nachinstallieren noch die Lockfile modifizieren. Wer Installationsberechtigungen unkontrolliert freigibt, riskiert, dass Agents bösartige Abhängigkeiten und fremde Skripte direkt in die Codebase einschleusen.
Harte Metriken statt LLM-Prosa für die Abnahme#
Grüne Test-Suites, Testabdeckung, Speicherverbrauch und Latenzen sind reproduzierbare, messbare Fakten. Textuelles Feedback eines Sprachmodells kann nützliche Hinweise liefern, taugt aber nicht als Qualitätsnachweis für die finale Abnahme.
Günstige Modelle gezielt einsetzen#
Haiku 5.5 macht parallele Ausführung extrem erschwinglich. Parallelität allein macht fehlerhaften Code jedoch nicht magisch korrekt. Erst wenn Entscheidung, Orchestrierung, Verifikation und Abnahme sauber getrennt sind, werden niedrige Kosten und hohe Geschwindigkeit zu einem echten Hebel in der Softwareentwicklung.
Diese Schichtenarchitektur entspricht exakt dem Graph-Konzept, das ich in AI Agents sind im Grunde nichts anderes als ein agiles Team beschrieben habe: Wer fängt an, wer übernimmt danach – und an wen wird eskaliert, wenn etwas schiefgeht?