Summary

OpenClaw 6.1 has a critically low cache hit rate, which is driving a massive and unsustainable spike in token costs.

Problem to solve

Since upgrading to OpenClaw 6.1, the cache hit rate has dropped dramatically — in our case from around 80% to under 20%. Nearly every request is being treated as a cache miss, which means the same prompts and context are being re-processed over and over again. This is causing our token consumption to multiply, directly inflating our LLM bills to several times their normal level. The current caching behavior is effectively broken, making it impossible to operate cost-effectively in production. This isn’t a minor inefficiency — it’s an urgent cost and reliability issue that needs immediate attention.

Proposed solution

Investigate and restore the cache hit rate to the levels seen in previous versions (or better). Specifically:

1. Review the caching key generation and invalidation logic introduced or changed in 6.1 — there may be a regression causing keys to be unnecessarily unique or to be evicted prematurely.
2. Ensure that semantically identical prompts and contexts are recognized as cache hits, even when minor formatting or metadata differences exist, unless those differences are intentionally part of the cache-busting design.
3. Consider adding observability: expose the cache hit/miss rate in logs or metrics so that operators can detect regressions immediately without having to deduce them from cost spikes.
4. If the current behavior is by design, document the breaking change clearly and provide a migration path or configuration toggle to restore the previous caching behavior.

Alternatives considered

• Manually enforcing consistent prompt prefixes: We attempted to standardize prompt structures to improve the hit rate, but this is inconsistent, hard to enforce across teams, and does not solve the core issue. It also adds cognitive overhead and is fragile against minor variations.
• Accepting the higher cost: Not viable long-term. The cost increase is too steep to absorb, especially for multi-tenant or high-volume usage.

Impact

• Affected users/systems: All users and automations relying on OpenClaw for LLM interactions in production, particularly those in cost-sensitive or high-volume environments.
• Severity: High — this blocks our ability to use 6.1 in production and forces a rollback.
• Frequency: Occurs on virtually every request; cache misses are constant.
• Consequence: Token costs have increased by 4–5× compared to the previous version. For our team, this translates to hundreds of extra dollars per day and makes the 6.1 upgrade financially unviable. It also prevents us from adopting newer features because the caching layer is effectively non-functional.

Evidence/examples

• After upgrading to 6.1 with no other changes to usage patterns, the hit rate dropped below 20%.

Additional information

We are available to provide detailed logs, configuration files, or a minimal reproducible test case if it helps isolate the regression. Please treat this as a high-priority issue — the caching layer is a critical component for production cost management.