Anthropic verschärft Claude-Code-Nutzungslimits ohne Vorankündigung

• Seit Anfang dieser Woche hat Anthropic die Nutzungslimits für Claude Code-Nutzer ohne Vorwarnung verschärft
• Vor allem unter Power-Usern des Max-Plans für 200 US-Dollar pro Monat nahm der Unmut stark zu; beim Erreichen des Limits erscheint lediglich die Meldung „Claude usage limit reached“, ohne konkrete Erläuterung
• Da die Limits ohne vorherige Information oder Änderungsankündigung gesenkt wurden, hielten manche Nutzer dies irrtümlich für ein Downgrade ihres Abos oder einen Fehler beim Usage-Tracking
• Anthropic erklärte offiziell lediglich ohne nähere Details, dass „einige Nutzer langsame Antworten erleben“, nannte aber weder einen genauen Zeitplan für die Behebung noch die Ursache
• Auch API-Überlastung und Netzwerkfehler traten begleitend auf, was den Unmut weiter verstärkte; Nutzer fordern nun mehr Vertrauen durch Transparenz sowie klarere Limits und bessere Kommunikation

---

Plötzliche Verschärfung der Nutzungslimits und Verwirrung

• Seit vergangenem Montag wurden die Claude-Code-Nutzungslimits plötzlich verschärft, wodurch viele Nutzer unerwartet an Beschränkungen stießen
• Es wird nur die Meldung „Claude usage limit reached“ angezeigt sowie der Hinweis, dass die Sperre nach einer bestimmten Zeitspanne (einigen Stunden) aufgehoben werde; konkrete Angaben zu den geänderten Limits fehlen
• Besonders unter teuren Abonnenten wie im 200-Dollar-Max-Plan wuchsen Misstrauen und Verwirrung durch vermutete Fehler beim Usage-Tracking und das Missverständnis eines Plan-Downgrades
• Auf GitHub-Issue-Seiten häuften sich Beschwerden über die Intransparenz der Verbrauchsberechnung, etwa: „Ich habe in 30 Minuten nur ein paar Anfragen gestellt und trotzdem das Limit von 900 Nachrichten überschritten.“
• Ein Nutzer beklagte, mit diesem Limit sei Projektarbeit unmöglich, und fügte hinzu, dass „Gemini oder Kimi ebenfalls kein Ersatz“ seien

Offizielle Stellungnahme und Netzwerkprobleme

• Anthropic erklärte lediglich, dass „einige Nutzer langsame Antworten erleben“, vermied aber weitere Erläuterungen
• Im gleichen Zeitraum traten API-Overload-Fehler und Netzwerkausfälle gleichzeitig an vielen Stellen auf, während die offizielle Statusseite weiterhin 100 % Verfügbarkeit anzeigte — ein offensichtlicher Widerspruch
• Zusätzlich verstärkte eine inoffizielle und variable Struktur, bei der Limits und verfügbare Kapazität je nach Nachfrage schwanken, die Verwirrung

Verwirrung durch komplexe Tarifstruktur und Usage-Politik

• Anthropics Tarifmodell bietet nur abgestufte Beschränkungen und Hinweise, aber keine klare Garantie für ein bestimmtes Nutzungsvolumen; bei Free/Pro/Max wird statt eines eindeutigen Maximums lediglich darauf verwiesen, dass es von der Nachfrage abhängt
  • Max-Tarif: offiziell 20-mal mehr Nutzung als Pro, Pro wiederum 5-mal mehr als Free — absolute Grenzwerte werden jedoch nicht veröffentlicht
  • Auch beim kostenlosen Limit wird ausdrücklich darauf hingewiesen, dass es „je nach Nachfrage variiert“, womit keine absolute Nutzungsgarantie besteht
• Nutzer konnten vor dieser jüngsten Verschärfung den Dienst teils in einem Umfang verwenden, der API-Aufrufen im Wert von mehr als 1.000 US-Dollar pro Tag entsprach, weshalb sie den Max-Plan bereits als instabiles und langfristig schwer tragfähiges Modell betrachteten
• Daher überraschte die Verschärfung an sich viele nicht; als größtes Problem wird jedoch der Mangel an Transparenz genannt
  • Eine typische Rückmeldung lautete: „Kommuniziert transparent. Fehlende Kommunikation zerstört Vertrauen.“

Das Kernproblem: Kommunikation und Vertrauen

• Einige Nutzer zeigen zwar Verständnis dafür, dass die Limits des Max-Plans langfristig womöglich nicht tragfähig sind, betonen aber die Forderung: „Kommuniziert einfach transparent.“
• Änderungen ohne Vorankündigung und unklare Hinweise führen zu Vertrauensverlust bei den Nutzern
• Klare Informationen zu Limits, frühzeitige Kommunikation und schnelle Reaktion auf Probleme sind entscheidend, um den Dienst stabil zu betreiben und das Vertrauen der Kunden zu erhalten

[princox]

Da es sich um ein Produkt an der vordersten Front des agentischen Codings handelt, scheint sich ziemlich viel Traffic darauf zu konzentrieren..

[GN⁺]

Hacker-News-Kommentare

• Ein Nutzer, der anonym bleiben wollte, erwähnte, dass er sein Projekt nach Einführung der Nutzungsbeschränkungen nicht mehr weiterführen konnte. Es fühle sich an, als habe er das Vibe-Limit erreicht und jetzt sei der Zeitpunkt gekommen, wieder selbst zu denken

  • Das stimmt schon, aber die grundlegende Prämisse, die diese Firmen verkaufen, ist doch, dass man einen erheblichen Teil des „Denkens“ auslagern kann, und auch die Investitionen in AI hängen stark an dieser Annahme. Dass hier so viel Geld hineingeflossen ist und der Markt trotzdem unverändert bleibt, wirkt etwas seltsam
  • Vermutlich wird es nicht bei ein bisschen Nachdenken bleiben. Wenn man das Projekt fortsetzen will, braucht es wohl deutlich tiefere Überlegungen, vielleicht sogar extreme Denkleistung
  • Man fragt sich sarkastisch, wer hätte denn ahnen können, dass eine starke Abhängigkeit von Drittanbieterdiensten mit unklarer langfristiger Verfügbarkeit problematisch werden könnte. Es fühlt sich an wie eine Rückkehr zur Zeit kostenpflichtiger Compiler oder entfernter Mainframes, und die Leute wiederholen dieselben Fehler immer wieder
  • Ich bin mir zu 99 % sicher, dass diese Nutzer keine Vibe-Coder sind, die selbst gar nicht programmieren können. Solche Leute würden Tools wie lovable verwenden und keine Terminal-Tools anfassen
  • Ich bin wegen genau dieses Zitats in die Kommentare gekommen. Es überrascht mich, dass wir diesen Punkt schon erreicht haben, aber eigentlich ist es auch nicht überraschend

• Claude 4.0 ist in Bezug auf rohe Intelligenz nicht wirklich klüger als andere führende Modelle. Es ist nur für die richtige Tool-Nutzung beim Coden sehr gut feinabgestimmt. Wenn andere Modelle bald aufholen, wird es schwer, solche strengen Limits aufrechtzuerhalten. Google ist dabei in einer günstigen Position, weil sie selbst das Silizium bereitstellen und optimieren und dadurch beim absoluten Cashflow im Vorteil sind. Interessanterweise scheint hier in den Kommentaren kaum jemand die Compute-Scaling-Gesetze zu verstehen. Viele haben das Uber-Modell im Kopf, bei dem ein System irgendwann die Preise erhöhen muss, aber AI ist keine menschliche Arbeit. Mit der Zeit werden die Rechenkosten sinken. Kurzfristig Verluste in Kauf zu nehmen und darauf zu wetten, ist eher die Strategie mit der höchsten Erfolgswahrscheinlichkeit, und ich halte das nicht für dumm. Viele warten nur darauf, dass diese Blase platzt, um dann schlau sagen zu können: „Ich hab’s doch vorhergesagt“ – aber langfristig ist diese Richtung am Ende wohl die richtige

  • Selbst wenn Moore’s Law weiter gilt, sinken die Compute-Kosten nur alle 18 Monate um die Hälfte – und das unter der Annahme, dass die Effizienz der Computernutzung unverändert bleibt und auch die Stromeffizienz pro Rechenschritt gleich bleibt. In den Kommentaren gab es aber den Fall, dass ein 200-$-Monatsplan auf 4000 $ hochgeschossen ist; rein kostenseitig würde es 8 Jahre dauern, bis sich das angleicht. Ob man bereit ist, 8 Jahre lang Verluste zu tragen, ist fraglich
  • Wenn man ehrlich ist, sind die aktuellen Modelle selbst nicht so „smart“, wie sie behaupten. Von AGI sind sie weit entfernt. Wichtiger sind Kontextverwaltung, Aufgabentrennung, Retry-Mechanismen, Vermeidung von Endlosschleifen, passende Tool-Exposition und so weiter
  • Ich nutze keinen 100-$-Monatsplan, sondern zahle nach API-Preisen und verwende Claude Code sehr vorsichtig. Am ersten Tag ist es in eine Schleife geraten, hat dieselben zwei falschen Lösungen wiederholt und erst aufgehört, nachdem es 30 $ verbrannt hatte. Seitdem gebe ich pro Tag etwa 3 bis 5 $ aus und erreiche damit effizient ziemlich viel. Anthropic sollte einen Weg finden, Entwickler dazu zu motivieren, Claude Code klüger zu nutzen. Wenn man es nicht im Griff hat, dreht es wirklich durch und läuft aus dem Ruder
  • Das Problem der Modelle ist, dass sie Unmengen nutzlosen Contents ausspucken. Solange die Branche klein ist, ist diese Art von Verschmutzung noch kein großes Problem, aber wenn das weltweit skaliert, wird die Nachbereitung nicht trivial
  • Claude ist auch okay, aber wenn man „Smartness“ braucht, ist das eine andere Sache. Persönlich habe ich den Eindruck, dass Mistrals medium 3 oder devstral medium unterschätzt werden. Beide sind nicht „smart“, aber wenn man für einfache Aufgaben brauchbaren Code braucht, sind sie preislich wirklich stark

• Ich habe Claude Code mit dem 20-$/Monat-Basisplan für ein Side-Project ausprobiert. Ich habe nicht einmal meine gesamte Arbeitszeit darauf verwendet, und trotzdem waren die Aufrufe mehr als ausreichend. Ich dachte, ich würde das 20-$-Limit schnell erreichen, habe es aber am Ende nicht geschafft. Ehrlich gesagt musste ich vieles, was die AI nicht konnte, selbst korrigieren oder von Hand coden, aber der Token-Verbrauch wirkte wirklich großzügig. Im Vergleich zu API-Preisen fühlte es sich an, als würde ich täglich Token im Wert von 10 bis 20 $ verbrauchen. Wahrscheinlich wurden die Limits anfangs extrem großzügig gesetzt, um Nutzer zu gewinnen, und jetzt zieht man sie an, weil die Kapazität nicht mehr reicht. Wie im Artikel erwähnt: Ich kann mir kaum vorstellen, wie viel man coden muss, um die Grenze des 200-$/Monat-Plans zu überschreiten

  • In Claude Code gibt es unzählige Möglichkeiten, Tokens effizienter zu nutzen. Ich vermute vorsichtig, dass bald ein eigenes Claude-Code-Modell kommen könnte. Nach meinen Experimenten wurden viele Tokens zum Beispiel dadurch verschwendet, dass ein komplettes Python-Skript immer wieder neu eingelesen wurde, nur um den Kommentarstatus zu prüfen, oder ein R-Skript erneut gelesen wurde, nur um zu kontrollieren, ob Klammern geschlossen sind. Wenn man schon solche ineffizienten Muster beseitigt, ließe sich eine Menge Ressourcen sparen
  • Solche Limits ändern sich derzeit oft sehr schnell, manchmal wöchentlich oder sogar innerhalb weniger Tage, und sie unterscheiden sich je nach Uhrzeit, Standort oder Erstellungsdatum des Accounts
  • Ich habe in CC schon mit nur einer Anfrage innerhalb einer Stunde das Limit erreicht. Es war nicht einmal Opus. Mit der Zeit erscheint zwar fast immer eine Art Vorwarnung, aber es ist schade, dass die Limits nicht klar ausgewiesen werden und es stattdessen so wirkt, als wolle man nur auf höhere Pläne upsellen
  • Der Thinking-Prozess ist deutlich ineffizienter als normales Chatten. Wenn man viel davon nutzt, kann man schnell Hunderte Dollar ausgeben
  • Wenn du das Limit nicht erreichst, heißt das vielleicht einfach, dass du deine Prompts kreativer formulieren solltest. Ich habe schon Prompts so angelegt, dass das System danach fast eine Stunde lang selbstständig arbeitet und damit das Limit erreicht. Man kann Unteragenten erstellen und parallel betreiben oder Aufgaben über lange Zeit vollständig automatisiert laufen lassen. Es lohnt sich, breiter zu denken als nur „mach bitte diese eine Sache“

• Wenn Apple ein M4 MacBook verkaufen und dann ohne jede Warnung die Leistung auf M1-Niveau senken würde, gäbe es einen riesigen Aufschrei in Tech-Medien und bei Verbraucherschützern. Aber wenn AI-Firmen einem für 100 Dollar Nutzungsrechte verkaufen und dann stillschweigend die Leistung reduzieren, bleibt es ruhig. Ich frage mich, wie so etwas möglich ist

  • Aus Sicht des Unternehmens ist die Kapazität begrenzt, und man möchte allen Nutzern ein vernünftiges Produkt bieten. Es scheint extrem schwierig gewesen zu sein, sinnvolle Limits festzulegen und durchzusetzen. Wahrscheinlich tun sie sich schwer damit, die tatsächliche Kapazität und die Zahl der Teilnehmenden vorherzusagen. Es gibt noch nicht viele Wettbewerber, und auch bei den Preisen gibt es keinen echten Maßstab. Ich hoffe, dass sich das künftig verbessert

• Vermutlich wird das Ganze gerade noch mit Verlust betrieben, daher finde ich nicht, dass schon der richtige Zeitpunkt zum Ärgern ist. Bei Cursor ist die Preispolitik ähnlich intransparent. Ich zahle für den Max-Plan, aber laut API-Report habe ich bereits fast 1000 $ an Nutzung verursacht. Ich weiß nicht einmal, wie viel Kontingent noch übrig ist, und auch die Preisangaben aus der API erscheinen mir nicht schlüssig

  • Ein Kollege von mir behauptet, er habe diesen Monat 1000 $ pro Woche verbrannt. Für das Unternehmen ist das erstaunlich, wenn die Abo-Gebühr doch nur 200 $ im Monat beträgt
  • Wir haben gestern gerade unsere Closed Alpha beendet und überlegen derzeit die optimale Preisstrategie. Falls ihr Feedback geben könntet, wären wir für einen Blick auf https://www.charlielabs.ai/pricing sehr dankbar
  • Mich würde interessieren, mit welchem Tooling du die Preise prüfst. Ist es cursor-stats?
  • Ich teile nicht die Ansicht, man müsse großzügig sein, nur weil das Ganze mit Verlust läuft. Ich bin diese Produkte leid, die ohne klares Erlösmodell einfach erst einmal starten

• Ich würde gern Videos von echten Workflows sehen, in denen Leute im Alltag tatsächlich an diese Limits stoßen. Ich selbst nutze sonnet hauptsächlich fürs Coden und habe beim 20-$/Monat-Plan nicht einmal das Basislimit erreicht. Ich verwende es für Spezifikationen, Dokumentation, Wiederholungsaufgaben auf Basis bekannter Beispiele oder für den wiederholten Aufbau bestimmter Services. Wenn es nicht um das Umschreiben der gesamten Codebase geht, ist es bei kleineren Änderungen oft schneller, selbst Hand anzulegen, statt das Problem erst auf Englisch zu erklären und dann einen großen AI-Zyklus anzustoßen

  • Bei mir passiert das mit Opus und langen Workflows. Konkret teile ich in zwei große Workflows auf – Planung und Implementierung – und allein für Ideenrecherche und die Erstellung des Planungsdokuments fallen API-Kosten von etwa 10 bis 30 $ an. Beim Review korrigiere ich kleine Fehler oder unnötige Ausschweifungen selbst und gehe dann in der nächsten Phase zur Implementierung über. Die Implementierungsphase ist sogar eher günstiger. Auf Basis dieses Planungsdokuments lasse ich dann automatisch sogar GitHub-PRs erzeugen. Um beim 100-$-Max-Plan das Rate-Limit zu erreichen, reicht es, einen solchen Zyklus innerhalb von 5 Stunden drei- bis viermal zu wiederholen. Man kann Opus auch einfach komplexe Anweisungen hinwerfen, und die Zuverlässigkeit ist sehr hoch. Wenn man Code nur für einfache Interaktionen nutzt, erreicht man das Limit fast nie. Es sind wohl meist die Vibe-Coder, die da regelmäßig durchbrechen
  • Wenn der Punkt kommt, an dem AI nicht mehr in die richtige Richtung konvergiert, muss am Ende doch wieder der Mensch selbst den Abschluss machen
  • Mich würde interessieren, ob du Claude Code zusammen mit sonnet nutzt. Über das Web wirkt das Limit sehr großzügig
  • Diese Woche konnte ich trotz Max-Plan nicht einmal einfache Aufgaben zuverlässig erledigen. Es ist nicht nur so, dass Max-Nutzer überlastet wären. Es fühlt sich an, als würden willkürlich jederzeit Rate-Limits greifen. Manchmal wird sogar schon der erste Prompt blockiert
  • Insgesamt ist es von Hand zwar schneller, aber ich arbeite interrupt-driven und springe zwischen mehreren Tasks hin und her. Deshalb werfe ich einfach schnell einen Prompt hinein und lasse die Arbeit im Hintergrund laufen, während ich warte. Selbst wenn der Agent dreimal so lange braucht, kostet mich das nur ein paar Sekunden fürs Tippen des Prompts

• Vor ein paar Tagen habe ich in zwei Projekten große Refactorings gemacht und parallel noch Designarbeit für zwei weitere Projekte erledigt. Als ich meine Gemini-API-Nutzung geprüft habe, hatte ich an einem Tag bereits 200 $ verbraucht. Nutzer können das noch deutlich intensiver fahren. Ich glaube nicht, dass bei einer 200-$/Monat-Flatrate für das Unternehmen viel Marge übrig bleibt. Künftig wird es wohl Systeme geben, die Arbeit unter Kostenaspekten intelligent verteilen. openrouter scheint sich in eine ähnliche Richtung zu bewegen, aber für korrektes Routing wird man eine enorme Menge an Kontextinformationen brauchen

• Nach Auftreten der Nutzungslimits gab es die Aussage: „Das Projekt kommt wirklich nicht mehr voran.“ Es wurden auch Gemini, Kimi und andere ausprobiert, aber es habe kein Tool mit einem so umfassenden Funktionsset wie Claude Code gegeben. Das wurde als PMF, also Product-Market Fit, bewertet

• Ich habe diese Woche den 200-$/Monat-Plan begonnen und zuvor ohnehin monatlich 300+ $ für API-Tokens ausgegeben. Dabei dachte ich noch: „Wie kann sich das für Anthropic überhaupt rechnen?“ Dann kamen aber ständig API-Overload-Fehler, sodass ich den Plan am Ende gekündigt habe und wieder zu API-Tokens zurückgekehrt bin. Ich weiß nicht, was der Sinn dieser Politik ist, aber ich bin bereit, dafür zu zahlen. Man sollte nicht einfach nur mit „200 $/Monat“ werben, sondern dann auch den Zugang zuverlässig garantieren

  • Mich würde interessieren, ob du diese Erfahrung mit Opus gemacht hast. Und auch, welche Art von Aufgaben du bearbeitet hast. Ich habe nur dann massenhaft Tokens verbraucht, wenn ich mit einer großen 2,5-MB-Quelldatei gearbeitet habe. Ansonsten schöpfe ich selbst den 100-EUR-Plan nicht aus. Ich nutze fast nur Opus
  • Ich frage mich grundsätzlich, ob die API-Preise nicht von vornherein viel höher angesetzt sind, als es den tatsächlichen Kosten entspricht. Ich habe einfach mal 5 $ aufgeladen und zum Test damit herumgespielt, und die Berechnung lief etwa 30 Minuten, was gefühlt eher 3 Stunden Nutzung entsprach. Grob wären das 10 $ pro Stunde und damit 90.000 $ im Jahr. Ich bin noch nicht überzeugt, dass Kauf und Betrieb von GPUs tatsächlich 90.000 $ pro Jahr kosten. Ich habe bislang nicht den Eindruck, dass die Kosten der GPU-Infrastruktur weit über ein normales Hardware-Investment hinausgehen

• Es ist schwer zu sagen, ob die Servicequalität absichtlich gesenkt wurde oder ob die Nachfrage so schnell gestiegen ist, dass man die Limits vorübergehend als Notmaßnahme reduziert hat. Wenn weiter zusätzliche Nachfrage hinzukommt, könnten diese Einschränkungen sogar dauerhaft noch strenger werden. Ich glaube nicht, dass Anthropic gerade ausgerechnet jetzt versucht, die COGS zu optimieren. Es gibt die Chance, den gesamten DevTools-Markt zu erobern, dazu viel Cash und starke Investitionsbereitschaft – in so einer Lage die Produktstärke abzuschwächen, wäre ziemlich kurzsichtig

  • Viele Nutzer sind Cursor extrem schnell wieder den Rücken gekehrt. Für mich ist ein IDE-Wechsel eine große Sache, deshalb habe ich Cursor gar nicht erst ausprobiert. Claude Code ist konzeptionell viel besser und muss nicht zwingend an eine IDE gekoppelt sein. Gerade deshalb ist aber auch der Wechsel zu einem Wettbewerber einfacher. In diesem Sinne bergen die modelleigenen Eigenschaften von Claude Code paradoxerweise auch das Risiko, dass Marktanteile letztlich bedeutungslos werden könnten.