Was eine KI-Funktion pro Kunde kostet

Kosten, die mit jedem Klick entstehen

Eine KI-Funktion verursacht Kosten bei jeder einzelnen Nutzung, weil jede Anfrage an ein Sprachmodell abgerechnet wird. Im Prototyp mit einer Handvoll Testern sieht man davon nichts. Mit echten Nutzern wird daraus die Zahl, an der sich entscheidet, ob das Produkt Geld verdient oder mit jedem aktiven Kunden Geld verliert.

Dieser Teil der Serie hat drei Schritte. Erst messen, was ein Kunde kostet. Dann zwei Grenzen einziehen, eine beim Anbieter und eine in der eigenen Anwendung. Und zuletzt den Preis so bauen, dass er zu diesen Kosten passt. Das Einrichten der Grenzen beim Anbieter machst du selbst, den Rest kann dein Agent umsetzen.

Wie man die Rechnung selbst kleiner bekommt, also Modellwahl, Caching und Batch-Verarbeitung, steht in KI-Kosten im Team senken. Hier geht es um die Frage davor: ob du die Kosten kennst und begrenzt hast.

Erst messen

Abgerechnet wird nach Token, grob gesagt nach Textmenge, die hinein- und herausgeht. Jede Antwort der Anbieter-Schnittstelle enthält die verbrauchten Token der Anfrage. Wirf diese Angabe nicht weg, denn später lässt sie sich keinem Kunden mehr zuordnen.

Die Preise trägst du selbst ein, von der Preisseite des Anbieters und mit Datum. Sie ändern sich häufig, und ein Agent, der sie aus seinem Trainingsstand einsetzt, kann veraltete Werte liefern.

Mit zwei Wochen echter Daten kannst du rechnen. Der Rechenweg ist einfach, hier mit erfundenen Beispielzahlen: Kostet eine Anfrage im Schnitt 2 Cent und stellt ein Kunde 40 Anfragen am Tag, sind das an 22 Arbeitstagen 17,60 Euro im Monat. Bei einem Tarif von 29 Euro bleibt etwas übrig. Wichtiger als der Durchschnitt ist aber der Kunde am oberen Ende. Stellt einer 400 Anfragen am Tag, kostet er 176 Euro und zahlt dieselben 29.

Zum Abgleich bieten die Modellanbieter eigene Auswertungen. Anthropic etwa stellt eine Usage and Cost API bereit, mit der sich die eigenen Aufzeichnungen gegen die Abrechnung prüfen lassen. Weichen beide deutlich ab, zählt deine Anwendung falsch oder es gibt Aufrufe, die an der Erfassung vorbeigehen.

Die Grenze beim Anbieter setzt du selbst

Die erste Grenze ist eine Obergrenze für die monatlichen Ausgaben beim Anbieter. Sie gehört in deine Hand, weil sie am Konto hängt und weil du wissen musst, was sie im Ernstfall tut.

Das Entscheidende vorab: Ein Budget ist nicht automatisch eine Grenze. Bei vielen Anbietern gibt es zwei getrennte Dinge, eine Benachrichtigung und einen Stopp, und nur das zweite hält die Rechnung auf. Die folgende Tabelle gibt den Stand der jeweiligen Dokumentation vom 13.10.2026 wieder.

Zwei Dinge gelten fast überall. Der Stopp greift mit Verzögerung: OpenAI schreibt, die Durchsetzung sei "not instantaneous", Vercel prüft nach eigener Angabe alle paar Minuten, und bei Azure liegen Kostendaten typischerweise erst nach 8 bis 24 Stunden vor. Setz die Grenze deshalb unter den Betrag, den du höchstens tragen kannst. Und ein Stopp heißt, dass die Funktion für alle Kunden ausfällt. Das ist die Notbremse, nicht die Steuerung.

So gehst du vor:

1. Öffne beim Modellanbieter die Abrechnungseinstellungen und such die beiden Begriffe: Alarm und Limit. Richte beide ein, den Alarm bei etwa der Hälfte des Limits.
2. Mach dasselbe bei der Plattform, auf der die Anwendung läuft. Lies in der Dokumentation nach, ob das Budget dort stoppt oder nur meldet.
3. Trag als Empfänger der Alarme eine Adresse ein, die jemand liest, und zwar nicht nur deine eigene.
4. Schreib auf, was beim Erreichen des Limits passiert und wie man es anhebt. Im Ernstfall sucht das sonst jemand unter Druck.

Beim Kundenauftrag liegen diese Konten beim Kunden, also setzt er die Grenzen oder gibt sie dir schriftlich vor. Ein Limit, das der Dienstleister nach eigenem Ermessen festlegt, führt zu Streit, sobald es zum ersten Mal greift.

Die Grenze je Nutzer baut der Agent

Die zweite Grenze sitzt in der Anwendung und regelt, wie viel ein einzelner Kunde verbrauchen darf. Sie ist die eigentliche Steuerung. OWASP führt ihr Fehlen in der Liste der API-Sicherheitsrisiken, zusammen mit dem fehlenden Ausgabenlimit bei Drittanbietern, und empfiehlt, die Zahl der Zugriffe je Client und Zeitraum zu begrenzen.

Für Nicht-Techniker: Ohne diese Grenze kann ein einzelner Nutzer, ein fehlerhaftes Skript oder jemand mit böser Absicht das Monatsbudget aller aufbrauchen. Mit ihr trifft es nur das eigene Kontingent.

Was der Nutzer sieht, wenn das Kontingent aufgebraucht ist, entscheidest du und nicht der Agent. Möglich sind ein harter Stopp bis zum Monatsende, ein Angebot zum Aufstocken oder ein Weiterarbeiten mit einem günstigeren Modell. Jede Variante ist vertretbar, solange sie vorher feststeht und im Tarif steht.

Nutzen mehrere Anwendungen oder Teams dasselbe Modellkonto, lohnt eine Zwischenschicht, die Budgets zentral verwaltet. Das Open-Source-Gateway LiteLLM etwa kennt Budgets je Schlüssel mit einem Zeitraum, nach dem sie zurückgesetzt werden, und lässt Anfragen scheitern, sobald ein Schlüssel sein Budget überschritten hat.

Der Preis muss zu den Kosten passen

Für Techniker ist das der ungewohnte Teil. Ein Pauschalpreis auf variable Kosten ist eine Wette darauf, dass die meisten Kunden wenig nutzen. Sie geht auf, bis die Kunden kommen, die das Produkt am meisten schätzen.

Wie die großen Anbieter damit umgehen, zeigt GitHub. Copilot rechnet seit dem 01.06.2026 verbrauchsbasiert ab: Jeder Plan enthält ein monatliches Kontingent an Credits, zusätzlicher Verbrauch lässt sich in bezahlten Plänen dazukaufen. GitHub begründet das damit, dass der Preis so besser zur tatsächlichen Nutzung passe und starke Nutzer weniger ausgebremst werden müssten.

Für das eigene Produkt gibt es im Kern drei Bauformen:

• Pauschale mit Kontingent. Ein fester Preis, der eine bestimmte Menge enthält. Planbar für den Kunden, und dein Risiko ist auf das Kontingent begrenzt. Das ist für die meisten der einfachste Einstieg.
• Stufen. Mehrere Tarife mit wachsendem Kontingent. Wer viel nutzt, zahlt mehr, ohne dass jede einzelne Anfrage abgerechnet wird.
• Verbrauchsabhängig. Der Kunde zahlt, was er nutzt, mit einem Aufschlag auf deine Kosten. Am genauesten, für Kunden aber schwer zu planen. Zahlungsanbieter wie Stripe haben dafür eigene Abrechnungsfunktionen.

Welche Form passt, ist eine Geschäftsentscheidung. Die Messung aus dem ersten Abschnitt liefert die Grundlage: Liegen die Kunden eng beieinander, reicht eine Pauschale mit großzügigem Kontingent. Liegen sie weit auseinander, brauchst du Stufen oder Verbrauch.

Rechne dabei den teuersten Fall mit: Was kostet dich ein Kunde, der sein Kontingent jeden Monat ganz ausschöpft? Liegt das über dem Preis des Tarifs, ist das Kontingent zu groß oder der Preis zu klein.

Kundenauftrag und internes Werkzeug

Baust du im Auftrag, gehört die Kostenfrage ins Angebot. Drei Punkte sollten dort stehen: wer die laufenden Kosten für Modell und Infrastruktur trägt, in welcher Größenordnung sie bei der erwarteten Nutzung liegen und was passiert, wenn die Nutzung deutlich höher ausfällt. Für die Größenordnung nimmst du den Rechenweg von oben mit den Annahmen des Kunden zu Nutzerzahl und Nutzung. Schreib die Annahmen dazu. Eine Zahl ohne Annahmen wird später als Zusage gelesen.

Bei einem internen Werkzeug zahlt niemand pro Nutzung, aber eine Kostenstelle trägt die Rechnung. Dort hilft dieselbe Messung, nur mit Abteilung statt Kunde. Wer nach drei Monaten zeigen kann, was das Werkzeug je Abteilung kostet und wie oft es genutzt wird, hat die Diskussion über das Budget schon halb geführt.

Womit du heute anfängst

Mit dem Limit beim Modellanbieter. Das dauert zehn Minuten und begrenzt den größten denkbaren Schaden. Lies dabei nach, ob du gerade einen Alarm oder einen Stopp eingerichtet hast.

Danach kommt die Erfassung je Kunde, weil alles Weitere auf ihren Zahlen aufbaut. Die Grenze je Nutzer und die Entscheidung über den Preis folgen, sobald du zwei Wochen echte Daten hast.