Der fundamentale Unterschied zwischen einem KI-Feature und jedem anderen Feature deiner App: Es kostet dich bei jeder einzelnen Nutzung Geld. Kein Fixpreis, keine Flatrate — jede Anfrage tickt auf deiner API-Rechnung. Wer das beim Bauen ignoriert, erlebt die Überraschung nach dem Launch, wenn das nette Zusammenfassungs-Feature plötzlich die Marge frisst.
Ich baue KI-Features in eigene Produkte und Kundenprojekte und habe die Lernkurve inklusive unangenehmer Rechnungen selbst durchlaufen. Hier ist das Kosten-Einmaleins, das ich gern vor dem ersten Projekt gehabt hätte.
Die Grundrechnung: Tokens rein, Tokens raus — zu verschiedenen Preisen
LLM-APIs rechnen in Tokens ab (grob: ein Token ≈ drei Viertel eines Wortes, deutsche Texte brauchen tendenziell mehr Tokens als englische). Drei Dinge musst du verinnerlicht haben:
Erstens: Input und Output kosten unterschiedlich viel — Output-Tokens sind typischerweise um ein Mehrfaches teurer als Input-Tokens. Ein Feature, das lange Texte generiert, hat eine völlig andere Kostenstruktur als eins, das lange Texte liest und kurz antwortet.
Zweitens: Der Preisunterschied zwischen Modellklassen ist enorm — zwischen dem kleinsten und dem größten Modell eines Anbieters liegt oft ein Faktor von zehn bis fünfzig. Die Modell-Wahl ist damit deine größte einzelne Kostenentscheidung.
Drittens, und das übersehen fast alle am Anfang: Bei Chat-Anwendungen schickst du die gesamte bisherige Konversation bei jeder Nachricht erneut als Input mit. Die zwanzigste Nachricht eines langen Chats kostet ein Vielfaches der ersten. Kosten wachsen in Konversationen quadratisch, nicht linear — ohne Begrenzung der Historie baust du dir eine Kostenbombe.
Vor dem Bauen: Die Serviettenrechnung
Bevor du ein KI-Feature baust, rechne es einmal grob durch: erwartete Anfragen pro Nutzer pro Monat × durchschnittliche Input-Tokens × Preis + dasselbe für Output. Dann vergleiche das Ergebnis mit deinem Preis pro Nutzer.
Ein Beispiel zum Gefühl bekommen: Ein Feature, das pro Aufruf 4.000 Input- und 500 Output-Tokens verbraucht, kostet mit einem Mittelklasse-Modell vielleicht einen halben Cent pro Aufruf. Klingt harmlos. Bei zwanzig Aufrufen pro Nutzer pro Tag und tausend aktiven Nutzern sind das aber schnell dreistellige Beträge pro Monat — für ein einziges Feature. Ist dein Produkt ein 10-Euro-Abo, geht das auf. Ist das Feature im Free Tier, subventionierst du jede Nutzung aus der Tasche.
Diese Rechnung dauert fünf Minuten und verhindert die häufigste Fehlentscheidung: ein teures Feature an einer Stelle, wo Nutzer es kostenlos und unbegrenzt triggern können.
Die drei größten Hebel, in Reihenfolge der Wirkung
1. Modell-Wahl pro Aufgabe statt ein Modell für alles
Der Reflex, überall das beste Modell zu nehmen, ist der teuerste Fehler. Die meisten Aufgaben in typischen Apps — Klassifizierung, Extraktion, kurze Zusammenfassungen, Umformulierungen — erledigt ein kleines, günstiges Modell praktisch gleichwertig. Die großen Modelle brauchst du für komplexes Reasoning, lange Kontexte mit Querbezügen und heikle Generierung. Bau deine Architektur so, dass das Modell pro Use Case konfigurierbar ist, und teste systematisch, wie weit runter du pro Aufgabe kommst. Ein Downgrade von Flaggschiff auf Mittelklasse bei gleichbleibender Qualität ist eine Kostensenkung um den Faktor fünf bis zehn — kein anderes Optimierungsprojekt in deiner App liefert das.
2. Prompt Caching für wiederholte Kontexte
Alle großen Anbieter bieten inzwischen Prompt Caching: Wiederkehrende Prompt-Teile — System-Prompts, Few-Shot-Beispiele, Dokumentenkontexte, Tool-Definitionen — werden serverseitig zwischengespeichert und bei Folge-Anfragen deutlich günstiger abgerechnet, teils um 90 Prozent reduziert. Die Voraussetzung: Dein Prompt muss so strukturiert sein, dass der statische Teil vorn steht und byte-identisch bleibt; der variable Teil kommt ans Ende. Das ist eine reine Architektur-Disziplin, die nichts kostet außer Sorgfalt — und bei chat- oder agentenlastigen Anwendungen der zweitgrößte Hebel nach der Modell-Wahl.
3. Kontext kürzen statt Kontext kippen
Der Reflex “einfach alles in den Kontext werfen, das Modell sucht sich das Relevante” funktioniert — und ist maximal teuer. Die günstigere Architektur gibt dem Modell nur, was es braucht: bei RAG die drei relevantesten Chunks statt zwanzig, bei Chats eine rollierende Zusammenfassung alter Nachrichten statt der kompletten Historie, bei Dokumenten-Features Vorfilterung statt Ganztext. Output begrenzt du ebenfalls: max_tokens sinnvoll setzen und im Prompt um knappe Antworten bitten — Output ist dein teuerstes Gut.
Kostenfallen aus der Praxis
Ein paar Muster, die auf realen Rechnungen besonders weh tun: Retry-Schleifen ohne Backoff-Limit — ein Bug, der fehlschlagende Anfragen endlos wiederholt, kann über Nacht vierstellig werden. Agenten-Loops, die zehn Tool-Aufrufe machen, wo einer gereicht hätte — Agents multiplizieren jede Ineffizienz. Ungeschützte Endpoints — ein öffentlich erreichbares KI-Feature ohne Rate Limit ist eine Einladung, deine API-Rechnung als kostenloses LLM zu missbrauchen. Und fehlende Budget-Alerts: Jeder Anbieter bietet Spending-Limits und Benachrichtigungen; sie nicht zu setzen ist fahrlässig.
Deshalb gehört zu jedem KI-Feature vom ersten Tag an Messung: Logge pro Anfrage Modell, Input-/Output-Tokens und den errechneten Preis, aggregiert pro Feature und pro Nutzer. Erst mit diesen Daten siehst du, welches Feature die Kosten treibt und welcher Power-User dich Geld kostet — und kannst mit Limits pro Tarif reagieren, bevor es brennt.
Die strategische Ebene: Kosten sinken, Rechnung nicht unbedingt
Zum Schluss die Einordnung für die Planung: Die Preise pro Token fallen seit Jahren kontinuierlich — was heute knapp kalkuliert ist, wird tendenziell günstiger. Aber verlass dich nicht darauf, dass deine Rechnung deshalb sinkt: Erfahrungsgemäß frisst wachsende Nutzung und der Griff zu fähigeren Modellen den Preisverfall wieder auf. Kalkuliere KI-Features deshalb wie variable Kosten (das sind sie), preise sie in dein Modell ein — Nutzungslimits pro Tarif sind völlig akzeptiert — und bau die Messung, bevor du sie brauchst.
Wenn du deine Kalkulation für ein konkretes Feature gegenrechnen willst: Im Discord der Community reden wir offen über echte API-Rechnungen und was dagegen geholfen hat.