Claude Code Dynamische Workflows: Hunderte parallele Subagenten mit Opus 4.8 ausführen

Claude Opus 4.8 bringt für Claude Code eine zentrale Funktion mit: Dynamische Workflows. Dabei kann ein orchestrierender Agent innerhalb einer Sitzung viele parallele Sub-Agenten starten, um große, verzweigte Aufgaben zu bearbeiten: Refactoring über Dutzende Dateien, breite Testmatrizen oder das parallele Prüfen mehrerer Lösungsansätze. Technisch basiert das nicht auf Magie, sondern auf zwei API-Bausteinen: xhigh-Aufwand und Systemmeldungen mitten im Gespräch.

Probieren Sie Apidog noch heute aus

Dieser Leitfaden zeigt, wie Dynamische Workflows funktionieren, wann sie sinnvoll sind und wie Sie dasselbe Orchestrierungsmuster direkt über die API nachbauen. Zum Modell selbst siehe was ist Claude Opus 4.8. Für den Architekturkontext ist der Überblick über die Claude Code Agent Harness-Architektur die passende Ergänzung.

Was Dynamische Workflows tatsächlich sind

In Claude Code erscheinen Dynamische Workflows als Modus ultracode im Aufwandsmenü. Wichtig: ultracode ist kein eigenes API-Aufwandslevel. Es kombiniert zwei vorhandene Opus-4.8-Funktionen:

1. das Aufwandslevel xhigh
2. Systemmeldungen mitten im Gespräch

Zusammen geben diese Bausteine dem Orchestrator genug Reasoning-Budget, um eine große Aufgabe zu planen, und gleichzeitig die Berechtigung, während der laufenden Aufgabe Worker-Agenten zu starten. Der Rest ist Claude-Code-Orchestrierung.

Bestandteil 1: xhigh-Aufwand

Der effort-Parameter steuert, wie viele Tokens Opus 4.8 für eine Antwort inklusive Tool-Aufrufen verwendet. xhigh ist das Level, das Anthropic für langfristige Coding- und Agentenaufgaben empfiehlt. Es ist auf Läufe ausgelegt, die länger als 30 Minuten dauern können und Token-Budgets im Millionenbereich erreichen.

Für Dynamische Workflows ist diese Tiefe entscheidend, weil der Orchestrator mehrere Schritte leisten muss:

• Aufgabe analysieren
• Arbeit in unabhängige Einheiten zerlegen
• passende Worker-Anzahl bestimmen
• Worker-Aufgaben formulieren
• Ergebnisse zusammenführen
• Konflikte oder Lücken erkennen

Niedrigere Aufwandslevel reduzieren den Arbeitsumfang und führen typischerweise zu weniger Tool-Aufrufen. Für einen Orchestrator ist das oft kontraproduktiv.

Ein sinnvoller Startpunkt ist:

{
  "output_config": {
    "effort": "xhigh"
  },
  "max_tokens": 64000
}

max_tokens sollte groß genug sein, damit der Orchestrator planen, delegieren und konsolidieren kann.

Bestandteil 2: Systemmeldungen mitten im Gespräch

Die zweite wichtige Funktion ist neu in der Messages API: Systemmeldungen können nicht nur am Anfang, sondern auch mitten im messages-Array stehen.

Vor Opus 4.8 war die Systemaufforderung fest am Anfang einer Konversation verankert. Jetzt können Sie während eines laufenden Gesprächs neue Systemanweisungen einfügen, zum Beispiel:

• neue Berechtigungen
• geänderte Ausführungsregeln
• Freigabe zum Starten von Workern
• neue Constraints für nachfolgende Schritte

Anthropic beschreibt den Mechanismus in Systemmeldungen mitten im Gespräch.

Für Orchestrierung ist das entscheidend: Der Agent muss nicht schon vorab alle Berechtigungen und Worker-Strukturen kennen. Er kann während des Laufs auf Basis der Analyse entscheiden, dass parallele Worker sinnvoll sind, und dann die entsprechende Berechtigung erhalten.

Aktivierung in Claude Code

In Claude Code aktivieren Sie Dynamische Workflows über die Option ultracode im Aufwandsmenü. Diese Option setzt xhigh-Aufwand und erlaubt der Sitzung, über Systemmeldungen mitten im Gespräch parallele Sub-Agenten zu starten.

Der typische Ablauf:

1. Sie wählen ultracode.
2. Sie beschreiben eine große Aufgabe.
3. Claude plant die Zerlegung.
4. Claude startet parallele Worker für Teilbereiche.
5. Worker-Ergebnisse werden zurückgestreamt.
6. Der Hauptagent führt die Ergebnisse zusammen.

Beispiel für eine geeignete Aufgabe:

Analysiere das Auth-Modul in allen Services, identifiziere doppelte Validierungslogik,
schlage ein gemeinsames Refactoring vor und erstelle einen Migrationsplan pro Service.

Wenn Sie Claude Code mit einem Plan eingerichtet haben, deckt der Einrichtungsleitfaden für das Claude Agent SDK mit Claude Plan die zugehörige Konfiguration ab.

Wann Dynamische Workflows sinnvoll sind

Dynamische Workflows eignen sich besonders für breite, parallelisierbare Aufgaben.

Gute Anwendungsfälle:

• Refactoring eines Musters über viele Dateien
• Analyse großer Codebasen nach Modul oder Service
• Generieren und Ausführen einer Testmatrix
• paralleles Prüfen mehrerer Implementierungsansätze
• Audit mehrerer APIs, Endpunkte oder Packages
• Migrationen, bei denen jeder Worker einen klar abgegrenzten Bereich übernimmt

Beispiel:

Durchsuche alle Packages nach direkter JWT-Validierung.
Erstelle pro Package eine Liste der Fundstellen, schlage eine Migration auf die zentrale Auth-Library vor
und markiere Stellen mit potenziell breaking changes.

Wann Sie Dynamische Workflows vermeiden sollten

Vermeiden Sie Dynamische Workflows bei engen oder strikt sequenziellen Aufgaben.

Schlechte Anwendungsfälle:

• Änderung an einer einzelnen Datei
• Bugfix mit klarer Ursache
• Aufgaben, bei denen jeder Schritt vom vorherigen abhängt
• kleine Code-Reviews
• einfache Dokumentationsänderungen

Der Grund ist simpel: Parallele Worker helfen nicht, wenn keine echte Parallelität vorhanden ist. Sie erhöhen nur Token-Verbrauch, Laufzeitkomplexität und Kosten.

Dasselbe Muster über die API aufbauen

Sie benötigen Claude Code nicht zwingend, um Orchestrierung zu bauen. Die Messages API stellt dieselben Grundbausteine bereit. Anthropic zeigt ein ausführlicheres Beispiel in einen Orchestrierungsmodus aufbauen.

Das Grundmuster:

1. Orchestrator mit xhigh starten
2. Aufgabe planen lassen
3. per Systemmeldung die Berechtigung für Worker geben
4. Worker-Aufrufe parallel ausführen
5. Ergebnisse sammeln
6. Ergebnisse an den Orchestrator zur Zusammenführung zurückgeben

Minimaler Orchestrator-Aufruf

import anthropic

client = anthropic.Anthropic()

orchestrator = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    thinking={"type": "adaptive"},
    messages=[
        {
            "role": "user",
            "content": "Plan a refactor of the auth module across all 14 services."
        }
    ],
)

print(orchestrator.content)

Der Orchestrator sollte zunächst nur planen. Lassen Sie ihn eine strukturierte Liste von Arbeitseinheiten erzeugen.

Beispiel-Zielformat:

{
  "work_units": [
    {
      "id": "service-auth-api",
      "scope": "services/auth-api",
      "task": "Find duplicated token validation logic and propose migration steps.",
      "expected_output": "List of files, risks, migration steps"
    },
    {
      "id": "service-billing",
      "scope": "services/billing",
      "task": "Analyze auth checks and identify coupling to legacy JWT helpers.",
      "expected_output": "Findings, recommended changes, test impact"
    }
  ]
}

Worker parallel ausführen

Jeder Worker ist ein separater Messages-Aufruf. Da Worker-Aufgaben enger begrenzt sind, können sie oft mit niedrigerem Aufwand laufen.

Beispiel:

from concurrent.futures import ThreadPoolExecutor, as_completed
import anthropic

client = anthropic.Anthropic()

work_units = [
    {
        "id": "service-auth-api",
        "scope": "services/auth-api",
        "task": "Find duplicated token validation logic and propose migration steps."
    },
    {
        "id": "service-billing",
        "scope": "services/billing",
        "task": "Analyze auth checks and identify coupling to legacy JWT helpers."
    }
]

def run_worker(unit):
    response = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=8000,
        output_config={"effort": "medium"},
        messages=[
            {
                "role": "user",
                "content": f"""
You are a worker agent.

Scope: {unit["scope"]}
Task: {unit["task"]}

Return JSON with:
- work_unit_id
- findings
- recommended_changes
- risks
- tests_to_run
"""
            }
        ],
    )

    return {
        "id": unit["id"],
        "response": response.content
    }

results = []

with ThreadPoolExecutor(max_workers=8) as executor:
    futures = [executor.submit(run_worker, unit) for unit in work_units]

    for future in as_completed(futures):
        results.append(future.result())

print(results)

Wenn Sie dies mit Anthropics gehosteter Agenten-Infrastruktur vergleichen möchten, beschreibt verwaltete Agenten vs. Agent SDK die wichtigsten Kompromisse.

Ergebnisse zusammenführen

Nach dem Fan-Out kommt der Merge-Schritt. Hier geben Sie die Worker-Ergebnisse an den Orchestrator zurück und lassen ihn daraus einen konsistenten Plan oder Patch-Vorschlag erstellen.

merge_response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=32000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": f"""
You are the orchestrator.

Merge these worker results into one implementation plan.

Requirements:
- group changes by service
- identify conflicts between workers
- list required tests
- mark high-risk changes
- produce an ordered migration plan

Worker results:
{results}
"""
        }
    ],
)

print(merge_response.content)

Praktisch ist es, Worker-Ausgaben strikt zu validieren. Wenn ein Worker statt JSON freien Text liefert, sollte der Merge-Schritt nicht stillschweigend weiterlaufen.

Kosten und Kontrolle

Parallele Sub-Agenten vervielfachen den Token-Verbrauch schnell. Ein Workflow mit 200 Workern, bei dem jeder viele Tokens verbraucht, kann teuer werden.

Drei Regeln helfen bei der Kontrolle:

• Worker eng begrenzen: Jeder Worker braucht einen klaren Scope.
• Aufwand pro Worker senken: Nutzen Sie medium oder low, wenn die Teilaufgabe einfach genug ist.
• max_tokens pro Worker begrenzen: Verhindert Ausreißer.
• Gemeinsamen Kontext cachen: Wiederholte System- oder Projektkontexte sollten nicht unnötig voll abgerechnet werden.
• Fan-Out begrenzen: Starten Sie nicht automatisch Hunderte Worker, wenn 8 bis 16 reichen.

Beispiel für konservative Worker-Defaults:

{
  "output_config": {
    "effort": "medium"
  },
  "max_tokens": 8000
}

Die Opus 4.8 Preisaufschlüsselung enthält Berechnungen zu Aufwandsstufen und Caching. Kurz gesagt: Orchestrierung ist leistungsstark, aber Parallelität sollte eine bewusste Entscheidung sein.

Ihre Orchestrierung mit Apidog testen

Wenn Sie Orchestrierung über die API bauen, liegt das größte Debugging-Risiko im Fan-Out:

• Erhalten Worker den richtigen Scope?
• Ist der Kontext klein genug?
• Stimmen die Antwortformate?
• Wird die Systemmeldung mitten im Gespräch korrekt übergeben?
• Funktioniert der Merge-Schritt mit realistischen Worker-Antworten?

Sie sollten solche Fehler nicht erst nach 200 Live-Worker-Aufrufen entdecken.

Apidog hilft dabei, die einzelnen Teile isoliert zu testen:

• Orchestrator-Request speichern und Aufgabenzerlegung prüfen
• Worker-Endpunkte mocken
• Fan-Out- und Merge-Logik ohne Token-Kosten testen
• Assertions für Worker-Antworten definieren
• einzelne Worker mit verschiedenen effort-Levels wiederholen
• Live-Requests erst aktivieren, wenn die Struktur stabil ist

Praktischer Ablauf:

1. Erstellen Sie in Apidog eine Anfrage an https://api.anthropic.com/v1/messages.
2. Speichern Sie den Orchestrator-Request.
3. Definieren Sie ein erwartetes Worker-Antwortschema.
4. Mocken Sie mehrere Worker-Antworten.
5. Testen Sie den Merge-Schritt gegen diese Mock-Daten.
6. Wechseln Sie erst danach auf Live-Worker-Aufrufe.

Der Opus 4.8 API-Leitfaden enthält die Basisanfrage, von der Sie ausgehen können.

FAQ

Was sind Dynamische Workflows in Claude Code?

Eine Funktion, mit der eine Sitzung viele parallele Sub-Agenten starten kann, um große, verzweigte Aufgaben zu bearbeiten. Technisch basiert sie auf xhigh-Aufwand und Systemmeldungen mitten im Gespräch in Opus 4.8.

Ist ultracode ein separates API-Aufwandslevel?

Nein. ultracode ist der Claude-Code-Name für die Kombination aus xhigh und der Berechtigung, Multi-Agenten-Workflows zu starten. Die API-Aufwandslevel bleiben low, medium, high, xhigh und max.

Was sind Systemmeldungen mitten im Gespräch?

Eine Messages-API-Funktion in Opus 4.8, mit der Sie einen System-Eintrag mitten in der Konversation platzieren können. Dadurch lassen sich während einer laufenden Aufgabe neue Anweisungen oder Berechtigungen hinzufügen.

Kann ich Dynamische Workflows ohne Claude Code erstellen?

Ja. Verwenden Sie direkt die Messages API mit xhigh-Aufwand und Systemmeldungen mitten im Gespräch. Worker-Aufrufe führen Sie dann selbst parallel aus.

Kosten Dynamische Workflows viel?

Das können sie. Viele Worker mit hohem Aufwand können Millionen Tokens verbrauchen. Begrenzen Sie Worker-Scope, max_tokens, Parallelität und Aufwand pro Worker.

Wann sollte ich Dynamische Workflows vermeiden?

Bei kleinen, engen oder streng sequenziellen Aufgaben. Wenn keine echte Parallelität vorhanden ist, erzeugen Sub-Agenten hauptsächlich zusätzliche Kosten und Komplexität.