Ihr Arbeitspensum
—Single-Thread-Gesamtzahl
—Fan-out insgesamt
—Ersparnisse
Gesamtkosten nach Aufgabenanzahl (N)
Alles andere wird an Ihren Eingängen oben gehalten und über N gewischt. Achten Sie darauf, wo der Fan-Out den Single-Thread überholt.
| Aufgaben (N) | Single-Thread | Fan-out | Günstiger |
|---|
So funktioniert dieser Rechner
A einzelnes sich ansammelndes Gespräch Bei der Bearbeitung von N Aufgaben wird der gesamte Verlauf jedes Mal erneut gesendet: Die Eingabe von Aufgabe i ist Basiskontext + (i-1) × vorherige-Ausgabe-Tokens. Über N Aufgaben hinweg summiert, wächst dieser Verlaufsbegriff wie folgt N × (N-1) / 2 – quadratisch in N – obwohl die Arbeit jeder Aufgabe identisch groß ist. Fanout auf isolierte Subagenten Gibt jeder Aufgabe einen neuen Kontext: Basiskontext + Aufgabe, plus eine feste Orchestrator-Dispatch-Eingabeaufforderung, um sie zu starten, und die Ausgabe des Subagenten, die als Orchestrator-Eingabe zurückgelesen wird. Dieser Overhead gilt pro Aufgabe und ist nicht kumulativ, sodass die Gesamtsumme des Fan-Outs skaliert linear in N, plus einem letzten Syntheseschritt.
Bei den Standardwerten (20 Aufgaben, 4.000 Basiskontext-Tokens, 1.200 Ausgabe-Tokens/Aufgabe, 300-Token-Versand, Preise der Sonnet-Klasse) fügt allein der Single-Thread-Verlaufsbegriff etwa 19×20/2 = 190 zusätzliche „vorherige Ausgabe“-Blöcke mit 1.200 Tokens zur Eingabe späterer Aufgaben hinzu – ein Kostenaufwand, der sich durch Single-Thread auszahlt, der sich durch Fan-Out einfach nie ansammelt. Small N bevorzugt Single-Thread, da es den Dispatch-/Ingest-Overhead vermeidet; Die Sweep-Tabelle zeigt genau, wo sich der Crossover Ihrer Arbeitslast befindet.
Häufig gestellte Fragen
Warum wird ein einzelnes langes Gespräch pro Aufgabe mit der Zeit teurer?
Da die meisten Chat-Abschluss-APIs zustandslos sind, wird bei jeder Runde der gesamte Konversationsverlauf als Eingabe-Token erneut gesendet. Aufgabe 1 sendet nur den Basiskontext. Aufgabe 20 sendet den Basiskontext sowie die Ausgabe der Aufgaben 1–19. Dieser Verlaufsterm wächst mit jeder Aufgabe, sodass die Gesamtzahl der Eingabetokens über N Aufgaben hinweg wie N*(N-1)/2 skaliert – quadratisch in N –, obwohl die eigene Arbeit jeder einzelnen Aufgabe gleich groß ist.
Warum wird dieses Wachstum durch die Verteilung auf isolierte Subagenten verhindert?
Jeder Subagent erhält ein neues Kontextfenster – seinen eigenen Basiskontext plus seine eine Aufgabe, nichts von den anderen N-1-Aufgaben. Der Orchestrator zahlt nur für eine kurze Versandaufforderung zum Starten jedes Subagenten und eine kurze Zusammenfassung zum Zurücklesen jedes Ergebnisses. Dieser Overhead ist pro Aufgabe festgelegt, sodass die Gesamtkosten linear mit N statt quadratisch skalieren. Der Kompromiss besteht im Dispatch-/Ingest-Overhead des Orchestrators selbst, weshalb Fan-out bei sehr kleinem N nicht automatisch günstiger ist.
Ab welcher Aufgabenanzahl beginnt der Fan-Out zu gewinnen?
Es hängt davon ab, wie groß Ihre Pro-Task-Ausgabe im Verhältnis zum Dispatch-/Ingest-Overhead des Orchestrators ist – größere Ausgaben machen den Single-Thread-History-Term-Ballon schneller und ziehen den Crossover-Punkt auf ein kleineres N. Verwenden Sie die Sweep-Tabelle unten mit Ihrem eigenen Basiskontext, Ihrer eigenen Ausgabegröße und dem Orchestrator-Overhead, um Ihren genauen Crossover zu finden, anstatt sich auf eine Faustregel zu verlassen.
Gilt dies auch für Claude Code-Subagenten, LangGraph oder CrewAI?
Die zugrunde liegende Mathematik ist die gleiche für jedes Framework, in dem ein Orchestrator isolierte Kontextarbeiter entsendet und kurze Ergebnisse zurücksammelt – Claude-Code-Subagenten, LangGraph-Subgraphen, CrewAI-Crews oder eine handgerollte Fan-Out-Schleife. Was sich zwischen den Frameworks unterscheidet, ist der genaue Dispatch- und Aufnahme-Overhead pro Subagent, weshalb es sich hier um separate Eingaben und nicht um fest codierte Eingaben handelt.