[BUG] Cache from a refused request is never reused, so after each safeguard refusal the next turns re-write the full context (4 refusals = whole 5-hour Pro limit)

Status Open
Reported on v2.1.280
Maintainer reply None cached
Activity 0 comments · opened Sep 26, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

After an Opus 5.5 safeguard refusal (stop_reason=refusal, category cyber), the prompt cache written by the refused request is never reused. The next request reads only the cache entry that existed before the refusal and writes everything after it again. On top of that, after every refusal Claude Code automatically sends one more request on the same context ("Opus 5.5's safeguards stopped the response above · continuing once with that noted").

With a warm cache this costs ~20k extra tokens per refusal and goes unnoticed. With a cold cache, e.g. right after a 5-hour limit lockout longer than the 1h TTL, every retry after a refusal re-writes the whole conversation. On a ~700k-token conversation that is ~15% of a Pro 5-hour window per request. Four refusals in 10 minutes exhausted my whole window (logs below).

Across one night and several sessions of one conversation: cache written by successful requests was always reused; cache written by refused requests never was.

What Should Happen?

  • The cache written for a refused request's prompt stays reusable by the next request (or the retry is repriced the way fallback credit works on the API), so a refusal does not cost a full context re-write.
  • Claude Code does not auto-send "continuing once" when that would re-write a large uncached context, or at least warns about the cost first.

Error Messages/Logs

Messages shown by Claude Code after a refusal:
system: Opus 5.5's safeguards stopped the response above · continuing once with that noted
meta:   Your response above was stopped by a safety classifier — this is not a tool or API error. The rest of it was withheld, and tool calls in it that had not finished did not run. Do not produce that content again, even reworded.
automatic continuation (22:13:31 UTC): API Error: Opus 5.5's safeguards flagged this session ... Details: [cyber] Request ID: req_011CfQveRZnVi4V3synEiEXf

Usage from the session transcripts (2026-09-25 UTC)

Warm cache, same session:
22:12:34 req_011CfQvdhxV5fdAy1WPHV4LS  refusal  cache_creation 16,869   cache_read 711,141
22:13:31 req_011CfQveRZnVi4V3synEiEXf  automatic continuation -> "safeguards flagged this session"
22:13:44 req_011CfQvj6b9udvRMpJiVhAMs  refusal  cache_creation 20,401   cache_read 711,141   <- not 728,010

Cold cache, after the 5-hour limit lockout (1h37m > 1h TTL):
23:51:51 req_011CfR4CLHjhiTY1wHZucTao  refusal  cache_creation 732,330  cache_read 0        (TTL expired, expected)
23:56:25 req_011CfR4YPjetZCWn36dH5XeP  refusal  cache_creation 687,400  cache_read 40,868   (other branch, expected)
23:57:48 req_011CfR4bZGjExh9rjBXhzHu9  refusal  cache_creation 690,943  cache_read 40,868   (same session, 83 s later)
23:59:52 req_011CfR4omv4yX8Ahij77yMBo  refusal  cache_creation 691,381  cache_read 40,868   (same session)
00:00:55 req_011CfR4uaMUQeXbfHN5g1qxq  rejected: 5-hour limit
Each refusal above was also followed by an automatic continuation request; those have no usage entries in the transcript.

Steps to Reproduce

  1. Work in a long Opus 5.5 conversation (~700k tokens of context) until a request is refused by the safeguards (stop_reason=refusal).
  2. Let Claude Code auto-continue ("continuing once with that noted"), then send any next message.
  3. Check usage in the session JSONL: the next request's cache_read equals the value from before the refused request, and the refused request's part of the context is written again (cache_creation).
  4. To see the full cost, let the cache go cold (>1h idle, e.g. a 5-hour limit lockout), then send a message that gets refused and retry: each attempt shows cache_creation ≈ the whole context and cache_read ≈ only the system prompt (~41k).

I have not re-tested on the latest version: reproducing costs most of a Pro 5-hour window. The request IDs above should be enough to inspect it server-side.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.280

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Claude Pro subscription (not an API key), Claude Code CLI via Remote Control, effort xhigh. Related but different: #95222 (cold cache after limit reset), #42338 (resume invalidates cache), #92201.

View original on GitHub ↗