"Dienstag soll es eine spannende Ankündigung geben, ich bin gespannt", dachte ich. Doch bevor sie kam, erschien erst mal ein langer Text über geänderte Nutzungsberechnungen.
Zusammengefasst: Das Pro-Abo für 200 Dollar im Monat wird für Neukunden wieder geöffnet, aber der Nutzungswert, umgerechnet in API-Preise, halbiert sich gegenüber dem alten Tarif.
Man wartet auf Böllerschüsse und bekommt vorab eine geänderte Rechnungsvorschrift.
Da sagt man schon mal: "Hallo?"
Trotzdem muss man hier eine Sache sauber trennen. Das ist keine Ankündigung, dass sich die Nutzungsmenge aller Modelle pauschal halbiert. In derselben Woche hat OpenAI die API-Preise von GPT-6 Sol und Luna gegenüber dem Aktionspreis von GPT-5.6 um 50 % gesenkt.
Die Logik des Anbieters lautet also:
Das nutzbare Kontingent in API-Dollar wird halbiert. Aber die Modelle werden auch billiger. Unterm Strich schafft man also mehr als vorher.
Die Logik verstehe ich.
Das Problem: Kundinnen und Kunden kaufen keine "API-Dollar-Werte", sondern erledigte Arbeit.
1. Was wird bei "halb" eigentlich halbiert?
In seinem Beitrag vom 29. September 2026 erklärt Tibo: Am 30. September werde das Pro-Abo für 200 Dollar wieder für Neukunden geöffnet, und nach der neuen Nutzungsberechnung sei der Wert "gegenüber dem alten Pro für 200 Dollar halbiert, gemessen in API-Ausgaben".
Gleichzeitig soll das 5-Stunden-Limit nicht zurückkehren, das Wochenkontingent soll weiter jederzeit nutzbar bleiben, Effizienzgewinne der Modelle und API-Preissenkungen sollen an die Nutzer weitergegeben werden, und am nächsten Tag soll es zusätzliche Funktionen geben, die kein Kontingent verbrauchen.
GPT-6 Sol und Luna, am 22. September vorgestellt, haben laut offizieller Angabe von OpenAI 50 % niedrigere API-Preise als GPT-5.6 zum Aktionspreis. Auch in der offiziellen Preisliste vom 29. September lassen sich die aktuellen Preise von Sol und Luna nachlesen.
Bis hierhin geht die Rechnung glatt auf.
Sei B das alte Nutzungsbudget und C die API-Kosten pro Aufgabe. Dann schafft man im alten Tarif ungefähr B/C Aufgaben.
Wenn das Budget auf 0,5B sinkt, aber dieselbe Aufgabe nur noch 0,5C kostet, gilt:
0,5B ÷ 0,5C = B ÷ C
Theoretisch sinkt die Arbeitsmenge also nicht.
Doch echte KI-Arbeit ist nicht so gleichförmig.
2. Nutzer zählen nicht "wie viele Dollar", sondern "wie viele Aufgaben fertig geworden sind"
Wer hundert kleine Fragen stellt, und wer ein riesiges Repository einlesen lässt, um eine Reparatur bis zum Ende durchzuziehen, meint mit "eine Anfrage" etwas völlig anderes.
Langer Kontext, tiefes Nachdenken, Tool-Aufrufe, mehrfache Prüfung, Neustart nach Fehlern.
Schwere Aufgaben fressen auf einen Schlag viel Kontingent.
Das Gefühl der Vielnutzer lautet deshalb weniger
"Ich kann noch Nachrichten schicken"
sondern eher
"Wenn ich das hier losschicke, geht das nächste große Ding nicht mehr."
Die Auskunft "Die API-Preise sind halbiert" beantwortet das nicht.
Wie viele Aufgaben kann ich diese Woche noch bis zum Ende durchbringen?
Nennen wir diese Kennzahl "erledigte Arbeitsmenge". Dann bemisst sich der Wert eines Flatrate-KI-Abos letztlich weder nach Nachrichten noch nach Tokens, sondern nach
erledigte Arbeitsmenge ÷ Monatspreis.
3. "Ich kann nur ein Hundertstel von Opus nutzen" ist kein Benchmark. Aber die Struktur der Unzufriedenheit ist echt
Wer schwere KI-Arbeit macht, empfindet die Kontingentunterschiede zwischen Diensten manchmal als extrem.
"Beim einen kann ich mehrere lange Aufgaben laufen lassen, beim anderen ist nach einer schweren Aufgabe Schluss. Fühlt sich an wie ein Hundertstel."
Natürlich ist dieses "Hundertstel" kein gemessener Faktor. Es hängt von Aufgabe, Modell, Tarif und Kontextlänge ab.
Aber dass die Zahl übertrieben ist, lässt das Problem nicht verschwinden.
Entscheidend ist, ob Aufgabengröße und Limitdesign zusammenpassen.
Bei Aufgaben von jeweils fünf Minuten kann man auch ein kleines Limit in kleinen Häppchen nutzen.
Bei Agentenarbeit, die 30 Minuten oder eine Stunde dauert oder mehrfach repariert werden muss, ist es dagegen am schlimmsten, wenn mittendrin der Sprit ausgeht.
Auch die klügste KI liefert fast nichts, wenn sie vor dem Ziel stehen bleibt.
Deshalb zählt nicht nur die Spitzenleistung, sondern auch
- ob eine Aufgabe bis zum Ende durchläuft
- ob man nach einem Fehler weitermachen kann
- wie viele Aufgaben pro Woche fertig werden
- ob man bei einem Modellwechsel alles neu bauen muss
4. Deshalb ist jetzt keine Zeit, KI zu verbrauchen, sondern Anlagen zu bauen
Jetzt kommt das eigentliche Thema.
Ob die heutigen leistungsstarken KI-Abos später teurer werden, das Kontingent schrumpft oder sie im Gegenteil billiger werden, weiß niemand.
Sicher ist nur: Nutzungsbedingungen sind kein Anlagevermögen.
Die Großzügigkeit von heute ist nicht der Standard von morgen.
Am verschwenderischsten ist es deshalb, in billigen Zeiten viel mit der KI zu chatten, sodass das Ergebnis nur im Chatverlauf liegt.
Stark ist dagegen, mit günstiger Inferenz Systeme zu bauen, die weitere Inferenz überflüssig machen.
Zum Beispiel:
- Was man früher jedes Mal von Hand recherchiert hat, automatisch einsammeln
- Beurteilungskriterien, die man der KI jedes Mal erklärt hat, als Regeln und Verträge speichern
- Prüfungen, die Menschen per Augenschein gemacht haben, in Tests verwandeln
- Lange Alles-oder-nichts-Aufgaben in Schritte zerlegen, die man mittendrin wieder aufnehmen kann
- Ergebnisse nicht im Chat, sondern in Dateien, Datenbank und Git ablegen
- Modellnamen eines einzelnen Anbieters nicht fest einbauen, sondern einen austauschbaren Zugang schaffen
- Aufzeichnen, welches Modell bei welcher Aufgabe gut ist
So bleibt das Ergebnis erhalten, auch wenn die KI von diesem Monat nächsten Monat verschwindet.
Während man die KI mietet, baut man eine Fabrik, die auch ohne KI läuft.
Das ist KI-Nutzung als Investition.
5. Bleibende Werte und verbrauchte Ausgaben trennen
Zehn Stunden KI-Nutzung können sehr Unterschiedliches hinterlassen.
| Nutzung, die sofort verpufft | Nutzung, die bleibt |
|---|---|
| Jedes Mal dieselbe Erklärung in den Chat schreiben | Eingabespezifikation und Beurteilungskriterien als Datei festhalten |
| Die KI von Hand prüfen lassen | Automatische Tests und Bewertungsroutinen bauen |
| Eine riesige Aufgabe auf einmal losschicken | In kleine Schritte mit Checkpoints aufteilen |
| Antwort lesen und fertig | Ergebnisse, Belege und Status speichern |
| Das stärkste Modell für alles nehmen | Erst ein leichtes Modell, nur bei Bedarf ein starkes |
| Magische Prompts für einen bestimmten Dienst hegen | Gemeinsame Aufgabenspezifikation und dünner Provider-Adapter |
| Beim Erreichen des Limits stehen bleiben | Resume, Retry und Handoff einbauen |
Auch aus der Forschung gibt es Belege dafür, mehrere Modelle je nach Aufgabe einzusetzen.
FrugalGPT hat gezeigt: Mit einer Kaskade, die pro Frage das Modell wechselt, lassen sich die Kosten bei den getesteten Aufgaben stark senken, bei einer Leistung nahe am besten Einzelmodell.
Eine weitere Studie von 2026 berichtet über ein zweistufiges Verfahren: Zuerst wird ans kosteneffiziente Modell verteilt, und nur Fälle mit zu geringer Qualität gehen an das starke Modell. Damit blieben 97 bis 99 % der Genauigkeit des stärksten Modells erhalten, bei höherer Effizienz.
Man muss nicht jede Aufgabe mit dem stärksten Modell erschlagen.
Das starke Modell nur in dem Moment einsetzen, in dem man es wirklich braucht.
6. Das ist der minimale Aufbau, der nicht an einen Anbieter fesselt
Ein austauschbares System muss kein großer Multi-Cloud-Plan sein.
Wenn man mindestens diese sechs Dinge trennt, ist man schon deutlich stärker:
Aufgabenspezifikation Was geht hinein, was gilt als fertig? Man beschreibt die Aufgabe selbst, nicht den Modellnamen.
Modellanbindung Unterschiede zwischen OpenAI, Anthropic und anderen werden nur hier abgefangen und von der eigentlichen Logik getrennt.
Zustandsspeicherung Festhalten, wie weit man ist. Lange Aufgaben nicht von vorn beginnen.
Ergebnisspeicherung Code, Texte, Auswertungen und Belege außerhalb des Chats ablegen.
Bewertungsroutine Nicht glauben, dass etwas "fertig" ist, sondern mit Tests, Vergleichen und echten Daten prüfen.
Verteilung Aufgaben, für die ein billiges Modell genügt, gehen ans billige Modell. Nur gescheiterte Fälle steigen auf.
Auch Microsofts Well-Architected Framework empfiehlt, enge Abhängigkeiten zu verringern und die Fachlogik von infrastrukturspezifischen Funktionen zu trennen.
Bei KI ist das genauso.
Je mehr es heißt "Diese Aufgabe läuft nur mit Opus" oder "Diese Verarbeitung setzt das Antwortformat von Sol voraus", desto eher wird jede Preisänderung zu einem Umbau des Systems.
Ist die Anbindung dagegen dünn, genügt:
Claude wird teurer → anderes Modell ausprobieren.
7. Was man die heutigen starken Modelle bauen lassen sollte
In billigen Zeiten lohnt es sich besonders, das starke Modell nicht nur um die Ergebnisse von heute zu bitten, sondern um das, was ab morgen automatisch Ergebnisse erzeugt.
Hohe Priorität haben diese Aufgaben:
Erstens: Wiederkehrende Arbeit automatisieren. Recherche, Aufbereitung, Prüfung, Veröffentlichung und Auswertung, die man jede Woche macht, sollen nicht mehr jedes Mal von Hand angestoßen werden.
Zweitens: Wiederanlauf nach Fehlern. Retry, Resume, Checkpoints, Idempotenz und Schutz vor Duplikaten einbauen. Ein einzelnes erreichtes Limit soll nicht den ganzen Ablauf töten.
Drittens: Qualitätsmaßstäbe auslagern. Statt "irgendwie gut" dem Bauchgefühl des Modells zu überlassen, daraus testbare Bedingungen machen.
Viertens: Beobachtung. Aufgabentyp, verwendetes Modell, Erfolgsquote, Zahl der Wiederholungen, Dauer und Nutzung festhalten.
Fünftens: Modellwechsel. Man muss nicht von Anfang an zwei oder drei Anbieter parallel nutzen. Aber einen austauschbaren Zugang sollte man bauen.
So wird eine künftige Preisänderung nicht zum "Weltuntergang", sondern zur "Änderung der Gewichte im Router".
8. Optimierungen, die jetzt gefährlich sind
Wenn man viele günstige Modelle nutzen kann, will man das ganze Design auf diese Bedingung zuschneiden.
Kurzfristig geht das schneller.
Langfristig ist es gefährlich.
Besonders vermeiden sollte man vier Dinge.
Das Ziel, das aktuelle Limit komplett auszuschöpfen. Nutzungsmenge ist kein Ergebnis. Wer anfängt, Arbeit zu erfinden, nur um übriges Kontingent zu verbrennen, hat es verdreht.
Alles auf riesige Einzelaufgaben setzen. Bei Limitänderungen, Verbindungsabbrüchen oder Modellausfällen geht dann leicht alles verloren.
Immer mehr stillschweigendes Wissen für einen einzigen Anbieter. Je mehr lange Zauberformeln nur bei einem bestimmten Modell funktionieren, desto teurer wird der Wechsel.
Das System auf vorhergesagte Preisänderungen auslegen. Man muss nicht festlegen: "Claude wird bestimmt teurer" oder "OpenAI senkt dauerhaft". Stärker ist es, eine Struktur zu bauen, die auch dann nicht schadet, wenn man danebenliegt, statt die Zukunft zu erraten.
9. Fazit: Die Großzügigkeit von Abos ist das Wetter, ein System ist das Haus
Man ärgert sich über die Änderung beim 200-Dollar-Kontingent.
Bei einem anderen Dienst fühlt es sich an, als könne man ein Vielfaches nutzen.
Dieses Gefühl ist völlig natürlich.
Wer aber jedes Mal nur verfolgt, "welcher Dienst gerade günstiger ist", dessen eigene Produktivität schwankt mit jeder Preisliste des Anbieters.
Stärker ist es, die derzeit ungewöhnlich billige Intelligenz in Anlagevermögen umzuwandeln.
Code.
Tests.
Bewertungsmaßstäbe.
Daten.
Automatisierung.
Wiederaufnehmbare Abläufe.
Eine Anbindung, die Modelle austauschbar macht.
All das verschwindet nicht, wenn das Wochenkontingent des Abos zurückgesetzt wird.
Weder das stärkste Modell von heute noch die Billigkeit von heute sollte man für ewig halten.
Solange es billig ist, ein System bauen, das auch dann noch funktioniert, wenn die Billigkeit endet.
Am Ende ist das am stärksten.
Gerade in einer Welt, in der man auf die "tolle Ankündigung" am Dienstag wartet und zuerst ein langer Text über geänderte Nutzungskontingente kommt.
