OpenClaw 6.1: Cache-Hit-Rate-Regression treibt LLM-Kosten in die Höhe

Zusammenfassung

Mit dem Release von OpenClaw 6.1 / 2026.6.1 wurde eine schwerwiegende Regression im Prompt-Caching-System bekannt. Zahlreiche Entwickler berichten, dass die Cache-Hit-Rate nach dem Update von etwa 80 % auf unter 20 % eingebrochen ist. Dies führt dazu, dass identische System-Prompts und Werkzeuge (Tools) bei jedem Schritt neu berechnet werden müssen. Die Folge ist eine drastische Erhöhung des Token-Verbrauchs und ein Anstieg der API-Kosten um das 4- bis 5-Fache, insbesondere bei der Nutzung des Anthropic-Vertex-Providers.

Was ist passiert?

Nach dem Upgrade auf die Version 6.1 von OpenClaw stellten Entwickler fest, dass ihre LLM-API-Rechnungen unerwartet in die Höhe schnellten. Diagnosetools wie cache-trace und der /status-Befehl offenbarten einen massiven Einbruch der Cache-Effizienz. Der Grund dafür liegt in einer fehlerhaften Konfiguration des Caching-Protokolls: Der Anthropic-Vertex-Provider fügt fälschlicherweise cache_control: ephemeral in Bereiche ein, die für dynamische Suffixe und aktive Speicherblöcke (Active Memory) bestimmt sind. Dadurch wird die standardmäßige Präfix-Übereinstimmung (Prefix Caching) ungültig, und der gesamte Kontext muss bei jedem API-Aufruf neu verarbeitet werden.

Warum es wichtig ist

Prompt-Caching ist für den wirtschaftlichen Betrieb von KI-Agenten unerlässlich. Agentische Workflows erfordern kontinuierlich das Senden von Systeminstruktionen, Verlaufsprotokollen und Werkzeugdefinitionen. Ohne funktionierendes Caching multiplizieren sich die Betriebskosten innerhalb kürzester Zeit. Ein Einbruch der Hit-Rate auf unter 20 % macht komplexe Agentenschleifen für viele Unternehmen wirtschaftlich unrentabel und führt zu erheblichen Latenzproblemen (TTFT - Time-to-First-Token).

Beweise

Die Fehlerberichte häufen sich in den offiziellen Entwicklerforen. Im GitHub-Issue #90583 wird das Absinken der Prompt-Cache-Hit-Rate von 80 % auf unter 20 % detailliert dokumentiert. Zudem zeigt Issue #91982, dass der @openclaw/anthropic-vertex-provider fehlerhafte cache_control-Header an den StreamRawPredict-Endpunkt sendet, was unter anderem zu einem Abbruch der Anfrage führt, sobald das Limit von maximal 4 Caching-Blöcken überschritten wird (“A maximum of 4 blocks with cache_control may be provided. Found 5.”).

Analyse

Die Ursache liegt in der Funktion applyAnthropicCacheControlToSystem in src/agents/anthropic-payload-policy.ts. Diese fügt fälschlicherweise den Header cache_control: ephemeral in den dynamic suffix des System-Prompts ein. Wenn das Feature active-memory aktiviert ist und gespeicherte Erinnerungen über prependContext in die Benutzer-Nachricht geladen werden, überschreitet die Gesamtzahl der markierten Blöcke das von Anthropic erlaubte Limit. Zudem sorgt die ungeeignete Platzierung von Caching-Markern in dynamischen Teilen dafür, dass der Cache-Schlüssel bei jeder kleinsten Änderung ungültig wird, wodurch das statische Präfix-Caching komplett ausgehebelt wird.

Praktische Erkenntnisse

Active Memory deaktivieren: Als temporärer Workaround kann das active-memory-Feature in der openclaw.json deaktiviert werden. Dies verhindert den 400-Bad-Request-Fehler und stabilisiert zumindest einen Teil des Cachings.
Rollback erwägen: Entwickler, die stark auf Caching und Kosteneffizienz angewiesen sind, sollten vorübergehend auf Version 2026.4.20 zurückgehen, bis ein Hotfix für die Payload-Policy veröffentlicht wird.
Diagnose nutzen: Überwachen Sie die Cache-Auslastung kontinuierlich mit dem /status-Befehl und analysieren Sie unvollständige Übereinstimmungen mithilfe von cache-trace.

Offene Fragen

Es bleibt zu klären, ob auch andere Provider (wie OpenAI oder native Anthropic-API-Wrapper) von ähnlichen Payload-Konstruktionsfehlern in Version 6.1 betroffen sind, oder ob sich die Regression ausschließlich auf den Anthropic-Vertex-Provider und die Active-Memory-Pipeline beschränkt. Zudem steht ein offizieller Patch der OpenClaw-Maintainer noch aus.