Cloud Intelligence™
Mehr Tokens, weniger Geld: Warum Token-Zahlen die Kosten von KI-Agenten auf den Kopf stellen
Ein eintägiger Vergleich von sechs Agent-Workloads in einem einzigen Account zeigte: Nicht das Token-Volumen, sondern die Compute-Kosten entschieden, welche am günstigsten waren.
Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.
Alle Zahlen stammen aus Live-Dashboard-Screenshots eines DoiT-Sandbox-Accounts und wurden nicht anhand einer Preisliste modelliert.
Mehr Tokens, weniger Geld: Warum Token-Zahlen die Kosten von KI-Agenten auf den Kopf stellen
TL;DR: Token-Zahlen und KI-Agenten-Kosten können in entgegengesetzte Richtungen zeigen. In einer Live-AWS-Sandbox waren am 15.08.2026 die drei Agenten mit den meisten Tokens die drei günstigsten im Betrieb – und die drei Agenten mit den wenigsten Tokens die drei teuersten: eine vollständige Umkehrung. Der Grund ist Compute, nicht Tokens: Jeder Agent läuft als eigener, dauerhaft laufender Fargate-Service, und Fargate machte bei den drei Workloads mit vollständiger Ressourcen-Aufschlüsselung 57 bis 80 % der Tageskosten aus – und nur 26 % bei einem vierten, leichteren Workload. Der AWS Cost Explorer kann Kosten pro Agent gar nicht anzeigen; er fasst alle Agenten in einer einzigen Zeile auf Service-Ebene zusammen. Erst eine Ressourcen-Aufschlüsselung pro Workload macht das Ranking hinter der Rechnung sichtbar.
Wer die Kosten von KI-Agenten nach Token-Verbrauch rankt, rankt sie womöglich in genau der falschen Reihenfolge.
Am 15.08.2026 (UTC), einem abgeschlossenen Tag in unserem Account
doit-apj-attribute-sandbox in us-east-1, waren die drei Agenten mit dem
höchsten Token-Verbrauch einer Anwendung zugleich ihre drei günstigsten – und die
drei Agenten mit dem niedrigsten Token-Verbrauch ihre drei teuersten. Der
Token-Abstand zwischen diesen Gruppen beträgt das Zweieinhalbfache – und zwar
entgegengesetzt zu den Dollarbeträgen. Rundungseffekte in der Anzeige reichen bei
weitem nicht aus, um das zu erklären.
Jede Dollar- und Token-Angabe unten stammt direkt aus fünf Screenshots dieses Sandbox-Accounts: einem Live-Report aus dem AWS Cost Explorer und vier Live-Ansichten aus DoiT Attribute. Keine davon ist anhand einer Preisliste modelliert. Die Prozentwerte und Pro-Million-Raten sind unsere eigene Rechnung auf Basis der angezeigten Zahlen – dort, wo sie erscheinen, entsprechend gekennzeichnet – und für die Cost-Explorer-Spalte gilt dessen eigener Hinweis zu "estimated charges". Ein sechstes Bild weiter unten im Beitrag ist ein illustratives Architekturdiagramm, kein Dashboard-Screenshot.
Was der AWS Cost Explorer über KI-Agenten-Kosten nicht verrät
Beginnen wir mit dem AWS Cost Explorer für diesen Tag: tägliche Granularität, gruppiert nach Service, amortisierte Kosten.
Die Spalte 2026-08-15:
Total costs $9.98Elastic Container Service $5.99Claude Haiku 4.5 (Bedrock Edition) $2.24VPC $1.01Claude Opus 5 (Bedrock Edition) $0.70Korrekt – und für diese Frage nutzlos. Alle Agenten der Anwendung teilen sich diese
eine Fargate-Zeile mit $5.99 und diese eine Haiku-Zeile mit $2.24. Die Rechnung
hat eine Service-Dimension und eine Account-Dimension. Eine Agenten-Dimension hat
sie nicht – sie kann Agenten also überhaupt nicht ranken, in keiner Richtung.
Beachten Sie die Fußnoten des Reports selbst: Datumsangaben sind in UTC, und Zahlen aus dem laufenden Abrechnungszeitraum sind als Schätzung gekennzeichnet.
Die Kosten-Umkehrung bei KI-Agenten
Derselbe Tag, in Attribute auf Workload-Ebene, gefiltert auf die
luminara-*-Workloads des Sandbox-Accounts:
Die in dieser Ansicht ausgewiesene Summe Cost (1 Day) $8.8 ist die Summe der
sieben hier gezeigten luminara-*-Workloads, gefiltert auf diesen einen Account.
Sie ist nicht mit der Cost-Explorer-Summe von $9.98 oben vergleichbar, die
sämtliche Kosten des Accounts umfasst – nicht nur die Fargate- und Modell-Ausgaben
dieser sieben Workloads.
Liest man die sechs luminara-*-Orchestrierungs- und Spezialisten-Workloads aus
dieser Liste ab:
| Workload | Tokens | Kosten | Token-Rang | Kosten-Rang |
|---|---|---|---|---|
luminara-orchestrator |
125.75K | $1.48 | 4 | 1 |
luminara-chain |
123.73K | $1.48 | 5 | 1 |
luminara-conditional |
115.27K | $1.46 | 6 | 3 |
luminara-route |
315.01K | $1.23 | 1 | 4 |
luminara-sites |
265.49K | $1.16 | 2 | 5 |
luminara-dining |
169.64K | $1.07 | 3 | 6 |
Die Gruppierung ist eine saubere Umkehrung. Die drei Workloads mit den wenigsten
Tokens sind die drei teuersten, die drei Workloads mit den meisten Tokens die drei
günstigsten. Das deutlichste Einzelpaar ist luminara-route gegen
luminara-orchestrator: 2,5-mal so viele Tokens – und an diesem Tag $0.25 weniger.
Die drei teuersten liegen nur $0.02 auseinander, ihre interne Reihenfolge ist bei dieser Anzeigegenauigkeit also nicht aussagekräftig. Die Umkehrung auf Gruppenebene ist weit größer als diese Spanne.
Ist Ihr Dashboard ein Token-Zähler, sieht diese Anwendung so aus, als werde sie von
luminara-route dominiert – tatsächlich der günstigste der sechs Workloads.
Warum Compute, nicht Tokens, das Kosten-Ranking von KI-Agenten entscheidet
Jeder luminara-*-Agent läuft als eigener, dauerhaft laufender ECS-Fargate-Service,
der für die Inferenz Bedrock aufruft. Dieser strukturelle Umstand ist der Grund,
warum es überhaupt eine Fargate-Zeile getrennt von der Modell-Zeile gibt: Fargate
rechnet bereitgestelltes Compute über die Zeit ab, Bedrock rechnet pro verbrauchtem
Token ab – zwei voneinander unabhängige Kostenachsen.
- Der Client sendet eine Anfrage an den ECS-Fargate-Service des Agenten.
- Der Fargate-Service führt den Agenten-Loop aus und ruft Amazon Bedrock für die LLM-Inferenz auf.
- Bedrock liefert die Modellantwort an den Fargate-Service zurück.
- Nur bei
luminara-toolcallruft der Fargate-Service das Bedrock AgentCore Gateway auf, um Tools auszuführen. - Das Gateway verteilt die Aufrufe auf drei Lambda-Funktionen hinter vier Tools.
- Nur bei
luminara-orchestratorschreibt der Fargate-Service Audit-Events in die SQS-Queueluminara-trajectory-audit. - Der Fargate-Service liefert die finale Antwort an den Client zurück.
Attribute schlüsselt jeden Workload nach seinen Ressourcen auf. Die Drill-downs der beiden Extreme erklären die Umkehrung.
luminara-orchestrator — Total resources cost: $1.48 (1 - 3 Out of 3)
luminara-poc EC2-ECS $1.18 20%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.30 125.75K Tokens 13%luminara-trajectory-audit AWSQueueService $0.00 --
luminara-route — Total resources cost: $1.23 (1 - 2 Out of 2)
luminara-poc EC2-ECS $0.70 12%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.53 315.01K Tokens 24%luminara-route gibt tatsächlich mehr für das Modell aus: $0.53 gegenüber
$0.30. Geschlagen wird der Workload trotzdem – denn die Fargate-Zeile des
Orchestrators liegt bei $1.18, die von route bei $0.70.
Die Prozentwerte in diesen beiden Screenshots (20%, 13%, 12%, 24%) sind
die Resource Accountability-Metrik von Attribute pro Ressourcen-Zeile, kein
Anteil an den Workload-Kosten; sie sind so wiedergegeben, wie sie angezeigt werden.
Die Fargate-Anteile unten sind unsere eigene Rechnung auf Basis der Dollarsummen –
eine andere Zahl.
Berechnet man die Anteile aus diesen Zahlen:
| Workload | Fargate | Modell | Fargate-Anteil |
|---|---|---|---|
luminara-orchestrator |
$1.18 | $0.30 | 80 % |
luminara-route |
$0.70 | $0.53 | 57 % |
Compute macht in beiden Fällen den Großteil der Tageskosten aus – und ist die Variable, die das Ranking entscheidet. Tokens sind der kleinere Posten, den ein Token-basiertes Dashboard für die ganze Geschichte hält.
luminara-dining schließt einen Zufall aus zwei Datenpunkten aus:
luminara-dining — Total resources cost: $1.07 (1 - 2 Out of 2)
luminara-poc EC2-ECS $0.70 12%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.38 169.64K Tokens 17%Der Workload zeigt dieselbe Fargate-Zeile mit $0.70 wie luminara-route – zwei
gleich dimensionierte Spezialisten-Services –, während der Orchestrator bei $1.18
liegt. Ein vierter Workload, luminara-toolcall, liegt mit $0.24 Fargate bei
$0.93 Tageskosten, also 26 %, am unteren Ende desselben Spektrums. Die
Ressourcen-Aufschlüsselung hinter dieser Zahl ist im Belegmaterial hinterlegt, wird
in diesem Beitrag aber nicht abgebildet.
Wir behaupten nicht, dass die Compute-Dominanz eine neue Erkenntnis ist. Eine
archivierte 30-Tage-Dashboard-Aufnahme bis zum 21.08.2026 hat den EC2-ECS-Anteil
von luminara-orchestrator bereits mit 71 % gemessen; wir zitieren sie nur, um
zu zeigen, dass sich dasselbe Muster in einem anderen Zeitfenster bestätigt. Neu
ist die Konsequenz. Weil der Compute-Anteil dominiert und je nach Workload-Rolle
variiert, entscheidet er das Ranking – und das Ranking, das er erzeugt, ist die
Umkehrung des Token-Rankings. Über Architekturen jenseits dieser Workloads treffen
wir keine Aussage.
Die dritte Ressource des Orchestrators, luminara-trajectory-audit, ist eine
AWSQueueService-Zeile mit $0.00. Attribute inventarisiert die Ressource auch
dann, wenn sie an diesem Tag nichts kostet – nur so erfahren Sie überhaupt, dass
dieser Agent eine Queue-Abhängigkeit hat.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Was das für das Tracking von KI-Agenten-Kosten bedeutet
Token-Zahlen sind kein Proxy für die Gesamtkosten von KI-Agenten
Sie sind ein Kosten-Proxy für die Modell-Zeile – und bei den drei Workloads, die
wir im Detail betrachtet haben, machte die Modell-Zeile zwischen 20 % und 43 % der
Tageskosten des jeweiligen Workloads aus. Jede Pro-Agent-Kostensicht, die rein auf
usage-Objekten aufbaut, wird die Agenten-Flotte falsch ranken, sobald sich die
Compute-Footprints unterscheiden – also immer dann, wenn sich Agenten in ihrer
Orchestrierungsrolle unterscheiden, etwa ein zentraler Orchestrator gegenüber enger
geschnittenen Spezialisten-Workloads.
Für das Kosten-Ranking von KI-Agenten brauchte es eine Compute-Sicht pro Workload
Clientseitiges Token-Accounting sieht Fargate überhaupt nicht. Die Rechnung sieht Fargate und fasst es in einer einzigen Zeile zusammen. Die Aufschlüsselung pro Workload oben ist der spezifische Beitrag von Attribute – und sie hat die Antwort gekippt.
Beides macht daraus kein Effizienz-Ranking. Diese Workloads erledigen unterschiedliche Aufgaben bei unterschiedlichen Anfragevolumina; gemessen werden hier Tageskosten pro Workload – nicht Kosten pro Anfrage, pro erreichtem Ziel oder pro Qualitätseinheit. Günstiger pro Tag ist nicht dasselbe wie günstiger pro Arbeitseinheit.
FAQ
Bedeutet ein höherer Token-Verbrauch höhere KI-Agenten-Kosten? Nicht unbedingt. In dieser Analyse waren die drei Agenten mit den meisten Tokens die drei günstigsten im Betrieb, die drei Agenten mit den wenigsten Tokens die drei teuersten. Das Token-Volumen bildet nur die Modell-Zeile ab, nicht die Gesamtkosten des Agentenbetriebs.
Warum kann der AWS Cost Explorer keine Kosten pro KI-Agent anzeigen? Der Cost Explorer gruppiert nach Service und Account, nicht nach Agent. Alle Agenten einer Anwendung teilen sich dieselben Fargate- und Bedrock-Positionen; die Rechnung hat schlicht keine Dimension, um Kosten pro einzelnem Agenten aufzuteilen.
Was entscheidet die Kosten von KI-Agenten, wenn nicht die Tokens? Compute. Bei den drei Workloads mit vollständiger Ressourcen-Aufschlüsselung machte die Fargate-Compute-Zeile 57 bis 80 % der Tageskosten aus, gegenüber 20 bis 43 % für die Modell-Zeile; beim vierten, leichteren Workload lag der Fargate-Anteil bei nur 26 %. Die Kosten variieren mit der Orchestrierungsrolle, nicht mit der Zahl der verbrauchten Tokens.
Wie misst man Kosten pro KI-Agent auf gemeinsam genutzter Infrastruktur? Indem man jeden Workload in seine zugrundeliegenden Ressourcen aufschlüsselt – Compute, Modellaufrufe und alle weiteren abgerechneten Ressourcen wie etwa eine Queue –, statt sich auf Token-Zahlen oder eine zusammengefasste Rechnungsposition zu verlassen. Attribute tut genau das auf Workload-Ebene, auf Basis von Laufzeitdaten statt Tags.
Ist eine tokenbasierte Kostenschätzung für agentische KI-Systeme zuverlässig? Nicht für sich allein. Tokens sind nur ein Proxy für die Modell-Zeile. Eine reine Token-Sicht kann Workloads falsch ranken, wenn sich deren Compute-Kosten unterscheiden – so wie bei den sechs hier gemessenen Workloads.
Wer KI-Agenten-Kosten richtig erfassen will, braucht eine Compute-Sicht pro Workload, keinen Token-Zähler.
