Innerhalb von zwei Tagen sind zwei Meldungen erschienen, die für Entwicklungsteams dieselbe Frage aufwerfen: Wie stabil ist die Grundlage, auf der KI-gestützte Entwicklung inzwischen läuft? OpenAI hat dem KI-Coding-Tool Cursor den Zugang zu seinen Modellen gekündigt. Anthropic verändert die wöchentlichen Nutzungslimits von Claude Code. Beides sind keine technischen Ausfälle, sondern Entscheidungen von Anbietern – und genau das macht sie planungsrelevant.

Fall 1: Cursor verliert den OpenAI-Zugang

Cursor ist ein Entwicklungswerkzeug, das Code-Vorschläge und Änderungen über große Sprachmodelle erzeugt. Diese Modelle betreibt Cursor nicht selbst, sondern bezieht sie von Anbietern. Nach der Übernahme von Cursor durch SpaceX hat OpenAI den Vertrag gekündigt. Zur Begründung heißt es, Elon Musks Firmen hätten wiederholt Verträge gebrochen.

Cursor-Mitgründer Michael Truell relativiert die Folgen: OpenAI mache nur fünf Prozent des KI-Traffics aus. Ob sich diese Einschätzung im Alltag der Nutzenden bestätigt, lässt sich aus der Meldung nicht ableiten. Bemerkenswert ist ein anderer Punkt: Der Auslöser für den Wegfall war kein Preisstreit und kein Kapazitätsproblem, sondern ein Eigentümerwechsel und daraus folgende Konflikte auf Vertragsebene. Solche Ursachen lassen sich mit technischen Mitteln kaum vorhersehen.

Fall 2: Claude Code mit neu justierten Wochenlimits

Bei Anthropic geht es nicht um Zugang, sondern um Menge. Claude Code ist das Kommandozeilen-Werkzeug von Anthropic, mit dem sich Aufgaben im Code direkt an ein Modell übergeben lassen. Für die Nutzung gelten wöchentliche Limits, also eine gedeckelte Kapazität pro Abrechnungszeitraum.

Eine temporäre Erhöhung dieser Kapazität um 50 Prozent läuft laut Ankündigung am 14. September aus. An ihre Stelle tritt eine dauerhafte Anhebung um 25 Prozent. Gegenüber dem aktuellen Zustand bedeutet das weniger verfügbare Kapazität, gegenüber dem Ausgangsniveau vor der temporären Erhöhung mehr. Anthropic stellt im Gegenzug mehr Kontrolle und Transparenz über den Verbrauch in Aussicht.

Für Teams, die sich an das höhere Niveau gewöhnt haben, ist das eine spürbare Änderung des Arbeitsrahmens – und zwar zu einem festen Datum. Wer Kapazität in Sprints oder Releaseplanungen einkalkuliert hat, muss neu rechnen.

Was die beiden Fälle gemeinsam haben

Die Ursachen unterscheiden sich, das Muster ist dasselbe: Die Leistungsfähigkeit der eigenen Toolchain hängt an Entscheidungen Dritter, die kurzfristig fallen können. Dabei entstehen zwei unterschiedliche Abhängigkeitsebenen, die in der Praxis oft vermischt werden.

  • Modellabhängigkeit: Ein bestimmtes Modell steht plötzlich nicht mehr zur Verfügung. Prompts, Konventionen und eingespielte Arbeitsweisen sind aber auf dessen Verhalten abgestimmt.
  • Anbieterabhängigkeit: Das Werkzeug selbst – die Oberfläche, die Integration in die Entwicklungsumgebung, die Abrechnung – liegt bei einem Anbieter, dessen Geschäftsbeziehungen sich ändern können.
  • Kapazitätsabhängigkeit: Nicht der Zugang fehlt, sondern die nutzbare Menge sinkt. Das trifft besonders Teams, die KI-Unterstützung fest in Arbeitsabläufe eingebaut haben.

Praktische Konsequenzen für die Toolchain

Aus den beiden Meldungen lassen sich keine Empfehlungen für bestimmte Produkte ableiten. Wohl aber Fragen, die sich vor der nächsten Verlängerung eines Abonnements lohnen.

  1. Welche Modelle nutzen wir tatsächlich – und wofür? Wer eine schlichte Liste hat, welches Modell in welchem Arbeitsschritt zum Einsatz kommt, kann bei einem Ausfall gezielt umschalten statt improvisieren.
  2. Ist ein Wechsel technisch vorgesehen? Werkzeuge, die mehrere Anbieter unterstützen, verringern das Risiko eines einzelnen Vertragsendes. Der Fall Cursor zeigt, dass Vielfalt auf der Modellseite hilft, auch wenn ein Anteil wegbricht.
  3. Wie viel Kapazität brauchen wir realistisch? Verbrauchsdaten sind die Voraussetzung für Budgetplanung. Angekündigte Transparenzfunktionen sind nur dann nützlich, wenn jemand sie regelmäßig auswertet.
  4. Was passiert, wenn das Limit erreicht ist? Es braucht einen definierten Zustand für den Fall, dass mitten in der Woche keine Kapazität mehr verfügbar ist – inklusive der Frage, welche Aufgaben dann Vorrang haben.
  5. Bleibt die Arbeit ohne KI-Unterstützung möglich? Wenn Reviews, Tests und Dokumentation ausschließlich über ein Werkzeug laufen, wird ein Anbieterwechsel zum Projektrisiko.

Kostenplanung wird zur laufenden Aufgabe

Beide Fälle zeigen, dass die Kosten- und Kapazitätsseite von KI-Werkzeugen nicht einmalig kalkuliert werden kann. Temporäre Erhöhungen können auslaufen, Verträge zwischen Anbietern können enden. Wer KI-Unterstützung produktiv einsetzt, sollte diese Posten wie andere Betriebskosten behandeln: mit einem festen Termin für die Überprüfung, mit dokumentiertem Verbrauch und mit einer Einschätzung, welche Alternative im Bedarfsfall greift.

Sinnvoll ist außerdem, Abhängigkeiten nach Kritikalität zu sortieren. Ein Werkzeug, das einzelne Entwickelnde beim Schreiben von Code unterstützt, ist ersetzbarer als eine Automatisierung, die in Build- oder Deployment-Prozesse eingebunden ist. Je tiefer die Integration, desto sorgfältiger sollte der Ausstiegspfad beschrieben sein.

Einordnung

Für Web- und Softwareprojekte heißt das: KI-Werkzeuge gehören inzwischen zur Infrastruktur und sollten dieselbe Aufmerksamkeit erhalten wie Hosting, Datenbanken oder Schnittstellen zu Drittsystemen. Wer Modelle austauschbar hält, Verbrauch messbar macht und den Betrieb ohne KI-Unterstützung nicht verlernt, bleibt handlungsfähig, wenn ein Anbieter kurzfristig andere Entscheidungen trifft. Die beiden Meldungen sind dafür weniger ein Alarmsignal als ein Anlass, die eigene Toolchain einmal bewusst durchzusehen.

Quellen