AIDiveIntro: dieselben Prüfungen, doppelte Anzeige, fünf Deckel
Ultracode ist das Schlüsselwort, oder der Schalter, der aus einer Anfrage in Claude Code ein ganzes Team von Agents macht. In einem Paartest mit derselben Spezifikation bestanden beide Läufe dieselben versteckten Prüfungen, und der ultracode-Lauf verbrauchte mehr als das Doppelte der Session-Anzeige. Der Grund ist kein klügeres Modell: Es ist ein Satz, den der Harness einfügt, und drei Schutzfunktionen, die er abschaltet.
Dieser Artikel behandelt vier Dinge:
- den Paartest, abgelesen an der Plan-Anzeige;
- den Token-Multiplikator über mehrere weitere Paare;
- die eine Art von Job, bei der ein Team 66 gepflanzte Bugs fand, während ein einzelner Agent 14 fand;
- die fünf Einstellungen, die einen Lauf deckeln, bevor er deine Woche auffrisst, von denen eine ihn am Usage-Limit selbst stoppt.
Was ultracode einschaltet: das Schlüsselwort, der Schalter, ein Workflow aus Agents
Ultracode besteht aus zwei Schaltern. Tippst du ultracode in einen Prompt, läuft genau diese Aufgabe als Workflow, ohne dass sich die Effort-Stufe der Session ändert. Legst du den Schalter über den Befehl /effort um, plant Claude für jede substanzielle Aufgabe einen Workflow, sodass aus einer Anfrage mehrere Workflows hintereinander werden können.
Ein Workflow ist ein Skript, das Claude für sich selbst schreibt; es lässt ein Team von Agents in Phasen laufen. In einer winzigen Sandbox (ein paar Dateien mit schlampiger Promise-Behandlung, nur lesende Prüfung angefordert) sondierte Claude die Dateien und startete einen Workflow namens "unhandled promise audit". Unter dem Eingabefeld erschien eine Aufgabenzeile mit Fortschrittsbalken, Agent-Anzahl, verstrichener Zeit und einer laufenden Token-Summe. Der Befehl /workflows listet eine Zeile pro Agent mit eigenem Token-Zähler, dazu Tasten zum Pausieren, Stoppen oder Neustarten.
In diesem Lauf hatte jeder Finder etwa 45.000 Tokens gelesen, noch bevor die Verifier überhaupt starteten, für eine Handvoll Codezeilen.
Jede Session trägt außerdem eine Größenrichtlinie, die Agent-Anzahl, unter der Claude bleiben soll:
| Größenrichtlinie | Empfohlene Agents |
|---|---|
| small (Standard bei Pro) | weniger als 5 |
| medium | weniger als 10 |
Jeder Agent schickt zusätzlich zu deinem Gespräch eigene Anfragen. Ein Workflow ist nie eine einzige Rechnung, sondern eine Rechnung pro Agent, und die Anzeige zählt jede davon mit.
Der Paartest: dieselben 136 Prüfungen, 8 Prozent gegen 18, und es hört nie auf
Ein Entwickler maß die Kosten im obersten Abo-Plan mit sauberem Setup: dieselbe Spezifikation für eine kleine Tabellenkalkulations-App, dasselbe Modell mit demselben Effort, ein normaler Lauf und ein ultracode-Lauf. Beide wurden mit versteckten Prüfungen bewertet, also Tests, die das Modell nie sieht. Beide bestanden alle 136.
| Lauf | Ende | Verbrauchtes Session-Limit | Bestandene Prüfungen |
|---|---|---|---|
| Normal | von selbst, 25 Min. | 8 % | 136 / 136 |
| Ultracode | von der Uhr bei 76 Min. abgebrochen, prüfte noch | 18 % | 136 / 136 |
Im ultracode-Lauf schrieb Claude ein Skript, dessen einziger Zweck es war, ein Team laufen zu lassen: 12 gezählte Agents, Tester, ein paar Richter und später einige "Breaker", deren Aufgabe es war, die Seite kaputtzumachen. Ein Breaker fand tatsächlich einen echten Bug in der Formelleiste, die nach einem Klick auf eine andere Zelle weiter den alten Text zeigte.
Pro Minute verbrauchte der ultracode-Lauf das Limit etwa so schnell wie der normale Lauf, im Schnitt sogar etwas langsamer. Er brannte nicht schneller, aber er hörte nicht auf. Ultracode macht Claude nicht klüger, es lässt Claude prüfen, und jede Prüfung bezahlst du. Das ist ein Paar bei einer kleinen Spezifikation, und der zweite Lauf wurde von einer Uhr abgebrochen, aber das Muster ist klar: dieselbe Antwort, mehr als das doppelte Session-Fenster, und die zusätzliche Zeit war reines Prüfen.
Warum es kostet: ein Satz und drei abgeschaltete Schutzfunktionen
Das Modell ist dasselbe. Was sich ändert, ist der Text, den der Harness ihm gibt; der Harness ist Claude Code selbst, seine Tools und die Anweisungen um das Modell herum.
Ist ultracode an, lädt Claude Code vor jedem Workflow eine Referenz. Dieser Text sagt dem Modell, standardmäßig für jede substanzielle Aufgabe einen Workflow auszuführen, und er enthält den Satz, der die Rechnung erklärt: "The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint." Das ist der eigene Text des Harness, und ein öffentliches GitHub-Issue zitiert dieselben Zeilen.
Gleichzeitig gehen drei Schutzfunktionen aus:
- Die Warnung vor großen Workflows, die normalerweise erscheint, wenn ein Lauf zu viele Agents einplant, bleibt aus.
- Das Limit der Session für gleichzeitig laufende Agents wird für die von Claude gestarteten Agents nicht durchgesetzt.
- Im Auto-Modus wird der erste Start nie zur Freigabe vorgelegt.
Die Größenrichtlinie ist ein Rat, kein Deckel: Auf small gestellt (weniger als 5 Agents) startete der ultracode-Lauf in der Sandbox trotzdem 9. Fairerweise ist der Satz ein Standard, den das Modell noch abwägen kann, und die Schutzfunktionen entfallen absichtlich bei sehr großen Jobs. Die Antwort passt in eine Zeile: Ultracode ändert nicht das Modell, es ändert die Anweisungen in "ein Team für alles, und Kosten sind kein Kriterium".
Der Multiplikator: drei Paare, die Effort-Leiter, das 30x-Paar
Ein zweiter Entwickler ließ im Pro-Plan mehrere Paare aus Einzel-Agent und Workflow laufen, Skripte im Review-Stil, und las die Usage-Anzeige jeweils vorher und nachher ab.
| Messwert | Einzel-Agent | Workflow |
|---|---|---|
| Tokens bei einem Review-Skript | etwa 115.000 | 972.000 |
| Token-Multiplikator über die Paare | 1x | bis zu 18x, für ungefähr dieselben Funde |
| Bewegung der Anzeige | 1x | bis zu 3x |
| Laufzeit | nahezu identisch | nahezu identisch |
Der Workflow wurde nicht schneller fertig; er gab mehr aus, während du genauso lange wartest. Die einzige Stelle, an der Parallelität sich lohnte, war ein Stapel unabhängiger Recherche-Jobs, bei dem die Agents schneller fertig waren, allerdings für mehr als das Doppelte an Tokens.
Ein dritter Test baute auf jeder Effort-Stufe ein paar kleine Apps zu API-Preisen. Jede Stufe der Leiter verdoppelte die Rechnung ungefähr, und ultracode landete bei mehreren Malen dessen, was max kostete, ohne je am besten abzuschneiden. Die meisten dieser Tokens waren Cache-Reads, die günstigen; der winzige Anteil an Output-Tokens machte fast die Hälfte der Kosten aus.
Noch ein Paar, eine Stadtszene: Ein einzelner Agent brauchte etwa eine Stunde für ein paar Dollar API-Preis. Der ultracode-Lauf brauchte fast einen Tag, Dutzende Subagents und etwa das 30-Fache an Kosten.
Das sind ganzzahlige Anzeigewerte, Greenfield-Apps zu API-Preisen und eine Stadtszene, also ist keines davon für sich eine Rangliste. Zusammen ergibt sich jedes Mal dasselbe Muster: Das Auffächern kauft Prüfung und Abdeckung, keine bessere Antwort, es sei denn, der Job zerfällt in unabhängige Teile.
Wo sich das Auffächern lohnt: eine Testsuite als Richter, und die Ein-Zeilen-Regel
Manche Jobs haben genau diese Form: eine Migration, ein Audit, ein Durchlauf durch eine Codebasis.
Bun wurde mit etwa 50 dynamischen Workflows in Claude Code von Zig nach Rust umgeschrieben, 11 Tage lang durchgehend. Das sind über eine halbe Million Zeilen Zig, vom Start bis zur bestandenen Testsuite auf jeder Plattform in denselben Tagen. Entscheidend war nicht die Agent-Anzahl, sondern der Richter: eine riesige bestehende Testsuite, die ohne jede Meinung "bestanden" oder "durchgefallen" sagte.
Anthropics Bug-Jagd zeigt dasselbe. In einer großen Codebasis wurden siebzig Bugs gepflanzt, und ein einzelner Agent lief mehrmals.
| Agent | Gefundene Bugs von 70 |
|---|---|
| Einzel-Agent (3 Läufe) | 14, 15, 27 |
| Workflow (3 Läufe) | 66 in jedem Lauf |
Eine Einschränkung: Dieser Test lief auf Claude Managed Agents, dem API-Produkt, nicht in Claude Code, und Kosten wurden nicht genannt.
Der Launch-Thread nennt weitere berichtete Erfolge, und sie sehen alle gleich aus: Review gegen eine Regeldatei, Übersetzung einer ganzen Codebasis, Aufräumen eines Stapels gescannter Seiten. Der Launch-Blog sagt es klar: Die meisten klassischen Coding-Aufgaben brauchen kein Gremium aus fünf Reviewern.
Die Regel: Fächere nur auf, wenn eine Testsuite oder ein Regelwerk die Ausgabe beurteilt und der Job in unabhängige Teile zerfällt. Alles andere läuft normal, auf high. Der Tester des Paars sagte dasselbe mit eigenen Worten: Spar es dir für Jobs auf, bei denen das Prüfen die Arbeit ist, etwa eine Migration über Hunderte Dateien.
Fünf Einstellungen, die einen Lauf deckeln
Jeder Deckel sitzt an einem Ort, den du schon kennst.
| # | Einstellung | Wo | Wirkung |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config unter Dynamic workflow size, oder settings.json |
Rat (weniger als 5 Agents), senkt auch die Schwelle der Warnung vor großen Workflows |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
Umgebungsvariable, vor dem Start exportiert | standardmäßig bis zu 16 Agents gleichzeitig; auf 4 gesetzt, warten die übrigen in der Schlange, das bremst den Verbrauch, ohne den Lauf zu beenden |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
Umgebungsvariable | lässt jeden Workflow-Agent auf einem von dir gewählten Modell laufen, während andere Subagents ihres behalten; ein günstigeres Modell macht das Prüfen günstiger |
| 4 | das Schlüsselwort ultracode, nie der Schalter |
im Prompt; nie der Schlüssel ultracode in den Einstellungen |
das Schlüsselwort lässt eine Aufgabe als Workflow laufen und hört dann auf; der Schalter macht es dauerhaft, bis du ihn ausschaltest |
| 5 | autoContinueAtUsageLimit |
Einstellungen | an: Ein Lauf, der das Limit erreicht, pausiert, wartet auf den Reset und macht weiter, auch mehrmals; aus: Die Agents scheitern an der Wand und der Lauf endet dort |
Drei Gewohnheiten gehören dazu. Der Launch-Blog sagt, ein im Prompt geschriebenes Budget wie "use 10k tokens" setzt den Deckel. Nach jedem Lauf zeigt /usage, wie viel der jüngsten Nutzung an Subagents und Workflows ging, mit einer Warnung, wenn sie überwiegen. Sieht ein Lauf währenddessen falsch aus, stoppen das Pane /workflows und die Taste x ihn, und die schon geleistete Arbeit bleibt meist erhalten.
Nichts davon macht einen Agent billiger. Es begrenzt, wie viele Agents ein Lauf bezahlen kann und wie lange er weiter ausgeben darf.
Der außer Kontrolle geratene Lauf, die Limits und das Urteil
Ein öffentlicher Bericht zeigt, wie eine Woche verschwindet. Ein vom Modell geschriebenes Skript im größten Plan startete in unter einer Stunde 221 Agents. Nach dem ersten Session-Limit-Fehler verteilte das Skript weiter Aufgaben, und in den nächsten Minuten starteten 189 weitere Agents. Die eigene Tabelle des Melders zählt vor der Wand zig Millionen Tokens über die Phasen.
| Phase | Tokens, Cache eingerechnet |
|---|---|
| Ground | 11.063.801 |
| Find | 35.885.272 |
| Merge | 516.226 |
| Gesamt | 47.465.299 |
Schuld war eine Zeile im generierten Skript, ein Fallback, der sagte: Wenn der Agent nichts zurückgab, nimm die Rohliste und mach weiter. Der Merge schlug fehl und der Lauf ging weiter. Diese Version ist älter als die Pause am Usage-Limit, und der Melder sagt, diese Tokens stammten nicht von den gescheiterten Agents. Eine Obergrenze für Gleichzeitigkeit hätte diesen Lauf ausgedünnt, und ausgeschaltetes Auto-Continue hätte ihn an der Wand beendet.
Das Urteil: Bei derselben Aufgabe und denselben bestandenen Prüfungen brauchte ultracode mehr als das Doppelte der Anzeige eines normalen Laufs. Nicht weil es klüger ist, sondern wegen des eingefügten Satzes und der Schutzfunktionen, die es fallen lässt. Es lohnt sich, wenn eine Testsuite oder ein Regelwerk die Ausgabe beurteilt und die Teile nicht aufeinander warten. Überall sonst tippst du es und zahlst fürs Prüfen. Fünf Einstellungen deckeln, was ein Lauf ausgeben kann: die Größenrichtlinie, die Obergrenze für Gleichzeitigkeit, das Workflow-Modell, das Schlüsselwort statt des Schalters und der Stopp am Limit.
