Zwei der größten Firmenkunden von Anthropic reduzieren ihren Einsatz von Claude deutlich: Microsoft senkte in der Cloud-Sparte das monatliche Budget pro Kopf von 100.000 auf 10.000 Dollar. Meta halbierte die Zahl der Beschäftigten mit Zugang zu Claude Code auf 30.000. Beide Konzerne setzen stattdessen stärker auf eigene KI-Werkzeuge.
Für Anthropic wird die enge Bindung an wenige Großkunden damit zu einem strategischen Risiko. Für alle anderen Unternehmen ist der Vorgang vor allem ein Hinweis darauf, wie schnell sich Werkzeugketten in der Softwareentwicklung verschieben können – und wie wenig verlässlich die Annahme ist, ein heute gesetzter Assistent bleibe auf Jahre hinaus gesetzt.
Was an diesen Zahlen interessant ist
Die Budgetkürzung bei Microsoft ist kein kleiner Korrekturschritt, sondern eine Reduktion um eine Größenordnung. Das deutet weniger auf Unzufriedenheit mit einem einzelnen Produkt hin als auf eine veränderte Beschaffungslogik: Wo ein Konzern eigene Modelle und eigene Entwicklungswerkzeuge betreibt, wird jeder externe Zukauf zur Frage der internen Verrechnung.
Bei Meta zeigt sich dasselbe Muster an der Nutzerzahl. Nicht das Werkzeug verschwindet, aber der Kreis derjenigen, die es verwenden dürfen, wird enger gezogen. In beiden Fällen bleibt offen, wie stark fachliche Gründe, Kostendruck oder strategische Unabhängigkeit den Ausschlag gegeben haben. Die Richtung ist dennoch eindeutig: weg von der breiten Lizenzierung eines externen Assistenten, hin zu internen Alternativen.
Die Lage im Mittelstand ist eine andere – das Risiko nicht
Mittelständische Unternehmen und Agenturen können keine eigenen Sprachmodelle trainieren und keine komplette interne Entwicklungsplattform aufbauen. Sie sind auf externe Anbieter angewiesen. Genau deshalb trifft sie eine Verschiebung im Anbietermarkt anders, aber nicht weniger hart.
Wenn ein Anbieter Preise anpasst, Kontingente ändert, ein Modell abkündigt oder die Verfügbarkeit in bestimmten Regionen einschränkt, lässt sich das nicht durch ein internes Ersatzprodukt auffangen. Es bleibt nur der Wechsel – und der ist umso teurer, je tiefer sich ein einzelnes Werkzeug in die tägliche Arbeit eingegraben hat.
Woran man Abhängigkeit im Entwicklungsalltag erkennt
Technische Bindung entsteht selten durch eine bewusste Entscheidung, sondern schleichend. Typische Anzeichen:
- Prompts und Anweisungen liegen verstreut in anbieterspezifischen Konfigurationsdateien statt an einem zentralen, dokumentierten Ort.
- Automatisierungen in der Build-Pipeline – also in den automatisierten Abläufen für Tests und Auslieferung – rufen eine herstellerspezifische Schnittstelle direkt auf, ohne Zwischenschicht.
- Code-Review-Prozesse setzen voraus, dass ein bestimmter Assistent verfügbar ist, und haben keinen definierten Rückfallpfad.
- Wissen über gute Arbeitsweisen steckt in den Köpfen einzelner Personen, nicht in überprüfbaren Richtlinien.
Keiner dieser Punkte ist für sich genommen dramatisch. Zusammengenommen führen sie dazu, dass ein Anbieterwechsel kein Konfigurationsthema mehr ist, sondern ein Projekt.
Modellunabhängig arbeiten: praktische Ansatzpunkte
Unabhängigkeit heißt nicht, auf KI-Unterstützung zu verzichten oder ständig parallel mehrere Abos zu bezahlen. Es heißt, die Wechselkosten niedrig zu halten.
- Abstraktionsschicht einziehen: Aufrufe an Sprachmodelle laufen über eine eigene schmale Schnittstelle im Projekt, nicht direkt aus dem Anwendungscode heraus. Ein Modellwechsel betrifft dann eine Stelle statt dreißig.
- Prompts versionieren: Systemanweisungen, Coding-Richtlinien und Projektkontext gehören ins Repository, nicht in ein Werkzeugmenü. So sind sie übertragbar und nachvollziehbar.
- Ergebnisse messbar machen: Wer Testabdeckung, Fehlerquoten und Durchlaufzeiten erhebt, kann einen alternativen Assistenten sachlich bewerten, statt nach Gefühl zu entscheiden.
- Qualitätssicherung unabhängig halten: Automatisierte Tests, statische Codeanalyse und verbindliche Reviews müssen funktionieren, egal welches Modell den Entwurf geliefert hat.
- Datenflüsse dokumentieren: Welcher Quellcode, welche Kundendaten gehen an welchen Dienst? Diese Dokumentation ist ohnehin nötig und macht einen Wechsel deutlich einfacher.
Verträge und Budgets realistisch planen
Die Entwicklung bei den beiden Großkonzernen zeigt auch, dass Budgets für KI-Werkzeuge kurzfristig revidierbar sein sollten. Lange Laufzeiten mit fixen Nutzerzahlen passen schlecht zu einem Markt, in dem sich Leistungsfähigkeit und Preismodelle im Halbjahresrhythmus ändern.
Sinnvoller ist es, den Einsatz zunächst auf klar umrissene Anwendungsfälle zu begrenzen, den Nutzen dort zu belegen und die Lizenzmenge daran auszurichten. Ein jährlicher Prüftermin, bei dem Werkzeuge, Kosten und Alternativen nüchtern verglichen werden, ersetzt das Prinzip Hoffnung.
Einordnung für Web- und Softwareprojekte
Für Web- und Softwareprojekte heißt das vor allem: Die Qualität eines Projekts darf nicht am konkreten KI-Assistenten hängen, sondern an Architektur, Tests und nachvollziehbaren Prozessen. Wer Prompts, Richtlinien und Schnittstellen sauber vom jeweiligen Anbieter trennt, kann ein besseres oder günstigeres Modell einsetzen, sobald es verfügbar ist – ohne Projektstillstand. Entscheidend ist damit nicht die Wahl eines Werkzeugs, sondern die Fähigkeit, diese Wahl jederzeit revidieren zu können.
