Was ein KI-Feature wirklich kostet: Kosten pro Request kalkulieren

„Was kostet uns KI?" ist keine beantwortbare Frage. „Was kostet ein Request, und wie oft passiert er?" ist eine, und die Antwort ist meistens niedriger als befürchtet und anders verteilt als angenommen.

Das ist kein Randthema. Die Einführung von KI im Mittelstand scheitert seltener an der Technik als an fehlender Kostentransparenz (openPR). Wer die Zahl nicht hat, entscheidet nicht, oder er sagt einen Preis zu, den er nicht durchgerechnet hat.

Die Rechnung

Kosten pro Request gleich Input-Token mal Input-Preis plus Output-Token mal Output-Preis. Preise werden pro Million Token angegeben.

Nehmen wir ein realistisches Feature: Ein Support-Ticket samt Verlauf wird zusammengefasst und kategorisiert. Etwa 4.000 Token gehen rein, etwa 500 kommen raus.

Bei einem mittleren Modell zu 3 Dollar Eingabe und 15 Dollar Ausgabe pro Million Token:

• Eingabe: 0,004 Millionen mal 3 Dollar gleich 1,2 Cent
• Ausgabe: 0,0005 Millionen mal 15 Dollar gleich 0,75 Cent
• Summe: rund 2 Cent pro Ticket

Bei 10.000 Tickets im Monat sind das etwa 195 Dollar. Bei einem günstigen Modell zu 0,50 Dollar Eingabe und 3 Dollar Ausgabe kostet dasselbe Feature rund 35 Dollar im Monat.

Zur Einordnung der aktuellen Preise, Stand August 2026: Claude Sonnet 5 liegt bei 2 Dollar Eingabe und 10 Dollar Ausgabe, wobei dieser Einführungspreis Ende August ausläuft und danach wieder auf 3 und 15 Dollar geht. GPT-5.2 liegt bei 1,75 und 14 Dollar, Gemini 3.1 Pro bei 2 und 12 Dollar, Gemini 3 Flash bei 0,50 und 3 Dollar (TLDL, abgerufen am 18.08.2026). Über alle Anbieter und Stufen hinweg spannt sich die Eingabeseite von 0,15 bis 75 Dollar pro Million Token (Spheron, abgerufen am 18.08.2026).

Diese Preise ändern sich schnell. Jede Kalkulation, die älter ist als ein Quartal, ist keine Kalkulation mehr.

Die Ausgabe dominiert, nicht die Eingabe

Im Beispiel oben sind die 500 Ausgabe-Token ein Achtel der Token und knapp 40 Prozent der Kosten. Ausgabe-Token liegen bei den großen Anbietern typischerweise um das Drei- bis Fünffache über den Eingabepreisen, weil sie sequenziell erzeugt werden.

Daraus folgt eine unpopuläre Konsequenz. Der lange, sorgfältig gebaute Prompt mit vielen Beispielen ist selten das Kostenproblem. Das Kostenproblem ist die Antwort, die ausführlicher ausfällt als nötig, weil niemand eine Obergrenze gesetzt hat.

Praktisch heißt das: Wer sparen will, begrenzt zuerst die Ausgabe. Ein festes Ausgabeschema mit klaren Feldern kostet einen Bruchteil eines freien Fließtexts und ist für den nachgelagerten Code ohnehin brauchbarer.

Drei Hebel, die tatsächlich etwas bringen

Prompt Caching. Wiederholte Eingabeteile werden zwischengespeichert und beim nächsten Aufruf günstiger abgerechnet, auf dem wiederholten Anteil bis zu 90 Prozent. Anthropic berechnet Cache-Lesevorgänge mit einem Zehntel der Eingaberate, Schreibvorgänge dagegen mit dem 1,25-fachen bei fünf Minuten Aufbewahrung und dem Doppelten bei einer Stunde. OpenAI aktiviert das ab 1.024 Token automatisch und rechnet zwischengespeicherte Eingaben ebenfalls zu einem Zehntel ab. Bei Google kommt eine stundenweise Speichergebühr hinzu (DataNorth, abgerufen am 18.08.2026).

Der Haken steckt in der Aufbewahrungszeit. Der Rabatt entsteht nur, wenn derselbe Präfix innerhalb des Zeitfensters wieder benutzt wird. Bei einem Feature mit wenigen Aufrufen pro Stunde zahlt man die teureren Schreibvorgänge und liest den Cache nie. Vor dem Einbauen gehört deshalb gemessen, wie oft ein identischer Präfix tatsächlich wiederkehrt.

Batch-Verarbeitung. Anthropic, OpenAI und Google geben pauschal 50 Prozent auf Ein- und Ausgabe für Arbeitslasten, die bis zu 24 Stunden Verzögerung vertragen. Das ist der einfachste Rabatt im Feld, weil er keine Änderung am Prompt braucht, nur eine Änderung daran, wann etwas läuft. Nächtliche Auswertungen, Klassifikation von Altbeständen und Berichte gehören dorthin. Kombiniert mit Caching sind auf dem wiederholten Anteil bis zu 95 Prozent Ersparnis erreichbar (Flexera, abgerufen am 18.08.2026).

Modellwahl pro Aufgabe. Zwischen der günstigen und der mittleren Stufe liegt in den Zahlen oben etwa Faktor vier bis sechs auf der Eingabeseite. Die meisten Anwendungen bestehen aus wenigen schweren Aufrufen und vielen leichten. Klassifizieren, Extrahieren und Umformatieren laufen auf der günstigen Stufe, ohne dass ein Nutzer den Unterschied merkt.

Der Fehler, den fast alle bei der Preisseite machen

Wer die Modellkosten in die eigene Preisseite schreibt, in Form von Guthaben und Verbrauchsanzeigen, baut sich eine Schwachstelle genau dort ein.

Ein Wettbewerber mit Pauschalpreis greift dann nicht das Produkt an, sondern die Abrechnung, und das ist der billigere Angriff. Der Kunde stört sich selten am Betrag. Er stört sich an der zweiten Rechnung und daran, vor jeder Aktion zu überlegen, ob sie sich lohnt. Ein Feature, bei dem der Nutzer zögert, wird nicht benutzt.

Bei den Preisen von 2026 verschwinden die Modellkosten für die meisten Anwendungen in der Marge eines gewöhnlichen Monatsabos. Ein Zähler in der Oberfläche kostet dann mehr Umsatz, als er an Kosten deckt.

Die Verschiebung, die den größten Unterschied macht

Der interessanteste Effekt steht in keiner Preistabelle, und ich habe ihn erst gesehen, als ich das eigene Modell durchgerechnet habe.

Solange man pro Kunde und pro Verbrauch abrechnet, wächst der KI-Kostenblock mit der Kundenzahl. Sobald die Arbeit über ein Abo mit festem Monatspreis pro Arbeitsplatz läuft, hört das auf. Ein Platz zu rund 100 Dollar im Monat deckt so viele Kunden ab, wie die Person an diesem Platz bedienen kann. Der Kostenblock ist damit von der Kundenzahl entkoppelt und wird zu einer festen Größe pro Person.

Das dreht die Margenkurve. Bei verbrauchsabhängigen Kosten läuft die Marge auf ein Plateau zu, weil jeder zusätzliche Kunde zusätzliche Kosten mitbringt. Bei festen Platzkosten steigt sie mit jedem Kunden weiter, weil der Nenner wächst und der Zähler stehen bleibt.

Für die Preisgestaltung ist das die eigentliche Nachricht. Nicht dass Modelle billiger geworden sind, sondern dass sie für viele Anwendungen aufgehört haben, ein variabler Posten zu sein. Was das für Wettbewerbsvorteile insgesamt bedeutet, steht in meinem Beitrag dazu, warum Software kein Moat mehr ist.

Was zu messen ist, bevor man einen Preis zusagt

Fünf Zahlen, und keine davon lässt sich schätzen:

1. Token pro Request, gemessen an echten Daten. Nicht am Beispiel-Prompt aus der Entwicklung, sondern an den längsten realen Eingaben. Support-Verläufe und hochgeladene Dokumente sind regelmäßig um ein Vielfaches größer als der Testfall.
2. Requests pro aktivem Nutzer und Monat. Der Durchschnitt reicht nicht, weil er die Rechnung nicht schreibt.
3. Das 95. Perzentil statt des Durchschnitts. Ein kleiner Teil der Nutzer erzeugt regelmäßig ein Vielfaches der mittleren Last, und genau dieser Teil sprengt eine Pauschale.
4. Die Wiederholungsrate. Fehlgeschlagene und wiederholte Aufrufe werden berechnet. Wer bei ungültiger Ausgabe automatisch neu anfragt, zahlt für jeden Versuch.
5. Die Cache-Trefferquote. Ohne sie ist jede Ersparnisrechnung mit Caching eine Vermutung.

Ohne diese fünf Zahlen ist eine Festpreiszusage eine Wette. Sie kann aufgehen, aber sie ist keine Kalkulation. Dieselbe Streuung, die Pauschalpreise bei KI-Features schwierig macht, macht sie auch bei Entwicklungsleistung schwierig, und ich habe das an anderer Stelle teuer gelernt.

Willst du wissen, was ein geplantes KI-Feature im Betrieb kosten würde, bevor es gebaut ist? 30 Minuten, unverbindlich: Termin buchen