# Laufzeit & Kosten: Zustand, Zeitgrenzen, Kostenmodell

> Ein Agentenlauf erfüllt keine Request-Annahme: Zustand außerhalb des Prozesses, Interaktionsmodell und drei Ebenen von Zeitgrenzen, das quadratische Kostenmodell der Schleife, Präfix-Caching, Modell-Routing, Nebenläufigkeit und erzwungene Budgets.

Track: [Agentic AI](https://physar.tech/learn/agentic-ai)  
Kanonische Fassung: https://physar.tech/learn/agentic-ai/agent-runtime-cost  
Stand: 2026-09-04  
Interaktiver Teil: 9 Checks (nur im Browser)

## Laufzeit und Kosten: ein Lauf ist kein Request

### Ein Lauf ist kein Request

Ein Agentenlauf dauert zwischen Sekunden und Stunden, seine Dauer ist vorab unbekannt, und er hält währenddessen Zustand. Damit erfüllt er keine der Annahmen, auf denen der übliche Web-Aufbau steht: kurz, vorhersagbar, zustandslos.

|  |  |
| --- | --- |
| Request | Kurz, Dauer bekannt, Zustand in der Datenbank, Wiederholung durch den Client möglich. |
| Agentenlauf | Dauer variabel, Zustand im Prozess, Wiederholung teuer — und die Verbindung überlebt ihn oft nicht. |

Alle Probleme dieses Moduls folgen aus dieser einen Verschiebung. Die Zeitgrenze des Gateways, der Prozessneustart beim Deployment, der Stapel von 5.000 Aufträgen gegen ein Altsystem, die Rechnung, die um Faktor sechzehn danebenliegt — jedes davon ist ein Fall, in dem eine Request-Annahme auf einen Lauf trifft.

**Agentenlauf:** Die Bearbeitung **eines** Auftrags von der Annahme bis zum Abschluss, bestehend aus einer unbekannten Zahl von Runden mit Zustand dazwischen. Er ist die Einheit, auf die Grenzen, Budgets, Wiederaufnahme und Protokollierung sich beziehen — nicht der einzelne Modellaufruf.

> **Merksatz:** Die erste Frage an jeden Agentendienst lautet nicht „wie schnell ist er“, sondern: **Was passiert, wenn der Prozess mitten im Lauf endet?**

### Zustand gehört nach außen

Ein Lauf, dessen Fortschritt im Prozessspeicher liegt, ist bei jedem Neustart verloren — und Neustarts gibt es nicht nur bei Abstürzen, sondern bei jedem Deployment. Bei einem Lauf von zwanzig Minuten mit mehreren schreibenden Schritten ist das kein Randfall, sondern ein täglicher.

Die Entwurfsannahme, die sich dafür bewährt hat, ist bemerkenswert pessimistisch: Man baut so, als könne der Kontext **jederzeit zurückgesetzt** werden. Was nicht außerhalb des Laufs steht, gilt als verloren.

- **Die Aufgabenliste** — was insgesamt zu tun ist, als Datei oder Datensatz, nicht als Absatz im Prompt.
- **Der Fortschritt** — was erledigt ist und was noch offen, fortgeschrieben nach jedem abgeschlossenen Schritt.
- **Der Ausgangszustand** — ein fester Bezugspunkt, gegen den ein neuer Lauf sich orientieren kann.
- **Ein Startskript** — der Weg, die Arbeitsumgebung wiederherzustellen, damit ein neuer Lauf nicht Runden damit verbringt, sie neu zu entdecken.

Der letzte Punkt wirkt nebensächlich und ist eine Kostengröße: Ein Agent, der bei jedem Wiederanlauf herausfinden muss, wie die Umgebung startet, bezahlt diese Entdeckung in Tokens — jedes Mal, in einem Kontext, der dadurch schon voll ist, bevor die eigentliche Arbeit beginnt.

> **Merksatz:** Ein Fortschrittseintrag gilt erst nach **verifizierter** Erledigung als erledigt, nicht wenn der Schritt ausgeführt wurde. Sonst beginnt jeder Wiederanlauf mit einer Lüge.

### Das Interaktionsmodell entscheidet über die Zeitgrenze

Wenn ein Lauf länger dauert als die Zeitgrenze der Verbindung, ist das kein Konfigurationsproblem. Es ist das falsche Interaktionsmodell.

|  |  |
| --- | --- |
| Synchron | Der Aufrufer wartet auf das Ergebnis. Tragfähig nur, wenn die obere Laufzeit sicher unter jeder Zeitgrenze auf dem Weg liegt — Gateway, Proxy, Client. |
| Asynchron mit Abfrage | Der Aufruf legt einen Auftrag an und gibt eine Kennung zurück; der Aufrufer fragt den Stand ab. Der Regelfall für variable Laufzeiten. |
| Asynchron mit Rückruf | Das Ergebnis wird an eine hinterlegte Adresse geliefert. Spart die Abfragen, verlangt aber einen erreichbaren Empfänger und Wiederholungslogik. |
| Fortlaufende Ausgabe | Zwischenstände werden während des Laufs gesendet. Verbessert die wahrgenommene Wartezeit, ändert aber nichts an der Zeitgrenze der Verbindung. |

Die letzte Zeile wird häufig als Lösung angeboten und ist keine: Eine laufende Ausgabe hält die Verbindung offen und beschäftigt, aber sie überlebt weder ein Deployment noch einen Verbindungsabbruch. Wer eine Laufzeit von bis zu zwölf Minuten hat, braucht einen Auftrag mit Kennung — alles andere verschiebt nur, wann es bricht.

Die übliche Umsetzung des zweiten Modells ist unspektakulär und seit Jahrzehnten bewährt: Der annehmende Aufruf antwortet mit `202 Accepted` und einer Kennung, der Stand ist unter `GET /runs/{id}` abrufbar, und der Antwortkopf `Retry-After` sagt dem Aufrufer, wann die nächste Abfrage sinnvoll ist. Damit ist die Zeitgrenze der Verbindung entkoppelt von der Laufzeit der Arbeit.

Der Zustand `running` braucht dabei mehr als ein Wort. Ein Aufrufer, der nur „läuft“ sieht, kann nach zehn Minuten nicht zwischen Fortschritt und Stillstand unterscheiden. Ein Feld mit dem zuletzt abgeschlossenen Schritt und dessen Zeitstempel kostet nichts und beantwortet die einzige Frage, die während des Wartens gestellt wird.

### Zeitgrenzen auf drei Ebenen

Eine einzige Zeitgrenze für den gesamten Lauf ist zu grob, weil sie zwei völlig verschiedene Störungen gleich behandelt. Nötig sind drei, und jede fängt etwas anderes.

|  |  |
| --- | --- |
| Je Werkzeugaufruf | Fängt das hängende Fremdsystem. Ohne sie blockiert ein einziger Aufruf den ganzen Lauf bis zur obersten Grenze. |
| Je Runde | Fängt den Modellaufruf, der nicht antwortet, und begrenzt den Anteil einer einzelnen Runde an der Gesamtzeit. |
| Je Lauf | Fängt den Fall, dass viele schnelle Runden zusammen zu lange dauern — der Rundendeckel greift dann noch nicht, die Zeit ist aber weg. |

Das typische Symptom für die fehlende erste Ebene: Ein Lauf hängt 29 Minuten an einem einzigen Aufruf und wird dann von der 30-Minuten-Grenze beendet. Das typische Symptom für die fehlende dritte: Ein Lauf mit sechzig schnellen Runden ist nach vierzig Minuten immer noch beschäftigt, weil keine einzelne Runde je auffällig war.

> **Merksatz:** Jede Grenze braucht einen **unterscheidbaren** Grund beim Greifen. Ein Lauf, der nur „Zeitüberschreitung“ meldet, sagt nicht, ob ein Fremdsystem hing oder die Aufgabe zu groß war — und das sind zwei verschiedene Untersuchungen.

### Das Kostenmodell der Schleife

Die Kosten eines Agenten hängen an der Rundenzahl, und zwar überproportional. Der Grund liegt in der Mechanik: Der Verlauf **akkumuliert fortschreitend**, frühere Runden bleiben vollständig erhalten, und jede Runde schickt alles Bisherige erneut als Eingabe.

### Wo die Tokens tatsächlich hingehen

Ein Agent braucht im Schnitt neun Runden. Systemprompt und Werkzeugdefinitionen sind zusammen 4.000 Tokens. Jede Runde fügt rund 1.000 Tokens Werkzeugergebnis hinzu. Die Ausgaben sind kurz.

**Anforderungen**

- Die Eingabetokens je Aufgabe beziffern
- Die Summe in Treiber zerlegen
- Je Treiber die passende Maßnahme benennen

**Schritte**

- Fester Vorspann: 4.000 Tokens mal neun Runden ergibt 36.000 Tokens — unabhängig davon, was der Agent tut.
- Wachsender Verlauf: Runde k trägt k mal 1.000 Tokens, über neun Runden also rund 45.000 Tokens.
- Summe: etwa 81.000 Eingabetokens statt der oft geschätzten 5.000 — Faktor sechzehn, nicht Faktor neun.
- Erster Treiber, der feste Vorspann, macht 44 Prozent aus. Er ist stabil und damit ein **Caching-Problem**.
- Zweiter Treiber, der wachsende Verlauf, macht 56 Prozent aus. Er ist veränderlich und damit ein **Kontext-Problem** — Verdichtung, Verdrängung, kleinere Rückgaben.
- Dritter Hebel, der in der Rechnung nicht sichtbar ist: die Rundenzahl selbst. Eine Runde weniger spart überproportional, weil sie den Verlauf für alle folgenden verkürzt.

**Merksatz:** Vor jeder Optimierung steht die Zerlegung. Wer am Verlauf spart, obwohl der Vorspann 44 Prozent trägt, arbeitet an der kleineren Hälfte.

### Präfix-Caching, präzise

Für den festen Vorspann gibt es einen Mechanismus mit klaren Regeln — und er ist eine der wenigen Stellen, an denen sich Kosten ohne inhaltliche Abstriche senken lassen.

|  |  |
| --- | --- |
| Preisverhältnis | Ein Cache-Schreibvorgang kostet etwa das 1,25-fache des normalen Eingabepreises, ein Cache-Lesevorgang etwa ein Zehntel davon. Der Schreibaufschlag ist beim zweiten Treffer wieder eingespielt. |
| Reihenfolge | Der Präfix umfasst Werkzeuge, Systemanweisung und Nachrichten — in dieser Reihenfolge. Eine Änderung auf einer Ebene entwertet diese und alle folgenden. |
| Haltepunkt | Er gehört an den **letzten Block, der über die Anfragen hinweg identisch bleibt**. Hinter einem veränderlichen Block gesetzt, greift er nie. |
| Mindestlänge | Unterhalb einer modellabhängigen Mindestzahl an Tokens wird nichts zwischengespeichert — ohne Fehlermeldung. |

Der Fehler, der das Caching in der Praxis am häufigsten wirkungslos macht, folgt aus der zweiten und dritten Zeile: Ein Zeitstempel, ein Nutzername oder eine je Lauf sortierte Werkzeugliste **vor** dem Haltepunkt erzeugt bei jeder Anfrage einen anderen Hash. Das Caching ist dann eingeschaltet, erscheint in der Konfiguration und taucht in der Rechnung nicht auf.

> **Preis der richtigen Wahl:** Ein cachefähiger Vorspann muss **stabil** sein. Damit wird jede Änderung an Systemanweisung oder Werkzeugliste teurer als vorher: Sie entwertet den Cache für alle laufenden Sitzungen. Kostenersparnis wird hier mit Änderungsträgheit bezahlt.

Ob der Cache greift, ist keine Vermutungsfrage: Die Nutzungsangabe jeder Antwort weist die Eingabe getrennt aus — als `input_tokens`, `cache_read_input_tokens` und `cache_creation_input_tokens`. Bleiben die beiden hinteren Werte über viele Anfragen hinweg bei null, ist das Caching eingeschaltet und wirkungslos. Diese drei Zahlen gehören in die Telemetrie, nicht in eine einmalige Stichprobe.

### Modell-Routing je Schritt

In einer Agentenschleife laufen selten gleichartige Runden. Eine Klassifikation eingehender Anfragen, eine Feldextraktion aus einem Dokument und die eigentliche Planungsentscheidung stellen sehr verschiedene Anforderungen — und werden meist mit demselben Modell bedient.

- **Klassifikation** — enger Ausgaberaum, klare Kriterien. Der Fall, in dem ein kleineres Modell am ehesten trägt.
- **Extraktion** — strukturiert, prüfbar gegen ein Schema. Fehler sind erkennbar, also ist ein Versuch mit einem kleineren Modell risikoarm.
- **Planung und Werkzeugwahl** — offener Ausgaberaum, Fehler wirken sich über den ganzen Lauf aus. Hier kostet ein schwächeres Modell mehr, als es spart.
- **Zusammenfassung am Ende** — mittlere Anforderung, aber hohe Sichtbarkeit gegenüber Nutzenden.

Der Preis dieser Aufteilung wird selten mitgerechnet: Zwei Modelle in einem Lauf heißen zwei Präfixe, zwei Cache-Bereiche und zwei Verhaltensweisen, die bei jeder Änderung getrennt geprüft werden müssen. Bei einem Lauf mit neun Runden, von denen zwei klassifizieren, ist die Ersparnis überschaubar und der Prüfaufwand verdoppelt.

### Nebenläufigkeit im Lauf

Innerhalb eines Laufs sind viele Schritte unabhängig voneinander und werden trotzdem nacheinander ausgeführt, weil die Schleife von Natur aus sequenziell ist. Wo Unabhängigkeit besteht, ist gleichzeitiges Aufrufen der billigste Latenzgewinn, den es gibt.

Die Bedingung ist echte Unabhängigkeit, und sie ist enger als sie aussieht. Zwei lesende Abfragen gegen verschiedene Systeme sind unabhängig. Zwei Schreibvorgänge gegen dasselbe Objekt sind eine Wettlaufsituation. Ein Schreibvorgang und eine anschließende Prüfung sind eine Kette, auch wenn sie technisch gleichzeitig startbar wären.

Nebenläufigkeit im Lauf ist außerdem nur eine Hälfte der Frage. Die andere ist die Nebenläufigkeit **zwischen** Läufen: Fünf gleichzeitige Läufe mit je vier parallelen Aufrufen erzeugen zwanzig gleichzeitige Anfragen an dasselbe Zielsystem. Beide Ebenen müssen zusammen gedeckelt werden, sonst multiplizieren sie sich.

### Die Grenze setzt das schwächste Glied

Der klassische Fall: Ein Agentendienst startet nachts einen Stapel von 5.000 Aufträgen. Jeder ruft ein internes Altsystem auf, das etwa zwanzig gleichzeitige Verbindungen verträgt. Ohne Steuerung fällt das Altsystem in den ersten Sekunden aus, und alle 5.000 Aufträge scheitern.

- **Gleichzeitigkeit begrenzen** — nicht die Zahl der Aufträge, sondern die Zahl gleichzeitiger Aufrufe je Zielsystem. Die Zahl kommt vom Zielsystem, nicht vom Wunsch.
- **Warteschlange statt Ablehnung** — Aufträge über der Grenze warten, statt zu scheitern. Der Stapel dauert länger und läuft durch.
- **Rückstau nach oben melden** — wenn die Warteschlange wächst, muss die Annahme neuer Aufträge bremsen, sonst wächst sie unbegrenzt.
- **Schutzschalter** — bei anhaltenden Fehlern eines Zielsystems die Aufrufe aussetzen, statt es mit Wiederholungen weiter zu belasten.

Der dritte Punkt ist der, der am häufigsten fehlt. Eine Grenze ohne Rückstau verschiebt das Problem nur: Statt eines überlasteten Altsystems hat man eine Warteschlange, die schneller wächst als sie abgearbeitet wird, und einen Speicherverbrauch, der irgendwann den Agentendienst selbst trifft.

Bemerkenswert ist, wie sich die Zahl herleitet. Sie kommt nicht aus einem Lasttest des Agentendienstes, sondern aus der Kapazität des Zielsystems — und die steht selten in einer Dokumentation. Sie ergibt sich aus dem Verbindungspool, der Zahl der Arbeitsprozesse oder einer Lizenzgrenze, und sie ist oft nur durch Nachfragen zu erfahren. Wer sie schätzt statt sie zu erfragen, hat eine Grenze mit derselben Verlässlichkeit wie keine.

### Budgets, die erzwungen werden

Kosten begrenzt man nicht dort, wo sie entstehen, sondern dort, wo sie durchgesetzt werden können. Eine Bitte im Systemprompt, effizient zu arbeiten, ist keine Grenze — sie ist eine Formulierung, die im Fehlerfall genau nichts tut.

**Kurzcheck:** Eine fehlkonfigurierte Kundenintegration hat einen Agenten über einen Tag in eine Werkzeugschleife getrieben und eine hohe Rechnung erzeugt. Die einzige Kostenkontrolle war ein Hinweis im Systemprompt. Was baut ihr ein?

- [x] Harte Obergrenzen je Aufgabe für Runden, Werkzeugaufrufe und Tokens, durchgesetzt je Mandant
- [ ] Ein Kostenalarm, der ab einer Tagesschwelle das Betriebsteam benachrichtigt
- [ ] Ein kleineres Modell für alle Runden, damit eine Schleife weniger kostet
- [ ] Eine Erkennung, die wiederholte identische Werkzeugaufrufe abbricht

> Die Grenze liegt außerhalb des Modells und wirkt unabhängig von dessen Verhalten. Die Durchsetzung je Mandant verhindert, dass ein Kunde das Budget aller anderen verbraucht.

### In welcher Reihenfolge man misst

Fast jede Optimierung an dieser Stelle wird an der falschen Stelle begonnen, weil sie am zuletzt gelesenen Artikel ansetzt statt an der eigenen Verteilung. Die Reihenfolge unten kostet einen Tag und spart Wochen.

Rundenzahl je Aufgabe messen — Mittelwert und oberes Perzentil, nicht nur den Mittelwert → Eingabetokens in festen Vorspann und wachsenden Verlauf zerlegen → **Prüfen, ob der Vorspann tatsächlich stabil ist und der Cache greift** → Erst danach über Modellwahl und Nebenläufigkeit entscheiden

Der hervorgehobene Schritt ist der, der am häufigsten übersprungen wird und am häufigsten die Antwort enthält. Ein aktiviertes, aber nicht greifendes Caching sieht in jeder Konfiguration richtig aus — sichtbar wird es nur daran, dass die Anteile für Cache-Lesen und Cache-Schreiben in der Nutzungsstatistik bei null liegen.

Das obere Perzentil im ersten Schritt ist ebenfalls kein Detail. Ein Agent mit im Mittel fünf Runden und einem oberen Zehntel bei dreißig hat zwei verschiedene Kostenprofile — und der Deckel gehört an die Verteilung, nicht an den Mittelwert.

### Was der Check prüft

- Ein Symptom der richtigen Zeitgrenzenebene zuordnen.
- Eine Kostenabweichung erklären und in ihre Treiber zerlegen.
- Ein Interaktionsmodell wählen, das zur Laufzeitverteilung passt.
- Eine Anfragestruktur lesen und die Stelle finden, an der der Cache-Präfix bricht.
- Laufzustand so ablegen, dass ein Neustart nicht bei null beginnt.
- Modelle je Schritt zuordnen und den Prüfaufwand der Aufteilung mitrechnen.
- Echte Unabhängigkeit im Lauf von scheinbarer unterscheiden.
- Eine Lastgrenze am schwächsten Glied setzen und den Rückstau mitdenken.
- Ein Budget an der Stelle durchsetzen, an der es nicht umgangen werden kann.

Der gemeinsame Nenner: Laufzeit und Kosten eines Agenten sind keine Eigenschaften des Modells, sondern der Umgebung, in die man ihn stellt. Jede der neun Entscheidungen fällt außerhalb des Prompts — und jede lässt sich vorher messen statt nachher erklären.

## Quellen

- Anthropic — Context windows — https://platform.claude.com/docs/en/build-with-claude/context-windows
- Anthropic — Prompt caching — https://platform.claude.com/docs/en/build-with-claude/prompt-caching
- Anthropic Engineering — Effective harnesses for long-running agents — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
- Anthropic — Memory tool — https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool
- OWASP GenAI Security Project — LLM10:2025 Unbounded Consumption — https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/