Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

For adapters that use per-task or per-issue session scoping (e.g. the openclaw_gateway Paperclip adapter with sessionKeyStrategy: "issue"), every run cold-starts with cacheRead=0 and pays a full cacheWrite of 18–25K tokens. This makes cross-run prompt caching impossible regardless of cacheRetention setting.

Steps to reproduce

1. Configure OpenClaw with openclaw_gateway Paperclip adapter using sessionKeyStrategy: "issue".
2. Run the agent on multiple separate Paperclip tasks (each gets a unique task UUID).
3. Observe session JSONL data: every run shows cacheRead=0 and a full cacheWrite of 18–25K tokens, regardless of cacheRetention setting.
4. Compare: switch to sessionKeyStrategy: "fixed" with a shared sessionKey: "paperclip" — cross-run caching works correctly (cacheRead dominates from T2 onward).

Expected behavior

Cross-run prompt caching should work for task-scoped adapters. With cacheRetention: "long", T2+ runs within the TTL window should show cacheRead dominating and near-zero input token costs, as observed with stable-chat_id adapters like Telegram.

Actual behavior

Every run cold-starts with cacheRead=0 and pays a full cacheWrite of 18–25K tokens. Cross-run prompt caching never engages regardless of cacheRetention setting. Session JSONL data from 8 consecutive Paperclip runs confirms this pattern:

Root cause: the chat_id field in the ## Inbound Context (trusted metadata) block maps to ctx.OriginatingTo, which for task-scoped adapters resolves to the per-task session key (e.g. paperclip:issue:<TASK_UUID>). This UUID is unique per task, making every system prompt unique and busting the Anthropic prompt cache unconditionally. There is only one cache_control: { type: "ephemeral" } breakpoint on the entire system array, so any volatile value anywhere invalidates the entire cache.

For comparison, Telegram (stable chat_id per peer) shows cacheRead dominating from T2 onward — caching works correctly there.

OpenClaw version

2026.3.23-2

Operating system

macOs 26.3

Install method

No response

Model

anthropic/claude-sonnet (direct Anthropic API, api_key auth profile)

Provider / routing chain

openclaw -> direct Anthropic API (api_key auth profile)

Additional provider/model setup details

Direct Anthropic API with api_key auth profile. openclaw_gateway adapter (Paperclip), sessionKeyStrategy: "issue". System context ~18–22K tokens (standard workspace bootstrap files + tool list + skill list). cacheRetention: "long" (also reproduced with auto-seeded "short").

Logs, screenshots, and evidence

Session JSONL data from 8 consecutive Paperclip runs (same model, same API key, all on OpenClaw 2026.3.23-2):

| Run (session key) | T1 cacheRead | T1 cacheWrite |
|---|---|---|
| paperclip:issue:c585d0cc | 0 | 20,192 |
| paperclip:issue:ca527062 | 0 | 20,133 |
| paperclip:issue:3f22f673 | 0 | 19,584 |
| paperclip:issue:d7d6ed57 | 0 | 22,273 |
| paperclip:issue:5c1165ee | 0 | 17,823 |
| paperclip:issue:35edf3ee | 0 | 24,840 |

The problematic system prompt structure:


[OpenClaw framework sections — stable across runs]

Group Chat Context                        ← extraSystemPrompt injection point

Inbound Context (trusted metadata)

{
  "schema": "openclaw.inbound_meta.v1",
  "chat_id": "paperclip:issue:c585d0cc-...",  ← VOLATILE: unique per Paperclip task
  "account_id": "default",
  "channel": "paperclip",
  "provider": "paperclip",
  "surface": "paperclip",
  "chat_type": "direct"
}

Project Context                            ← AGENTS.md, SOUL.md, MEMORY.md, etc.

Silent Replies
Heartbeats
Runtime                                   ← single cache_control: {type: "ephemeral"} here


Workaround confirmed: switching to `sessionKeyStrategy: "fixed"` with `sessionKey: "paperclip"` stabilizes `chat_id` and enables cross-run caching. Tradeoff: all runs share one session and accumulate conversation history across tasks.

Impact and severity

Affected: All users running openclaw_gateway adapters with sessionKeyStrategy: "issue" (or any per-task session scoping) on direct Anthropic API Severity: High — cross-run prompt caching is completely non-functional; every task pays full cold-start token costs Frequency: Always (100% reproducible with per-task sessionKeyStrategy) Consequence: Meaningful extra cost — at ~20K tokens cold-start × Anthropic Sonnet input pricing × multiple Paperclip tasks per day during active sprint work. With cross-run caching working, T2+ runs within the TTL window pay ~0.1x the cold-start cost. High-leverage fix for any user running OpenClaw as a backend task agent rather than an interactive chat assistant.

Additional information

Recommended Fix

One or more of the following, in rough order of preference:

1. Stabilize chat_id for backend/adapter channels. For channel == "paperclip" (or any non-chat, non-messaging channel), chat_id has no user-facing display purpose. Replace it with a stable identifier — the agent ID, the channel name, or omit it entirely. This is a minimal, targeted fix.

2. Move per-run identifiers to the user turn rather than the system prompt. The wake message already carries full task context (PAPERCLIP_TASK_ID, issue_id, etc.); the system prompt doesn't need chat_id for task routing.

3. Add a second cache_control breakpoint (the #49700 static/volatile split) so the stable prefix (tools, skills, workspace files) is cached independently of the volatile suffix. This is the highest-leverage fix and also addresses MEMORY.md churn between sessions.

4. Config knob to suppress chat_id from inbound_meta per adapter or per channel type.

Related Issues

• #49700 — static/volatile system prompt split (would address this more cleanly at the architectural level)
• #19279, #37325 — resolveCacheRetention() provider string validation
• #48753 — bootstrap truncation warnings moved out of system prompt (same class of fix: volatile content removed from system prompt)
• #21785 — dynamic inbound flags moved from system metadata to user-context (same class of fix)