Wer KI-Funktionen in eigene Produkte einbaut oder Entwicklungsteams mit Modellunterstützung arbeiten lässt, hat eine neue Position in der Kostenrechnung: die Abrechnung pro Anfrage beim Modellanbieter. Diese Position ist derzeit in Bewegung. Berichten zufolge wirbt OpenAI gezielt Kunden von Anthropic ab und gewährt dafür Preisnachlässe von bis zu 90 Prozent. Unternehmen wie Rippling, Replit und DataCamp berichten von entsprechenden Kostensenkungen.

Der Hintergrund ist ein Verdrängungswettbewerb. Anthropics Wachstum hat sich den Angaben nach verlangsamt, OpenAI kauft sich Marktanteile über den Preis – und bezahlt das mit der eigenen Marge. Gleichzeitig drücken chinesische Anbieter wie Deepseek von unten auf das Preisniveau. Das Ergebnis ist ein Markt, in dem die Kosten für vergleichbare Leistung schneller fallen, als die meisten Budgetplanungen abbilden können.

Warum das für Projekte mit KI-Anteil relevant ist

In klassischen Webprojekten sind die laufenden Kosten gut kalkulierbar: Hosting, Wartung, Lizenzen. Sobald ein Produkt Modellaufrufe auslöst – etwa für Textgenerierung, Klassifikation oder Suche –, entsteht eine Kostenart, die mit der Nutzung skaliert. Steigt die Nutzerzahl, steigt die Rechnung mit.

Fallen die Preise, wird diese Rechnung billiger. Das klingt zunächst nur erfreulich. Praktisch verschiebt es aber die Machbarkeitsgrenze: Anwendungsfälle, die vor einem Jahr aus Kostengründen verworfen wurden, können heute tragfähig sein. Wer solche Entscheidungen getroffen hat, sollte die Annahmen prüfen, statt sie fortzuschreiben.

Rabatte sind kein dauerhafter Zustand

Gleichzeitig gilt Vorsicht. Preisnachlässe in dieser Größenordnung entstehen in einer Wettbewerbssituation und nicht aus gesunkenen Betriebskosten. Wenn ein Anbieter Marktanteile auf Kosten der eigenen Marge kauft, ist das kein stabiler Dauerzustand. Entweder sinken die Produktionskosten entsprechend nach, oder die Preise ziehen wieder an, sobald die Marktpositionen geklärt sind.

Für die Kalkulation heißt das: Ein Sonderkonditionsangebot ist eine gute Grundlage für ein Pilotprojekt, aber eine schlechte Grundlage für ein Geschäftsmodell, das über Jahre tragen soll. Wer seine Deckungsbeiträge auf einem Rabatt aufbaut, hat ein Risiko in der Bilanz, das nicht im eigenen Einflussbereich liegt.

Anbieterunabhängigkeit wird zur Architekturaufgabe

Die eigentliche Konsequenz liegt in der Technik. Wenn Preise und Leistungsverhältnisse sich mehrmals im Jahr verschieben, muss ein Wechsel des Modellanbieters ein überschaubarer Vorgang sein – und keine Neuentwicklung.

Das erreicht man nicht nebenbei, sondern durch bewusste Entwurfsentscheidungen:

  • Abstraktionsschicht: Die Anwendung spricht nicht direkt mit einem Anbieter, sondern mit einer eigenen internen Schnittstelle. Dahinter liegt austauschbar das jeweilige Modell.
  • Prompts als Konfiguration: Die Anweisungen an das Modell gehören nicht fest in den Programmcode, sondern an eine zentrale, versionierte Stelle. Nur so lassen sie sich beim Anbieterwechsel anpassen, ohne die Anwendung umzubauen.
  • Messbare Qualität: Ein Satz definierter Testfälle mit erwarteten Ergebnissen zeigt, ob ein günstigeres Modell für den konkreten Anwendungsfall ausreicht. Ohne solche Tests bleibt der Vergleich Bauchgefühl.
  • Kostentransparenz pro Funktion: Welcher Programmteil verursacht welchen Anteil der Modellkosten? Diese Zuordnung ist die Voraussetzung dafür, gezielt zu optimieren statt pauschal zu sparen.
  • Datenschutz und Standort: Ein Anbieterwechsel ist auch ein rechtlicher Vorgang. Wo Daten verarbeitet werden und unter welchen Bedingungen, gehört vor den Wechsel geprüft, nicht danach.

Nicht jede Aufgabe braucht das teuerste Modell

Ein weiterer Hebel liegt unabhängig vom Preiskampf im eigenen Haus. In vielen Anwendungen laufen alle Anfragen über dasselbe, leistungsfähigste Modell – auch solche, die eine einfache Zuordnung oder eine kurze Zusammenfassung erfordern. Eine Staffelung nach Aufgabentyp senkt die Kosten oft deutlich, ohne dass Nutzerinnen und Nutzer einen Unterschied bemerken.

Dazu kommen klassische Maßnahmen: wiederkehrende Anfragen zwischenspeichern, Eingabetexte auf das Nötige kürzen, Ergebnisse nicht mehrfach neu erzeugen. Solche Optimierungen wirken unabhängig davon, welcher Anbieter gerade den besten Preis macht – und sie bleiben wirksam, wenn die Rabattphase endet.

Verträge und Abhängigkeiten prüfen

Wer ein Rabattangebot annimmt, sollte die Gegenleistung kennen. Üblich sind Mindestabnahmen, Laufzeiten oder exklusive Bindungen. Je länger die Bindung, desto geringer der Nutzen fallender Marktpreise während der Laufzeit. Eine kürzere Vertragsdauer zu einem etwas schlechteren Preis kann in einem derart bewegten Markt die bessere Wahl sein.

Ebenso lohnt der Blick auf die Betriebsstabilität: Wenn ein Anbieter Marktanteile über den Preis kauft, ist nicht garantiert, dass Kapazität, Antwortzeiten und Support auf dem gewohnten Niveau bleiben. Ein zweiter, einsatzbereiter Anbieter im Hintergrund ist nicht nur eine Preis-, sondern auch eine Ausfallsicherung.

Einordnung für Web- und Softwareprojekte

Für laufende Projekte heißt der Preiskampf vor allem: Die Modellwahl ist keine einmalige Festlegung mehr, sondern eine Entscheidung, die regelmäßig überprüft gehört. Technisch zahlt sich das nur aus, wenn die Anbindung von Anfang an austauschbar gebaut ist – nachträglich wird dieser Umbau teuer. Wer heute eine Anwendung mit KI-Anteil plant, sollte die Abstraktionsschicht und eine einfache Testsuite für Modellqualität als festen Bestandteil des Projektumfangs einplanen, nicht als späteres Extra.

Quellen