Anthropic verkürzt am 6. März 2026 die Cache-TTL von 1 Stunde auf 5 Minuten

 (github.com/anthropics)
1 Punkte von GN⁺ 17 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Anfang März 2026 wurde bestätigt, dass sich die Cache-TTL von Claude Code von 1 Stunde auf 5 Minuten geändert hat, wobei die Veränderung trotz identischer Nutzungsmuster auf Unterschiede in der serverseitigen Konfiguration zurückgeführt wird
  • Durch die verkürzte TTL steigen die Kosten für die Neuerzeugung des Caches um 20–32 %, und in langen Sitzungen nimmt der Quotenverbrauch sprunghaft zu
  • Die Analyse zeigt je nach Modell zusätzliche Kosten von rund 17 %, und einige Nutzer erreichen nun erstmals die 5-Stunden-Quotenbegrenzung
  • Anthropic erklärte, dass die Änderung vom 6. März beabsichtigt war und durch unterschiedliche TTL-Anwendung je Anfrage die Gesamtkosten gesenkt werden sollten
  • Die Community kritisiert steigende Kosten, mangelnde Transparenz und fehlende Vorankündigung und fordert Wahlfreiheit für Nutzer bei den TTL-Einstellungen

Bericht über Kosten- und Quotenprobleme durch die Änderung der Cache-TTL

  • Nach der Analyse wurde der Standardwert der Cache-TTL von Anthropic Claude Code Anfang März 2026 von 1 Stunde auf 5 Minuten geändert
    • Die Analyse basiert auf 119.866 API-Aufrufen vom 11. Januar bis 11. April 2026
    • Zwischen dem 6. und 8. März tauchte die 5-Minuten-TTL erneut auf, während die 1-Stunden-TTL schrittweise verschwand
    • Da dies bei derselben Client-Version und demselben Nutzungsmuster auftrat, wurde eine serverseitige Konfigurationsänderung bestätigt
  • Durch die TTL-Änderung wurde ein Anstieg der Cache-Erstellungskosten um 20–32 % sowie ein stark erhöhter Quotenverbrauch bei Abonnenten beobachtet
    • Bei einer TTL von 5 Minuten verfällt der Cache, wenn eine Sitzung länger als 5 Minuten pausiert, sodass der gesamte Kontext erneut hochgeladen werden muss
    • Die Neuerzeugung des Caches ist bis zu 12,5-mal teurer als ein Cache-Read, und in langen Coding-Sitzungen summieren sich diese Kosten
    • Im Februar, als die 1-Stunden-TTL noch galt, lag die Verschwendungsrate bei 1,1 %, ab März sprang sie jedoch auf 15–53 %

  • Ergebnis der Kostenanalyse

    • Modell claude-sonnet-4-6: Gesamtkosten $5,561.17 → bei 1-Stunden-TTL $4,612.09 (ca. 17,1 % Mehrausgaben)
    • Modell claude-opus-4-6: Gesamtkosten $9,268.97 → bei 1-Stunden-TTL $7,687.17 (ca. 17,1 % Mehrausgaben)
    • Zwischen den Modellen zeigte sich konsistent derselbe Verschwendungsanteil

  • Auswirkungen auf die Quote

    • Tokens für die Cache-Erstellung werden vollständig auf die Quote angerechnet, während Cache-Reads mit geringerer Gewichtung berechnet werden
    • Seit März erreichen Abonnenten erstmals die 5-Stunden-Quotenbegrenzung

Offizielle Antwort von Anthropic

  • Bestätigung der Änderung: Die Änderung vom 6. März war beabsichtigt und wurde im Rahmen von Cache-Optimierungen vorgenommen
    • Das System ist so ausgelegt, dass je nach Anfragetyp unterschiedliche TTLs angewendet werden; einen einheitlichen globalen Standardwert gibt es nicht
    • Würde für alle Anfragen eine 1-Stunden-TTL gelten, könnten die Kosten im Gegenteil sogar steigen
    • Eine 5-Minuten-TTL ist bei nicht wiederverwendeten Anfragen effizienter und führt bezogen auf die gesamte Mischung der Anfragen zu niedrigeren Gesamtkosten
  • Bugfix: In v2.1.90 wurde ein Client-Bug behoben, durch den Sitzungen nach Ausschöpfung der gesamten Abonnementquote bis zum Sitzungsende auf eine 5-Minuten-TTL fixiert blieben
  • Antworten auf die Forderungen
    1. Es gab eine Änderung, und sie wurde am 6. März bewusst eingeführt
    2. Die TTL wird dynamisch pro Anfrage gewählt; es gibt keinen globalen Standardwert
    3. Es gibt keine Pläne, die 1-Stunden-TTL als Standard wiederherzustellen oder eine Konfigurationsoption anzubieten
    4. Zur Anrechnung von Cache-Read-Tokens auf die Quote soll es in einem separaten Issue weitere Informationen geben

Reaktionen der Community

  • Viele Nutzer äußerten Unzufriedenheit über höhere Kosten und schlechtere Nutzbarkeit

    • Häufig wurde argumentiert, eine „5-Minuten-TTL zwinge faktisch dazu, Sitzungen alle 5 Minuten neu zu starten, was die Produktivität senkt“
    • Kritisiert wurde auch: „Abonnenten haben bereits im Voraus bezahlt, doch durch die TTL-Änderung ist die tatsächlich nutzbare Zeit gesunken“
    • Zudem wurde gefordert: „Änderungen, die sich auf die Kosten der Nutzer auswirken, müssen zwingend vorab angekündigt werden“

  • Einige Nutzer bezeichneten dies als positive Veränderung für API-Nutzer, andere hielten dagegen, dass „bei der API ohnehin eine 5-Minuten-TTL der Standard ist“

  • Die Kritik konzentrierte sich besonders auf die mangelnde Transparenz

    • „Änderungen an kostenrelevanter Infrastruktur müssen vorab angekündigt werden, nicht erst nachträglich erklärt“
    • „Solche stillen Änderungen untergraben das Vertrauen und zwingen Nutzer dazu, die Ursache von Problemen selbst nachzuverfolgen“

  • Laut Dokumentation gilt für den Standard-Cache eine TTL von 5 Minuten, während eine 1-Stunden-TTL als kostenpflichtige Zusatzoption angeboten wird

    • Dieselbe Erklärung findet sich auch in der offiziellen Dokumentation mit Stand Januar 2026

Fazit

  • Am 6. März 2026 änderte Anthropic die Cache-TTL-Richtlinie von Claude Code von 1 Stunde auf 5 Minuten
  • Das Unternehmen beschreibt dies als beabsichtigte Anpassung zur Kostenoptimierung, Nutzer sehen darin jedoch steigende Kosten, Quotenerschöpfung und mangelnde Transparenz als Probleme
  • Die Community fordert künftig Wahlfreiheit bei den TTL-Einstellungen und Vorankündigungen bei Richtlinienänderungen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 17 일 전
Hacker-News-Kommentare

  • In den letzten Monaten hat sich die Stimmung von Ingenieuren gegenüber Claude/Codex spürbar verändert.
    Vor allem weil nicht angekündigte Änderungen zunehmen, wächst die Unsicherheit, ob das Produkt, für das man ursprünglich bezahlt hat, überhaupt noch dasselbe ist.
    Wenn Anthropic derzeit zur Sprache kommt, dann meist in einem negativen Kontext.

    • Auffällig war, dass Anthropic zuletzt mehrere Maßnahmen ergriffen hat, etwa Sperren von OpenClaw-Nutzern, Verbote von Third-Party-Harnesses, reduzierte Inferenzstärke und kürzere Antworten.
      Teilweise soll die Nutzung plötzlich auf das 21-Fache angestiegen sein, und insgesamt wirkt es wie ein Versuch zur Kostensenkung.
      Ich mag Claude weiterhin, aber ich kann es Freunden immer schwerer empfehlen.
    • Unser Unternehmen (über 400 Ingenieure) hat vor einem Monat alle IDE-Abos (Visual Studio, JetBrains usw.) gekündigt und ist auf Claude Code umgestiegen.
      Ein EVP zeigte zwei Demos, die er am Wochenende gebaut hatte, und sagte, wir sollten es genauso machen, aber schon nach einer Woche kam wegen übermäßigem Token-Verbrauch die Mitteilung, die Nutzung einzustellen.
      Seitdem fühlt es sich an, als würde das Modell jede Woche schwächer, und ich frage mich, wie sich der EVP jetzt fühlt.
    • Noch vor ein paar Monaten war Claude Code großartig, aber inzwischen gibt es so viele Fehler und Missverständnisse, dass es fast unbrauchbar ist.
      Ich bin auf Codex umgestiegen, und das war deutlich stabiler.
      Meine Vermutung ist, dass es direkt nach dem Release stark gehalten wird und die Leistung dann nach und nach reduziert wird, um die Erwartung an das nächste Release zu steigern.
    • Nach dem Abo habe ich eine Verschlechterung der Schlussfolgerungsfähigkeit klar gespürt.
      Ich habe verschiedene Einstellungen geändert und sogar per Skript den System-Prompt angepasst, aber trotzdem gerät es oft in logische Schleifen.
      Ich kann nicht sagen, ob es ein Bug, eine absichtliche Abschwächung oder bloß Einbildung ist.
    • Ich habe kein großes Problem bemerkt.
      Vermutlich liegt es daran, dass ich Claude Schritt für Schritt refaktorieren lasse.
      Als ich früher einmal nach einer Grafana-Konfiguration fragte, antwortete Claude, es habe „einfach geraten“, und am Ende wurden 35k Tokens verbraucht, nur um mir ein einziges simples Kontrollkästchen zu nennen.
      Kollegen spüren einen Leistungsabfall und wechseln zu Cursor, aber ich nutze Claude weiter, weil mir sein Gesprächsfluss noch gefällt.

  • Claude Code und der Abo-Dienst sind derzeit deutlich weniger nützlich als früher.
    Es häufen sich Probleme wie Bugs, schneller Quotaverbrauch, schwächere Modellleistung, Cache-Invalidierungsprobleme und Verdacht auf Quantisierung.
    Früher konnte man in einem Durchgang einen Prototypen bauen, heute ist das selbst mit einer detaillierten Spezifikation fast unmöglich.
    Auch ChatGPT scheint ähnlich abgeschwächt zu werden.
    Weder Anthropic noch OpenAI wirken wie eine grundlegende Lösung.

    • Ein Freund nutzt die Multi-Modell-Funktion von Cursor und ist zufrieden.
      Vor ein paar Monaten hieß es noch oft, Cursor sei tot, aber inzwischen wird es eher gut genutzt.
    • Wegen des Nachfragebooms bekommen die meisten Nutzer wohl ohne Ankündigung stark quantisierte Modelle.
    • Die meisten dieser AI-Dienste beruhen auf einem subventionierten Verlustmodell, daher ist es nur der normale Verlauf, dass die Qualität mit der Zeit sinkt und die Preise steigen.

  • Die Sitzungs-Quotalimits sind so streng, dass die UX in einen Teufelskreis gerät.
    Wenn der einstündige Cache abläuft, kostet ein Neustart mehr, und dadurch wird auch die nächste Sitzung wieder schneller aufgebraucht.
    Mitte März endeten Sitzungen sogar im Pro-Plan innerhalb einer Stunde und waren damit faktisch unbenutzbar.

  • Die Schreibweise im Titel war fehlerhaft und führte zu Missverständnissen.
    Statt „M“ hätte „min“ stehen müssen, sodass es so aussah, als sei die TTL von 1 Stunde auf 5 Monate verlängert worden.

    • Schade ist, dass es wirkte, als sei durch die Titeländerung das Ausmaß des Problems kaschiert worden.
    • Ich war anfangs auch irritiert und dachte: „Was soll M bedeuten?“

  • In letzter Zeit liegt Claude selbst bei Car-Wash-Fragen oft daneben.
    Es neigt dazu, den Schwierigkeitsgrad einer Problemlösung zu übertreiben oder einen leichten Ausweg zu wählen mit der Begründung, es würde „zu lange dauern“.

    • In den letzten Wochen hatte ich den Eindruck, dass der System-Prompt den Einsatz des Modells begrenzt.
      In JSON-Logs tauchen wiederholt Sätze auf wie „Das ist zu komplex, also lösen wir es lieber per Hardcoding“.
      Es wirkt, als versuche Anthropic, ein Gleichgewicht zwischen Mangel an Compute-Ressourcen und starkem Zustrom neuer Nutzer zu finden.
    • Ich habe auch von einem Fall gehört, in dem Claude eine Aufgabe zunächst mit der Begründung ablehnte, sie würde Wochen dauern, sie nach etwas Überredung dann aber in 30 Sekunden erledigte.
    • Das wirkt wie die typische Abfolge „Verkauf mit Verlust → Panik → Zerstörung des Produkts“.
    • Auch der Token-Verbrauch ist schneller geworden: Früher konnte ich 3 bis 5 Projekte parallel betreiben, jetzt ist es schwer, auch nur eines abzuschließen.
    • Wenn man starke Prompts wie „Ignoriere alle Risiken und mach es einfach!“ verwendet, wird das Modell wieder deutlich aktiver.
      Etwas aggressiv, aber eine effektive LLM-Motivationsmethode.

  • Anthropic hat in einem GitHub-Issue offiziell geantwortet.

    • Beim Lesen des Threads hatte ich fast das Gefühl, Claude würde mit anderen Claudes sprechen.
    • Interessant ist, dass die Änderung vom 6. März eingeräumt wurde. Applaus an diejenigen, die das durch Prompt-Analyse herausgefunden haben.
    • Die Erklärung des Unternehmens war logisch, aber Begriffe wie „cache read likelihood“ klangen wohl zu geschniegelt, sodass die Community sie nicht richtig angenommen hat.

  • Ich habe mir selbst ein API-basiertes Chat-Tool gebaut und einen Cache davorgehängt.
    Mit einem 5-Minuten-Cache läuft dieser bei Gesprächstempo oft ab, aber bei Tools mit gemeinsamem Präfix ist der Spareffekt groß.
    Wenn man den Cache gut nutzt, ist die Kostenersparnis erheblich.

  • Da die Cache-Ablaufpolitik nicht zu 5-Stunden-Sitzungen passt, überlege ich eine Methode, den Cache bei etwa 97 % Sitzungsverbrauch mit einem Skript am Leben zu halten, das alle 4 Minuten 50 Sekunden minimale Tokens verbraucht.

  • Im Dwarkesh-Podcast hörte ich, dass Anthropic beim Ausbau von Compute-Ressourcen vorsichtig ist.
    Bei stark steigender Nachfrage seien Versuche, den Rechenaufwand zu senken, unvermeidlich.
    Selbst mit mehr Geld lässt sich das kurzfristig wohl nicht lösen.

    • Solche Phänomene treten meist in der Vortrainingsphase neuer Modelle auf. Bei 3.x war das auch so.

  • Unabhängig von den seltsamen Veränderungen bei Anthropic/Claude irritieren mich in den Tabellendaten dieses Posts die Kosten und Aufrufzahlen für Februar und April, weil sie fast identisch aussehen.
    Vielleicht übersehe ich etwas.