Usage-based statt Flat-Rate: Die KI-Kostenwende war absehbar — und so federst du sie ab

Martin Rau · · 9 Min. Lesezeit

Es war eigentlich immer klar, dass dieser Tag kommt. Die ganzen Flat-Rate-Pläne der KI-Anbieter — 20 € hier, 200 € da, unbegrenzt KI für alle — waren von Anfang an ein Lockmittel, kein nachhaltiges Geschäftsmodell. Sie haben den Markt geöffnet, Millionen Leute gewöhnt, Workflows entstehen lassen. Und jetzt, wo wir alle drinstecken, drehen die Anbieter den Hebel um: Richtung verbrauchsbasiert. Anthropic ist mit Extra Usage und Volume Tiers vorgeprescht, OpenAI hat öffentlich angekündigt, dass „unlimited” so nicht bleiben kann, Cursor hat von Request-basiert auf Token-Credits umgestellt. Wer mit KI arbeitet, sollte sich darauf einstellen — und idealerweise schon vorher die Hausaufgaben gemacht haben.

Die Kernthese in einem Satz

Wer KI bisher als Flat-Rate-Buffet behandelt hat, wird in den nächsten Monaten teuer dafür bezahlen — wer Token-Bewusstsein, Modell-Routing und gute Architektur eingebaut hat, merkt vom Umstieg fast nichts.

Warum das kommen musste

Die Anbieter machen mit den Flat-Rates kein Geld. Anthropic-CEO Dario Amodei und OpenAI-Manager Nick Turley sagen das inzwischen offen: Eine unbegrenzte Flat-Rate auf Compute ist wie eine unbegrenzte Stromflatrate — sie funktioniert nur, solange niemand den Hahn richtig aufdreht. Sobald Nutzer anfangen, Agenten laufen zu lassen, lange Coding-Sessions zu fahren oder mehrere Stunden am Stück mit Claude Code oder Cursor zu arbeiten, explodiert der Verbrauch. Aus „ein paar tausend Tokens pro Chat” werden „Millionen Tokens pro Aufgabe”.

Das Bittere für die Anbieter: Genau diese Power-User sind die, die KI ernst nutzen — und gleichzeitig die, die das Flat-Rate-Modell am schnellsten kippen lassen. Mein eigener Schreibtisch ist ein gutes Beispiel. Ich habe in den letzten Wochen mehrfach den Test gemacht: Ein größerer Refactor, der einmal über die API läuft, ist locker bei 5 € Verbrauch — und das ist eine kleine Aufgabe. Bei echter Arbeit, mit Architektur, Recherche, Implementierung, Reviews, sind 500.000 bis 1 Mio. Tokens pro Sitzung kein Ausreißer. Pro Sitzung. Wenn du das umrechnest auf einen Arbeitstag, ist klar, was hier passiert. Das ist kein 20-€-Abo mehr. Das ist eine Stromrechnung.

Und gleichzeitig haben Millionen Leute genau das in ihre Prozesse eingebaut — und mit dem Budget der Flat-Rate kalkuliert. Workflows, Tools, ganze Agenturen sind darauf aufgebaut, dass die Maschine im Hintergrund halt einfach läuft. Wenn jetzt der Hebel umgelegt wird, schlägt das voll auf die Marge.

Was sich gerade konkret ändert

Drei Bewegungen passieren parallel, und sie greifen ineinander:

1. Flat-Rates werden ausgehöhlt, ohne den Preis offen anzuheben. Anthropic hat das im April vorgemacht: Opus 4.6 ist still aus dem Picker verschwunden, Fast Mode läuft nur noch über den separaten Extra-Usage-Topf, und der neue Tokenizer von Opus 4.7 erzeugt für denselben Text bis zu 35 % mehr Tokens. Die Liste-Preise stehen unverändert da — das Plan-Limit ist trotzdem schneller weg. Das ist eine Preiserhöhung durch die Hintertür.

2. Volume Tiers und Pay-per-Token werden zum Standard. Anthropic hat zum 1. Mai 2026 gestaffelte API-Rabatte eingeführt — ab 50.000 $ Monatsverbrauch 15 % günstiger. Klingt erst mal nett, ist aber vor allem ein Signal: Wer skaliert, wird belohnt. Wer kleine Volumina hat, zahlt den vollen Preis. Cursor hat im Frühjahr von Request-basiert auf Token-Credits umgestellt — gleiche Logik.

3. OpenAI bereitet das Ende von „unlimited” vor. Nick Turley, Head of ChatGPT, hat im Podcast offen gesagt: „In einer Welt, in der sich Technologie so schnell verändert, gibt es keine Welt, in der das Preissystem sich nicht dramatisch ändert.” Und Sam Altman spricht davon, KI „wie Strom auf Verbrauch” zu verkaufen. Das ist keine Sondermeinung mehr — das ist die offizielle Roadmap.

Zusammen ergibt sich ein klares Bild: Die Anbieter ziehen die Reißleine. Nicht laut, nicht über Nacht, sondern in kleinen Schritten. Erst ein Toggle hier, ein gestaffelter Rabatt dort, ein neuer Tokenizer, ein Limit, das schneller greift. Bis am Ende verbrauchsbasiert das Default-Modell ist.

Mein eigener Aha-Moment

Ich erinnere mich an die erste Sitzung, in der ich die API für eine Aufgabe benutzt habe, die ich sonst einfach so durch den Chat habe laufen lassen — ohne mir Gedanken zu machen, ob ich sie wirklich brauche. Ein kleines Experiment, das ich aus Neugier gestartet habe. Innerhalb von wenigen Minuten standen da 5 $ Verbrauch auf dem Dashboard. Fünf Dollar. Für eine Aufgabe, die ich im Abo gar nicht bemerkt hätte.

Das war der Moment, in dem mir klar wurde: Was wir alle die ganze Zeit machen, hat einen realen Preis. Den sieht man nur nicht, weil das Abo ihn schluckt. Wenn du mit echten Aufgaben anfängst — größere Refactorings, lange Recherchen, mehrstufige Reasoning-Ketten — sind 500.000 Tokens nichts Ungewöhnliches. Eine Million ebenfalls nicht. Was bei Opus 4.7 mit $5 / MTok Input und $25 / MTok Output durch die Pipeline geht, summiert sich pro Sitzung schnell auf zweistellige Eurobeträge. Pro Sitzung.

Und genau diese Aufgaben sind das, was wir in Workflows integriert haben. Der Schreck kommt also nicht beim Schritt vom 20-€-Plan auf den 200-€-Plan. Er kommt beim Schritt von „ich bezahle für Compute” weg vom Pauschal-Modell — wenn plötzlich jede Sitzung sichtbar etwas kostet.

Warum mich das nicht aus der Bahn wirft — und warum es viele andere doch trifft

Ich arbeite seit Monaten genau auf dieses Szenario hin. Nicht weil ich Hellseher bin, sondern weil die Kostenkurve im API-Dashboard nicht lügt. Wer regelmäßig direkt mit der API arbeitet, sieht den wahren Preis sofort — und passt seine Architektur an.

Bei mir laufen drei Hebel parallel, und genau diese drei Hebel machen den Unterschied zwischen „Umstellung schmerzt richtig” und „Umstellung interessiert mich kaum”:

1. Modell-Routing nach Aufgabe, nicht nach Gewohnheit

Architektur und Planung gehören in das große Modell — das ist die Stelle, an der schlechte Entscheidungen den ganzen Workflow vergiften. Wer hier am Modell spart, zahlt später doppelt. Aber: sobald der Plan steht, kann fast alles andere ein kleineres, günstigeres Modell erledigen. Sonnet statt Opus, manchmal sogar Haiku. Wenn der Plan sauber ist, liefert das kleine Modell oft erstaunlich gute Arbeit — weil es nicht denken muss, sondern ausführen.

Konkret heißt das: Eine Sitzung mit Opus für die schwere Planung, dann Sonnet für 80 % der Folgearbeit. Das senkt die Token-Kosten um den Faktor 5 bis 10 — bei gleichem Ergebnis. Das ist kein theoretischer Tipp; das ist der Standardweg, den ich täglich fahre.

2. KIDOKU und RAG: weniger suchen, weniger einlesen

Der zweite große Hebel: Tokens, die gar nicht erst verbraucht werden. Ein typischer Coding-Workflow mit KI verbringt erschreckend viele Tokens damit, im Repository herumzusuchen — Dateien lesen, scannen, wieder lesen, weil die letzte Antwort den Kontext schon nicht mehr enthielt. KIDOKU (mein MCP-basiertes Wissens-Layer) und gezieltes RAG drehen das Verhältnis um: Statt das Modell suchen zu lassen, bekommt es die richtigen Schnipsel direkt. Statt 50.000 Tokens für die Recherche zu verbrennen, sind es vielleicht 3.000.

Über eine ganze Sitzung gerechnet ist das oft der größere Hebel als das Modell-Routing. Beides zusammen senkt den realen Token-Verbrauch dramatisch, ohne dass am Ergebnis sichtbar etwas leidet.

3. Knappheits-Disziplin im Prompt selbst

Der dritte Hebel ist der kleinste, aber der wichtigste mental: dem Modell beibringen, knapp zu antworten. „Erkläre nicht, was du gleich tun wirst — tu es.” „Antworte in Stichworten, nicht in Prosa.” „Halte Text zwischen Tool-Calls auf zwei Sätze.” Klingt banal, spart aber in Summe enorme Output-Tokens — und die kosten bei Opus 4.7 das Fünffache der Input-Tokens.

Was ich an dieser Stelle auch sage: Diese Disziplin tut weh, wenn man sie nicht gewohnt ist. Die meisten Nutzer haben den Komfort des Flat-Rate-Plans nie hinterfragt, weil sie ihn nie hinterfragen mussten. Sobald jetzt aber jede Antwort einen sichtbaren Preis hat, wird genau diese Disziplin zur Kernkompetenz.

Was du jetzt konkret tun solltest

Wer noch ausschließlich auf Flat-Rate-Plänen arbeitet und keine Vorstellung vom eigenen Token-Verbrauch hat, sollte die nächsten Wochen nutzen — bevor die Verschiebung in die eigenen Workflows kommt.

1. Einen API-Account anlegen und drei Tage „echt” arbeiten lassen. Das zwingt dich, das Dashboard zu sehen. Du musst nichts umstellen, du musst nur einmal verstehen, was deine Standard-Tasks tatsächlich kosten. Diese Zahlen sind unbequem — und sie sind die Grundlage für jede vernünftige Entscheidung.

2. Den teuersten Workflow benennen. Wahrscheinlich gibt es eine Aufgabe, die du täglich oder wöchentlich machst und die viel länger läuft als alles andere — Refactoring, Recherche, Content-Briefing. Genau die musst du als erstes „kostenfest” machen. Modell aufteilen, Kontext kürzen, Output knapp halten.

3. Aufhören, „Opus für alles” zu fahren. Das ist die teuerste Gewohnheit, die wir kollektiv haben. Sonnet ist für 70 % der Tasks völlig ausreichend, kostet einen Bruchteil und ist oft sogar schneller. Wer den Reflex „großes Modell = sicheres Ergebnis” nicht durchbricht, zahlt beim Umstieg auf verbrauchsbasiert dreifach.

4. Workflows automatisieren statt manuell wiederholen. Jede Aufgabe, die du fünfmal pro Woche manuell durch den Chat schiebst, ist ein Kandidat für Automatisierung — mit fest definiertem Modell, festem Kontext, knapp ausgehandeltem Output. Da liegt der eigentliche Hebel auf Dauer.

Das Gute an dem Umstieg

Ich weiß, das klingt erst mal düster — und für Leute, die KI bisher unreflektiert genutzt haben, wird es das auch. Aber es gibt eine zweite Seite: Verbrauchsbasiert macht Qualität sichtbar. Eine schlampig formulierte Frage, ein zu großes Modell, ein unaufgeräumter Kontext — das hat plötzlich einen Preis. Und Preis ist das schärfste Feedback-Signal, das ein Markt kennt.

Wer Token-bewusst arbeitet, wird im neuen Modell nicht mehr, sondern weniger bezahlen als jemand, der pauschal 200 € pro Monat abdrückt. Und die Workflows, die heute gut gebaut sind, werden im Verbrauchsmodell sogar wirtschaftlich attraktiver, weil sie eine harte Kostenuntergrenze haben statt einer fixen monatlichen Gebühr, die man nicht ausnutzen kann.

Genau das ist die Linie, an der wir bei boostN arbeiten: Architektur, die Tokens spart. Routing, das Modelle nach Eignung wählt. Tools wie KIDOKU, die das Modell von der Suche entlasten. Wenn der Markt jetzt nachzieht, ist das nicht das Ende der Party — das ist der Anfang von ernsthafter Arbeit mit KI.

Entdecke mehr