Warum Sub-Agents das Wochenkontingent in 30 Minuten verbrennen können
Jeder Tool-Call-Roundtrip sendet den gesamten Verlauf erneut
Wenn Sie 5 Sub-Agents 30 Minuten lang parallel laufen lassen, kann das Kontingent dutzende Male schneller schwinden als bei einer einzelnen Unterhaltung – denn jeder Tool-Call-Roundtrip sendet den gesamten bis dahin aufgelaufenen Gesprächsverlauf erneut.
Aktualisiert 2026-09-19
Vier zentrale Fakten
Der gesamte Verlauf wird erneut gesendet
Die meisten Multi-Turn-/Tool-Calling-APIs sind zustandslos – jede Anfrage muss den System-Prompt, alle bisherigen Nachrichten und sämtliche bisherigen Tool-Call-Ergebnisse erneut als Input mitsenden.
Die kumulierte Nutzung wächst etwa quadratisch mit der Rundenzahl
Wenn eine Aufgabe N Runden von Tool-Calls benötigt und die durchschnittliche Verlaufsgröße pro Runde linear mit der Rundenzahl wächst, wächst die kumulierte Token-Nutzung ungefähr in der Größenordnung von N zum Quadrat.
Mehrere Sub-Agents gleichzeitig verstärken den Effekt
Jeder parallel laufende Sub-Agent führt seinen eigenen Verlauf separat und sendet ihn erneut – M parallele Sub-Agents vervielfachen die Nutzung einer einzelnen Unterhaltung grob um den Faktor M.
Prompt Caching spart Geld, nicht zwingend Kontingent
Das Prompt Caching mancher Anbieter senkt die abgerechneten Kosten für wiederholte Präfixe, aber Rate Limits und Kontingente werden meist weiterhin anhand der tatsächlich verarbeiteten Tokens berechnet – betrachten Sie Caching daher nicht als Allheilmittel gegen Kontingentprobleme.
Was hinter dem erneuten Senden von Tokens steckt
Die meisten gängigen Konversations-/Agent-APIs sind „zustandslos“ – jede Anfrage muss den vollständigen Kontext mitführen (System-Prompt, alle bisherigen Nachrichten, Ein- und Ausgabe jedes Tool-Calls); das Modell selbst erinnert sich nicht an die vorherige Anfrage. Das heißt: Bei einer Aufgabe mit N Runden von Tool-Calls sendet Runde 1 nur den Anfangskontext, Runde 2 muss zusätzlich die Ergebnisse von Runde 1 enthalten, und Runde N muss alles aus allen N-1 vorherigen Runden enthalten – die kumulierte Menge gesendeter Tokens wächst ungefähr quadratisch mit der Rundenzahl, nicht linear. Das ist der eigentliche Grund, warum lange Aufgaben und mehrstufige Agent-Schleifen besonders kontingenthungrig sind.
Warum parallele Sub-Agents das deutlich sichtbarer machen
Wenn Sie mehrere Sub-Agents parallel für verschiedene Teilaufgaben starten, vollführt jeder für sich denselben Tanz des „erneuten Sendens des Verlaufs“, meist zur gleichen Zeit – die sich in einem kurzen Zeitfenster aufsummierende Token-Nutzung kann leicht das Mehrfache bis Dutzendfache der Nutzung einer einzelnen Unterhaltung erreichen. Das ist die tatsächliche technische Ursache der häufigen Klage: „Ich habe ein paar parallele Agents laufen lassen und das Wochenkontingent in 30 Minuten verbraucht.“
Zeitachse
Dass zustandslose APIs in jeder Runde den vollständigen Verlauf erneut senden, ist bei gängigen Konversations-/Agent-APIs von Anfang an die übliche Architektur.
Die Verbreitung paralleler Sub-Agents und Multi-Agent-Workflows macht den Kontingentverbrauch durch dieses systembedingte Verhalten für Nutzer deutlich unmittelbarer spürbar.
Techniken wie Prompt Caching entschärfen die Abrechnungskosten, doch die Berechnung von Kontingenten und Rate Limits wurde meist nicht entsprechend gelockert.
Bestätigt vs. verbreitetes Missverständnis
Bestätigt
Die Zustandslosigkeit gängiger Multi-Turn-/Agent-APIs und die dadurch entstehende, ungefähr quadratisch wachsende kumulierte Nutzung durch das erneute Senden des vollständigen Verlaufs in jeder Runde sind öffentlich dokumentiertes, allgemeines Verhalten dieser API-Architektur und werden in offiziellen Dokumentationen und Entwicklerdiskussionen einheitlich beschrieben.
Verbreitetes Missverständnis
Viele nehmen an: „Wenn ich Prompt Caching nutze, stoße ich nicht so schnell ans Kontingentlimit“ – Caching wirkt sich hauptsächlich auf die abgerechneten Kosten aus; Kontingente und Rate Limits werden meist weiterhin anhand der tatsächlich verarbeiteten Tokens oder der Anfragemerkmale berechnet, sodass Sie sich nicht vollständig auf Caching verlassen können, um den Kontingentverbrauch zu steuern.
So schätzen und reduzieren Sie die Nutzung
So schätzen Sie
Schätzen Sie die erwartete Anzahl der Tool-Call-Runden und die durchschnittliche Verlaufsgröße pro Runde, und rechnen Sie die Gesamtnutzung grob quadratisch hoch, statt einfach linear „Nutzung pro Runde × Rundenzahl“ zu rechnen.
So reduzieren Sie sie
Fassen Sie den Verlauf regelmäßig zusammen bzw. komprimieren Sie ihn, behalten Sie nur die Tool-Call-Ergebnisse, die die Aufgabe wirklich braucht, statt alles wortwörtlich zu übernehmen, und begrenzen Sie die Zahl paralleler Sub-Agents sowie die maximale Rundenzahl pro Sub-Agent – allesamt gängige Maßnahmen zur Reduzierung.
Was Sie konkret tun sollten
Begrenzen Sie erstens die maximale Zahl der Tool-Call-Runden pro Aufgabe – sobald ein Schwellenwert erreicht ist, lösen Sie eine Zusammenfassung bzw. Komprimierung des Verlaufs aus, statt unbegrenzt anzusammeln. Behalten Sie zweitens nur die Teile der Tool-Call-Ergebnisse, die die Aufgabe wirklich braucht, statt ganze Roh-Logs bzw. Ausgaben in den Kontext zu packen. Begrenzen Sie drittens, wie viele Sub-Agents gleichzeitig parallel laufen, oder weisen Sie unkritischen Sub-Agents ein günstigeres Modell mit kürzerem Kontext zu. Betrachten Sie viertens den Kontingentverbrauch als Eingangsgröße der Aufgabenplanung – schätzen Sie vorab grob, wie viel Kontingent eine komplexe Aufgabe verbraucht, statt erst bei laufender Aufgabe zu merken, dass das Limit bald erreicht ist.
Was Sie bei QCode tun können
Parallele Sub-Agents können das Kontingent eines Modells in kurzer Zeit leicht ausschöpfen; wenn Sie verschiedene Sub-Agents über einen QCode-Key auf unterschiedliche Modellfamilien leiten, verteilt sich der Kontingentdruck, sodass ein einzelnes Modell, das sein Limit erreicht, nicht die gesamte Multi-Agent-Aufgabe ausbremst.
FAQ
Warum verbrauchen Sub-Agents Kontingent so viel schneller als eine einzelne Unterhaltung?
Jeder Sub-Agent führt seinen eigenen Gesprächsverlauf separat und sendet ihn erneut, sodass M parallele Sub-Agents die Nutzung einer einzelnen Unterhaltung grob um den Faktor M vervielfachen; hinzu kommt, dass die kumulierte Nutzung eines einzelnen Sub-Agents ohnehin schon ungefähr quadratisch mit den Runden wächst – dadurch wird der Verbrauch im kurzen Zeitfenster deutlich verstärkt.
Kann Prompt Caching dieses Problem lösen?
Es senkt die abgerechneten Kosten für wiederholte Präfixe, aber Kontingente und Rate Limits werden meist weiterhin anhand der tatsächlich verarbeiteten Tokens oder der Anfragemerkmale berechnet – Sie können sich nicht vollständig auf Caching verlassen, um das Limit zu vermeiden.
Wie schätze ich grob ab, wie viel Kontingent eine Aufgabe verbraucht?
Schätzen Sie die erwartete Anzahl der Tool-Call-Runden und die durchschnittliche Größe des Verlaufs pro Runde, und rechnen Sie das Ganze als ungefähr quadratisch hoch – nicht als einfaches „Nutzung pro Runde × Anzahl der Runden“.
Schadet die Begrenzung paralleler Sub-Agents der Effizienz der Aufgabe?
Es gibt einen Zielkonflikt: Mehr Parallelität schließt die Aufgabe schneller ab, erhöht aber auch den Druck, das Kontingent in kurzer Zeit aufzubrauchen. Sie müssen das gegen Ihr verbleibendes Kontingent und die Dringlichkeit der Aufgabe abwägen.
Haben alle Agent-Frameworks dieses Problem?
Grundsätzlich weist jedes Agent-Framework, das auf gängigen zustandslosen Konversations-APIs aufbaut, diese Eigenschaft auf. Je besser die Strategie eines Frameworks zur Komprimierung bzw. Zusammenfassung des Verlaufs ist, desto geringer ist der tatsächlich spürbare Verbrauch – die zugrunde liegende architektonische Ursache bleibt jedoch dieselbe.
Was passiert mit einer laufenden Multi-Agent-Aufgabe, wenn sie ein Kontingentlimit erreicht?
Das Modell bzw. Konto, das das Limit erreicht hat, lehnt neue Anfragen ab, und die Aufgabe bleibt meist hängen oder bricht mit einem Fehler ab. Einzelne Sub-Agents gezielt auf andere Modelle umzuleiten, ist ein gängiger Weg, um zu vermeiden, dass die gesamte Aufgabe am Limit eines einzelnen Modells hängen bleibt.
Quellen
Dass zustandslose Konversations- bzw. Agent-APIs in jeder Runde den vollständigen Verlauf erneut senden, ist eine architektonische Tatsache, die öffentlich dokumentiert ist und in der Dokumentation gängiger Modellanbieter sowie in Entwickler-Communitys durchgängig so beschrieben wird. Diese Seite trifft keine Aussagen über die private Implementierung eines einzelnen Anbieters. Stand: 2026-08-27.
Lassen Sie eine Multi-Agent-Aufgabe nicht an einem einzelnen Kontingent hängen bleiben
Ein QCode-Key leitet verschiedene Sub-Agents an unterschiedliche Modelle weiter und verteilt so den Kontingentdruck.
Weiterführende Artikel
Claudes 5-Stunden-Rolling-Window erklärt
Die Limit-Ebene, die bei kurzen Phasen intensiver Nutzung am ehesten erreicht wird.
Abo vs. API: Frisst ein 24/7-Agent Ihren Tarif auf?
Die Wirtschaftlichkeit lang laufender automatisierter Aufgaben.
So rotieren Sie das Kontingent über mehrere Tools hinweg
Kontingente mehrerer Modelle/Tools sinnvoll kombinieren.
Diese Seite bietet eine allgemeine, anbieterübergreifende technische Erläuterung und trifft keine Aussagen über die private Implementierung eines einzelnen Anbieters. Das tatsächliche Verhalten hängt vom jeweiligen Modell und der Dokumentation des von Ihnen verwendeten Clients ab.