Die Kosten für den Betrieb eines AI-Agenten: Bepreisen Sie den gesamten Loop, nicht die Tokens

Die Kosten für den Betrieb eines AI-Agenten werden selten vom Modell dominiert. Bei den Agenten, die wir konzipieren und bauen, sind die größten Posten die Tool-Calls, die um das Modell herum liegen (Suche, Scraping, Datenenrichment, E-Mail-Verifizierung), die Retries, die diese Tools erneut abrechnen, sowie das Hosting und Tracing, das Sie brauchen, bevor Sie dem System einen unbeaufsichtigten Betrieb zutrauen. Wenn Sie eine Zahl wollen, die Sie vor einem Vorstand vertreten können, bepreisen Sie den gesamten Loop pro abgeschlossener Aufgabe und behandeln Sie den Preis pro Million Tokens als einen von sechs Inputs.

Was eine einzelne Agenten-Aufgabe tatsächlich kostet

Nehmen wir ein einfaches Beispiel: ein Agent, der eingehende Leads qualifiziert. Ein einzelner Durchlauf könnte die Website des Interessenten über eine Scraping-API abrufen, zwei oder drei Websuchen durchführen, Unternehmensdaten von einem Enrichment-Anbieter abrufen, eine E-Mail-Adresse verifizieren und drei oder vier Modellaufrufe tätigen, um zu planen, zu extrahieren, zu entwerfen und zu prüfen. Jeder dieser Schritte ist ein abgerechnetes Ereignis. Das Modell ist wahrscheinlich das Einzige, das Sie bepreist haben.

Die vollständige Stückliste für eine Aufgabe sieht meist so aus:

• Modell-Tokens, aufgeteilt in Input, Output und gecachten Input, über jeden Aufruf im Loop
• Tool- und API-Aufrufe, jeweils mit eigenem Preis pro Anfrage oder einer Seat-Lizenz mit Kontingent
• Retries und erneute Durchläufe, verursacht durch Tool-Timeouts, fehlerhafte Modellausgaben oder Rate-Limits
• Infrastruktur: Queue, Worker, Datenbank, Vector Store, falls genutzt
• Observability: Tracing-Spans und Log-Aufbewahrung, oft pro Ereignis bepreist
• Zeit für menschliche Überprüfung für den Anteil an Aufgaben, der markiert wird

Die Besonderheit bei Agenten, im Gegensatz zu einer festen Pipeline, ist, dass der Agent selbst entscheidet, wie viele Tool-Calls er macht. Ihre Kosten pro Aufgabe sind eine Verteilung, keine feste Zahl. Zwei Aufgaben, die von außen identisch aussehen, können sich in den Kosten um ein Vielfaches unterscheiden, weil die eine fünfmal gesucht hat und die andere nur einmal.

Warum Tool-Calls schneller wachsen als Tokens

Die Tokenpreise sind stetig gefallen, und Sie können sie mit Prompt-Caching und Batch-Processing weiter senken. Anthropic dokumentiert beide Möglichkeiten auf seiner Preisseite. Die Preise pro Anfrage für Such-, Scraping- und Enrichment-APIs entwickeln sich nicht auf diese Weise. Sie werden pro Aufruf abgerechnet, für den maschinellen Verbrauch kalkuliert, und der Agent ruft sie wiederholt auf, wo ein Mensch nur eine Seite überflogen hätte.

Der Markt bewegt sich in dieselbe Richtung. Brave hat kürzlich angekündigt, dass seine Search API über das x402-Protokoll agentenfähige Zahlungen akzeptiert. Das ist ein Tool-Anbieter, der explizit für Agenten konzipiert, die pro Aufruf bezahlen, ohne dass ein Mensch im Loop ist. Erwarten Sie, dass mehr Anbieter Ihres Agenten so abrechnen werden. Das ist praktisch für den Agenten und gefährlich für das Budget, wenn Sie es nicht begrenzen.

Caching hilft nur auf der Modellseite. Das Modell liest Ihren System-Prompt einmal, und der Cache fängt die Wiederholungen ab. Ein externer API-Aufruf wird niemals gecacht, es sei denn, Sie bauen diesen Cache selbst, mit einem sinnvollen Schlüssel nach Domain, Query oder Datensatz und einer vernünftigen Ablaufzeit.

Was wir bei unserer eigenen Outreach-Engine gelernt haben

Wir betreiben intern ein Outreach-Tool, das die Website jedes Interessenten scrapt und für jedes Unternehmen eine maßgeschneiderte E-Mail schreibt. Die erste wirkliche Design-Frage waren die Grenzkosten pro Interessent, da sowohl der Preis pro gescrapter Seite als auch der Modellpreis pro Aufruf mit der Liste skalierten. Am Ende haben wir Firecrawl selbst gehostet und ein lokales Modell betrieben, sodass die Grenzkosten pro Interessent größtenteils aus bereits bezahlter Compute bestehen. Die zweite Erkenntnis war weniger offensichtlich: Ein einzelner Aufruf, der die Fakten extrahiert und die E-Mail in einem Durchgang entwirft, schlug eine mehrstufige Chain sowohl bei Kosten als auch bei Qualität. Weniger Aufrufe bedeuteten weniger Fehlerquellen, was weniger Retries bedeutete, und genau dort hatte die Chain still und leise Geld verbraucht. Das allgemeine Muster haben wir in Single Call vs. Agent Chains ausgeführt.

Der Retry-Multiplikator

Retries sind der Posten, den niemand einplant. Eine Scraping-API läuft in einen Timeout, das Modell gibt JSON mit einem überflüssigen Komma zurück, bei der dritten Suche greift ein Rate-Limit. Jeder Retry rechnet alles innerhalb des Loops, den er neu startet, erneut ab. Wenn Ihre Retry-Policy die gesamte Aufgabe umschließt statt nur den fehlgeschlagenen Schritt, kann ein einziges instabiles Tool die Kosten dieser Aufgabe verdreifachen.

Zwei Metriken erkennen das frühzeitig. Die erste ist die Anzahl der Tool-Calls pro abgeschlossener Aufgabe, erfasst als Verteilung mit ihrem Tail, nicht nur als Mittelwert. Die zweite ist die Anzahl der Versuche pro abgeschlossener Aufgabe, die zeigt, wie oft der Loop neu gestartet wurde. Wenn der Tail einer der beiden wächst, wächst Ihre Rechnung, bevor es Ihre Dashboards zeigen. Harte Obergrenzen für beide, im Code durchgesetzt und nicht nur im Prompt, sind die mit Abstand günstigste Kontrolle. Ebenso wichtig ist es, kostenpflichtige Aktionen idempotent zu machen, damit ein erneuter Durchlauf sie nicht wiederholt. Das haben wir in AI-Agent Duplicate Actions und Idempotency behandelt.

Fixkosten, die klein wirken, bis man herunterskaliert

Eine Queue, zwei Worker, eine Postgres-Instanz und eine Tracing-Plattform sind in absoluten Zahlen günstig. Verteilt auf ein paar Tausend Aufgaben pro Monat sind sie fast kostenlos. Verteilt auf zweihundert Aufgaben pro Monat können sie pro Aufgabe mehr kosten als alle API-Aufrufe zusammen. Tracing-Plattformen, die pro Span abrechnen, sind die extremste Ausprägung davon: Ein Agent mit zwölf Schritten erzeugt zwölf Spans pro Aufgabe, zuzüglich Retries.

Welches Regime bei Ihnen vorliegt, bestimmt den Großteil Ihrer Architektur. Bei geringem Volumen ist eine Managed-Agent-Runtime, die pro Run abrechnet, oft günstiger als der Betrieb eines eigenen Stacks, und die Fixkosten verschwinden in der Marge eines anderen Anbieters. Bei hohem Volumen dreht sich die Rechnung, und Self-Hosting der aufwendigen Tools beginnt sich zu lohnen. Die Trade-offs sind in Managed vs. selbst gehostete Agent-Runtimes dargelegt.

So schätzen Sie, bevor Sie bauen

Sie können sich schon vor dem ersten Code einer vernünftigen Bandbreite annähern, sofern Sie die Vorarbeit auf Papier erledigen:

1. Schreiben Sie den Loop als Liste von Aufrufen auf. Notieren Sie für jeden Schritt den Anbieter und die erwartete Spannweite an Aufrufen pro Aufgabe (Minimum, typisch, Worst Case).
2. Bepreisen Sie jeden Schritt zum Listenpreis. Markieren Sie, welche pro Aufruf abgerechnet werden, welche per Seat-Lizenz mit Kontingent und welche fix monatlich sind.
3. Multiplizieren Sie mit der erwarteten Anzahl an Versuchen. Wählen Sie für den Piloten eine ehrliche Retry-Annahme und ersetzen Sie sie innerhalb der ersten Woche durch gemessene Daten.
4. Verteilen Sie Fixkosten auf das monatliche Volumen. Infrastruktur, Tracing und etwaige Lizenzen, geteilt durch die Anzahl der abgeschlossenen Aufgaben, die Sie tatsächlich erwarten, nicht die Zahl aus dem Pitch-Deck.
5. Vergleichen Sie mit dem Wert einer abgeschlossenen Aufgabe. Wenn ein qualifizierter Lead oder ein gelöstes Ticket weniger wert ist als die Worst-Case-Kosten seiner Erzeugung, überarbeiten Sie den Loop, bevor Sie ihn bauen.

Führen Sie dann einen Piloten mit einigen hundert Aufgaben durch, bei dem die Kostenerfassung pro Schritt von Tag eins an aktiviert ist. Der Pilot dient dazu, Ihre Schätzungen aus den Schritten eins und drei zu ersetzen. Wenn Sie während des Piloten nur Tokens tracken, gehen Sie mit einer Modellrechnung, die Sie verstehen, und einer Tool-Rechnung, die Sie nicht verstehen, in den produktiven Betrieb.

Stellhebel, die die Rechnung tatsächlich bewegen

Sobald Sie gemessene Zahlen haben, stammen die meisten Einsparungen aus einer kurzen Liste:

• Schritte zusammenlegen. Jeder Modellaufruf, den Sie entfernen, entfernt auch dessen Retries und dessen Spans.
• Tool-Ergebnisse cachen. Scrapen Sie eine Domain einmal und nutzen Sie sie über mehrere Aufgaben hinweg wieder. Geben Sie Suchergebnissen für alles, was keine Nachricht ist, eine Time-to-Live im Bereich von Tagen.
• Das aufwendige Tool selbst hosten, wenn das Volumen es rechtfertigt. Scraping und kleine Extraktionsmodelle sind die üblichen Kandidaten, wie bei unserer Outreach-Engine.
• Alles batchen, was nicht dringend ist. Nächtliches Enrichment und Klassifizierung können über vergünstigte Batch-Endpoints laufen statt über Live-Aufrufe.
• Tool-Calls pro Aufgabe im Code begrenzen. Eine Prompt-Anweisung wie "höchstens dreimal suchen" ist ein Hinweis. Ein Zähler im Loop ist eine Kontrolle.
• Nach Schritt routen. Nutzen Sie ein kleines Modell für Extraktion und Formatierung und reservieren Sie das Frontier-Modell für die Beurteilungsentscheidung, gemäß der Argumentation in Kleines LLM vs. Frontier-Modell.

Beachten Sie, dass die tokenfokussierten Ratschläge in den meisten Cost-Guides für Agenten am unteren Ende dieser Liste stehen. Es lohnt sich trotzdem, sie zu befolgen, und wir pflegen dazu einen eigenen Guide zur LLM-Kostenoptimierung, aber dort geht es um die kleinere Rechnung.

Was Sie vor der Unterschrift fragen sollten

Wenn ein Anbieter oder eine Agentur Ihnen einen Tokenpreis und eine monatliche Plattformgebühr nennt, ist die Schätzung unvollständig. Fragen Sie nach den prognostizierten Kosten pro abgeschlossener Aufgabe und den Annahmen dahinter. Fragen Sie, wie viele Tool-Calls eine typische Aufgabe macht und wie der Worst Case aussieht. Fragen Sie, wie Retries begrenzt werden und ob kostenpflichtige Aktionen idempotent sind. Fragen Sie, welche Kosten fix sind und was mit den Kosten pro Aufgabe passiert, wenn Ihr Volumen nur halb so groß ist wie geplant.

Ein Team, das bereits einen Agenten im Produktionsbetrieb hatte, wird diese Fragen mit Zahlen aus einem Dashboard beantworten. Ein Team, das nur Demos gebaut hat, wird mit Tokenpreisen antworten. Wenn Sie gerade einen Agenten bepreisen und vor der Entscheidung für einen Stack eine zweite Meinung zum Loop möchten, sprechen wir.