Was kostet ein KI-Agent wirklich? Kosten je erfolgreichem Task statt Preis je Token

Ehrlich: Die meisten Kalkulationen, die uns Kunden zu Agenten-Projekten zeigen, rechnen mit dem Tokenpreis des Modells und einer geschätzten Tokenzahl je Anfrage — fertig ist die Kostenschätzung. Das Problem: Ein Agent ist kein einzelner API-Call. Er ruft Werkzeuge auf, wartet auf Antworten, plant um, wiederholt Schritte bei Fehlern und schleift die gesamte bisherige Historie durch jeden weiteren Schritt. Die Tokenzahl eines kompletten Laufs kann leicht das Zehn- bis Zwanzigfache einer einzelnen Anfrage betragen.

Dieser Artikel zeigt, warum der Tokenpreis die falsche Kennzahl ist, welche vier Faktoren die Kosten in der Praxis wirklich treiben, mit welchen Hebeln man sie senkt — und rechnet ein vollständiges Beispiel mit 1.200 Läufen im Monat durch, gegengerechnet gegen die Bearbeitungszeit eines Mitarbeiters. Die konkreten Zahlen unserer Preisseite für den Agentenbetrieb tauchen dabei mehrfach auf, weil sie den Rahmen für jede seriöse Kalkulation vorgeben.

Für Geschäftsführung und CFO ist das mehr als eine akademische Unterscheidung. Wer ein Agenten-Projekt anhand des Tokenpreises freigibt, vergleicht Äpfel mit Birnen: Der Business Case für Automatisierung steht und fällt mit der Frage, ob ein Vorgang am Ende erledigt ist oder nicht — nicht damit, wie günstig die einzelne Modellanfrage war, die dazu geführt hat. Die folgenden Abschnitte liefern das Handwerkszeug, um diese Unterscheidung im eigenen Projekt sauber zu treffen, statt sie der Marketingfolie des Modellanbieters zu überlassen.

Warum der Preis je Million Tokens die falsche Kennzahl ist

Modellanbieter veröffentlichen Preise in Cent je Million Tokens, weil das ihre Abrechnungseinheit ist — nicht, weil sie für Ihr Business aussagekräftig wäre. Drei Gründe, warum diese Zahl in die Irre führt:

• Sie ignoriert den Overhead der Ausführung. Ein LLM-Aufruf ist bei einem Agenten nie isoliert. Tool-Calls, Zwischenschritte und wiederholtes Mitschleifen der Historie vervielfachen die tatsächlich verarbeiteten Tokens gegenüber einer einzelnen Chat-Anfrage.
• Sie sagt nichts über Erfolg. Ein günstiger Lauf, der scheitert und eskaliert werden muss, ist teurer als ein etwas teurerer Lauf, der beim ersten Versuch funktioniert — weil zur reinen Modellkosten noch Bearbeitungszeit eines Menschen hinzukommt.
• Sie verschleiert Ausreißer. Retry-Schleifen ohne Deckel können einen einzelnen Lauf auf ein Vielfaches der Durchschnittskosten treiben, ohne dass der durchschnittliche Tokenpreis das abbildet.

In der Praxis sehen wir Projekte, bei denen der reine Modellanteil unter zehn Prozent der Gesamtkosten eines Laufs ausmacht — der Rest verteilt sich auf Tool-Calls, Orchestrierung, Monitoring und eben die Fälle, die nicht beim ersten Versuch klappen.

Hinzu kommt: Modellanbieter senken ihre Token-Listenpreise in kurzen Abständen, oft im zweistelligen Prozentbereich pro Quartal. Wer seine Kalkulation auf diesen Wert stützt, baut auf einem Fundament, das sich unter ihm verschiebt — während die eigentlichen Kostentreiber im Betrieb (Kontextlänge, Tool-Call-Zahl, Erfolgsquote) von der Preisentwicklung der Anbieter weitgehend unberührt bleiben. Die Kosten je erfolgreichem Task sind die stabilere, weil selbst beeinflussbare Größe.

Kosten je erfolgreichem Task: die richtige Formel

Die Kennzahl, die tatsächlich mit Ihrem heutigen manuellen Prozess vergleichbar ist, lautet:

Diese Formel zwingt zu zwei Dingen, die viele Projekte überspringen: einer sauberen, maschinell prüfbaren Definition von "erfolgreich" — und einer laufenden Messung der Erfolgsquote, nicht nur einer einmaligen Schätzung vor dem Rollout. Genau das leistet eine Observability-Schicht mit Kostenattribution: Sie ordnet jeden Trace einem Ergebnis zu und macht die Kennzahl belastbar statt geschätzt.

Die vier Kostentreiber im Detail

In den Projekten, die wir begleiten, wiederholen sich vier Muster, die die Kosten je Lauf in die Höhe treiben — meist unbemerkt, weil sie sich erst im Betrieb zeigen, nicht im Proof of Concept.

1. Kontextlänge und das Mitschleifen der History

Jeder Schritt eines Agenten sendet in der Regel die komplette bisherige Konversation erneut an das Modell — System-Prompt, Tool-Definitionen, alle vorherigen Nachrichten und Zwischenergebnisse. Bei zehn Schritten wird der System-Prompt zehnmal mitgeschickt. Kommt RAG hinzu, wächst der Kontext um jede abgerufene Textpassage zusätzlich. Ohne Kompaktierung steigt die Tokenzahl je Lauf oft linear mit der Anzahl der Schritte statt konstant zu bleiben.

2. Tool-Call-Ping-Pong

Wenn ein Agent für eine einfache Aufgabe mehrfach zwischen Modell und Werkzeug hin- und herspringt — Anfrage, Zwischenergebnis, erneute Anfrage, Korrektur, erneuter Aufruf — vervielfacht sich sowohl die Zahl der Tool-Calls als auch die Zahl der Modellaufrufe. Ein sauber orchestrierter Lauf braucht für eine Rechnungsprüfung vielleicht fünf bis sieben Tool-Calls; ein schlecht geführter Agent kann für dieselbe Aufgabe zwanzig oder mehr produzieren, ohne dass das Ergebnis besser wird. In der Praxis entsteht dieses Muster oft, wenn ein einzelner Agent zu viele Verantwortlichkeiten in einem Schritt bündelt, statt die Aufgabe in klar abgegrenzte, orchestrierte Teilschritte aufzuteilen.

3. Retry-Schleifen ohne Deckel

Scheitert ein Tool-Aufruf oder liefert das Modell ein ungültiges Format, versuchen viele Implementierungen es automatisch erneut — teils unbegrenzt. Ohne Obergrenze kann ein einzelner hartnäckiger Fall Kosten produzieren, die dem Zehnfachen eines normalen Laufs entsprechen, bevor überhaupt jemand bemerkt, dass etwas schiefläuft. Besonders tückisch: Diese Ausreißer verschwinden in einem groben Monatsdurchschnitt fast vollständig und werden erst sichtbar, wenn die Kostenverteilung je Lauf einzeln betrachtet wird.

4. Zu große Modelle für triviale Schritte

Klassifikation, Formatprüfung oder einfache Feldextraktion werden oft mit demselben großen Modell erledigt wie die eigentliche Planung — obwohl ein kleineres, günstigeres Modell für diese Teilschritte ausreicht. Das treibt die Durchschnittskosten je Lauf nach oben, ohne die Ergebnisqualität an den kritischen Stellen zu verbessern. Häufig ist die Ursache simpel: Beim ersten Prototyp wurde ein einziges Modell für alle Schritte gewählt, weil es am schnellsten zum Ergebnis führte — und diese Entscheidung wurde beim Übergang in den Produktivbetrieb nie wieder hinterfragt.

Die Hebel, die tatsächlich wirken

Gegen die vier Kostentreiber gibt es keine Wunderlösung, aber fünf Stellschrauben, die in der Praxis messbar wirken:

Prompt-Caching mit Cache-Hit-Quote als Kennzahl

Wiederkehrende Teile des Kontexts — System-Prompt, Tool-Definitionen, stabile History-Abschnitte — lassen sich serverseitig zwischenspeichern, sodass sie nicht bei jedem Schritt neu voll berechnet werden. Die Cache-Hit-Quote sollte als feste Kennzahl im Betrieb mitlaufen, nicht nur einmalig getestet werden: Sie schwankt mit jeder Änderung am Prompt-Aufbau. In der Praxis reicht oft schon die Reihenfolge im Prompt — variable Inhalte ans Ende, stabile Blöcke an den Anfang —, um die Trefferquote spürbar zu erhöhen.

Routing klein zu groß

Triviale Teilschritte an ein kleines, günstiges Modell delegieren, nur komplexe Planungs- und Bewertungsschritte an das große Modell eskalieren. Diese Aufgabenteilung senkt die Durchschnittskosten je Lauf spürbar, ohne die Qualität an den entscheidenden Stellen zu opfern. Eine einfache Faustregel: Wenn ein Mensch die Entscheidung ohne Nachdenken in Sekunden träfe, reicht in der Regel ein kleines Modell; wenn Abwägung und Kontext nötig sind, gehört der Schritt zum großen Modell.

Kontextfenster aktiv beschneiden

Statt die komplette History unverändert mitzuschleifen, werden ältere, nicht mehr relevante Abschnitte zusammengefasst oder entfernt. Das begrenzt das lineare Wachstum der Tokenzahl über die Schritte eines Laufs hinweg. Gerade bei langlaufenden Agenten mit vielen Zwischenschritten ist das der Hebel mit dem größten Effekt, weil er nicht nur Kosten, sondern auch die Antwortzeit je Schritt reduziert.

Budget-Cap je Lauf

Ein harter Deckel für Tokens, Tool-Calls oder Euro je Lauf verhindert, dass eine Retry-Schleife oder ein hartnäckiger Fehlerfall die Kosten unkontrolliert eskalieren lässt. Erreicht ein Lauf den Cap, bricht er kontrolliert ab, statt unbegrenzt weiterzulaufen — auf unserer Preisseite ist das als Klassenmerkmal hinterlegt.

Rate-Limit je Werkzeug

Ein Rate-Limit auf Ebene des Agent Gateways begrenzt, wie oft ein einzelnes Werkzeug je Zeiteinheit oder je Lauf aufgerufen werden darf. Das kappt Tool-Call-Ping-Pong an der Wurzel, statt es erst im Nachhinein in den Traces zu entdecken. Wie diese Kontrollen technisch in eine bestehende Systemlandschaft eingebunden werden, beschreibt der Artikel zur Systemintegration von Agentic AI im Detail.

Rechenbeispiel: 1.200 Läufe im Monat

Rechenbeispiel, keine Preisliste. Die folgenden Nutzungssätze sind Kalkulationsannahmen — dieselben Platzhalterwerte, mit denen auch der Kostenrechner auf unserer Preisseite arbeitet: 0,12 € je Lauf, 0,004 € je Tool-Call, 0,90 € je Million Tokens. Sie sind noch nicht final freigegeben und dienen ausschließlich der Veranschaulichung.

Annahme: Ein mittelständisches Unternehmen lässt einen Agenten monatlich 1.200 Läufe bearbeiten — etwa Rechnungsprüfungen oder Support-Tickets — mit durchschnittlich 7 Tool-Calls je Lauf und 12.480 Tokens je Lauf. Die gemessene Erfolgsquote liegt bei 78 Prozent.

Rein rechnerisch ergibt das Kosten je Lauf von 1.681 € ÷ 1.200 = 1,40 € — die Zahl, die ein Blick in den Rechner liefert. Bei 78 Prozent Erfolgsquote haben aber nur 936 der 1.200 Läufe tatsächlich zum Ziel geführt. Kosten je erfolgreichem Task: 1.681 € ÷ 936 = 1,80 €.

Die 264 gescheiterten Läufe verschwinden nicht — sie gehen an einen Mitarbeiter zur Nachbearbeitung. Annahme: 6 Minuten Bearbeitungszeit je Fall bei einem Vollkostensatz von 45 €/Stunde, also 4,50 € je manuell bearbeiteten Fall. Das ergibt 264 × 4,50 € = 1.188 € zusätzliche Personalkosten.

Für Support-Anwendungsfälle haben wir diese Rechnung noch einmal eigens durchgespielt, mit anderen Ausgangswerten und Ticket-Typen: Support-Deflection: die Rechnung.

Vergleichstabelle: Kosten je Token, je Lauf und je erfolgreichem Task

Kennzahl	Was sie zeigt	Was sie verschweigt	Beispielwert
Preis je Mio. Tokens	Reine Modell-Inferenzkosten des Anbieters	Tool-Calls, Retries, Erfolgsquote, Personalkosten	0,90 € (Annahme)
Kosten je Lauf	Durchschnittliche Gesamtkosten inkl. Pauschale, Tools, Tokens	Ob der Lauf überhaupt zum Ziel geführt hat	1,40 €
Kosten je erfolgreichem Task	Preis für ein tatsächlich erledigtes Ergebnis, inkl. Fehlversuchen	Wenig, solange Erfolg maschinell messbar ist	1,80 € (2,39 € im Blend mit Nacharbeit)

Nur die dritte Zeile ist direkt mit dem Preis einer manuellen Bearbeitung vergleichbar — die ersten beiden dienen höchstens der internen Kostenkontrolle und dem Auffinden von Ausreißern.

Was das für Ihr Budget bedeutet

Die Betriebspauschalen von HostSpezial für den Agentenbetrieb liegen bei 690, 1.490 oder ab 3.900 € im Monat zzgl. USt., abgestuft nach Service-Klasse und Governance-Umfang — Details dazu auf der Preisseite. Diese Pauschale deckt Bereitstellung, SLA-Reaktion und Kostenattribution ab, unabhängig vom Volumen. Der nutzungsabhängige Anteil je Lauf, Tool-Call und Million Tokens kommt hinzu und ist — das sei hier wiederholt — aktuell ein Kalkulationswert, keine finale Preisliste.

Für die Budgetplanung heißt das: Bei niedrigem Volumen dominiert die Pauschale die Kosten je Task, bei hohem Volumen dominiert die Nutzung. Die Klasse Start mit 690 € lohnt sich, wenn ein einzelner Use Case mit überschaubarem Volumen automatisiert wird; die Klasse Business mit 1.490 € passt zu mehreren Use Cases mit schreibenden Werkzeugen, wie in unserem Rechenbeispiel; die Klasse Enterprise ab 3.900 € trägt sich in der Regel erst bei kritischen Prozessen mit Nachweispflichten, bei denen Failover, Governance-Retainer und 24/7-Rufbereitschaft ohnehin gefordert sind. Ob sich der Eigenbetrieb einer solchen Plattform gegenüber der Pauschale überhaupt rechnet, haben wir separat durchgerechnet: Eigenbau vs. Managed Agent Platform und ausführlicher im Vergleich Eigenbau.

Wer die Kennzahlen zunächst am eigenen Datensatz sehen will, statt sie zu schätzen, kann das im Quickstart-Sandbox-Zugang tun — kostenfrei, ohne Vorleistung, abgerechnet wird erst der produktive Betrieb. Einen Überblick über alle Schichten der Plattform, inklusive der interaktiven Systemkarte, gibt die Agentic-AI-Übersicht.

Ein Sonderfall verdient Erwähnung: Wer variable Tokenkosten grundsätzlich vermeiden will, kann Modelle auch on-premise betreiben — mit eigener oder gemieteter GPU-Hardware und planbaren Fixkosten statt nutzungsabhängiger Abrechnung. Das verschiebt die Rechnung von "Kosten je Task" zu einer klassischen Kapazitätsplanung und lohnt sich vor allem bei sehr hohem, gleichmäßigem Volumen. Für Unternehmen, die die komplette KI-Wertschöpfungskette inklusive Agentenbetrieb aus einer Hand wollen, bündeln wir das entsprechende Leistungsspektrum im KI Full Stack Providing.

Wann sich das NICHT lohnt: Grenzen der Rechnung

Die gesamte Kennzahl "Kosten je erfolgreichem Task" steht und fällt mit einer Voraussetzung: Erfolg muss sich maschinell prüfen lassen. Das ist nicht überall der Fall.

• Offene Texterstellung ohne Referenz: Bei freier Content-Erstellung, Ideenfindung oder strategischer Beratung gibt es kein objektives Richtig oder Falsch, das sich automatisch auswerten lässt. Die Erfolgsquote wird zur Schätzung, nicht zur Messung.
• Geschmacks- und Ermessensfragen: Aufgaben, bei denen zwei Menschen legitim zu unterschiedlichen, aber beide vertretbaren Ergebnissen kommen, lassen sich schlecht binär in "erfolgreich" oder "gescheitert" einteilen.
• Sehr niedriges Volumen: Bei wenigen Läufen im Monat dominiert die Betriebspauschale die Kosten je Task so stark, dass die Feinsteuerung über Kostentreiber kaum ins Gewicht fällt — hier lohnt sich eher die Frage, ob überhaupt ein Agent gebraucht wird oder ein einfacheres Skript reicht.
• Fehlende Baseline: Ohne verlässliche Zahl zur heutigen manuellen Bearbeitungszeit fehlt die Vergleichsgröße, gegen die man rechnet — dann bleibt nur eine Kosten-, aber keine Wirtschaftlichkeitsaussage.

In diesen Fällen ist die ehrliche Antwort: rechnen Sie die Kosten je Lauf, aber verzichten Sie auf die Behauptung einer belastbaren Kosten-je-Task-Kennzahl, solange kein automatisierbares Erfolgskriterium existiert. Ein Zwischenweg funktioniert manchmal: Statt binärem Erfolg/Misserfolg ein grobes, aber konsistentes Bewertungsraster einführen — etwa durch stichprobenartige menschliche Bewertung nach festen Kriterien. Das ersetzt keine echte Erfolgsmessung, macht die Kennzahl aber zumindest grob vergleichbar über die Zeit.

Häufige Fragen zu Kosten von KI-Agenten

Warum ist der Preis je Million Tokens die falsche Kennzahl für KI-Agenten?

Weil er nur die reinen Modellkosten zeigt, aber nichts über Nutzen sagt. Ein Agent mit Retry-Schleifen, langen Tool-Call-Ketten und niedriger Erfolgsquote kann trotz günstigem Tokenpreis teurer sein als einer mit höherem Tokenpreis, aber sauberer Ausführung. Aussagekräftig ist nur der Preis je erfolgreich abgeschlossenem Task.

Wie berechnet man die Kosten je erfolgreichem Task?

Man teilt die Gesamtkosten eines Zeitraums — Betriebspauschale plus Kosten für Läufe, Tool-Calls und Tokens — durch die Anzahl der Läufe, die tatsächlich zum Ziel geführt haben, nicht durch die Gesamtzahl der Läufe. Fehlversuche und Eskalationen an Menschen gehen als Kosten ein, aber nicht als Erfolg.

Was ist Prompt-Caching und warum senkt es die Kosten spürbar?

Prompt-Caching speichert wiederkehrende Teile des Kontexts serverseitig zwischen, sodass sie bei Folge-Anfragen nicht erneut voll berechnet werden. Die Cache-Hit-Quote ist die entscheidende Kennzahl: Bei guter Prompt-Struktur liegen 60 bis 90 Prozent Trefferquote drin.

Was bedeutet Routing von klein zu groß bei KI-Agenten?

Einfache Teilschritte wie Klassifikation oder Formatprüfung laufen auf einem kleinen, günstigen Modell; nur komplexe Planungs- oder Bewertungsschritte werden an ein großes Modell eskaliert. Das senkt die Durchschnittskosten je Lauf, ohne die Qualität an kritischen Stellen zu senken.

Was ist ein Budget-Cap je Lauf und wieso ist er notwendig?

Ein Budget-Cap begrenzt, wie viel ein einzelner Lauf maximal verbrauchen darf, bevor er kontrolliert abgebrochen wird. Ohne Deckel können Retry-Schleifen einen Lauf auf ein Vielfaches der Normalkosten treiben.

Wie hoch sind die Betriebspauschalen für KI-Agenten bei HostSpezial?

690, 1.490 oder ab 3.900 € im Monat zzgl. USt., je nach Service-Klasse. Hinzu kommt ein nutzungsabhängiger Anteil je Lauf, Tool-Call und Million Tokens — aktuell Kalkulationswerte, noch keine finale Preisliste. Details auf der Preisseite.

Ab wann rechnet sich ein KI-Agent gegenüber manueller Bearbeitung?

Sobald die Kosten je erfolgreichem Task inklusive Fehlversuchen und Nacharbeit unter der vollen Bearbeitungszeit eines Mitarbeiters liegen. In unserem Rechenbeispiel lag der Blend bei 2,39 € je Fall gegenüber 4,50 € bei rein manueller Bearbeitung.

Für welche Use Cases lässt sich die Kostenrechnung nicht sauber aufmachen?

Überall dort, wo Erfolg nicht maschinell prüfbar ist — etwa bei offener Texterstellung oder Aufgaben mit Geschmacksfragen ohne objektives Richtig oder Falsch. Ohne automatisierbares Erfolgskriterium fehlt der Nenner für die Kennzahl, und die Rechnung wird zur Schätzung.