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

REANALYZED 2026-08-28. The previous version of this skill replaced Roo's last-two-user-messages marking with a single "last stable message" breakpoint. Direct source recon shows Roo (a Cline fork) carries the same documented rolling read/write ladder as Cline — the inline comment explains it verbatim. Applying the old diff would remove a working cache write point. Verify the ladder instead; the real Roo-specific wins are below.

Target

src/api/transform/caching/anthropic.ts in RooCodeInc/Roo-Code (moved there by v3.54.0 — the ladder function addCacheBreakpoints lives in that file now; src/api/providers/anthropic.ts calls it).

Permalink: https://github.com/RooCodeInc/Roo-Code/blob/v3.54.0/src/api/transform/caching/anthropic.ts

What Roo actually does

Same shape as Cline (see cline-fix-volatile-msg for the full ladder explanation — Roo's inline comment documents it verbatim): current user turn = write point, previous user turn = read point, system prompt has its own breakpoint.

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

Same 3-turn capture as the Cline skill. Ladder holds → leave the breakpoints alone. Thrash → real bug, apply the Cline skill's diagnosis. Do not skip this step on the strength of the source code alone — the ladder only proves itself on the wire.

Step 2 — Vertex: respect the 4-block budget explicitly

Roo's anthropic-vertex.ts documents Vertex-specific limits: max 4 cache_control blocks, text-only, user/assistant restrictions — and implements an explicit strategy (system + last text block of each of the last two user messages). If you patch message-level caching on direct Anthropic, make sure the Vertex path still fits its own budget:

• System prompt: 1 block
• Last text block of second-to-last user message: 1
• Last text block of last user message: 1
• → 3 used, 1 spare. Any added breakpoint must not be a 4th on Vertex unless it replaces a message breakpoint.

Step 3 — OpenAI-native lanes: the missing prompt_cache_key

Roo scans show zero prompt_cache_key usage across the codebase (665 TS files checked, 2026-08-28). Its OpenAI-native handler relies on automatic prefix matching only. That works for single-session use but leaves multi-worker pod routing to chance — the same gap Cline has. See cline-openai-cache-key for the hash-derivation pattern; the same fix applies to src/api/providers/openai-native.ts (derive the key from system prompt + model slug, NOT a per-session UUID).

Step 4 — MiniMax / anthropic-compat providers inherit the ladder

Roo's minimax.ts handler (and any Anthropic-compatible provider added later) re-implements addCacheControl with the same last-two-user-messages shape. Any future provider handler copied from it inherits the ladder — apply the same verify-don't-rip rule, and check the compat endpoint actually honors cache_control (gotcha 17: a 200 response proves nothing).

Verify (whole skill)

3-turn capture on the direct Anthropic path unchanged in shape; Vertex capture shows ≤4 blocks per request; OpenAI path shows stable prompt_cache_key across turns and non-zero cached_tokens by turn 2.

Background

• docs/gotchas.md #17, #18.
• Full audit: audits/roo-code.md.