Was kostet es, KI in eine App zu bauen?

Wo entstehen die Kosten wirklich?

Es gibt drei Posten, und ihre Reihenfolge überrascht die meisten Teams. Erstens Entwicklung: Feature entwerfen, Prompts schreiben, ein Evaluationsset bauen, die Oberfläche bauen. Zweitens Modellnutzung: die Tokengebühr je Anfrage. Drittens Wartung: Modelle ändern sich, Prompts veralten, Nutzerverhalten verschiebt sich.

Die meisten Teams schauen auf den zweiten Posten, weil nur er eine veröffentlichte Preisliste hat. In einem kleinen oder mittleren Produkt ist die Modellrechnung aber meist der kleinste; das Geld fließt in Entwicklung und — nach dem ersten Jahr — in Wartung.

Die Einheit sind Tokens, nicht Nutzer

Modellpreise laufen über Tokens: der in das Modell eingehende Text wird als Input berechnet, der erzeugte als Output — und Output kostet immer mehr. Praktisch heißt das: zwei Produkte mit identischer Nutzerzahl können um ein Vielfaches auseinanderliegen.

Den Unterschied macht der Ablauf. Ein Produkt, das mit jeder Anfrage vierzig Seiten Kontext schickt, verbraucht ein Vielfaches der Tokens eines Produkts, das eine kurze Frage kurz beantwortet — bei gleicher Nutzerzahl. Deshalb genügt „wie viele Nutzer“ nicht zur Kostenschätzung, „was wird pro Interaktion gesendet“ schon.

Drei Mechanismen, die die Kosten senken

• **Prompt-Caching.** Der bei jeder Anfrage wiederholte feste Kontext — Systemanweisung, Produktregeln, ein Dokument — wird einmal geschrieben und danach gelesen. Auf Anthropics Preisseite entspricht ein Cache-Lesezugriff etwa einem Zehntel des normalen Input-Preises. In jedem Produkt mit wiederholtem Kontext ist das der größte Einzelhebel.
• **Batch-Verarbeitung.** Arbeit ohne Sofortantwort — nächtliche Klassifikation, Massen-Zusammenfassung, Datenanreicherung — läuft über den Batch-Endpunkt zum halben Standardpreis.
• **Aufteilung über Modelle.** Mechanische Schritte wie Klassifikation, Routing und Formatierung an ein kleines Modell, den Schritt mit Urteilsbedarf an ein starkes. Eine Architektur, die alles mit einem Modell erledigt, zahlt den Preis des teuersten Schritts bei jedem Schritt.

Zusammen angewendet ist der Unterschied ein Vielfaches, kein Prozentwert. Alle drei sind aber Architekturentscheidungen, keine Einstellungen nach Fertigstellung des Features. Deshalb gehört Kostenoptimierung in die Designphase.

Drei Fehler, die die Rechnung sprengen

• **Den API-Schlüssel in die App einbetten.** Ein in eine mobile App eingebetteter Schlüssel lässt sich extrahieren — und ab dann bestimmt ein anderer Ihre Rechnung. Modellaufrufe gehören immer über Ihren Server; der Client sieht nur Ihren Endpunkt.
• **Kein Limit pro Nutzer.** Ist nicht definiert, wie viele Anfragen ein Nutzer monatlich stellen darf, kann ein einziges Skript das Monatsbudget an einem Tag verbrauchen. Das Limit ist Teil des Produkts, keine nachgelagerte Sicherheitsmaßnahme.
• **Den Kontext unbegrenzt wachsen lassen.** In einem Ablauf, der den Chatverlauf ungekürzt anhäuft, kostet jede neue Nachricht mehr als die letzte; die Kosten steigen kumulativ statt linear.

Geht ein Festpreis?

Für die Entwicklung ja, für die Nutzung nein — und dieser Schnitt schützt vorab beide Seiten. Entwicklungsumfang ist definierbare Arbeit: Feature, Oberfläche, Evaluationsset, Übergabe. Die Modellnutzung hängt am Nutzerverhalten; sie fix zu bepreisen heißt, das Risiko in den Preis zu legen und Sie dafür zahlen zu lassen.

Was funktioniert: Entwicklung zum Festpreis, Nutzung transparent und gemessen direkt beim Anbieter. Dazu eine vorab definierte Monatsobergrenze und eine Warnung, wenn sie sich nähert. Dann sind die Kosten weder Überraschung noch Schätzung.