Der stille Budgetkiller: Warum Agents sich von Chatbots unterscheiden

Chat ist vorhersehbar. Nutzer schickt eine Nachricht, das Modell antwortet. Ihre Kosten skalieren grob mit der Nutzung.

Agents sind anders. Sie geben einem halbautonomen Skript Zugang zu Ihrem Modellanbieter. Wenn dieses Skript in einen Fehlerzustand gerät – falsch geparste Tool-Antwort, hängt in einer Wiederholung – kann es fünfzig High-Token-Anfragen pro Minute auslösen. Ohne Nutzerbeteiligung. Ohne natürlichen Stopp.

1. Wo die Leckage entsteht

In agentenbasierten Workflows kommen überhöhte Kosten meist aus drei Quellen:

Rekursive Reasoning-Loops

Der Agent fragt das Modell immer wieder nach „Klarstellung“ zu einer Unteraufgabe, die er nicht lösen kann. Jeder Aufruf addiert Tokens und Kosten.

Token-Bloat

Agents schicken oft ihren kompletten „Speicher“ oder Notizblock in jeden Schritt. Eine 5-Schritte-Aufgabe kann ohne Limit bis zur letzten Iteration auf 32k Tokens anwachsen.

Falsches Modell für die Aufgabe

GPT-4o oder Claude 3.5 Sonnet für einfache Klassifikation zu nutzen, die ein günstigeres Modell zu einem Bruchteil des Preises erledigen könnte.

2. Eine „Agent-Firewall“ auf Anwendungsebene

Ein monatliches Limit im Provider-Dashboard ist ein reaktiver Kill-Schalter. Er schneidet alles ab, wenn das Limit erreicht wird – schlechte UX und oft zu spät.

Sie brauchen Steuerung bevor die Aufrufe den Provider erreichen:

• Max-Iterations-Limits: Harte Obergrenze für „Gedanken“ oder Aktionen pro Sitzung
• Token-Zuordnung: Jede Anfrage mit user_id oder session_id markieren, um zu sehen, welche Agent-Instanz Budget verbrennt
• Budget-Handshakes: Wenn eine einzelne Aufgabe ein Token-Limit überschreitet, günstigeres Modell oder Freigabe verlangen, bevor es weitergeht

Ziel ist es, Fehlverhalten früh zu erkennen, nicht nach dem Schaden.