mild kestrel
Anyone facing this issue where the recent update pollutes the prefix / system prompt thus fully invalidating Anthropic's caching capabilities (meaning you pay full price per conversation turn)?
https://github.com/openclaw/openclaw/issues/18963
Several other users have validated this as an active bug on Github.
Fill issue text:
Summary
Anthropic prompt caching appears to miss on most turns in auto-reply flows.
Observed pattern across many adjacent turns:
cacheWrite very high (~137k)
cacheRead = 0
small fresh input tokens
This causes repeated high-cost re-caching.
Environment
OpenClaw: 2026.2.16 (db3480f)
Provider: direct Anthropic (not OpenRouter)
Model: anthropic/claude-sonnet-4-5-20250929
Install: local CLI install
Channel observed: Telegram auto-reply (code path appears shared across other channel adapters too)
Relevant config
active Anthropic model has params.cacheRetention: "long"
agents.defaults.contextPruning.mode: "cache-ttl"
agents.defaults.contextPruning.ttl: "55m"
agents.defaults.contextPruning.minPrunableToolChars: 50000
agents.defaults.contextPruning.softTrim.maxChars: 4000
Expected
Within TTL, adjacent turns should show meaningful cacheRead for unchanged prompt-prefix segments.
Actual
Most turns show near-full cacheWrite and cacheRead=0.
Additional runtime signal
There are occasional cache-hit continuations immediately after tool/result boundaries, but normal subsequent user turns return to cacheRead=0 + large cacheWrite. That suggests caching is not globally disabled, but prefix reuse is unstable across regular turns.
Suspected cause
Auto-reply builds extra system prompt content from inbound metadata:
src/auto-reply/reply/get-reply-run.ts
src/auto-reply/reply/inbound-meta.ts
The inbound metadata includes volatile per-message fields:
message_id
reply_to_id
history_count
If these are part of the cached prefix, they can change every inbound turn and defeat cache reuse.
brittle sierra