Anthropic hängt auch den Rest des Agenten an den Zähler

Die E-Mail kam heute Morgen, mit dem orangefarbenen Stern und dem warmen Business-Ton.

Ab dem 15. Juni bekommt mein Max-20x-Tarif ein monatliches Guthaben von 200 $ für das Claude Agent SDK und claude -p. Alles, was darauf aufbaut (Conductor, OpenClaw, Harnesses von Drittanbietern), zieht aus demselben Topf. Wenn das Guthaben aufgebraucht ist, stoppt die programmatische Nutzung, es sei denn, du aktivierst „extra usage", abgerechnet zu API-Preisen. Die Subscription-Limits für interaktiven Claude Code und Chat bleiben unverändert.

Das ist die ganze Änderung, jedenfalls so, wie mein Tarif sie mir verkauft.

Ich habe es zweimal gelesen. Eine dieser sorgfältig warmen Ankündigungen, bei denen die Nachricht im Negativraum lebt. „Du bekommst jetzt ein monatliches Guthaben von 200 $" klingt nach Zusatz. Die interessante Frage ist, was vorher da war und jetzt nicht mehr.

Die Rechnung

Bis zum 15. Juni teilte sich meine gesamte Claude-Nutzung einen Topf. Interaktiver Claude Code im Terminal, Chat im Web, headless -p-Skripte, GitHub Actions, alles, was über das Agent SDK lief. Dasselbe Subscription-Rate-Limit. Das Limit war großzügig genug, dass du mit aggressivem Scripting ein Token-Volumen durchpushen konntest, das bei API-Preisen etwa 2000 $ im Monat kosten würde. Die genaue Zahl hängt davon ab, wie stark du mit den 5-Stunden-Fenstern geflirtet hast, aber die Größenordnung stimmt. Die intensivsten Nutzer holten rund 10× den API-äquivalenten Wert aus einem 200-$-Tarif.

Ab dem 15. Juni teilt sich der Topf. Interaktiv bleibt, wo es war. Programmatisch bekommt ein eigenes Guthaben, das, rein zufällig natürlich, genau dem entspricht, was du zahlst. Pro: 20 $. Max 5x: 100 $. Max 20x: 200 $.

Für einen intensiven Scripter sind das etwa zehnmal weniger Budget für den Teil, der eigentlich zählte, verpackt in Sprache, die wie ein Bonus klingt. Für jemanden, der das SDK nie angerührt hat, ist es ein kleines kostenloses Guthaben, das in einem ansonsten unveränderten Account auftaucht.

Beide Beschreibungen stimmen. Die Frage ist, welche meine ist.

Zwei Lesarten, beide wahr

Bis letzte Woche war es technisch gegen die Bedingungen, aber praktisch geduldet, einen Harness eines Drittanbieters auf einer Claude-Subscription laufen zu lassen, mit periodischen Account-Sperren, die daran erinnerten, dass die Toleranz an Bedingungen geknüpft war. Die neue Regelung macht es explizit und legal. Du bekommst 200 $ Budget zu API-Preisen für den Use Case, der vorher nicht wirklich erlaubt war, und deine interaktive Subscription funktioniert weiter wie immer. Leute ohne Skripte bekommen ein kleines kostenloses Guthaben. Die Minderheit, die für 200 $ Subscription 2000 $ Compute verbrannte, hört auf, die gemeinsamen Rate-Limits für alle anderen runterzuziehen.

Das ist die bullische Lesart. Sie stimmt.

Es gibt auch eine bearische. Die Form der Änderung ist ein 10×-Downgrade für den programmatischen Fall, verpackt als Geschenk, von einer Firma, die seit Monaten die Spielregeln bei Rate-Limits verschiebt. Die Sprache „Hol dir dein kostenloses Guthaben" soll weich landen, aber die neue Obergrenze liegt deutlich unter der alten, für genau den Use Case, der jetzt abgerechnet wird. Die Leute, die die lautesten Harnesses gebaut haben, die, die vor einem Jahr ihren Kollegen geraten haben, zu Claude zu wechseln, sind die, die am meisten verlieren.

Das stimmt auch.

Ich pendle ehrlich gesagt zwischen beiden hin und her. Die Änderung ist keine einzelne Zahl. Sie ist eine Neusegmentierung. Interaktive Nutzer, die ihr Token-Volumen nie ausreizen, bekommen dasselbe Angebot. Programmatische Nutzer, die das tun, zahlen näher an dem, was ihr Compute Anthropic tatsächlich kostet.

Wenn deine Arbeit nicht auf claude -p aufbaut, sieht der 15. Juni aus wie der 14. Juni plus Kleingeld. Wenn deine Arbeit ein Stapel Headless-Skripte war, ist es ein 10× kleineres Budget für den Teil, der zählte.

Was wirklich passiert

Aus Anthropics Sicht gelesen, ist das Bild einfacher, als die Ankündigung es klingen lässt. Sie müssen nichts gewinnen. Sie müssen die Population an Entwicklern, die Headless-Skripte auf Subscription-Abrechnung laufen lassen, klein genug halten, damit die Subscription-Preise weiter funktionieren. Das ist die eigentliche Bedingung, nicht „alle Skripte stoppen".

Anthropic versucht nicht, programmatische Nutzung zu eliminieren. Sie könnten es nicht, selbst wenn sie wollten, denn SDK und CLI sind ihre eigenen Produkte und Headless-Mode ist ein Feature, das sie bewusst gebaut haben. Der Punkt ist, dass Subscription-Preise für sie nur dann funktionieren, wenn der mediane Subscriber ein Mensch ist, der an einem Prompt tippt, mit natürlichen Pausen und menschlichem Durchsatz. Die 10×-Power-User waren eine echte Workload auf einem Preismodell, das für eine andere Workload entworfen war, und diese Lücke wurde mit jedem Monat teurer, weil die Inference-Nachfrage wuchs.

Du kannst dich am Framing reiben (die PR rund um das Ganze ist wirklich schlecht) und trotzdem sehen, dass der zugrundeliegende Schritt eine Preiskalibrierung ist. Anthropic versucht nicht, den Entwicklermarkt zu verlieren. Sie versuchen, den Entwicklermarkt so zu bepreisen, wie man einen Entwicklermarkt bepreist.

Der Teil von mir, der seit einem Jahr Skripte gegen das Ding laufen lässt, ist genervt. Der Teil, der für Kunden Inference-Kosten kalkuliert, sieht die Rechnung und zuckt mit den Schultern. Beide Teile sind echt und ich glaube nicht, dass sie sich vertragen.

Die Pre-IPO-Revenue-Ramp-Lesart ist wahrscheinlich auch teilweise wahr. Investorendruck, die 1,4-Billionen-$-Zahl, der Enterprise-Pivot. Nichts davon ist entscheidend. Auch ohne diese Zwänge würde dieselbe Rechnung innerhalb eines Jahres dieselbe Art von Schritt erzwingen. Compute wird nicht schnell genug billiger, um mit der wachsenden Nachfrage Schritt zu halten. Die Subventionsphase wäre planmäßig zu Ende gegangen.

Der tmux-Workaround

Der Workaround ist offensichtlich genug, dass er innerhalb von Stunden nach der Ankündigung auftauchte. Lass das echte Claude Code in einer tmux-Session im normalen interaktiven Modus laufen. Steuere es aus einem Orchestrator mit tmux send-keys. Hänge dich an die Lifecycle-Events so an, wie du es in jedem Harness machen würdest. Subscription-Rate-Limits, keine API-Credits.

Der Haken ist auch offensichtlich. Anthropic kann das Muster erkennen. Wahrscheinlich werden sie es. Sobald sie es tun, baut jemand ein anderes Muster. Dann erkennen sie das. Das Spiel geht weiter, solange beide Seiten es lohnenswert finden.

Es ist dasselbe Gleichgewicht wie der Punkt zur Preiskalibrierung, nur von der anderen Seite. Anthropic muss nicht jedes Muster erkennen. Sie brauchen Erkennung, die teuer genug ist, dass die Population an Entwicklern, die Headless-Skripte auf Subscription-Abrechnung fahren, klein genug bleibt, damit die Preisrechnung weiter aufgeht. Die andere Seite muss nicht jede Runde gewinnen. Jeder neue Workaround muss bloß schneller zu finden sein, als die nächste Erkennungsregel ausgerollt werden kann.

In derselben Woche wie diese Ankündigung waren Beschwerden über die Qualität von Opus 4.7 im Vergleich zu 4.6 laut. Das ist ein anderes Thema, aber es summiert sich. Wenn sich das Modell schlechter anfühlt und die Preisgestaltung sich schlechter anfühlt, im selben Monat, wird die Geduld für „glaubt uns, das ist nur Kalibrierung" knapp. Ich habe meine eigenen Meinungen zu 4.7, aber darum geht es in diesem Text nicht.

Was ich tue

Vieles, woran ich arbeite, sitzt auf genau so einer Infrastruktur. Tools, die ich baue und benutze, Produkte, die agent-adjacent shippen, Orchestrierung, die meinen eigenen Workflow antreibt. Wenn sich ein Pricing-Primitiv bewegt, sehe ich es zuerst aus dem Inneren des Designproblems, bevor ich es als Kunde sehe.

Meine Orchestrierung läuft schon in tmux mit Hooks, aus Gründen, die älter sind als diese Änderung und nichts mit ihr zu tun haben. Im engen Sinne bricht der 15. Juni also nichts bei mir. Die Headless-Skripte, die ich als claude -p aus einer interaktiven Session heraus hätte fahren können, fahre ich nicht. Teils aus Geschmack. Teils, weil ich dem impliziten Zuschuss nie genug vertraut habe, um produktionsreife Dinge darauf zu bauen.

Das Persönliche ist aber nicht die Lehre. Die Lehre ist, dass jeder Agent-Harness, der auf einem einzelnen Pricing-Primitiv eines Anbieters baut, ein Ablaufdatum hat, das an dieses Primitiv hängt. claude -p war so ein Primitiv. Günstig. Subscription-bepreist. Integriert. Einfach aufzurufen. Leute haben tägliche News-Briefings darauf gebaut. GitHub-PR-Bots. TDD-Verifier. Bildauswertungs-Pipelines. Eigene UIs auf dem SDK. Keiner dieser Nutzer hat etwas falsch gemacht. Sie haben auf einem Preis gebaut, der für den Verkäufer nicht tragbar war.

Das Orchestrierungs-Pattern ist der Teil, der überlebt. Was unter der Schnittstelle sitzt, egal ob claude -p, codex oder ein lokales Modell, ist der Teil, der ausgetauscht wird. Wenn dein Harness konkret an claude -p verdrahtet ist, baut die nächste Tarifänderung deinen Harness neu. Wenn er auf „eine CLI läuft in einer Session, an die ich Keys senden kann" verdrahtet ist, ist der CLI-Tausch eine Konfigurationsänderung.

Mein Ziel ist, dass ein Engine-Wechsel Stunden kostet, keine Monate. Das macht mich nicht immun gegen Preisänderungen, nichts tut das, aber es ändert, was sie mich kosten. Aus einem Rebuild wird eine Routing-Entscheidung. Aktuell nutze ich Claude für das meiste und Codex für ein paar Dinge, wo es messbar besser ist. Wenn die nächste Biegung dieser Kurve kommt, und sie wird kommen, möchte ich, dass es eine Routing-Entscheidung wird und kein Rebuild.

Am 8. Juni hole ich mir das Guthaben ab. „Extra usage" lasse ich aus, damit mir kein außer Kontrolle geratenes Skript eine vierstellige Überschreitung bescheren kann. Und ich mache weiter, was ich schon vorher gemacht habe.

Die Ära, in der man produktionsreife Agent-Workflows auf einem subscription-bepreisten Zuschuss baut, schließt planmäßig. Der 15. Juni ist lauter als die Schritte davor. Es werden mehr folgen.