Claude Code Dynamic Workflows: 1.000 Subagents auf einer echten Codebase orchestrieren

Claude Code Dynamic Workflows sind ein Multi-Agent-Orchestrierungssystem: Claude schreibt ein JavaScript-Skript, das die Arbeit auf bis zu 1.000 parallele Subagents verteilt, alle Zwischenergebnisse in Skriptvariablen statt im Kontextfenster des Modells hält und nur die finale, geprüfte Antwort an deine Session zurückgibt. Sie erschienen am 28. Mai 2026 zusammen mit Claude Opus 4.8 und brauchen CLI v2.1.154 oder neuer.

Dieser Post deckt die Architektur ab, die sechs Skript-Primitiven, echte Anwendungsfälle, ehrliche Kostenrechnung und die Stolperfallen, in die Entwickler in den ersten Wochen der Research Preview tappen.

Inhaltsverzeichnis

1. Was ist das Dynamic-Workflow-System von Claude Code?
2. Wie Claude Code Workflows funktionieren: Architektur
3. Echte Anwendungsfälle für Claude Code Workflows
4. Kosten, Limits und Effizienz von Claude Code Workflows
5. Vorbehalte und Stolperfallen, in die Entwickler tappen
6. Claude Code Workflows vs. LangGraph, Temporal und andere
7. Best Practices für Claude Code Workflows
8. Häufig gestellte Fragen

Was ist das Dynamic-Workflow-System von Claude Code?

Vor den Claude Code Dynamic Workflows gab jeder Subagent, den Claude losschickte, sein Ergebnis zurück ins Kontextfenster der Hauptkonversation. Bei einem Lauf mit 50 Agents sammelten sich also 50 Brocken Zwischentext an, das Kontextfenster füllte sich, und die Qualität sackte ab, lange bevor die Aufgabe fertig war. Die Obergrenze für die Agent-Zahl war keine harte Grenze, eher eine weiche Wand: An der lief dem Modell der nützliche Arbeitsspeicher aus.

Dynamic Workflows lösen das, indem sie die Orchestrierung komplett aus der Konversation herausziehen. Claude schreibt für genau die Aufgabe, die du ihm gibst, ein JavaScript-Skript. Dieses Skript läuft in einer Hintergrund-Runtime. Die Orchestrierungslogik (welche Agents gestartet werden, wie viele, in welcher Reihenfolge, wann geprüft wird) lebt in Skriptvariablen. Das Kontextfenster des Modells bekommt nur das final synthetisierte Ergebnis.

Die sechs Primitiven, die in einem Workflow-Skript verfügbar sind:

• agent(prompt, opts?) — startet einen einzelnen Subagent, gibt seinen finalen Text oder validiertes JSON zurück
• parallel(thunks) — führt ein Array von Aufgaben nebenläufig aus, mit einer Synchronisationsbarriere
• pipeline(items, ...stages) — schleust Items durch Stufen, ohne Barriere dazwischen
• workflow(nameOrRef, args?) — ruft einen gespeicherten Workflow als Teilschritt auf (maximal eine Verschachtelungsebene)
• phase(title) — benennt eine Fortschrittsgruppe im /workflows-Monitoring-Dashboard
• log(msg) — gibt eine Erzähler-Zeile in der Workflow-Ausgabe aus

Das Wort „dynamic" hat hier eine konkrete Bedeutung. Claude entscheidet in Echtzeit über die Zerlegung der Aufgabe, die Agent-Zahl, die Phasenstrategie und den Prüfansatz — und zwar für genau die Aufgabe, die du beschrieben hast. Keine zwei Workflow-Skripte sind identisch. Das ist etwas anderes als Routines (das sind statisch geplante Prompts, die du einmal definierst) und auch anders als die ältere ScheduleWakeup-Primitive, die in /loop-Sessions zum Einsatz kam.

So sieht die minimale Struktur eines gültigen Workflow-Skripts aus:

export const meta = {
  name: 'security-audit',
  description: 'Parallel security scan across auth, DB, and input layers',
  whenToUse: 'When you need a full security sweep before shipping',
  phases: [
    { title: 'Scan', detail: 'Three specialized agents run in parallel' },
    { title: 'Synthesize', detail: 'One agent compiles a prioritized report' },
  ]
}

phase('Scan')
const [auth, db, input] = await parallel([
  () => agent('Audit authentication flows for bypass vulnerabilities', { label: 'auth-scanner' }),
  () => agent('Check all database queries for injection risks', { label: 'db-scanner' }),
  () => agent('Review input validation and sanitization', { label: 'input-scanner' }),
])

phase('Synthesize')
const report = await agent(
  `Compile a prioritized security report from these three findings:\n\nAuth: ${auth}\n\nDB: ${db}\n\nInput: ${input}`,
  { label: 'synthesizer' }
)

return report

Wie Claude Code Workflows funktionieren: Architektur

Wenn du einen Workflow auslöst, läuft folgende Abfolge ab:

Schritt 1: Planung. Claude analysiert deine Anfrage und schreibt ein JavaScript-Orchestrierungsskript. Das Skript kodiert, welche Phasen es gibt, wie viele Agents in jeder Phase laufen, ob Items parallel oder durch eine Pipeline fließen und welche Prüflogik vor der Rückgabe der Ergebnisse läuft.

Schritt 2: Freigabe. Du siehst die geplanten Phasen aus dem meta.phases-Array. Du kannst es ausführen, es für dieses Projekt als vertrauenswürdig markieren (dann fragt es nie wieder), das rohe JS-Skript mit Ctrl+G öffnen und prüfen, oder abbrechen.

Schritt 3: Ausführung. Die Workflow-Runtime führt das Skript in einem Hintergrundprozess aus. Die Subagents erledigen die eigentliche Arbeit: Dateien lesen, Shell-Kommandos, Web-Fetches, MCP-Tool-Aufrufe. Jeder agent()-Aufruf gibt sein Ergebnis als JavaScript-Wert zurück (ein String oder validiertes JSON, falls du ein schema übergeben hast). Diese Werte sammeln sich in Skriptvariablen, nicht in Claudes Kontext.

Schritt 4: Verifikation. Die meisten von Claude generierten Workflows enthalten eine Prüfphase, in der separate Agents versuchen, die Befunde der Hauptphase zu widerlegen oder infrage zu stellen. Der Workflow iteriert, bis die Ergebnisse konvergieren.

Schritt 5: Lieferung. Der Rückgabewert des Skripts, die final synthetisierte Antwort, landet in deiner Session. Das ist das Einzige, was das Kontextfenster von Claude berührt.

Resume und Caching. Die Runtime protokolliert das Ergebnis jedes abgeschlossenen agent()-Aufrufs. Wenn du einen Workflow mit der Taste p im /workflows-Dashboard pausierst, geben abgeschlossene Agents beim Fortsetzen ihre gecachten Ergebnisse sofort zurück. Das funktioniert nur innerhalb derselben Claude-Code-Session: Beendest du die Anwendung, wird das Protokoll verworfen, und die nächste Session startet bei null.

Der Prompt-Cache und die Kostenfolgen. Anthropics Prompt-Cache hat standardmäßig eine TTL von 5 Minuten. Jeder agent()-Aufruf, der mehr als 300 Sekunden nach dem vorherigen feuert, verfehlt den Cache komplett und löst ein vollständiges Neuschreiben aus — zum 12,5-fachen Preis eines Cache-Reads. Bei Workflows mit Lücken zwischen den Phasen von über fünf Minuten fordere die 1-Stunden-TTL-Verlängerung explizit an, per cache_control: { type: 'ephemeral', ttl: '1h' } beim initialen Setup. Das kostet den 2-fachen Cache-Write-Preis, macht lange Workflows aber dramatisch billiger.

Das /workflows-Monitoring-Dashboard (tippe /workflows, um es zu öffnen) zeigt Phasen, die Zahl der aktiven Agents, Token-Summen und die verstrichene Zeit. Navigation: Hoch/Runter, um Phasen oder Agents auszuwählen, p zum Pausieren oder Fortsetzen, x, um einen Agent oder den ganzen Workflow zu stoppen, r, um einen ausgewählten Agent neu zu starten, s, um den Lauf als wiederverwendbares Kommando zu speichern.

Echte Anwendungsfälle für Claude Code Workflows

1. Paralleles Code-Review über einen großen PR. Teile die geänderten Dateien in Batches auf, lass einen Agent pro Batch Logik, Typen, Sicherheit und Tests prüfen, und synthetisiere die Befunde dann zu einem priorisierten Review. Ein Entwickler startete für ein einziges Code-Review nach diesem Muster 90 Agents und stieß an seine Monats-Token-Limits — ein Zeichen, dass das Muster funktioniert, aber Budget-Leitplanken braucht.

2. Große Migration oder Rewrite. Das Paradebeispiel ist Jarred Sumners Bun-Projekt: rund 750.000 Zeilen Zig in 11 Tagen nach Rust portiert, mit 99,8 % der bestehenden Test-Suite bestanden, vom ersten Commit bis zum Merge. Das Muster ist ein 600-zeiliges Mapping-Dokument (jeder Zig-Typ und jedes Idiom übersetzt in sein Rust-Pendant) plus parallele Agents, die nicht-überlappende Dateimengen verarbeiten, mit worktree-Isolation, damit sie ohne Kollisionen schreiben können.

3. Security-Audit mit adversariellem Gegencheck. Ein Orchestrator startet drei spezialisierte Scanner (Authentifizierungsflüsse, Datenbankabfragen, Input-Validierung) parallel, dann versucht ein separater Prüf-Agent, in jedem Befund False Positives zu finden, bevor ein priorisierter Report kompiliert wird. Die eingebaute adversarielle Prüfphase macht dieses Muster zuverlässig genug für Audits vor dem Release.

4. Recherche-Gerüst über mehrere Quellen. Das eingebaute /deep-research-Kommando ist selbst ein Workflow, der das Fan-out-Muster demonstriert: Neun Agents durchsuchen gleichzeitig verschiedene Quellen, Zwischenbefunde reduzieren sich zu gerankten Kandidaten, ein Synthese-Agent kompiliert den finalen Report. Dasselbe Muster funktioniert für Wettbewerbsanalysen, Dependency-Audits oder das Zusammenfassen von Changelogs über ein Monorepo.

5. Test-Generierung in großem Maßstab. Fächere über jedes Modul einer Codebase auf, ein Agent pro Modul schreibt Tests gegen die öffentliche API-Oberfläche, dann prüft eine Konvergenzphase auf Coverage-Überlappung und entfernt Duplikate, bevor die finalen Testdateien geschrieben werden. Die Option isolation: 'worktree' in agent() verhindert, dass parallele Agents Dateikonflikte erzeugen.

Kosten, Limits und Effizienz von Claude Code Workflows

Harte Limits (von der Runtime erzwungen, nicht verhandelbar):

Token-Preise (Pay-as-you-go):

• Claude Opus 4.8: $5 Input / $25 Output pro Million Tokens
• Claude Sonnet 4.6: $3 Input / $15 Output pro Million Tokens
• Cache-Reads: ~10 % des Input-Preises. Cache-Writes: ~25 % des Input-Preises (wenn alles korrekt läuft).

Preisrechnung an einem echten Workflow. Ein paralleles Security-Audit mit drei Sonnet-4.6-Agents zu je 8.000 Input-Tokens und je 2.000 Output-Tokens kostet ungefähr: (3 × 8.000 × $3/M) + (3 × 2.000 × $15/M) = $0,072 + $0,090 = $0,162. Tausche das gegen Opus 4.8 aus, kostet derselbe Lauf $0,42. Lässt du 90 solcher Agents auf einem großen Codebase-Review zu Opus-Raten laufen, sind das allein $12,60 an Output-Tokens vor dem Overhead — das erklärt, wie ein Entwickler die Monatslimits in einer einzigen Session verbrennen kann.

Wann Workflows kosteneffizient sind und wann verschwenderisch:

Effizient:

• Aufgaben, bei denen Parallelität die reale Laufzeit verkürzt (du brauchst das Ergebnis schnell, Kosten sind zweitrangig)
• Große Migrationen, bei denen sequentielle Ausführung Tage dauern würde
• Aufgaben mit klaren Teilaufgaben-Grenzen und ohne Abhängigkeiten zwischen Agents mitten im Lauf

Verschwenderisch:

• Routine-Edits an einzelnen Dateien (eine normale Konversation ist schneller und billiger)
• Aufgaben, die Echtzeit-Steuerung oder Anleitung mitten im Lauf brauchen (Workflows laufen unbeaufsichtigt)
• Explorative oder unklare Anfragen, bei denen die Zerlegungsstrategie unbekannt ist

Die 5-Minuten-Cache-Klippe. Wenn dein Workflow Phasen hat, die mehr als 300 Sekunden auseinanderliegen, zahlt jeder Agent in der späteren Phase volle Cache-Write-Kosten statt günstiger Cache-Reads. Bei einem 50-Agent-Lauf mit einem Opus-Orchestrator kann das die Kosten um das 3- bis 6-fache gegenüber einem gut gecachten Lauf aufblähen. Übergib das 1-Stunden-TTL-Flag im initialen Kontext, um das zu vermeiden.

Budget-bewusste Schleifen. Die globale Variable budget in Workflow-Skripten gibt das beim Start gesetzte Token-Ziel her. Sichere budget-sensible Schleifen immer ab: if (budget.total && tokensUsed > budget.total * 0.8) break. Ohne Absicherung laufen Schleifen bis zur harten Obergrenze von 1.000 Agents.

Vorbehalte und Stolperfallen, in die Entwickler tappen

Workflow-Skripte sind JavaScript, nicht TypeScript. Die Runtime hat keine TypeScript-Transpilationsschicht. Typ-Annotationen in einem Workflow-Skript erzeugen einen Parse-Fehler. Willst du typisierte Orchestrierung, schreib einen TypeScript-Wrapper, der den Workflow zur Laufzeit aufruft; pack keine Typen ins Skript selbst.

Drei nicht-deterministische Built-ins werfen in Workflow-Skripten. Date.now(), Math.random() und new Date() ohne Argumente sind verboten. Der Grund: Der Resume-Cache protokolliert jeden agent()-Aufruf über seinen deterministischen Schlüssel. Nicht-deterministische Werte würden beim erneuten Lauf andere Schlüssel erzeugen und das Resume kaputtmachen. Workarounds: Übergib Zeitstempel beim Start über args, variiere Prompts über den Schleifen-Index statt über einen Zufallswert.

Kein direkter Dateisystem- oder Shell-Zugriff im Skript. Die Orchestrierungsschicht kann keine Dateien lesen und keine Kommandos ausführen. Aller I/O läuft über Subagents. Das Skript ist eine reine Koordinationsschicht.

Verwirrung zwischen parallel() und pipeline(). parallel() ist eine Synchronisationsbarriere: Es wartet auf jeden Thunk, bevor es zurückkehrt. pipeline() hat keine Barriere: Item A kann in Stufe 3 sein, während Item B noch in Stufe 1 steckt. Nimm standardmäßig pipeline() für unabhängige Item-Verarbeitung. Greif nur dann zu parallel(), wenn eine nachgelagerte Stufe die komplette Menge aller vorherigen Ergebnisse auf einmal braucht (Deduplizierung, Cross-Ranking, adversarielle Prüfung der gesamten Menge). Ein fehlgeschlagener Thunk in parallel() löst sich zu null auf, statt zu rejecten — filtere das Ergebnis-Array also immer mit .filter(Boolean).

Der acceptEdits-Modus übernimmt Dateiänderungen automatisch. Subagents, die in einem Workflow laufen, arbeiten standardmäßig im acceptEdits-Modus. Datei-Edits werden ohne einzelne Review-Abfragen übernommen. Bei einem 50-Agent-Lauf, der hunderte Dateien anfasst, heißt das: Ungeprüfte Änderungen landen in großem Umfang. Prüf das generierte Workflow-Skript (Ctrl+G im Freigabe-Prompt), bevor du es auf Produktions-Branches laufen lässt.

Wann du keine Dynamic Workflows nutzen solltest:

• Jede Aufgabe, bei der du mitten im Lauf steuern oder nachjustieren musst
• Exploratives Debugging, bei dem der nächste Schritt davon abhängt, was du gerade gesehen hast
• Aufgaben, die eine einzelne fokussierte Antwort unter 10 Minuten brauchen
• Kostensensible Umgebungen ohne Budget-Leitplanken pro Lauf

Der Push-Scope-Bug bei .github/workflows/. Wenn ein Subagent Dateien unter .github/workflows/ bearbeitet, gelingt der Edit lokal, scheitert aber beim Push, weil der Claude-Code-OAuth-Credential den workflow-Scope nicht hat. Der Fehler taucht erst auf, nachdem das gesamte Session-Budget aufgebraucht ist. Prüf das Workflow-Skript auf Writes nach .github/workflows/, bevor du freigibst.

Claude Code Workflows vs. LangGraph, Temporal und andere

Diese Tools besetzen verschiedene Schichten des Stacks und sind nicht austauschbar. Die richtige Frage ist, für welche Schicht du gerade eine Lösung suchst.

Claude Code vs. LangGraph. Das sind keine Konkurrenten. Claude Code ist ein Tool für die Entwicklungszeit. LangGraph ist ein Runtime-Application-Framework für zustandsbehaftete Workflows, die in Produktion laufen. Nutze Claude Code, um LangGraph-Anwendungen zu bauen. Die wichtige Einschränkung: Claude Code ist auf Anthropics Claude-Modelle festgelegt. LangGraph ist über LangChain-Integrationen modell-agnostisch.

Claude Code vs. Temporal. Temporal hüllt jede Ausführung (auch Claude-betriebene Agents) in absturzsichere Dauerhaftigkeit. Claude Code hat keine sitzungsübergreifende Zustandspersistenz, keine Exactly-once-Semantik und keine auditierbare Ausführungshistorie. Wenn dein Agent Geld, juristische Datensätze oder irgendeine unumkehrbare Operation anfasst, gehört Temporal in den Stack.

Die komplementäre Architektur für Produktions-KI-Agents: Das Claude Agent SDK übernimmt das KI-Reasoning und die Tool-Use-Schleife. Temporal hüllt es für Fehlertoleranz ein. OpenAI Codex und Replit Agent 3 haben beide diese Aufteilung gewählt.

Best Practices für Claude Code Workflows

Nimm standardmäßig pipeline(), nicht parallel(). pipeline() beginnt mit Item N+1, sobald Item N seine erste Stufe abgeschlossen hat, und beseitigt so Leerlauf-Lücken. Greif nur dann zu parallel(), wenn eine Stufe wirklich alle vorherigen Ergebnisse auf einmal braucht.

Nutze schema für strukturierte Ausgabe, wann immer du Agent-Ergebnisse parsen musst. Ein JSON-Schema an agent() zu übergeben, zwingt den Subagent in einen Strukturierte-Ausgabe-Tool-Aufruf mit automatischem Retry bei Abweichung. Das entfernt fragiles Text-Parsing aus deiner Orchestrierungslogik.

Setz die 1-Stunden-Cache-TTL bei langen Workflows. Bei Läufen mit Phasen, die mehr als ein paar Minuten auseinanderliegen, kostet dich die voreingestellte 5-Minuten-Cache-TTL das 3- bis 6-fache von dem, was nötig wäre. Das 1-Stunden-TTL-Flag kostet den 2-fachen Write-Preis, spart aber bei Reads weit mehr bei mehrphasigen Läufen.

Sichere budget-sensible Schleifen ab. Jede Endlos-bis-Konvergenz-Schleife sollte vor dem Iterieren budget.total prüfen: if (budget.total && estimatedTokensUsed > budget.total * 0.8) { log('approaching budget, stopping early'); break }. Ohne das läuft die Schleife bis zur Obergrenze von 1.000 Agents.

Nutze phase() und log() großzügig. Gut benannte Phasen und Erzähler-Zeilen im /workflows-Dashboard machen es möglich, einen Lauf, der entgleist, zu pausieren, bevor er fertig ist. Ein Workflow ohne Phasen-Labels ist eine Blackbox, bis er durch ist.

Nutze isolation: 'worktree' nur, wenn Agents wirklich dieselben Dateien beschreiben. Worktree-Isolation startet pro Agent ein eigenes git-worktree — korrekt für parallele Schreibaufgaben, aber Overhead, den du für Read-only-Agents nicht brauchst.

Speichere Workflows, die funktionieren. Drück s im /workflows-Dashboard bei einem abgeschlossenen Lauf und speichere nach .claude/workflows/ (projektweit geteilt) oder ~/.claude/workflows/ (persönlich). Ein einmal gespeicherter Workflow wird zu einem /command, das du bei jedem künftigen Lauf mit demselben Muster nutzen kannst.

Häufig gestellte Fragen

Wie viele Agents kann Claude Code parallel laufen lassen?

Claude Code Dynamic Workflows deckeln die nebenläufige Agent-Ausführung bei 16 gleichzeitig laufenden Agents. Die Gesamtzahl der Agents über einen ganzen Lauf ist bei 1.000 gedeckelt. Diese Limits werden von der Workflow-Runtime erzwungen, unabhängig von deinem Abo-Plan. Die Nebenläufigkeitsgrenze kann auf Maschinen mit wenigen CPU-Kernen niedriger liegen.

Wie löse ich einen Claude Code Dynamic Workflow aus?

Drei Wege: Schreib das Wort „workflow" irgendwo in einen Prompt (Claude Code hebt das Keyword hervor und schreibt ein Orchestrierungsskript), führe das /deep-research-Kommando aus, oder setz /effort ultracode — das plant für jede substanzielle Aufgabe in der Session automatisch einen Workflow. Drück alt+w, um den Keyword-Trigger für einen einzelnen Prompt zu unterdrücken, ohne das Feature global abzuschalten.

Sind Dynamic Workflows im Free- oder Pro-Plan verfügbar?

Dynamic Workflows sind auf Pro ($20/Monat) standardmäßig aus und müssen manuell per /config aktiviert werden. Auf Max ($100/Monat und $200/Monat) und Team-Plänen sind sie standardmäßig an. Auf Enterprise-Plänen sind sie standardmäßig aus und brauchen eine Admin-Aktivierung. Alle Pläne brauchen CLI v2.1.154 oder neuer.

Wie unterscheidet sich Claude Code von Cursor bei Agent-Workflows?

Claude Code ist ein Terminal-natives agentisches Tool, ausgelegt auf langlaufende Multi-Agent-Orchestrierung über eine ganze Codebase. Es hat Hooks, MCP-Integrationen, Skills, Dynamic Workflows und arbeitet komplett über die Kommandozeile, mit vollem Dateisystem- und Shell-Zugriff. Cursor ist IDE-integriert und auf schnelles Editieren einzelner Dateien innerhalb von VS Code optimiert. Fürs tägliche Code-Editing in einer IDE gewinnt Cursor bei der Ergonomie. Für repo-weite Migrationen, Security-Audits oder Multi-Agent-Builds hat das Workflow-System von Claude Code in Cursor kein direktes Pendant.

Für welche echten Aufgaben wurden Claude Code Dynamic Workflows schon genutzt?

Das meistzitierte Beispiel ist Buns Zig-zu-Rust-Rewrite: rund 750.000 Zeilen in 11 Tagen portiert, mit 99,8 % Test-Suite-Bestehensquote auf Linux x64 (PR #30412, gemergt am 14. Mai 2026). Rakuten kürzte die Feature-Auslieferung von 24 Arbeitstagen auf 5 Tage, mit parallelen Claude-Code-Sessions. Uber erreichte bis März 2026 eine Claude-Code-Adoption von 84 % über rund 5.000 Engineers, wobei etwa 70 % des committeten Codes KI-Ursprung hatten.

Fazit

Claude Code Dynamic Workflows verschieben die Orchestrierung aus dem Kontextfenster des Modells in eine JavaScript-Runtime — und das ist die strukturelle Änderung, die 500-Agent- und 1.000-Agent-Läufe ohne Qualitätsverlust machbar macht. Die Primitiven sind klein und kombinierbar. Die Kosten sind real und brauchen Leitplanken. Die Stolperfallen (nur-JS-Skripte, verbotene nicht-deterministische Built-ins, acceptEdits-Auto-Übernahme, die 5-Minuten-Cache-Klippe) sind konkret genug, dass du sie umgehen kannst, sobald du sie kennst.

Fang mit einem eng umrissenen Anwendungsfall an: einem parallelen Code-Review, einem Doku-Durchlauf über eine Modulgrenze hinweg oder einem Security-Audit auf einer gut abgegrenzten Oberfläche. Speichere den Lauf als Kommando. Iteriere am Skript. Die Workflows, die zuverlässig funktionieren, sind die, die du über mehrere Läufe verfeinerst — nicht die, die du am ersten Tag auf eine codebase-weite Aufgabe loslässt.

Gepostet von @speedy_devv