Claude Code Workflows: 41 Agenten, 5 Mio. Tokens, getestet

Claude Code Workflows: 41 Agenten, 5 Mio. Tokens, getestet

Einundvierzig Agenten. So viele Haiku-Instanzen hat einer meiner Claude-Code-Workflows letzte Woche gleichzeitig hochgefahren, um jede Skill zu prüfen und zu bewerten, die ich installiert hatte. Ich beobachtete, wie der Zähler im Terminal stieg — 12, 28, 41 — jeder ein vollständiger, unabhängiger Claude-Aufruf, der ein anderes Rezept anhand von Kriterien bewertete, die ich dem Orchestrator übergeben hatte. Das Ganze verarbeitete ungefähr 5 Millionen Input-Tokens, bevor es fertig war.

Diese Zahl ließ mich innehalten. Fünf Millionen. Bei den meisten Preiskalkulationen klingt das nach einer panikauslösenden Rechnung. Aber hier ist der Twist, der das gesamte Feature für mich neu eingerahmt hat: Der Output war winzig. Ein Ranking-Bericht, ein paar hundert Zeilen. Der gesamte Token-Aufwand ging ins Lesen — Crawlen, Parsen, Bewerten — nicht ins Generieren. Rechenintensiv, sicher. Übertrieben teuer? Nicht wirklich. Haiku-Input-Tokens sind günstig, und 41 davon, die parallel lesen, waren in einem Bruchteil der Wanduhrzeit fertig, die ein einzelner Agent für das sequenzielle Abarbeiten desselben Stapels gebraucht hätte.

Das ist der Moment, in dem Claude-Code-Workflows für mich klickten. Nicht als Buzzword aus dem Opus-4.8-Launch. Als ein spezifisches Werkzeug mit einer spezifischen Form — eines, das sich wirklich von Skills, Sub-Agenten und Agenten-Teams unterscheidet und das erschreckend leicht falsch zu benutzen ist, wenn man diese Form nicht versteht.

Genau das ist dieser Beitrag. Keine Feature-Ankündigung. Ein Praxisleitfaden. Am Ende wirst du genau wissen, welches der fünf Orchestrierungsprimitive du greifen solltest — Skill, Sub-Agent, Agenten-Team, Workflow oder die /goal-Schleife — und ungefähr, was dich jedes an Tokens und Komplexität kostet. Ich habe das meiste davon auf die etwas teurere Art gelernt. Das musst du nicht.

Was Anthropic tatsächlich mit Workflows am 28. Mai ausgeliefert hat

Dynamische Workflows landeten am 28. Mai 2026, gebündelt in das Claude Opus 4.8-Release als Research Preview. Wenn du bereits meinen Überblick über die Effort-Level von Opus 4.8 gelesen hast, dann denke bei Workflows an die andere Hälfte dieses Releases — das Modell bekam einen Denkregler, und Claude Code bekam eine Möglichkeit, dieses Denken über Hunderte von Agenten gleichzeitig zu verteilen.

Du brauchst Claude Code v2.1.154 oder neuer, um sie zu nutzen. Sie funktionieren in der CLI, der Desktop-App und der VS Code Extension. Und die Art, wie du einen auslöst, ist fast verdächtig lässig: Du setzt einfach das Wort Workflow irgendwo in deinen Prompt. Sage „starte einen Workflow, um jede API-Route auf fehlende Auth-Checks zu prüfen" und Claude macht etwas, das es noch nie zuvor getan hat — es schreibt ein JavaScript-Orchestrierungsskript im Handumdrehen, übergibt es einer Hintergrund-Laufzeit, und diese Laufzeit startet die Agenten.

Zwei harte Limits, die du dir einprägen solltest: Die Laufzeit führt maximal 16 Agenten gleichzeitig aus, und eine einzelne Workflow ist auf 1.000 Agenten insgesamt begrenzt. Mein 41-Agenten-Skill-Audit kam nicht annähernd an die Obergrenze. Aber es ist sehr einfach, einen Prompt zu schreiben, der das tut — „analysiere jede Datei in diesem Monorepo" gegen ein paar tausend Dateien wird dieses Limit schnell ausreizen und die Warteschlange beschäftigt halten. Wir kommen darauf zurück, denn das ist die größte Art und Weise, wie Leute mit diesem Feature Geld verbrennen.

Hier ist das architektonische Detail, das wirklich zählt. Das Detail, das Workflows anders macht und nicht einfach „Sub-Agenten, aber mehr." Lass es mich zeigen.

Das eine Detail, das Workflows anders macht: Der Plan lebt außerhalb von Claudes Kopf

Jedes andere Orchestrierungstool in Claude Code hält seinen Plan innerhalb des Kontextfensters des Modells. Die Hauptsitzung merkt sich, was sie delegiert hat, verfolgt, was zurückkam, hält den laufenden Zustand in ihrem eigenen Arbeitsgedächtnis. Das ist in Ordnung für eine Handvoll Aufgaben. Bei Skalierung bricht es zusammen, weil Kontextfenster endlich sind und jedes zurückgesteckte delegierte Ergebnis Platz frisst, den du für tatsächliches Schlussfolgern brauchst.

Workflows brechen diese Regel vollständig. Der Plan und der Ausführungszustand leben in einer externen JavaScript-Datei, nicht in Claudes Kontext.

Lies das nochmal, denn es ist das ganze Spiel. Wenn du einen Workflow startest, entscheidet Claude nicht nur, Agenten zu starten — es schreibt ein echtes Skript: Schleifen, Verzweigungslogik, wie viele Agenten gestartet werden, was jeder bekommt, wie die Ergebnisse kombiniert werden, welche Verifizierungsrunden laufen. Dieses Skript wird in einem von dir angegebenen Ordner gespeichert. Eine separate Laufzeit führt es in einer isolierten Umgebung aus, völlig getrennt von deiner Chat-Sitzung. Die Zwischenergebnisse — jede Roh-Ausgabe jedes Agenten, jede Hilfsberechnung — bleiben in den Variablen des Skripts. Sie berühren nie deine Konversation.

Was in deine Sitzung zurückkehrt, ist nur die endgültige, kombinierte Antwort.

Stell dir den Unterschied bildlich vor. Mit Sub-Agenten ist deine Hauptsitzung ein Manager, der ein Klemmbrett hält und persönlich jeden Bericht verfolgt, wenn er hereinkommt. Bei einem Workflow schreibt deine Hauptsitzung ein Programm, gibt es an einen Build-Server, geht weg und kommt zu einem einzigen fertigen Artefakt zurück. Das Klemmbrett wird nie voll. Deshalb hat mein 41-Agenten-Audit das Kontextfenster nicht gesprengt, obwohl es 5 Millionen Token an Input verarbeitet hat — 99 % dieser Tokens lebten und starben innerhalb der Variablen des Skripts. Meine Sitzung sah nur den Ranking-Bericht am Ende.

Das hat zwei Konsequenzen, die ich erst nach ein paar Durchläufen begriffen habe. Erstens, weil die Orchestrierung eine gespeicherte Datei ist, sind Workflows wiederausführbar und versionskontrollierbar. Du kannst das Skript committen, diffen, einem Teamkollegen geben. Speichere einen nützlichen und er wird zu einem Slash-Kommando — dein Branch-Review-Workflow wird zu /my-review, für immer wiederholbar. Zweitens, und das ist entscheidend für das mentale Modell: Die gestarteten Agenten sprechen nicht miteinander. Jeder ist ein vollständig unabhängiger Claude-Aufruf mit seinem eigenen isolierten Kontext. Sie fächern auf, erledigen ihre eine Aufgabe, geben eine Zusammenfassung zurück, und das war's. Kein Austausch. Keine Debatte. Die Zusammenführung passiert in der Logik des Skripts, nicht in einem Gespräch zwischen Agenten.

Halte dieses „Agenten sprechen nicht"-Detail fest. Es ist die exakte Linie, die einen Workflow von einem Agenten-Team trennt — und diese Linie falsch zu ziehen, ist die Art, wie Leute das falsche Tool wählen und dafür bezahlen.

Skill vs. Sub-Agent vs. Agenten-Team vs. Workflow vs. /goal: Das mentale Modell

So. Hier ist der Teil, für den du gekommen bist. Fünf Primitive, und die ehrliche Wahrheit ist, dass die meisten Leute nur zwei davon brauchten und aus Begeisterung zu den teuren griffen. Ich auch. Lass mich jedes so durchgehen, wie ich es jetzt tatsächlich nutze, von günstigsten zu teuerstem, denn Kosten und Komplexität steigen gemeinsam auf einer sauberen Leiter: Skills → Sub-Agenten → Agenten-Teams → Workflows. Die /goal-Schleife steht daneben auf einer anderen Achse, und ich erkläre gleich, warum.

Was ist eine Skill in Claude Code?

Eine Skill ist ein wiederverwendbares Rezept, das in deiner persönlichen Claude-Code-Sitzung läuft. Es ist eine Ein-Agenten-Automatisierung — ein gespeicherter Satz von Anweisungen, den Claude auf Abruf aufrufen kann, durch dich oder andere Tools, ohne etwas Paralleles hochzufahren.

Das ist die unterste Stufe, und es sollte dein Standard sein. Eine Skill fächert nicht auf. Sie bekommt keinen eigenen separaten Kontext. Sie läuft direkt in deiner Sitzung, wie eine Funktion, die du beim Namen aufrufen kannst. Meine SEO-Check-Routine, mein Commit-Nachrichtenformatierer, mein „Prüfe diese Datei auf N+1-Queries"-Rezept — alles Skills. Günstig im Betrieb, trivial in der Wartung und überall wiederverwendbar. Ich habe ein ganzes Argument für Skills bauen, bevor du je zu Agenten greifst geschrieben, und ich stehe jetzt noch stärker dahinter als bei der Veröffentlichung. Die überwiegende Mehrheit der „Ich brauche dafür einen Agenten"-Instinkte sind in Wirklichkeit „Ich brauche dafür eine Skill."

Nutze eine Skill, wenn die Aufgabe klein, wiederholbar und in sich geschlossen ist. Wenn du sie als Rezept beschreiben kannst, ist es eine Skill. Fertig.

Was ist ein Sub-Agent?

Ein Sub-Agent läuft parallel zu deiner Hauptsitzung, teilt aber nicht deren Kontextfenster, kann nicht mit anderen Sub-Agenten sprechen und meldet sein Ergebnis nur an die Hauptsitzung zurück.

Das ist die nächste Stufe, und das Schlüsselwort ist Entlasten. Ein Sub-Agent ist für Situationen, in denen du eine Nebenaufgabe erledigt haben willst, ohne dass sie den Speicher deines Hauptthreads zumüllt. Angenommen, ich stecke tief in einem Refactoring und möchte die Erklärung der Test-Suite zusammengefasst haben, ohne meinen Kontext zu entgleisen — das übergebe ich einem Sub-Agenten. Der geht hin, erledigt die Sache, kommt mit einer Antwort zurück, und das Arbeitsgedächtnis meiner Hauptsitzung bleibt sauber. Der Kompromiss, den er eliminiert, ist Kommunikationsoverhead. Ein Sub-Agent koordiniert nicht, verhandelt nicht, informiert niemand anderen. Es ist ein Einwegauftrag. Das ist ein Feature, keine Einschränkung — es macht Sub-Agenten günstig und vorhersagbar.

Nutze einen Sub-Agenten, wenn du eine einfache, unabhängige Nebenaufgabe hast und sie aus deinem Hauptkontext heraushaben willst. Keine Zusammenarbeit nötig. Einfach „geh das erledigen und berichte zurück."

Was ist ein Agenten-Team?

Ein Agenten-Team ist eine kleine Gruppe von Agenten, die kommunizieren, Aufgaben teilen und auf ein Ziel hin zusammenarbeiten, innerhalb ihres eigenen gemeinsamen Kontextfensters — Agenten debattieren, koordinieren und bauen auf der Arbeit der anderen auf.

Jetzt sind wir auf der teuren Stufe, und das unterscheidende Wort ist Reden. Anders als bei Sub-Agenten können die Mitglieder eines Agenten-Teams einander sehen und Informationen austauschen. Sie teilen Kontext. Die Erkenntnis des einen Agenten informiert die des anderen. Sie debattieren, übergeben, konvergieren. Ich habe genau ausgearbeitet, wie und wann Agenten miteinander sprechen sollten, in einem eigenen Beitrag, und die Kurzfassung ist: Dieses Gespräch ist der ganze Punkt, und es ist auch der Grund, warum Teams echtes Geld kosten. Geteilter Kontext plus Hin-und-her bedeutet mehr Tokens, mehr Runden, mehr Rechenleistung.

Nutze ein Agenten-Team, wenn die Aufgabe wirklich kollaborativ ist — wenn die Diskussion zwischen Agenten etwas produziert, das kein einzelner Agent könnte, und wenn das Teilen von Kontext zwischen ihnen entscheidend ist. Architekturdebatten. Multi-Perspektiv-Reviews, bei denen die Kritik des einen Agenten den Vorschlag des anderen schärft. Nicht für Durchsatz. Für Beratung.

Was ist ein Workflow?

Ein Workflow ist ein JavaScript-orchestriertes System, das viele unabhängige Agenten startet — möglicherweise Hunderte — die parallel an verschiedenen Teilen einer Aufgabe arbeiten und deren Ergebnisse in Skriptlogik kombinieren. Die Agenten kommunizieren nicht; der Plan lebt in einer externen Datei, nicht in Claudes Kontext.

Oberste Stufe. Am mächtigsten, am komplexesten, am teuersten. Alles, was ich zwei Abschnitte zuvor beschrieben habe. Das definierende Merkmal, das Ding, das es von einem Agenten-Team trennt: Breite ohne Gespräch. Ein Team sind wenige Agenten, die reden. Ein Workflow sind viele Agenten, die nicht reden — jeder mahlt an seinem eigenen Segment, Ergebnisse werden durch Code zusammengeführt. Meine 41 Haiku-Bewerter waren ein Lehrbuch-Workflow: 41 unabhängige Jobs, null Cross-Talk, ein kombiniertes Ranking am Ende.

Nutze einen Workflow, wenn eine Aufgabe natürlich in viele unabhängige, parallelisierbare Teile zerfällt. Eine ganze Codebase crawlen. Einen großen Datensatz scoren. Breite Recherche über Dutzende Blickwinkel. Die Art von Arbeit, bei der die Teile nichts voneinander wissen müssen — sie müssen nur alle erledigt werden, schnell, und aufgerollt.

Was macht der /goal-Befehl?

/goal führt einen Schleifenprozess aus, bei dem ein Agent immer wieder am selben Problem iteriert, bis eine Abschlussbedingung erfüllt ist — das kann viele Zyklen durchlaufen und lange dauern.

Hier ist der Grund, warum ich sagte, /goal sitzt auf einer anderen Achse. Alles oben dreht sich um wie viele Agenten und ob sie reden. /goal dreht sich um wie oft ein Versuch iteriert. Es ist eine Schleife. Du übergibst ein Ziel und eine Definition von „fertig", und es mahlt — versuchen, bewerten, verfeinern, nochmal versuchen — bis die Bedingung erfüllt ist. Es kann ein Dutzend Zyklen laufen. Es kann eine ganze Weile dauern. Das ist erwartet.

Nutze /goal, wenn die Aufgabe Tiefe braucht — iterative Verfeinerung hin zu einem harten Ziel — statt Breite.

Und dieses Wort, Tiefe, ist der Schlüssel zur gesamten Karte. Lass es mich konkret machen.

Breite vs. Tiefe: Der Rahmen, der das Ganze endlich hat klicken lassen

Hier ist der eine Satz, der reorganisiert hat, wie ich über all das denke:

Workflows sind Breite. /goal ist Tiefe.

Ein Workflow breitet sich aus — viele Agenten, jeder ein anderes Stück bearbeitend, alle gleichzeitig. Breite. Du nutzt es, wenn die Arbeit breit ist: hundert Dateien zu scannen, fünfzig Behauptungen zu verifizieren, ein großer flacher Stapel unabhängiger Aufgaben. Der Gewinn ist Parallelismus. Du tauschst Tokens gegen Wanduhrzeit und bekommst einen breiten Job schnell erledigt.

Die /goal-Schleife bohrt sich hinein — ein Versuch, immer wieder verfeinert, bis er richtig ist. Tiefe. Du nutzt sie, wenn die Arbeit tief ist: ein einzelnes kniffliges Problem, das Zyklus für Zyklus durchgehämmert werden muss, bis es eine Latte reißt. Der Gewinn ist Beharrlichkeit. Du tauschst Zeit gegen Qualität bei einem schwierigen Ding.

Sobald ich diesen Rahmen hatte, hörte die Werkzeugwahl auf, Raterei zu sein. Breit und flach? Workflow. Schmal und tief? /goal. Beides nötig — ein breiter Job, bei dem jedes Stück auch iterative Verfeinerung braucht? Da kombinierst du sie vorsichtig, und ich werde gleich ehrlich berichten, wie das läuft, denn es ist mächtig und eine großartige Methode, ein Vermögen zu verbrennen.

Diese Breite-versus-Tiefe-Linse erklärt auch die zwei Headline-Features, die Anthropic auf Workflows aufgesetzt hat. Beide sind Workflows unter der Haube, auf die zwei Enden dieses Spektrums abzielend.

Ultra Code und /deep-research: Workflows ohne Handschuhe

Zwei Dinge sitzen auf der rohen Workflow-Engine, und du solltest wissen, dass es sie gibt, bevor du entscheidest, ob du sie brauchst.

Ultra Code (/effort ultracode) ist die maximale Einstellung: höchste Denkanstrengung plus automatische Workflow-Orchestrierung. Schalte es ein und Claude entscheidet für jede substantielle Aufgabe in der Sitzung, ob ein Workflow dafür geplant werden soll. Eine einzige Anfrage kann in mehrere Workflows hintereinander münden — einen zum Verstehen des Codes, einen zum Durchführen der Änderung, einen zum Verifizieren. Es ist der leistungsfähigste Modus, den Claude Code hat. Es ist auch, wenig überraschend, das Teuerste, was du laufen lassen kannst. Höchste Anstrengung verbrennt die meisten Denk-Tokens, und das in automatische Orchestrierung zu verpacken, multipliziert die Agentenanzahl. Ich greife zu Ultra Code, wenn ich etwas mache, das wirklich schwer und wirklich lohnenswert ist. Ich lasse es nicht standardmäßig an. So bekommt man überraschende Rechnungen.

/deep-research ist der eingebaute Workflow für die Recherche-Form. Stelle eine Frage und er fächert Websuchen über mehrere Blickwinkel auf, ruft Quellen ab und prüft sie gegeneinander, lässt Agenten über konkurrierende Behauptungen abstimmen und synthetisiert einen einzelnen zitierten Bericht. Es ist ein Workflow, speziell gebaut für Recherche-Breite — Breite angewandt auf Wissen statt auf Code. Wenn du die verschiedenen Deep-Research-Tools kennst, die herumgeistern, ist das dasselbe Muster, nativ in Claude Code, auf derselben Orchestrierungs-Engine wie mein 41-Agenten-Audit.

Verwaltet wird alles mit einem Befehl: /workflows. Führe ihn jederzeit aus, um zu sehen, was läuft, was fertig ist, und um eine Fortschrittsansicht zu öffnen — oder einen Workflow zu stoppen, der offensichtlich aus dem Ruder läuft. Ich habe diesen Stopp-Button gedrückt. Mehr als einmal. Was mich zu dem Teil dieses Beitrags bringt, den ich dir am meisten ans Herz legen möchte.

Was ich falsch gemacht habe: Die Token-Fehler, vor denen dich niemand warnt

Ich bin ehrlich zu dir — mein erster Instinkt mit Workflows war, sie auf alles zu werfen, und das war ein Fehler, der mich Tokens gekostet und mir die wahren Regeln beigebracht hat.

Fehler eins: Ich nutzte einen Workflow für einen Job, der nicht breit war. Anfangs startete ich einen Workflow für eine Aufgabe, die eigentlich nur drei sequenzielle Schritte an einer Datei war. Das Hochfahren der Orchestrierung, das Schreiben des Skripts, das Starten der Agenten — der ganze Overhead, für etwas, das eine einzelne Skill in einem Viertel der Tokens erledigt hätte. Workflows sind Overkill für kleine oder einfache Jobs, Punkt. Die Orchestrierung kostet etwas, noch bevor die Agenten laufen. Wenn die Aufgabe nicht wirklich in viele unabhängige Teile zerfällt, zahlst du die Einrichtungssteuer für nichts.

Fehler zwei: Ich war vage, und ein Workflow nahm mich wörtlich. Ich bat einen darum, „die Codebase auf Probleme zu überprüfen." Kein Scope, kein Deliverable, keine Grenzen. Er fächerte fröhlich über weit mehr Dateien auf, als mir lieb war, jeder Agent ein vollständiger Claude-Aufruf, der Input-Token-Zähler drehte sich wie ein Spielautomat. Das ist der Fehlermodus. Workflows können Input-Tokens absurd schnell bei breiten Jobs verbrennen, gerade weil sie fürs breite Crawlen designed sind. Ein Workflow tut genau das, was du gesagt hast — und im Maßstab von Hunderten parallelen Agenten umfasst „genau das, was du gesagt hast" jede lose Interpretation eines schlampigen Prompts.

Die Lösung für beides ist dieselbe, und sie ist langweilig, und sie funktioniert: Sei explizit und spezifisch. Definiere das Deliverable. Begrenze den Scope. „Prüfe die 14 Dateien in app/Http/Controllers auf fehlende Authorization-Middleware und liefere eine Tabelle aus Datei, Route und fehlendem Check" gibt dem Orchestrator eine Wand, an der er stoppt. „Prüfe den Code" gibt ihm einen Kontinent.

Hier ist die Regel, nach der ich jetzt tatsächlich lebe. Ein Workflow ist das richtige Werkzeug nur, wenn all das zutrifft: Die Aufgabe ist groß, die Teile sind unabhängig, und diese Teile sind parallelisierbar. Verfehle eines davon und du hast das falsche Primitiv gewählt. Groß, aber sequenziell? Nutze /goal. Klein, aber wiederholend? Nutze eine Skill. Kollaborativ und diskussionsgetrieben? Nutze stattdessen ein Agenten-Team. Die Orchestrierungswahl folgt derselben aufgabengeformten Logik, die ich in meinem Architektur-Breakdown zu Agentenschwärmen durchgearbeitet habe — passe die Struktur an die Arbeit an, nicht an deine Begeisterung.

Wenn du diese Rechnung lieber nicht durch das Verbrennen von Tokens auf einem Live-Kundenrepo lernst, ist das genau die Art von Orchestrierungs-Setup, die ich für Teams baue und abstimme — du kannst sehen, was ich auf meinem Fiverr anbiete. Die Primitiv-Auswahl beim ersten Mal richtig zu treffen, ist der größte Teil des Werts.

Der Trick, der die Ökonomie verändert: Skills in Workflows verschachteln

Hier ist der Zug, der Workflows weniger wie eine Geldgrube und mehr wie Hebelwirkung anfühlen ließ. Du kannst Skills innerhalb eines Workflows verschachteln. Jeder der vielen Agenten, die ein Workflow startet, kann deine bestehenden wiederverwendbaren Rezepte aufrufen.

Überleg, was das bewirkt. Du investierst die Mühe einmal, um eine präzise, gut getestete Skill zu schreiben — sagen wir, ein genaues „bewerte diese Skill-Datei anhand dieser zehn Kriterien"-Rezept. Dann startet ein Workflow 41 Agenten und jeder führt dieselbe Skill gegen ein anderes Ziel aus. Du bekommst den Parallelismus eines Workflows mit der Konsistenz und Wartbarkeit einer Skill. Die teure, komplexe Schicht stützt sich auf die günstige, einfache Schicht. Das ist die Architektur, auf die ich für das Audit kam, mit dem dieser Beitrag eröffnete, und es ist der Grund, warum die Ausgabe so sauber war — jeder dieser 41 Agenten bewertete nach derselben Rubrik, weil sie alle dieselbe Skill ausführten.

Das ist der Teil der Kosten-Komplexitäts-Leiter, den die Leute übersehen. Die Stufen schließen sich nicht gegenseitig aus. Das kluge Muster ist das günstigste Werkzeug, das die eigentliche Arbeit macht, eingewickelt in das teure Werkzeug, nur wo du die Skalierung wirklich brauchst. Workflows oben drauf, Skills darunter. Du wählst nicht zwischen ihnen — du stapelst sie.

Du kannst noch weiter gehen und einen Workflow mit /goal kombinieren — Breite und Tiefe zusammen, viele parallele Agenten, die jeweils auf ein Ziel hin iterieren. Es ist die mächtigste Orchestrierung, die ich je ausgeführt habe. Es ist auch das teuerste Ding in diesem gesamten Beitrag, mit deutlichem Abstand, und ich behandle es wie ein Elektrowerkzeug ohne Schutzvorrichtung. Lohnenswert für einen wirklich großen, wirklich schweren Job. Eine großartige Methode, Tokens bei allem anderen zu verdampfen.

Ein kurzer Exkurs, der nichts mit Workflows zu tun hat: Wenn all das nach mehr Orchestrierung klingt, als dein tatsächliches Problem braucht — sagen wir, du willst einfach nur eine KI-App oder Website mit ein paar MCP-Verbindungen bauen, nicht 41 Agenten koordinieren — dann ist Lovable eine weit einfachere Auffahrt. Es verkabelt MCP-Server und gibt dir ein Bauerlebnis, das nichts von alldem erfordert. Es ist ein anderes Werkzeug für eine andere Flughöhe. Der ganze Punkt dieses Beitrags ist, das Werkzeug auf die Aufgabe abzustimmen, also wäre ich ein Heuchler, wenn ich es nicht erwähnte. Jetzt zurück zu den Agenten.

Was dich das tatsächlich kostet — und wie du weißt, dass es funktioniert

Lass mich die Ökonomie fundieren, denn „5 Millionen Tokens" ohne Kontext ist entweder erschreckend oder bedeutungslos, je nachdem, was du annimmst.

Die Zahl, die zählt, ist nicht die Gesamtzahl der Tokens — es geht darum, welche Tokens. Mein 41-Agenten-Audit bestand fast vollständig aus Input-Tokens, und ich ließ die Bewerter auf Haiku laufen. Bei Anthropics veröffentlichten Preisen kostet Haiku-Input einen Bruchteil eines Cents pro tausend Tokens, also sind 5 Millionen Input-Tokens mit günstigem Modell eine fundamental andere Rechnung als 5 Millionen Output-Tokens mit Opus-Generierung. Die Lehre verallgemeinert sich: Die Kosten eines Workflows werden dominiert davon, wie viel seine Agenten lesen, mal dem Preis des Modells, mit dem sie lesen. Wähle das Modell bewusst. Günstige Modelle für breites, flaches Crawlen. Teure Modelle nur für die Teile, die echtes Schlussfolgern brauchen.

Wie weißt du, ob ein Workflow die richtige Wahl ist, bevor du ihn laufen lässt? Mache diesen Bauchgefühl-Check. Zähle die unabhängigen Teile. Wenn die Aufgabe in grob zehn oder mehr Brocken zerfällt, die wirklich nicht voneinander abhängen, wird Parallelismus den Orchestrierungsoverhead amortisieren — das ist dein grünes Licht. Weniger als das, oder die Teile hängen voneinander ab, und ein einfacheres Primitiv gewinnt fast sicher bei den Kosten.

Und sobald er läuft, beobachte zwei Dinge in /workflows: die Agentenanzahl und die Wanduhrzeit. Wenn die Agentenanzahl in Bereiche klettert, die du nicht beabsichtigt hast — dieser Monorepo-Skalen-Fan-Out — stoppe ihn und verschärfe deinen Scope. Wenn ein Workflow wesentlich länger dauert als der äquivalente sequenzielle Job, war die Aufgabe wahrscheinlich nicht parallelisierbar und du hast falsch gewählt. Das gesamte Versprechen von Breite ist schnellere Wanduhrzeit durch Parallelismus. Wenn du das nicht bekommst, war die Form falsch.

Die realistische Belohnung, wenn die Form stimmt: Jobs, die einen einzelnen Agenten eine Stunde sequenzielles Schuften gekostet hätten, sind in Minuten fertig, weil die Arbeit breit war und du sie sich ausbreiten ließest. Das ist die gesamte Wertpropositon. Keine Magie. Einfach Parallelismus, korrekt angewendet, mit dem Plan sicher außerhalb des Modellkopfs gehalten.

Die eine Entscheidung, die all das einfach macht

Geh zurück zu dem Terminalzähler, der über 41 kletterte. Der Grund, warum sich dieser Lauf gut anfühlte statt rücksichtslos, war nicht die Technologie. Es war, dass ich das Werkzeug an die Form der Arbeit angepasst hatte: ein breiter, flacher Stapel unabhängiger Bewertungsaufgaben, jede dieselbe Skill ausführend, Ergebnisse in Code zusammengeführt, Output klein. Richtiges Primitiv, richtiges Modell, begrenzter Scope. Alles stromabwärts von dieser einen Entscheidung war einfach.

Das ist die gesamte Fähigkeit hier, und es geht eigentlich gar nicht um Claude Code. Es geht darum, eine Aufgabe anzuschauen und eine Frage zu stellen, bevor du auch nur einen einzigen Befehl anfasst: Ist das breit oder tief, kollaborativ oder unabhängig, groß oder klein? Beantworte das ehrlich und das Werkzeug wählt sich selbst. Skill für das Kleine und Wiederholte. Sub-Agent für den einfachen Nebenauftrag. Agenten-Team für die echte Debatte. Workflow für den breiten unabhängigen Crawl. /goal für das tiefe iterative Schleifen. Die teuren Werkzeuge um die günstigen gewickelt, nie umgekehrt.

Also, bevor dein nächster großer Job ansteht — das Codebase-Audit, die breite Recherche, der Datensatz, vor dem du dich gedrückt hast — halte inne und benenne seine Form laut. Breit oder tief? Dieses eine Wort wird dir mehr Tokens sparen als jede Einstellung in der App. Was ist die breiteste Aufgabe auf deinem Tisch, die du gerade Datei für Datei erledigst?

Häufig gestellte Fragen

Was sind dynamische Claude-Code-Workflows?

Dynamische Claude-Code-Workflows sind ein Feature, das am 28. Mai 2026 gelauncht wurde und es Claude ermöglicht, ein JavaScript-Orchestrierungsskript zu schreiben und viele unabhängige Agenten parallel auf verschiedenen Teilen einer Aufgabe auszuführen. Der Plan lebt in einer externen Datei, nicht in Claudes Kontextfenster, und Agenten kommunizieren nicht — Ergebnisse werden in Skriptlogik kombiniert. Du löst einen aus, indem du das Wort „Workflow" in deinen Prompt aufnimmst (erfordert Claude Code v2.1.154+).

Wie unterscheiden sich Workflows von Sub-Agenten und Agenten-Teams?

Workflows starten viele nicht kommunizierende Agenten parallel, wobei der Plan in einem externen Skript liegt, während Sub-Agenten isolierte Nebenaufgaben ausführen, die nur an die Hauptsitzung berichten, und Agenten-Teams eine kleine Gruppe sind, die doch miteinander sprechen und Kontext teilen. Die klare Regel: Sub-Agenten entlasten, Teams beraten, Workflows fächern breit auf. Für die tiefere Unterscheidung, wann Agenten kommunizieren sollten, siehe meinen Agenten-Teams-Guide.

Wann sollte ich einen Workflow verwenden statt des /goal-Befehls?

Nutze einen Workflow für Breite — viele unabhängige, parallelisierbare Teile wie das Crawlen einer Codebase oder das Bewerten eines Datensatzes — und nutze /goal für Tiefe, bei der ein Versuch in einer Schleife iteriert, bis ein Ziel erreicht ist. Workflows breiten sich aus; /goal bohrt sich hinein. Wenn die Aufgabe breit und flach ist, Workflow. Wenn sie schmal und tief ist, /goal.

Wie viel kosten Claude-Code-Workflows in Tokens?

Die Kosten eines Workflows werden dominiert davon, wie viel seine Agenten lesen, multipliziert mit dem Preis des verwendeten Modells, sodass derselbe 5-Millionen-Token-Lauf auf Haiku-Input günstig und auf Opus-Output teuer ist. Die Kosten eskalieren, wenn Prompts vage oder der Scope unbegrenzt ist, weil jeder der bis zu 1.000 Agenten ein vollständiger Claude-Aufruf ist. Begrenze den Scope und wähle günstige Modelle für breites, flaches Crawlen. Für die Modellseite dessen siehe meinen Überblick der Effort-Level von Opus 4.8.

Was ist der Ultra-Code-Modus in Claude Code?

Ultra Code (/effort ultracode) kombiniert die höchste Denkanstrengung mit automatischer Workflow-Orchestrierung, wodurch Claude entscheiden kann, wann jede substantielle Aufgabe das Hochfahren eines Workflows rechtfertigt. Es ist der leistungsfähigste Modus in Claude Code und der teuerste — eine einzige Anfrage kann in mehrere Workflows hintereinander münden. Nutze ihn für wirklich schwere, wertvolle Arbeit, nicht als Standard.

Lass uns zusammenarbeiten

Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (Individuallösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io