Anthropic resumes billing for requests its safeguards block, while Opus 5.5 flags noodle recipes

Anthropic announced through its ClaudeDevs account on September 24 that it will again charge for requests its classifiers block before Claude answers, in three categories: biology, distillation, and frontier LLM development. The stated reason is "coordinated attacks on our systems in recent weeks." Anthropic says the classifiers run below a 0.1% false-positive rate, and that 99.7% of Claude Code, Claude.ai and Cowork accounts hit none of the billable blocks in testing. (AlphaSignal coverage)

Same day, an r/ClaudeAI thread listed prompts that tripped "This model's safeguards flagged this message" on Opus 5.5: comparing USD against Hilton points, Amex transfer partners, a yen conversion, a pan mee recipe. The moderator summary after 30 comments says the thread's consensus is that the classifier is too aggressive right now. Scientists reported Opus 5.5 refusing ordinary research work earlier this week too.

I want to be careful here because two claims are getting conflated. Anthropic's sub-0.1% figure is about the three billable categories, and the noodle recipe is a different classifier producing a different refusal. Those are not the same measurement, and the Reddit list is anecdote, not a rate. Anthropic has not said how it handles refunds for a wrong block, which is the gap I'd want closed before I felt fine about this.

What I'd do with it, concretely: instrument stop_reason and count refusal as its own bucket in whatever telemetry you keep on model calls. Not as an error, as a category. If that count is non-zero and growing on a workload you believe is benign, you now have a billing exposure and a reliability problem in the same number. Claude Code 2.1.282, released to npm September 24 at 15:56 UTC, added the other half: when the summarization request during compaction gets refused, compaction retries on a fallback model instead of failing the turn. (changelog) Wire that fallback before it shows up on an invoice.

The same release has a permission bug that's more interesting than it looks. Bash allow rules with a mid-pattern :*, the shape Bash(git:* push), were silently skipped when they came from settings files, though --allowedTools honored them. They apply from every source now, with a startup warning explaining how matching works. So a rule you wrote months ago in settings.json may have never matched anything, and after upgrading, it matches. Go read your allow list before you run the next unattended session. That release also stops repository, user and --add-dir skills from pre-approving their own tools through allowed-tools when allowManagedPermissionRulesOnly is set, which closes a path where a cloned repo's skill grants itself permissions.