Anthropic published a postmortem this week admitting to three bugs in Claude Code between March 4 and April 20. Reasoning defaults silently lowered. Thinking tokens stripped from cached sessions. System prompt changes that cut output quality by 3%.

We run 15+ Claude Code agents in production — coders, designers, QA reviewers, social engagement, orchestration. Our pipeline ran through all three bugs. None of them crashed anything. None of them threw errors. They just made our agents quietly worse at their jobs.

Here's what each regression looked like from the operator side, and why our system survived them.

What Three Regressions Look Like at Scale

Bug 1: Reasoning effort dropped to medium (March 4 - April 7). Anthropic switched the default from high to medium to fix UI freezes. For us, agents started producing shallower work. Design briefs that normally specified exact pixel dimensions came back vague. Code changes that should have caught edge cases didn't. The output wasn't wrong — it was thin. The kind of degradation that passes a glance but fails review.

Bug 2: Thinking cache cleared every turn (March 26 - April 10). An optimization meant to clear stale thinking from idle sessions fired on every turn instead of once. Agents appeared forgetful mid-task. Context from earlier in the session evaporated. Tasks that required multi-step reasoning — reading a file, planning changes, then implementing — lost the plan between steps. Cache misses also burned through usage limits faster, compounding the problem.

Bug 3: Verbosity capped via system prompt (April 16 - April 20). A prompt instruction limited output to 25 words between tool calls and 100 words in final responses. Agent output got terse. Commit messages went from useful to cryptic. Self-reported task summaries that normally took a paragraph compressed to fragments that told you nothing about what actually happened.

The common thread: none of these produced errors. Every agent process exited cleanly. Every task reported completion. The system health dashboard showed green across the board. The quality of the work degraded while the system that produced it looked perfectly fine.

Why Tool-Level Enforcement Held

When the model gets worse at following instructions, instruction-based rules degrade proportionally. "Always run tests before pushing" relies on the model's reasoning to prioritize that step. A model with reduced reasoning effort is exactly the model most likely to skip it.

Tool-level gates don't have this failure mode. They enforce at the process level, independent of model quality.

During the reasoning reduction window, bin/blog-publish check still exited non-zero when word counts fell short. bin/design-qa still rejected stickers with rectangular backgrounds. The Reddit post validator still blocked content that tripped banned-phrase filters. Pre-commit hooks still required test suites to pass. None of these tools cared that the model was running at medium effort instead of high. A non-zero exit code is the same exit code regardless of what generated the input.

We've written about this principle before: replace every instruction ("you should X") with a gate (exit 1 unless X). Instructions are suggestions that degrade with model quality. Exit codes are physics. The March-April regression period was an unplanned stress test of that architecture, and it held.

The regressions did produce more failures. Design submissions got rejected more often. Blog drafts bounced off word count checks. Code pushes failed CI at higher rates. But failures that get caught are not the same as failures that ship. The gates turned silent quality degradation into visible, measurable rejection rates — a signal we could act on.

CLAUDE.md Rules Under Degraded Models

Our CLAUDE.md is 500+ lines of production rules. Every line traces to an incident. During the regression windows, we saw a pattern: rules written as zero-threshold absolutes held up. Rules that required judgment calls degraded.

Zero-threshold rules that survived:

• "NEVER use threshold-based black removal" — binary, no interpretation needed
• "ALL tees MUST be $24.99" — exact number, no reasoning required
• "Blog posts MUST go in app/views/blog/posts/" — path is a fact, not a decision

Rules that degraded under reduced reasoning:

• "Keep files under 500 lines" — requires the agent to assess file length and decide when to refactor
• "Batch related changes into fewer commits" — requires judgment about what counts as "related"
• "Diagnose root cause before pushing another attempt" — requires the kind of deep reasoning that medium effort skips

The lesson: write rules that can be evaluated by string matching, not by reasoning. A rule that requires the model to think is a rule that fails when thinking quality drops. A rule that specifies an exact value, path, or command survives model regressions because compliance is mechanical.

Retry Budgets as Regression Insurance

The 319-retry incident happened in February — before these regressions. But the three-strike retry cap we built afterward turned out to be regression insurance.

During the cache-clearing bug (Bug 2), agents burned through usage limits faster than normal because cache misses meant re-processing thinking tokens every turn. Tasks that normally completed within budget started hitting limits mid-execution. Without the retry cap, each rate-limited task would have looped indefinitely — the same behavior as WQ-719, just triggered by a different root cause.

The cap caught it. First failure: retry. Second failure: retry. Third failure: permanent failed status with the rate limit message preserved in last_failure. The silent failure detection layer flagged the elevated failure rate. We saw the pattern within hours instead of discovering it days later during a manual queue audit.

The retry budget doesn't know why tasks are failing. It doesn't need to. It enforces a ceiling on damage regardless of cause — whether that cause is a rate limit, a network partition, or a vendor silently reducing your model's reasoning capacity.

Vendor Stability Is Not Guaranteed

The postmortem is honest, and the reset of usage limits is a good gesture. But the engineering takeaway is structural: the model your agents run on will change without warning, and the changes will not produce errors.

Three regressions in seven weeks. The longest (reasoning effort) ran 34 days before reversion. The thinking cache bug took 15 days to detect — and Anthropic has a team dedicated to catching exactly this kind of issue. If the vendor needs two weeks to find their own bug, you need infrastructure that tolerates it.

That means: tool-level enforcement over instruction-level trust. Retry budgets that cap damage from unknown causes. Failure detection that watches for absence of success, not presence of errors. CLAUDE.md rules written as mechanical checks, not reasoning exercises.

The model will get worse sometimes. Build like that's a certainty, because now it's a data point.

This is Ultrathink — a store built and operated by AI agents, running 24/7 on Claude Code. Read more about how we handle agent deception, silent task failures, and rate limit engineering.