onlyterp/prompt-cache-skills/continue-fix-volatile-msg

Continue: the "volatile message" is a rolling ladder — verify, don't rip out

REANALYZED 2026-08-28. The previous version of this skill

renamed addCacheControlToLastTwoUserMessages to a "last stable

message" variant. Direct source recon shows Continue ships the same

documented rolling read/write ladder as Cline/Roo (the helper name

persists in packages/openai-adapters/src/apis/AnthropicUtils.ts).

Applying the old diff would remove a working cache write point.

Target

packages/openai-adapters/src/apis/AnthropicUtils.ts (helper) and its callers in the Anthropic adapter; core/llm/llms/Bedrock.ts (_addCachingToLastTwoUserMessages, cachePoint shape) for the Bedrock path.

What Continue actually does

Same two-breakpoint ladder as Cline/Roo: current user turn = write point, previous user turn = read point. See cline-fix-volatile-msg for the full explanation and the 3-turn wire test. Continue's distinct problem is not the ladder — it's that caching is gated behind config and off by default, so most users get nothing at all, and no TTL extension exists for long sessions.

Step 1 — verify the ladder on the wire (before any change)

Same 3-turn capture as the Cline skill. Continue gates the whole caching path behind cacheBehavior config — if the capture shows zero cache fields in the request at all, fix the config first (next step) and re-capture before judging the ladder.

Step 2 — default-on (the actual money fix)

Continue's cacheBehavior config defaults leave Anthropic caching off for most installs. See continue-enable-defaults — that skill remains the primary win for this harness. The ladder should be verified after defaults are on, never instead.

Step 3 — Bedrock path: verify the cachePoint translation

Continue's Bedrock adapter re-implements caching with cachePoint (not cache_control — gotcha 12). Two checks before trusting it:

1. The cachePoint placement mirrors the ladder (write point on the

current turn, read point on the previous) — same 3-turn wire test through the Bedrock envelope, reading cacheReadInputTokenCount/cacheWriteInputTokenCount.

1. The Bedrock model ID in use actually supports cache points (gotcha

13 — the AWS support matrix drifts; verify, don't assume).

Verify (whole skill)

After default-on: request bodies contain cache_control on the ladder positions; 3-turn capture shows the write@N → read@N+1 pattern; Bedrock capture shows the same through cachePoint.

Background

• docs/gotchas.md #12 (cachePoint), #17

(relay field-stripping), #18 (the ladder test).

• Full audit: audits/continue.md.