Wöchentliche Nutzungslimits für Claude Code

• Für den Dienst Claude Code von Anthropic wurden wöchentliche Nutzungslimits eingeführt
• Sie gelten sowohl für kostenlose als auch für zahlende Nutzer
• Nutzer unterliegen pro Woche einer Begrenzung bei der maximalen Anzahl an Abfragen oder der Menge verarbeiteter Tokens
• Die Einführung der Limits dient der Verhinderung von Missbrauch und der Sicherstellung der Stabilität von Systemressourcen
• Entwickler und Startups müssen bei der Nutzung der API besonders auf Ressourcenmanagement achten

---

Überblick über die Einführung wöchentlicher Nutzungslimits für Claude Code

Für den von Anthropic angebotenen Dienst Claude Code gilt nun eine neue Richtlinie mit wöchentlichen Nutzungslimits.

• Für alle Nutzer (kostenlos und kostenpflichtig) wird ein bestimmtes Limit für die Nutzung von Abfragen oder Tokens festgelegt
• Dieses Limit wurde eingeführt, um Missbrauch zu verhindern, eine faire Bereitstellung des Dienstes zu gewährleisten und die Stabilität der Infrastrukturressourcen sicherzustellen
• Das Limit wird jede Woche zurückgesetzt; bei Überschreitung ist in derselben Woche keine weitere Nutzung möglich

Wichtige Auswirkungen auf Entwickler und Startups

• Bei der Nutzung von Claude Code für die Produktentwicklung steigt der Bedarf an Nutzungsplanung
• Bei API-integrierten Diensten entsteht die Notwendigkeit, Logik für automatisiertes Management oder Warnungen bei Überschreitung des Limits zu implementieren
• Bei umfangreicher Codegenerierung, Analyse oder wiederholten Aufrufen wird die Optimierung der Ressourcennutzung noch wichtiger

Fazit

• Die Einführung der wöchentlichen Nutzungslimits für Claude Code dient der Nachhaltigkeit und der Verbesserung der Servicequalität
• Startups und IT-Fachleute müssen bei der Integration in bestehende Systeme und beim Service-Design die wöchentlichen Limits prüfen und ihre Nutzung entsprechend planen

[GN⁺]

Hacker-News-Kommentare

• Ich werde das Wochenlimit vermutlich nicht erreichen, aber es beunruhigt mich, dass es ein Wochenlimit ist und nicht so etwas wie ein 36-Stunden-Fenster.
  Wenn man ans Limit stößt, kann man den Rest der Woche gar nicht mehr darauf zugreifen.
  Ein Tool, an das man sich gewöhnt hat, so lange nicht nutzen zu können, ist unangenehm.
  Manche würden vielleicht sagen, dass ich zu sehr von Claude abhängig bin, aber bei anderen Tools wie ripgrep ist es nicht anders.
  Ein paar Tage ohne wären okay, aber eine Woche ist zu lang.
  Und auffällig ist auch, dass angeblich nur „weniger als 5 % der Nutzer“ betroffen sind.
  Solche Ankündigungen sagen normalerweise, dass weniger als 1 % betroffen sind, aber Anthropic sagt hier, dass 1 von 20 Menschen das Limit überschreiten wird.

  • Genau so fühlt sich das 100/Woche-Limit für o3 im ChatGPT-Plus-Plan an.
    Man kann nicht einmal sehen, wie viel man schon verbraucht hat, und weil es sich wie eine wichtige Ressource anfühlt, spart man instinktiv damit.
    Am Ende nutzt man den Plan nicht richtig aus und weicht auf Modelle wie o4-mini aus.
    Ein Tageslimit wäre mir lieber.
    Vielleicht ist genau dieses Sparverhalten aber auch der Zweck eines Wochenlimits.

  • Es ist traurig, dass Entwickler davon abhängig werden, proprietäre Online-Dienste zu nutzen.
    Früher konnte man alles mit FOSS-Tools erledigen und musste nicht mit einem monatlichen Abo an ein bestimmtes Unternehmen oder einen Dienst gebunden sein.
    Manche sind heute schon wie Monsanto-Bauern und zahlen jeden Monat für Tools, bis sie verlernt haben, wie man ohne sie arbeitet.

  • Mit Sonnet stoße ich oft drei Mal am Tag an das Pro-Limit.
    Wenn man Claude Code und Claude zusammen benutzt, ist es in 30 Minuten aufgebraucht.
    Und das, obwohl ich weder 24/7 Multi-Agenten laufen lasse noch mehrere Fenster offen habe.
    Ich halte mich nicht für einen Top-5-%-Nutzer, aber es würde mich nicht wundern, wenn mein Limit schon am Mittwoch aufgebraucht ist.
    Gerade wollte ich Claude Chat stärker nutzen, aber wenn ich mich für mehrere Tage nicht darauf verlassen kann, hat das keinen Sinn.

  • Anthropic sagt, dass 1 von 20 Leuten an das Limit stößt, aber ich glaube nicht, dass es so viele Nutzer gibt, die Accounts teilen oder 24/7-Automatisierung betreiben.

  • Wenn man das Limit erreicht, ist es nicht so, dass man die ganze restliche Woche nichts mehr nutzen kann, sondern nur für die verbleibende Zeit.
    Du hast selbst gesagt, dass du es wahrscheinlich kaum erreichen wirst; wenn doch, dann wohl eher in den letzten etwa 36 Stunden der Woche.
    Man kann auch einfach die API nutzen und dafür bezahlen.

• Langfristig weiß ich nicht, wie sich das entwickelt, aber ich mag es nicht, dass sich die Nutzung eines LLM immer wie ein begrenztes Gut anfühlt.
  Die Leute haben sich an Unlimited-Pläne gewöhnt.
  Das aktuelle Preismodell fühlt sich gezwungen an und ist unangenehm.

  • Unlimited funktioniert bei allen Diensten, die „zu billig sind, um sie überhaupt messen zu müssen“.
    Beim Internet oder bei SMS geht das, weil die direkten Kosten extrem niedrig sind.
    Bei LLMs fallen aber pro Ausführung immer noch ziemlich hohe direkte Kosten an.

  • Ich stimme der Annahme nicht zu, dass die Nutzung über den ganzen Monat hinweg gleichmäßig verteilt sein sollte.
    Ich nutze es oft den ganzen Monat kaum und dann an ein paar Tagen jeweils 11 Stunden am Stück, und genau dann werde ich vermutlich vom Limit ausgebremst.
    Deshalb fühlt es sich besser an, die API direkt zu nutzen, weil das Limit dann nur von der Tiefe meines Geldbeutels abhängt.
    Mit Dingen wie OpenRouter kann man außerdem die Grenzen des Abo-Modells umgehen.
    Zurzeit passt Gemini 2.5 Pro für Code-Arbeit ohnehin besser zu mir als Claude.
    Mich würde interessieren, welche anderen kosteneffizienten Optionen es noch gibt.
    https://docs.anthropic.com/en/api/rate-limits#rate-limits

  • Ich finde, man sollte diese Tools nicht mehr nach dem Muster „20 Dollar im Monat“ oder „200 Dollar im Monat“ verkaufen, bei dem man Zugriff auf eine begrenzte Menge bekommt und die Limitberechnung undurchschaubar ist.
    Es sollte vollständig nutzungsbasiert sein, das wäre wirklich nutzerfreundlich.
    Man könnte eine Free-Tier mit zum Beispiel 20 kostenlosen Nutzungen zum Ausprobieren anbieten oder über gestaffelte Preise den Satz schrittweise erhöhen und Extremnutzer am Ende nahe an den tatsächlichen Kosten abrechnen.
    Dann könnten Wenignutzer es günstig verwenden, und man würde trotzdem Marktanteile gewinnen.
    Wenn man bessere Preise als OpenRouter bietet, bleiben die Leute in diesem Ökosystem, statt zu Tools anderer Anbieter zu wechseln.
    Wenn das Tool wirklich gut ist, bleiben Nutzer auch bei nutzungsbasierter Abrechnung.
    Das Problem ist, dass Anbieter Nutzer zur Gewinnung von Marktanteilen subventionieren wollen, gleichzeitig aber Missbrauch und Extremnutzung verhindern möchten.
    Die einzige 100-%-Lösung ist vollständige nutzungsbasierte Abrechnung ohne Eintrittsgebühr.
    Allerdings würden damit Leute, die nur abonnieren und wenig nutzen, möglicherweise schlechter wegkommen, weshalb das Vertriebsteam wohl dagegen wäre.
    Außerdem würde es den Leuten leichterfallen, ständig Preise zu vergleichen und zu wechseln, statt sich für ein oder zwei Monate gebunden zu fühlen.

  • Langfristig werden lokale LLMs meiner Meinung nach besser sein als die besten Cloud-LLMs des Jahres 2025, sodass 99 % der Alltagsarbeit unbegrenzt lokal erledigt werden und man nur für wirklich komplexe Probleme in die Cloud geht.
    LLMs werden effizienter, und auch GPUs, Arbeitsspeicher und Speicher werden weiter billiger und zugänglicher.
    Im Moment wirkt das nur deshalb so unerquicklich, weil wir noch in einer Übergangsphase sind.

  • Selbst wenn es eine begrenzte Ressource ist, wäre es okay, wenn ich wenigstens sehen könnte, wie viel ich schon verbraucht habe.
    Dass man keinen Fortschritt sehen kann, ist das Ärgerliche.

• Ich bin verwirrt über den Unterschied zwischen Max 5x und Max 20x.
  In meiner E-Mail steht: „Die meisten Max-20x-Nutzer können Sonnet 4 240–480 Stunden pro Woche und Opus 4 24–40 Stunden pro Woche nutzen.“
  In der offiziellen Mitteilung steht dagegen: „Die meisten Max-5x-Nutzer können Sonnet 4 140–280 Stunden pro Woche und Opus 4 15–35 Stunden pro Woche nutzen.“
  Ich hätte lieber gesehen, dass das Limit wenigstens mehr als proportional zum Preis steigt, aber bei Opus 4 liegt der Unterschied nur bei 5–9 Stunden.
  Müsste es bei doppeltem Preis nicht wenigstens doppelt so hoch sein?

  • Wenn das wirklich so ist, steige ich bei Max 20x sofort auf einen kleineren Plan um.
    Ich zahle in Australien 350 Dollar im Monat.

  • Ich habe auf 20x hochgestuft, weil ich ständig ans Opus-Limit gestoßen bin, und jetzt sieht es so aus, als gäbe es zwischen 20x und 5x fast keinen Unterschied.

  • Deshalb habe ich MAX gekündigt, bin zurück auf Pro gegangen und nutze o3 und andere Modelle über die API.
    Anfangs brauche ich gar nicht so viele Stunden; für etwa 10 Dollar pro Projekt komme ich mit o3, Gemini und Opus aus.
    Alle paar Tage erscheint ein neues Modell, und ich will nicht an nur einen Anbieter gebunden sein.

  • Tatsächlich bekommt man nicht die doppelte Nutzung, sondern nur höhere Priorität bei Lastspitzen.

  • Falls das Marketingmaterial nicht den Tatsachen entspricht, hoffe ich, dass das jemand mit echten Daten untersucht und eine Sammelklage anstrengt.

• Ich verstehe ja, dass selbst 200 Dollar im Monat nicht ausreichen.
  Dann sollte es aber auch einen Plan geben, mit dem man ohne Limit-Sorgen arbeiten kann.
  Nichts unterbricht den Flow so sehr wie eine Meldung im Stil von „Zeit abgelaufen!“.
  Ein Creditsystem wäre mir lieber, dann könnte ich wenigstens sehen, wie viel ich verbraucht habe, und notfalls nachkaufen.
  Das Konzept „Warten, während die GPU abkühlt“ hilft der Produktivität überhaupt nicht.
  Wenn man mehrere Agenten parallel laufen lässt, sind „35 Stunden“ völlig unzureichend.
  Schon seltsam, dass das Tool überhaupt so entworfen wurde, dass es diese Arbeitsweise unterstützt.

  • Wenn man einen Plan anbieten würde, der für alle ausreicht und trotzdem profitabel ist, würden vermutlich erst recht alle zur Konkurrenz abwandern.
    Es kann strategisch sinnvoller sein, die Nutzer abhängig von einem Tool zu machen und die Preise dann schrittweise zu erhöhen.

  • „Mehrere Agenten parallel laufen lassen“ ist meiner Meinung nach kein üblicher Anwendungsfall für einen persönlichen Plan.
    In solchen Fällen musste man schon immer direkt für API-Nutzung zahlen.
    Dass ein Flat-Rate-Modell so etwas überhaupt erlaubt hat, war Großzügigkeit des Dienstes, und beworben wurde von Anfang an mit „höheren Limits“, nicht mit „unbegrenzt“.

  • Bei der API sind die Limits viel großzügiger und praktisch fast unbegrenzt.
    Claude ist außerdem auch über Aws und gcp verfügbar, mit jeweils anderen Limits, Credits und Preisen.

  • Die Politik sollte auf „gute Nutzer“ optimiert werden und nicht auf „schlechte Nutzer“.

  • Einfach die API nutzen.

• Insgesamt halte ich das für eine positive Änderung: Das System wird vor einigen Nutzern geschützt, die 24/7 mit vielen Agenten laufen, damit mehr Leute den Dienst dauerhaft nutzen können.
  Trotzdem ist es frustrierend, dass nicht angezeigt wird, „wie viel Nutzung noch übrig ist“.
  Ich weiß nicht, um wie viele Prozent es geht, aber zumindest gelegentliche Hinweise, etwa bei der Hälfte, würden die Planung erleichtern.
  Dass sie das nicht anbieten, weckt den Verdacht: „Wollen sie vielleicht gar nicht, dass wir es messen können?“
  Ich will es nicht penibel nachverfolgen, ich möchte nur grob wissen, wo ich stehe.

• Laut dem Anthropic-Reddit-Account
  hat ein Nutzer mit einem 200-Dollar-Plan LLM-Leistung im Wert von Zehntausenden Dollar verbraucht.
  Das Unternehmen arbeitet an einer separaten Lösung für Power-User,
  doch die neuen Limits sollen vor allem für eine fairere Erfahrung sorgen und Account-Sharing sowie Weiterverkauf verhindern.
  Deshalb bekommen wir jetzt keinen „guten Service“.

  • Ein Startup, bei dem ich früher gearbeitet habe, hatte einmal ebenfalls eine Unlimited-Option.
    Anfangs dachten wir, niemand würde jemals so viel nutzen können, aber tatsächlich gab es sehr viele Nutzer, die kreativ darin waren, die Grenzen des Dienstes auszureizen.
    Accounts hingen 24/7 am Service und fuhren die Request-Limits konstant bis auf 95 % hoch.
    Sie nutzten unterschiedliche IPs, und die Muster sahen oft nicht einmal menschlich aus.
    Anfangs haben wir das als Ausreißer hingenommen, aber als die Zahl solcher Accounts exponentiell zunahm,
    stellte sich heraus, dass mehrere Unternehmen in Wirklichkeit viele Accounts anlegten und Lastverteilung darüber betrieben.
    Wenn man sich das durchschnittliche Gewinn-/Verlust-Diagramm pro Nutzer anschaut, hinterlassen solche Accounts riesige Verluste und verbrauchen gleichzeitig maximal Ressourcen, sodass die Richtlinie am Ende geändert werden musste.
    Man verliert dadurch zwar solche „Kunden“, aber die meisten normalen Nutzer sind nicht betroffen.
    Im Gegenteil, der Dienst wird insgesamt angenehmer.
    Diese Erfahrung macht jedes Startup mit hoher Nutzung.

  • Es kann gut sein, dass das Unternehmen den Dienst derzeit mit Verlust verkauft.

  • Kann man solchen Missbrauch mit den aktuellen Limits nicht ohnehin blockieren? Ich verstehe das nicht ganz.

  • Jemand hat gestern auf Twitter damit geprahlt.
    Er habe mit einem 200-Dollar-Account Leistungen im Wert von 13.200 Dollar verbraucht und dabei 4–5 Opus-only-Agenten 24/7 in rekursiven Aufrufen gegeneinander laufen lassen.
    Das ist eindeutig Missbrauch und sollte gezielt unterbunden werden.
    Aber ich weiß nicht, wie ein Inference-Anbieter so etwas überhaupt verhindern soll.
    Bei Cursor ist es noch schwieriger, weil dort im Vergleich zu Anthropc/OpenAI noch ein Premiumaufschlag dazukommt.
    Anthropic steckt in einer ähnlichen Lage, hat hier aber keine Premium-Option.
    Wenn man für 20 Dollar im Monat nur bis zu realen Kosten von 500 Dollar zuließe, wäre das effektiv immer noch ein 95-%-Rabatt, und so ein Modell ist nie tragfähig.
    Solche Subventionen fördern am Ende nur ein Anspruchsdenken in der Community.
    Es fühlt sich zwar an, als würde einem etwas weggenommen, an das man sich gewöhnt hat, aber schon CapEx/OpEx sind kaum tragbar, und wenn man noch die R&D-Kosten einrechnet, wird selbst der Modellbetrieb schwierig.
    Realistisch bleibt dann nur: die Preisstruktur immer wieder ändern und zusehen, wie die Nutzer zum nächsten Unternehmen mit großzügigerer Subvention weiterziehen.
    Besser wäre es gewesen, solche Regeln von Anfang an als Trial zu kennzeichnen und transparent zu sagen, in welchem Ausmaß subventioniert wird.
    Dann hätten die Leute die Modelle testen können und wären zum Teil geblieben, selbst wenn ein gewisser Abgang unvermeidlich gewesen wäre.
    Wenn man die Struktur aus CapEx, Betriebskosten und Entwicklungskosten wirklich transparent offenlegte,
    würden die Leute vielleicht akzeptieren, dass das preislich ungefähr auf dem Niveau eines unermüdlichen Senior Engineers liegt.

• Es wäre viel hilfreicher gewesen, wenn diese E-Mail monatlich ausgewiesen hätte, „in welchen Monaten man das Limit erreicht hat“ (Aug 2024, Jan 2025, May 2025 usw.).
  Ich habe keine Ahnung, ob ich zu den Top 5 % gehöre.
  Ein 1-%-Limit halte ich eigentlich für nachvollziehbar, aber 5 % im SaaS-Bereich entspricht praktisch einem erheblichen Teil der tatsächlichen Nutzer.

• Solche Dienste brauchen nutzungsbasierte Tarife.
  Alle AI-Unternehmen stoßen auf dasselbe Problem.
  Abos mit Fixpreis sind darauf ausgelegt, dass Nutzer sich über Kosten keine Gedanken machen.
  Eine winzige Gruppe von Power-Usern fährt die Abo-Grenzen jedoch bis zum Anschlag aus,
  und Dienste wie Terragon werden eigens dafür entwickelt, diese Nutzung noch weiter zu optimieren.
  Deshalb senken die Unternehmen ihre Limits immer weiter, und Nutzer denken dadurch am Ende noch stärker über Kosten nach.
  Cursor hat seine Limits mehrfach angepasst, und jetzt zieht Anthropic nach.
  Letztlich wollen sie die obersten 10 % der Extremnutzer nicht länger subventionieren.
  Ich wünschte, es gäbe direkt im Webinterface nutzungsbasierte Tarife.

  • Die API gibt es ja bereits, man kann direkt ein Token erzeugen und Claude Code ohne separaten Tarif damit nutzen.

  • Das erinnert mich an Shared Hosting in den 1990ern.

  • Wenn man nutzungsbasierte Webpläne anbietet, müsste man offenlegen, wie teuer Inference-Unterstützung tatsächlich ist, und das wäre unangenehm.
    AI auf einem Niveau zu betreiben, das für produktive reale Arbeit taugt, ist derzeit schlicht noch sehr teuer.

• Wegen dieser „fortgeschrittenen Nutzungsmuster, bei denen Claude 24/7 im Hintergrund läuft“, bekommen wir keinen guten Service.

  • AI-Dienste werben doch selbst damit: „Die AI erledigt die Arbeit von allein. Der Entwickler kann Kaffee trinken oder schlafen, während weitergearbeitet wird.“ Und dann gibt es eben Entwickler, die den Dienst genau so legitim nutzen.
    Ihnen im Nachhinein die Schuld zu geben, ist schon seltsam.

  • Darüber musste ich lachen.
    Das klingt fast wie ein „wohlmeinender Weltzerstörer“, der die Hitzetod-Entwicklung des Universums noch ein bisschen beschleunigen will.

  • Ich finde, dieses Problem war absolut vorhersehbar.
    Bei der ursprünglichen Preisgestaltung wird das sicher ausreichend bedacht worden sein.
    Man wollte es wohl nur nicht schon zum Start blockieren, und jetzt wird es eben an die Realität angepasst.

  • Egal wie ein Tarif gestaltet ist, Nutzer werden versuchen, ihren Plan zu 100 % auszuschöpfen.
    Ich bin Max-Abonnent und stoße trotzdem oft an Limits.
    Dass ich trotz Bezahlung nur begrenzt „laufen lassen“ darf, fühlt sich merkwürdig an.

  • Genau das ist Preisexperimentierung.
    Wenn die Regeln locker genug sind, tauchen irgendwann Extremnutzer auf, und das Unternehmen verkauft ein nicht tragfähiges Modell erst so, als wäre es realistisch, um später die Boni wieder wegzunehmen.

• Vielleicht ist das ein abwegiger Vorschlag, aber ich habe über adaptive Limits nachgedacht.
  Option 1: Anfangs darf man für kurze Zeit burstartig sehr viel nutzen, dann wird die Geschwindigkeit schrittweise gedrosselt, und nach einer Cooldown-Phase ist wieder ein Burst möglich.
  So können Nutzer kurzfristig maximale Produktivität erreichen, und die Server bekommen zwischendurch Luft.
  Option 2: Wie bei mobilem Datenvolumen: Erst hat man eine bestimmte Menge an Requests mit voller Geschwindigkeit, danach wird gedrosselt, und wer mehr braucht, kann dazukaufen.
  Das wäre zugleich ein Modell mit zusätzlichem Umsatz.
  Option 3: Adaptive Ressourcenzuteilung auf Infrastruktur- und Netzebene.
  Nicht-GPU-Aufgaben könnten niedriger priorisiert werden, Netzwerkanfragen langsamer abgearbeitet werden, oder in k8s könnten Jobs je nach Auslastung auf verschiedene Server verteilt werden.
  Und statt nur über Limits zu reden, könnte man auch nachverfolgen, welche Requests tatsächlich die meisten Kosten verursachen; vielleicht lässt sich durch Optimierungen an ineffizienten Codepfaden oder der Infrastruktur Luft schaffen.
  Schon kleine Code-Optimierungen können einem System erheblich mehr Spielraum verschaffen.