AI-Agent-Kosten: Aktionspreise und Self-Hosting-Laufzeitkosten vergleichen

Kurz gesagt: Abrechnung pro Aktion bedeutet, dass Sie umso mehr zahlen, je besser Ihr Agent arbeitet. Die wahren Kosten hängen davon ab, ob die Nutzung mit dem Erfolg explodiert, von den nicht ausgewiesenen Rechnungen für Daten-Egress und Lock-in und davon, wo der Break-even beim Self-Hosting liegt.

Zum Quartalsende öffnet der CFO die Rechnung der Agent-Plattform und stutzt: Es ist das Vierfache des Budgets.

Niemand hat Geld verschwendet, ganz im Gegenteil – der Kundenservice-Agent war zu erfolgreich. Rechnet man diese Rechnung auf: Vor dem Go-live bearbeitete das Team etwa 5.000 Tickets pro Tag; nach dem Go-live des Agents stieg die Effizienz pro Kopf, und das bewältigte Volumen verdoppelte sich auf rund 10.000. Und die Plattform rechnet pro Aktion ab, denn hinter jedem bearbeiteten Ticket stecken: Kunde nachschlagen, Auftrag nachschlagen, Historie nachschlagen, Wissensdatenbank nachschlagen, Rückerstattung anstoßen, Benachrichtigung versenden – sieben, acht Aktionen mindestens. Eine grobe Rechnung: 10.000 Tickets × 7 Aktionen × 0,10 $ ≈ 7.000 $ pro Tag, rund 2,5 Millionen Dollar im Jahr. Das Budget aber war ursprünglich über den Daumen auf „5.000 Tickets, je etwas weniger Aktionen” angesetzt.

Das Ironischste daran ist: Je erfolgreicher dieses Projekt, desto erschreckender diese Rechnung. Und so ist die erste Reaktion des Vorstands nicht, die verdoppelte Effizienz zu feiern, sondern zu fragen „können wir das Nutzungsvolumen etwas drosseln” – ein Erfolg, der eigentlich ausgeweitet werden sollte, wird wegen des Abrechnungsmodells ausgebremst. Bevor der ROI sich wirklich realisiert, wird die Skalierung schon von der Kostenangst erstickt.

Zehn Cent, multipliziert mit einer Zahl, die sich aufbläht

Salesforce’ Agentforce führt die Flex-Abrechnung ein: 0,10 $ pro Aktion. Betrachtet man nur diese Zahl, ist sie so günstig, dass man die Wachsamkeit fahren lässt.

Aber genau hier muss man bei der Agent-Abrechnung am wachsamsten sein – sie bindet die Kosten an das Nutzungsvolumen, und der ganze Sinn eines Agents besteht gerade darin, autonom, hochfrequent und unermüdlich zu handeln. Und je autonomer der Agent, desto mehr Zwischenaktionen löst er aus, um eine Sache gut zu erledigen: Eine Anfrage „hilf mir, die Situation dieses Kunden aufzubereiten” steckt womöglich hinter einem Dutzend Werkzeugaufrufen, die Sie vorab weder abzählen noch leicht deckeln können. Manche Plattformen rechnen pro Token ab, was noch schwerer vorhersagbar ist als pro Aktion – bei derselben Aufgabe wird die Rechnung länger, je mehr Schritte das Modell denkt. Der Vergleich aus öffentlichen Berichten ist nicht übertrieben: Bei gleichem Verbrauch können die Jahreskosten im SaaS-Modell über 2 Millionen Dollar erreichen, während ein funktional gleichwertiges self-hosted Deployment mit Lizenz plus Infrastruktur etwa in der Größenordnung von 250.000 Dollar liegt – ein Unterschied von einer Größenordnung.

Ist nutzungsabhängige Abrechnung nicht günstiger und flexibler?

Hier muss man ernsthaft einen Einwand aufgreifen, denn in vielen Szenarien stimmt er: Nutzungsabhängige Abrechnung hat keine Vorabinvestition, wer wenig nutzt, zahlt wenig, der Anbieter übernimmt den Betrieb für Sie, und Sie zahlen nur für den erzeugten Wert – diese Logik wurde im Zeitalter des Cloud Computing immer wieder bestätigt; warum sollte sie ausgerechnet beim Agent nicht gelten?

Sie gilt, aber unter einer Voraussetzung: Jenes „Volumen”, mit dem die Kosten mitwachsen, muss von Ihrem Wert entkoppelt oder nur schwach mit ihm korreliert sein. Cloud-Speicher pro GB abzurechnen ist kein Problem, weil mehr Speicher meist ein größeres Geschäft bedeutet, das es sich leisten kann; beide laufen ungefähr synchron.

Der Agent durchbricht diese Voraussetzung. Er rechnet nach „Anzahl der Aktionen” ab, und die Anzahl der Aktionen explodiert gerade mit dem Grad der Autonomie und dem Grad des Erfolgs – je mehr Sie ihn für sich arbeiten lassen wollen und je besser er arbeitet, desto mehr Aktionen löst er aus, desto höher die Rechnung. Das wird zu einer Art Steuer auf den Erfolg: Je härter Sie optimieren (den Agent einen Schritt mehr nachschlagen, einmal mehr gegenprüfen lassen, um die Qualität zu erhöhen), desto höher der Steuersatz. Traditionelle Software rechnet pro Sitzplatz ab, so intensiv man sie auch nutzt, die Kosten sind gedeckelt; bei Abrechnung pro Aktion zahlen Sie mehr, je besser Sie es machen. Jene Intuition aus dem Cloud-Zeitalter, „nach Volumen ist fair”, versagt bei einem Ausführungskörper, der selbst unzählige Zwischenaktionen auslöst und den Sie obendrein ermuntern, mehr zu tun.

Ab welchem Nutzungsvolumen sollte man also selbst betreiben? Rechnen wir den Schnittpunkt aus

Bleiben Sie nicht bei „kommt darauf an” stehen. Mit den zwei Zahlen des CFO lässt sich der Schnittpunkt grob ausrechnen.

Auf der Self-Hosting-Seite nehmen wir an, die Jahreskosten sind fest bei rund 250.000 $ (Lizenz + Infrastruktur + ein Teil anteiliger Betriebskosten), sie ändern sich kaum mit der Anzahl der Aufrufe. Auf der Pro-Aktion-Seite sind es 0,10 $ × Anzahl der Aktionen. Setzt man beide gleich:

250.000 $ = 0,10 $ × Aktionen pro Jahr
Aktionen pro Jahr ≈ 2,5 Millionen  →  rund 6.800 Aktionen pro Tag

Das heißt: Sobald Ihre Agent-Aktionen pro Tag die Größenordnung von rund 7.000 überschreiten, beginnt die Pro-Aktion-Abrechnung teurer zu werden als Self-Hosting, und danach wird der Abstand immer größer. Zurück zu jenem CFO: Er liegt bei 70.000 Aktionen pro Tag (10.000 Tickets × 7), längst beim Zehnfachen des Schnittpunkts – genau das ist der Grund, warum die Rechnung auf 2,5 Millionen hochschoss. Sein Leid ist kein Zufall, er hätte längst selbst betreiben sollen, nur sperrte ihn das Abrechnungsmodell auf der falschen Seite ein.

Diese Rechnung können Sie direkt auf Ihre eigenen Zahlen anwenden: Multiplizieren Sie das tägliche Interaktionsvolumen Ihres Teams mit „etwa wie viele Aktionen pro Interaktion” und vergleichen Sie es mit der Größenordnung 7.000 – dann wissen Sie, auf welcher Seite des Schnittpunkts Sie liegen.

Drei Kostenmodelle, nebeneinander verglichen

Modell	Vertreter	Womit die Kosten wachsen	Vorhersagbarkeit	Wo die Daten liegen
Pro Aktion / pro Token	Agentforce Flex (0,10 $/Aktion)	Linear bis sogar überlinear mit der Aktionszahl	Schlecht, je besser genutzt, desto teurer	Anbieter-Cloud
Pro Sitzplatz	Die meisten Copilot-artigen	Mit der Personenzahl, gedeckelt, aber pro Kopf nicht niedrig	Mittel, aber entkoppelt von der Agent-Autonomie	Anbieter-Cloud
Self-hosted Runtime	ObjectStack / ObjectOS	Mit der Infrastruktur, weitgehend von der Nutzung entkoppelt	Gut, Kurve bleibt bei verdoppeltem Volumen fast unverändert	Ihre eigene Infrastruktur

Pro Sitzplatz sieht stabil aus, hat aber einen inneren Widerspruch: Der Wert des Agents besteht darin, ohne Sitzplatz große Mengen repetitiver Arbeit zu ersetzen, Sie aber zahlen weiter „pro Kopf” – die Abrechnungsdimension und die Wertdimension passen nicht zusammen. Self-Hosting tauscht hingegen die gesamte Kostenstruktur aus: Sie zahlen für die Ausführungsengine und Ihre eigene Rechenleistung; steigt das Volumen, wächst die Rechnung nicht automatisch linear mit der Zahl der Aktionen.

Erst eine kalte Dusche: Self-Hosting ist nicht überall günstiger

Nehmen Sie „40–60 % gespart” nicht als allgemeingültig. Es hat einen klar definierten Gültigkeitsbereich, jenseits dessen es nicht mehr gilt.

Jene Kopfzahl von 250.000 $ rechnet die Menschen nicht mit ein. Self-Hosting heißt, Sie brauchen jemanden, der betreibt, patcht, die Verfügbarkeit sicherstellt – haben Sie kein Plattformteam, kann diese versteckte Personalkostenposition einen Großteil des bilanziellen Vorteils auffressen und jenen Schnittpunkt nach rechts verschieben. Zudem hat es Fixkosten: Infrastruktur und Betrieb werden vorab ausgegeben, weitgehend unabhängig vom Nutzungsvolumen.

Daher ist in der Phase mit sehr kleinem, sehr niederfrequentem, rein experimentellem Volumen nutzungsabhängige Abrechnung im Gegenteil flexibler und günstiger – Sie müssen für eine fast leerlaufende Runtime kein Team unterhalten. Der Vorteil von Self-Hosting realisiert sich erst, nachdem Sie sicher in die Skalierung gehen.

Die wirklich teure Position steht nicht auf der Preisliste

Selbst auf der Seite, auf der Self-Hosting lohnender ist, unterschätzt der bloße Vergleich der Monatsrechnung das Problem. Bevor Sie das Abrechnungsmodell wählen, sollten Sie eigentlich drei Rechnungen aufmachen, von denen zwei nicht auf der Preisliste stehen:

Die Volumenrechnung: Explodieren die Kosten mit dem Erfolg? Das ist jene vierfache Rechnung des CFO – ob Ihr Volumen positiv mit dem Erfolg des Agents korreliert. Wenn ja, ist pro Aktion eine Falle.
Die Compliance-Rechnung: Der Preis dafür, dass Daten den Geltungsbereich verlassen. SaaS pro Aktion oder pro Sitzplatz bedeutet, dass Geschäftsdaten fortlaufend in die Anbieter-Cloud fließen. Unter strengeren AI- und Cloud-Souveränitätsanforderungen kann ein Datenresidenz-Verstoß teurer werden als viele Jahre Lizenz.
Die Lock-in-Rechnung: Der Preis, künftig nicht mehr wegzukommen. Wenn Geschäftsdefinition, Prozesse und Berechtigungen alle in einer bestimmten Plattform wachsen, steigen die Migrationskosten mit der Nutzungsdauer im Zinseszins. Sie glauben, für Software zu zahlen, in Wahrheit zahlen Sie ein Pfand dafür, „künftig nicht mehr wegzukommen”.

Rechnet man diese drei zusammen, ist jene oberflächliche Günstigkeit von „zehn Cent pro Aktion” schnell aufgezehrt.

Warum Self-Hosting diese Posten gleichzeitig in den Griff bekommt

Der Kern ist nur ein Satz: Sie zahlen für die Engine, die diese Geschäftsdefinition ausführt, nicht dafür, wie oft sie aufgerufen wird. Daraus folgt:

Kosten und Volumen sind entkoppelt. ObjectOS führt die Geschäftsdefinition auf Ihren eigenen Servern aus; egal wie oft der Agent governte Werkzeuge aufruft, es wird nicht pro Aufruf berechnet – die Kosten bestimmt die Infrastruktur, vorhersagbar und planbar. Verdoppelt sich das Ticketaufkommen jenes CFO, bewegt sich die Rechnung kaum.
Die Daten verlassen den Geltungsbereich nicht. Objekte, Berechtigungen, Audit-Beweise bleiben alle in Ihrer eigenen Infrastruktur, Compliance-Risiko und die Kosten des Datenabflusses sinken gemeinsam.
Kein Lock-in. Die Geschäftsdefinition sind Metadaten in Ihrem Repository unter einem offenen Protokoll (Apache 2.0), diffbar und migrierbar. Sie kaufen den Dienst der Runtime, kein Pfand dafür, „künftig nicht mehr wegzukommen”.

Schlusswort

„0,10 $ pro Aktion” ist ein sorgfältig gestaltetes Preisschild: Wenn Sie gerade erst starten und das Volumen klein ist, wirkt es harmlos; wenn Sie wirklich erfolgreich sind und das Volumen abhebt, zeigt es seine Reißzähne. Zurück zu jenem CFO am Quartalsende – seine Rechnung ist nicht außer Kontrolle geraten, sie ist die Zwangsläufigkeit, die dieses Abrechnungsmodell so entworfen hat: Es reicht Ihnen in dem Moment, in dem Sie am meisten feiern sollten, die größte Rechnung.

Wenn Sie die Kostenrechnung eines Agents aufstellen, schauen Sie nicht nur auf den Stückpreis. Rechnen Sie jene drei Rechnungen – Volumen, Compliance, Lock-in – und vergleichen Sie dann mit jener Schnittpunktformel Ihr eigenes Volumen. Rechnet man das durch, ist „Self-Hosting spart 40–60 %” keine Parole, sondern ein Schluss, den man ins Budget schreiben kann – und bei dem man auch weiß, wann er nicht gilt.

npm i -g @objectstack/cli && os start

Bringen Sie ein Geschäftsobjekt auf Ihrer eigenen Maschine zum Laufen, lassen Sie einen Agent es ein paar tausend Mal aufrufen und schauen Sie sich dann die Rechnung an – sie bewegt sich nicht, weil es keine Position „jedes Mal 0,10 $” gibt.