Goodbye Anthropic

Anthropic hat die Bedingungen für die Nutzung des Claude Agent SDK mit bestehenden Claude-Plänen geändert. Ab dem 15. Juni 2026 zählen Claude Agent SDK, claude -p, die Claude Code GitHub Actions Integration und Third-Party-Apps auf Basis des Agent SDK nicht mehr gegen die normalen Subscription-Limits. Stattdessen gibt es einen separaten monatlichen Agent-SDK-Credit: 20 Dollar für Pro, 100 Dollar für Max 5x und 200 Dollar für Max 20x. Danach läuft die Nutzung nur weiter, wenn Extra Usage aktiviert ist, dann zu Standard-API-Preisen. Die eigentlichen Bedingungen stehen hier: Use the Claude Agent SDK with your Claude plan.

Die X-Ankündigung klingt erstmal freundlich: Subscriptions bekommen jetzt Agent-SDK-Credits. Für mich ist es aber eine klare Produktgrenze. Genau die nicht-interaktiven und automatisierten Workflows, die Claude für mich wertvoll gemacht haben, werden aus der Flat-Rate-Subscription rausgenommen und in ein Usage-Modell verschoben.

Donnerstagmorgen, ich wach auf, Mail von Anthropic im Postfach. Programmatic Usage wird künftig in eigene Buckets sortiert. Agent SDK hier, claude -p dort, interaktive Nutzung nochmal woanders. Mein erster Gedanke war nicht “Ah, faire Produktdifferenzierung”. Mein erster Gedanke war: Oh shit, ich muss weg von Claude. 😅

Nicht weil ich das dramatisch finde, sondern weil ich meine Zahlen kenne. Ich erzeug ungefähr 1.900 Dollar Usage pro Monat. Diese 1.900 Dollar will ich monatlich nicht bezahlen und ehrlich gesagt kann ich’s auch nicht. Und dann wird’s halt real: Wenn meine Agenten nur funktionieren, solange Anthropic meine Nutzung querfinanziert, dann hab ich keine stabile Automatisierung gebaut. Dann hab ich auf einer Marketing-Flatrate gebaut.

Das ist für mich der Punkt, an dem ich meine Anthropic Subscription kündige. Nicht weil die Claude-Modelle plötzlich schlecht wären. Im Gegenteil: Opus ist für viele Coding- und Agent-Aufgaben weiterhin eines der besten Modelle. Genau deshalb hab ich die Subscription bezahlt — nicht weil ich die Claude-Produkte oder die Anthropic-UI besonders gut fand, sondern weil ich damit Zugang zu Opus hatte. Der Wert lag für mich im Modell, nicht im Produkt drumherum.

Was Claude Pro für mich wertvoll gemacht hat

Claude Pro war für mich nie nur ein besseres Chatfenster. Es war eine bezahlbare Rechenquelle für mein Bastelzeug. Besonders wichtig waren dabei claude -p und das Agent SDK, weil sie Claude aus dem interaktiven Chat rausgeholt haben.

Ich hab Automatisierungen um diese Schnittstellen herum gebaut. Dazu gehört auch mein eigener Telegram-Agent, der Claude als Backend nutzt (ja, ich hab sowas 🙈). Und genau solche Workflows sind wahrscheinlich der Grund, warum Anthropic diese Nutzung jetzt aus den normalen Subscription-Limits rauszieht: Es ist nicht mehr “ein Mensch chattet mit Claude”, sondern programmatische Modellnutzung mit potenziell sehr hohem Verbrauch.

Aber komm, es geht nicht nur um aggressive Power-User-Setups. Es gibt auch sehr harmlose und naheliegende Workflows. claude -p in einer CI/CD-Pipeline zu nutzen, um automatische Code-Reviews auf Pull Requests zu machen, ist kein Missbrauch. Das ist genau die Art von Entwicklerautomation, für die ein gutes Coding-Modell eigentlich prädestiniert ist. Anthropic nennt die Claude Code GitHub Actions Integration sogar explizit als Teil dessen, was künftig aus dem Agent-SDK-Credit bezahlt wird.

Anthropic-Marketing: “Baut Agents! Automatisiert eure Arbeit mit AI!” Anthropic-Kleingedrucktes: “aber blooooß nicht mit eurer Subscription” 🌚

Der andere große Punkt ist UX-Freiheit. Das Agent SDK macht es möglich, eine andere Oberfläche für dieselben Modelle zu bauen. Das ist wichtig, weil die Anthropic-Produkte für meinen Workflow ehrlich gesagt nicht die beste Software- und UX-Umgebung sind. Bei Claude Code im Terminal verliert man in längeren Sessions schnell den Überblick. Die Desktop-Integration fühlt sich für mich lieblos an. Dass ich mit dem Gefühl nicht allein bin, sieht man an einem Claude-Code-Issue, das eine offizielle Desktop-GUI fordert und konkrete Pain Points nennt: Chat-History-Management, Side-by-side-Ansicht für Codeänderungen, Dateibäume und Conversation Context sowie bessere Accessibility (anthropics/claude-code#5103).

Ich nutz dafür gern T3 Code ☺️ T3 Code beschreibt sich selbst als minimale Web-GUI für Coding Agents, aktuell unter anderem für Claude und OpenCode. Genau so eine Schicht ist für mich wertvoll: nicht weil sie ein anderes Modell liefert, sondern weil sie eine bessere Arbeitsoberfläche über bestehende Agenten legt. Ähnliche Projekte wie CCUX zeigen denselben Bedarf: eine Desktop-UX für Claude Code mit Sessions, Artifacts, Git-Integration und besserer Übersicht. Das gibt’s nicht trotz Anthropic, sondern wegen Anthropic. Weil die eigene UX für viele nicht reicht.

Warum Anthropic das tut

Naja, Geld halt. Was sonst.

Meine eigene Nutzung zeigt das Problem ziemlich gut: 1.900 Dollar Usage pro Monat, rund 100 Euro zahle ich dafür. Und ich bin garantiert nicht der einzige 🌚. Dass das nicht ewig so geht, ist keine Überraschung. Ein 100-Dollar- oder 200-Dollar-Credit ist in so einem Workflow kein Ersatz für die bisherige Subscription-Erwartung, sondern eher ein Übergangsschild Richtung API-Abrechnung. Agenten verbrauchen Token anders als Chat-Nutzer. Sie laufen länger, sie iterieren mehr, sie rufen Tools auf, sie lesen viel Kontext, sie probieren Dinge aus und machen Fehler, die wieder korrigiert werden müssen.

I get that, business-wise. Ne Subscription funktioniert, wenn der Median-User gelegentlich chattet oder interaktiv in Claude Code arbeitet. Sie funktioniert nicht, wenn Power-User wie ich sie als günstige Compute-Flatrate für autonome Systeme, CI/CD und nicht-interaktive Agenten benutzen.

Das macht die Produktstrategie ziemlich deutlich. Anthropic verkauft nicht einfach das beste Modell an der besten Stelle im Workflow. Anthropic verkauft einen Kosmos. Claude, Claude Code, Claude Desktop, Agent SDK, Credits, Extra Usage, API-Key-Pfade. Alles soll in die eigene Produkt- und Abrechnungslogik zurückführen. Wenn Opus in OpenCode besser funktioniert, ist das aus Nutzersicht ein Argument für OpenCode. Aus Anthropics Sicht ist’s ein Problem, weil der Wert dann im Modell liegt und nicht im kontrollierten Produktkosmos.

Und das ist nicht neu. Anthropic hat schon länger klargemacht, dass Third-Party-Produkte nicht einfach claude.ai-Login oder Pro-/Max-Plan-Limits für ihre eigenen Produkte anbieten dürfen. Anthropic schreibt’s selber: “Unless previously approved, Anthropic does not allow third party developers to offer claude.ai login or rate limits for their products” (Claude Agent SDK overview). OpenCode wurde dieser Weg schon vorher zugedreht: kein OAuth-Zugang mehr, keine Nutzung der Subscription-Limits über diesen Pfad (The New Stack).

Das Problem ist nicht, dass Anthropic Geld verdienen will. Das Problem ist, dass diese Änderung genau die Workflows trifft, die Claude für Entwickler besonders wertvoll gemacht haben. Wer Agenten ernsthaft nutzt, baut um Schnittstellen herum. Wenn diese Schnittstellen plötzlich ökonomisch oder technisch entwertet werden, ist das kein kleines Produktdetail. Es ist ein Signal: Verlasst euch nicht drauf, dass Consumer-Subscriptions eine stabile Grundlage für Agent-Infrastruktur sind.

Was jetzt?

Schnellste Variante: Claude Code weiter als Harness benutzen, aber den Modelltreiber austauschen. Der Punkt ist gerade nicht, sofort das ganze Tooling zu wechseln. Der Punkt ist, bestehende claude-Workflows, Aliases, Prompts, CI-Aufrufe und claude -p-Skripte möglichst unverändert weiterlaufen zu lassen, während im Hintergrund ein anderer Provider antwortet.

Schritt null, bevor ihr irgendwas migriert: Trackt eure Usage. Nicht irgendwann, sondern jetzt. Wenn ihr nicht wisst, was heute durch eine Subscription subventioniert wird, wisst ihr auch nicht, welche Kosten auf euch zukommen, wenn das Marketing vorbei ist. Ich nutz dafür gern CodexBar, weil’s sehr viele Provider unterstützt und mir zumindest ein Gefühl dafür gibt, welche Workflows wirklich teuer sind (war ne Weile ohne unterwegs und hab dann gemerkt: ohne ist dumm 🙈)

Das geht, wenn der Provider eine Anthropic-kompatible API anbietet. Claude Code lässt sich über ANTHROPIC_BASE_URL gegen einen anderen Endpoint richten. Ein einfacher technischer Proof of Concept ist Z.AI mit GLM:

export ANTHROPIC_AUTH_TOKEN="..."
export ANTHROPIC_BASE_URL="https://api.z.ai/api/anthropic"
exec claude "$@"

Wichtig: Für mich ist das kein Qualitäts-Ersatz für Opus. Ich hab GLM getestet und für meinen Use Case wieder verworfen. Die Antworten waren nicht stabil genug, teilweise mit chinesischen Textfragmenten (lol), und die Agent-Persönlichkeit war flacher als bei Opus. Aber als POC zeigt’s den entscheidenden Punkt: Claude Code ist nicht magisch. Es ist ein Harness. Wenn man den Endpoint tauschen kann, ist Anthropics Lock-in schwächer als es aussieht.

Der zweite Proof of Concept ist OpenAI bzw. ChatGPT/Codex als Treiber hinter Claude Code. Das ist fummeliger, weil die APIs nicht deckungsgleich sind. Dafür braucht man eine Anthropic-kompatible Zwischenschicht. LiteLLM kann einen /v1/messages-Endpoint bereitstellen; zusätzlich braucht man bei manchen Backends einen kleinen Kompatibilitätsproxy, der Anthropic-System-Prompts in normalen User-Kontext umschreibt, weil das ChatGPT-Subscription-Backend System-Messages anders behandelt.

Der Wechsel ist technisch einfacher als erwartet. Qualitativ ist er kein Drop-in-Replacement. Jedes Modell hat andere Stärken, andere Schwächen und fühlt sich im Agenten anders an. Ihr müsst das selber testen, nicht nur den Endpoint umbiegen.

uv tool install 'litellm[proxy]'
litellm --config config.yaml --port 4000

export ANTHROPIC_AUTH_TOKEN="dummy"
export ANTHROPIC_BASE_URL="http://localhost:4000"
claude -p "Sag kurz hallo"

Wenn man die Modellschicht ersetzen kann, verliert Anthropic einen Teil des Lock-ins. Für ne schnelle Migration ist das oft wichtiger als ne perfekte Architektur.

Die naheliegendste Variante innerhalb von Anthropic ist natürlich: Extra Usage aktivieren oder direkt API-Keys verwenden. Sauber, offiziell, vermutlich die stabilste Lösung. Aber dann sollte man ehrlich rechnen: Man bezahlt nicht mehr eine Subscription für Agent-Infrastruktur, sondern API-Usage mit einem kleinen monatlichen Rabatt davor.

Langfristig kann man auch das Harness wechseln. Codex, OpenCode, gibt’s alles. Aber das ist ein größerer Schritt. Für den akuten Fall ist interessanter, ob man die bestehende Claude-Code-CLI weiterverwenden kann, ohne sofort alle Automatisierungen umzubauen. Genau dafür sind diese POCs gedacht.

FYI: Das ist nicht nur theoretische Open-Source-Romantik. Der AkitaOnRails LLM Coding Benchmark zeigt einen direkten Vergleich, der für meine Argumentation viel relevanter ist als irgendein allgemeines Modell-Leaderboard: dasselbe Modell, Claude Opus 4.7, läuft in Claude Code und in OpenCode auf derselben Rails/RubyLLM-Aufgabe. Die Zahlen unten sind ein Snapshot aus den aktuellen Benchmark-Reports; bei Benchmarks immer nochmal die README und Reports prüfen, bevor man harte Schlüsse daraus zieht.

Modell	Harness	Ergebnis	Einordnung
Claude Opus 4.7	Claude Code	Tier 3 in der Solo-Variante; halluzinierte chat.complete, ca. $6.74, 11m	Das First-Party-Harness war hier nicht der beste Ort für das eigene Modell
Claude Opus 4.7	OpenCode	97/100, Tier A, korrekte RubyLLM-API, ca. $4.04, 18m	Dasselbe Modell lieferte im alternativen Harness deutlich bessere Korrektheit und niedrigere Kosten
Claude Opus 4.7 + Sonnet/Haiku Executor	Claude Code forced delegation	92/100 mit Sonnet, 90/100 mit Haiku	Claude Code konnte durch Delegation repariert werden, blieb aber hinter OpenCode solo zurück

Das ist genau mein Punkt: Opus ist das Wertvolle, nicht zwingend Claude Code. Wenn Anthropic mich daran hindert, Opus in dem Harness zu nutzen, in dem es für meinen Workflow besser funktioniert, dann reduziert Anthropic den Wert meiner Subscription. Nicht weil das Modell schlechter wird, sondern weil der Zugriff schlechter wird.

Mein Take

Die AI-Subscriptions, an die wir uns gewöhnt haben, waren nie die echte Preisstruktur. Sie waren Marketing. Loss-Leader-Marketing. Sie haben uns daran gewöhnt, sehr viel Modellleistung für sehr wenig Geld zu bekommen, damit wir Workflows, Gewohnheiten und Abhängigkeiten aufbauen.

Jetzt sehen wir den ersten klaren Weg zur Profitabilität: Nutzung, die zu teuer oder zu automatisierbar ist, wird aus der Flatrate rausgeschnitten und in Credits, Extra Usage oder API-Preise verschoben. Das passiert jetzt beim Agent SDK, bei claude -p und bei GitHub Actions. Wer glaubt, dass es dabei bleibt, hat die Kostenrechnung nicht gemacht.

Ob interaktive Claude-Code-Nutzung langfristig in der Flat-Rate bleibt, ist offen. Heute bleibt sie laut Anthropic unverändert in den normalen Subscription-Limits. Ich würd meine Architektur trotzdem nicht drauf wetten.

Also realtalk: Wer Agents betreibt, sollte nicht planen, dass Consumer-Subscriptions eine stabile Infrastrukturgrundlage bleiben. Modelle müssen austauschbar sein. Harnesses müssen portabel sein. Automationen dürfen nicht an einem einzigen Consumer-Plan hängen. Alles, was heute “unlimited genug” wirkt, ist nur so lange unlimited, bis es in der Kostenrechnung auffällt.

Konsequenz für mich: Ich setz in Zukunft stärker auf OpenCode und Flexibilität 🤓 Konkret heißt das: neue Agent-Workflows laufen bei mir zuerst über OpenCode, und bestehende Claude-Code-Automationen ziehe ich schrittweise aus der Subscription-Abhängigkeit raus. Nicht weil OpenCode magisch wäre, sondern weil’s mir erlaubt, Harness, Modell und Billing voneinander zu trennen. Wenn Anthropic zu teuer wird, muss ich wechseln können. Wenn OpenAI gerade besser oder günstiger ist, muss ich wechseln können. Wenn ein anderer Provider für einen bestimmten Workflow besser passt, muss ich wechseln können. Die Subscription darf nicht mehr die Architekturentscheidung sein.

Goodbye Anthropic heißt für mich deshalb nicht: Claude ist schlecht. Es heißt: Ich zahl nicht mehr für eine Subscription, deren wichtigster Nutzen gerade entfernt wird. Der Rest wartet wahrscheinlich nur drauf, als nächstes dran zu sein. Ich will meine Agenten nicht mehr um einen Anbieter herum bauen, sondern um Austauschbarkeit.