Ein Konfigurations-Snippet macht diese Woche die Runde: Setze agents.max_concurrent_threads_per_session = 64 in deiner Codex-config.toml und sieh zu, wie eine Session in Dutzende Subagenten auffächert. Der Beitrag, der das ausgelöst hat, behauptet, der Standardwert sei 3 und OpenAI habe 64 getestet. Die Einstellung ist echt. Die beiden Zahlen stehen nicht in der Dokumentation, und das Interessante ist überhaupt nicht das Limit. Es ist das, was mit der Arbeit passiert, wenn man es erhöht.
Dieser Beitrag behandelt, was die Einstellung laut der Codex-Referenz tatsächlich bewirkt, und die drei Dinge, die nacheinander schiefgehen, sobald eine einzelne Session mehr Agenten laufen lässt, als eine Person lesen kann.
TL;DR
agents.max_concurrent_threads_per_session begrenzt, wie viele Threads gestarteter Agenten Codex gleichzeitig offen hält, ohne den primären Thread mitzuzählen. Die Referenz gibt keinen Standardwert an; sie besagt, dass Codex einen wählt, wenn der Schlüssel nicht gesetzt ist. Subagenten liefern Zusammenfassungen an den Hauptthread zurück, der auf alle wartet und einmal antwortet, und die Dokumentation empfiehlt sie für leseintensive Arbeit, warnt aber, dass parallele schreibintensive Workflows Konflikte und Koordinationsaufwand verursachen. Das Limit auf 64 zu erhöhen, strapaziert genau diese beiden Punkte: gemeinsame Dateien und eine einzige konsolidierte Antwort, die niemand prüfen kann. Sharkly führt Codex als Runtime aus und verlagert die Parallelität eine Ebene nach oben, wo jeder Lauf ein Task mit eigenem Worktree, eigenem Protokoll und eigenem Reviewer ist.
Was die Einstellung bewirkt
Drei Schlüssel im Abschnitt [agents] von config.toml sind hier relevant. Die folgenden Formulierungen stammen aus der Konfigurationsreferenz.
| Schlüssel | Was die Referenz sagt |
|---|---|
agents.max_concurrent_threads_per_session |
„Maximale Anzahl gleichzeitig offener Threads gestarteter Agenten, ohne den primären Thread. Wenn nicht gesetzt, wählt Codex den Standardwert.“ |
agents.max_threads |
„Veralteter Alias für agents.max_concurrent_threads_per_session.“ |
agents.enabled |
„Multi-Agent-Tools aktivieren oder deaktivieren (Standard: true).“ |
Zwei verwandte Schlüssel, agents.default_subagent_model und agents.default_subagent_reasoning_effort, legen fest, worauf gestartete Agenten laufen, sofern ein Spawn-Aufruf nichts anderes angibt.
Das Snippet funktioniert also wie geschrieben:
[agents]
max_concurrent_threads_per_session = 64
Was die Referenz nicht sagt, ist, wie der Standardwert lautet oder dass irgendein Wert getestet wurde. Behandle „Standardwert 3“ und „OpenAI hat 64 getestet“ als Behauptungen aus einem Beitrag, nicht vom Anbieter, bis die Doku etwas anderes sagt.
Der Subagenten-Leitfaden fügt die zwei Sätze hinzu, die entscheiden, ob eine Erhöhung des Limits eine gute Idee ist. Zu den Ergebnissen: „Wenn viele Agenten laufen, wartet Codex, bis alle angeforderten Ergebnisse verfügbar sind, und gibt dann eine konsolidierte Antwort zurück.“ Zur Eignung: Subagenten eignen sich für „leseintensive Aufgaben wie Exploration, Tests, Triage und Zusammenfassung“, und der Leitfaden rät bei „parallelen schreibintensiven Workflows zur Vorsicht, da Agenten, die gleichzeitig Code bearbeiten, Konflikte erzeugen und den Koordinationsaufwand erhöhen können.“
Liest man beides zusammen, ergibt sich die Reihenfolge der Fehler von selbst.
Was zuerst schiefgeht: der gemeinsame Checkout
Subagenten in einer Session teilen sich das Arbeitsverzeichnis der Session, sofern man nichts anderes einrichtet. Das ist in Ordnung, wenn vierundsechzig Agenten lesen. Bei vier schreibenden Agenten ist es ein Merge-Problem.
Der Fehler ist nicht dramatisch. Zwei Subagenten bearbeiten dieselbe Datei, der zweite Schreibvorgang gewinnt, und die konsolidierte Zusammenfassung meldet beide Aufgaben als abgeschlossen. Man erfährt es beim Review, falls man eins hat, oder in der Produktion, falls nicht. Die Warnung der Doku vor Konflikten und Koordinationsaufwand beschreibt genau das.
Die Lösung ist die, auf die jede Parallel-Agenten-Einrichtung hinausläuft: eine Arbeitskopie pro Arbeitseinheit. In Sharkly erhält jeder Task-Lauf ein isoliertes Verzeichnis, und repository-gestützte Arbeit verwendet pro Lauf einen separaten Git-Worktree – der Mechanismus, der in parallele Agenten in isolierten Worktrees beschrieben wird. Zehn Tasks gegen ein Repository, null gemeinsamer Zustand. Die Runtime, die die Bearbeitung durchführt, kann weiterhin Codex sein; die Isolation wird darum herum bereitgestellt.
Was als Zweites schiefgeht: die konsolidierte Antwort
Codex wartet auf jeden Subagenten und gibt eine Antwort zurück. Bei vier Subagenten ist das praktisch. Bei vierundsechzig ist es eine einzelne Nachricht, die vierundsechzig Arbeitseinheiten zusammenfasst, geschrieben von dem Agenten, der sie entsandt hat, mit ausgeblendeten Zwischenergebnissen.
Das ist die falsche Form für ein Review. Ein Reviewer muss wissen, was jede Arbeitseinheit angefasst hat, was sie ausgeführt hat und wo sie stehen geblieben ist, und muss jede einzeln annehmen oder ablehnen können. Eine Zusammenfassung von Zusammenfassungen lässt sich nicht teilweise annehmen.
Sharkly speichert die endgültige Antwort des Agenten am Task und führt pro Lauf ein Ausführungsprotokoll mit Auslöser, Start und Ende, Tool-Aufrufen, Runtime-Ereignissen und Fehlerdetails. Ausführungen befinden sich in einem eigenen Tab, getrennt von der Kommentar-Timeline. Vierundsechzig Arbeitseinheiten sind vierundsechzig Tasks mit vierundsechzig Protokollen, jedes einzelne überprüfbar, jedes einzelne liefert sein Ergebnis an die Stelle zurück, an der eine Person nachsehen wird.
Was als Drittes schiefgeht: der Mensch im Loop
Das Limit sagt nichts darüber aus, was passiert, wenn ein Subagent einen Menschen braucht. Innerhalb einer Session ist ein blockierter Subagent ein Thread, der in einem konsolidierten Warten verstummt ist. Der Hauptthread kann nicht für dich antworten, und du kannst nicht sehen, welcher der vierundsechzig Threads derjenige ist, der angehalten hat.
Sharkly hält den Task-Status und den Arbeitszustand des Agenten getrennt: Ein gestarteter Task kann Working, Waiting for human reply, Waiting for human review oder Error anzeigen. Wartende und fehlgeschlagene Signale landen im Bereich Primary der Inbox für die verantwortliche Person, und eine Antwort am Task startet den Folge-Lauf mit dem Thread als Kontext. Der festgefahrene meldet sich, anstatt in einem Warten zu hängen, das man nicht einsehen kann.
Subagenten oder Tasks? Ein Entscheidungspaar
Setze Codex-Subagenten innerhalb einer Session ein, wenn die Arbeit leseintensiv ist und auf eine einzige Antwort hinausläuft: eine Codebasis erkunden, eine Reihe von Fehlern triagieren, eine Gruppe von Dokumenten zusammenfassen, eine Testsuite ausführen. Dafür empfiehlt sie der Leitfaden, und ein höheres Limit ist günstig, wenn nichts schreibt.
Verwende separate Tasks, die jeweils einem Agenten auf einem Computer zugewiesen sind, wenn die Arbeitseinheiten Code schreiben, wenn verschiedene Personen verschiedene Teile prüfen oder wenn eine Person möglicherweise mitten im Lauf antworten muss. Sharkly ist kein Ersatz für Codex; Codex ist die Runtime, die jeden Task ausführt. Der Unterschied liegt darin, wo die Parallelität lebt: innerhalb des konsolidierten Wartens einer Session oder über ein Board, auf dem Kontext, Fortschritt, Blocker, Ergebnisse und menschliches Review von der Anfrage bis zur Freigabe sichtbar bleiben.
Das Limit sicher erhöhen
Wenn du max_concurrent_threads_per_session erhöhst, dann so, wie es die eigenen Parallelitäts-Dokumente von Sharkly für Computer beschreiben: Erhöhe erst, wenn das aktuelle Setup die bestehende Arbeitslast zuverlässig bewältigt, denn höhere Parallelität verbraucht mehr CPU, Arbeitsspeicher, Speicherplatz, Anbieterkapazität und Repository-Bandbreite. Ein Computer in Sharkly hat sein eigenes Task-Parallelitätslimit, und Agenten, die temporäre Verzeichnisse verwenden, nutzen standardmäßig die Hälfte davon. Die Kapazität wird durch den Computer, die Parallelität des Agenten und die Verfügbarkeit von Verzeichnissen begrenzt, und ein online befindlicher Agent kann trotzdem wartende Arbeit haben, wenn diese Kapazität ausgeschöpft ist.
Die Anbieterkapazität ist diejenige, die man vergisst. Vierundsechzig Threads gegen einen einzigen API-Schlüssel sind vierundsechzig Möglichkeiten, gleichzeitig ein Rate Limit zu treffen, und ein 429, das „Kontingent erschöpft“ bedeutet, wird nicht durch einen erneuten Versuch behoben. Das Protokoll fehlgeschlagener Läufe von Sharkly bewahrt die Originalantwort des Anbieters neben einem einfachen Titel auf, sodass der Unterschied sichtbar ist, bevor jemand einen erneuten Versuch unternimmt.
Häufig gestellte Fragen
Was ist der Standardwert von agents.max_concurrent_threads_per_session? Die Konfigurationsreferenz gibt keinen an. Sie besagt, dass Codex den Standardwert wählt, wenn der Schlüssel nicht gesetzt ist. Zahlen, die in sozialen Medien kursieren, stammen nicht aus der Referenz.
Macht eine Erhöhung des Limits Codex schneller? Bei leseintensivem Fan-out werden mehr Threads früher fertig. Bei schreibintensiver Arbeit warnt die Doku, dass gleichzeitige Bearbeitungen Konflikte und Koordinationsaufwand erzeugen, was mehr Zeit kostet, als die Parallelität spart.
Laufen Codex-Subagenten in separaten Git-Worktrees? Der Subagenten-Leitfaden sagt nicht, dass sie es tun. Plane so, als würden sie sich das Arbeitsverzeichnis teilen, es sei denn, du hast selbst eine Isolation eingerichtet.
Wie verwendet Sharkly Codex? Als Runtime. Ein Computer, auf dem Codex läuft, meldet es als verfügbar, und Tasks, die einem Agenten auf diesem Computer zugewiesen sind, werden darüber ausgeführt, wobei jeder Lauf in seinem eigenen isolierten Verzeichnis oder Worktree erfolgt.
Kann ich Subagenten trotzdem innerhalb eines Sharkly-Tasks verwenden? Ja. Alles, was die Runtime eigenständig tun kann, funktioniert weiterhin innerhalb des Laufs. Sharkly fügt den Task, die Isolation, das Protokoll und das Review darum herum hinzu.
Die Kurzfassung
Die Einstellung ist echt und das Snippet funktioniert. Was es nicht tut: vierundsechzig gleichzeitige Bearbeitungen sicher machen, eine einzige konsolidierte Antwort überprüfbar machen oder dir sagen, welcher Thread auf dich wartet. Das sind die drei Dinge, die schiefgehen, in dieser Reihenfolge. Behalte Subagenten für leseintensives Fan-out, und lege schreibintensive parallele Arbeit auf ein Board, auf dem jeder Lauf seinen eigenen Worktree und seinen eigenen Reviewer hat. Verbinde einen Computer mit Codex darauf, erstelle einen Agenten und weise ihm etwas Langweiliges zu. Die Doku behandelt jedes Konzept ausführlicher: docs.sharkly.ai.
