Skip to main content
  1. Posts/

Every Claude 5 change that silently rewired my Claude Code setup

··1324 words·7 mins·
Nick Liu
Author
Nick Liu
Building infrastructure for Facebook Feed Ranking at Meta. Previously at Walmart, Twitter, AWS, and eBay. MS in Computer Science at Georgia Tech.
Table of Contents
The first sign that a model generation had turned over under my feet was a billing prompt that made no sense. I ran /model to switch back to Fable 5 and the CLI opened a browser tab telling me to set up usage credits, for a model my Max plan already includes. A full restart of Claude Code fixed it. That little glitch sent me digging, and what I found was a pile of changes, some breaking, some silent, scattered across at least five official pages. This is the consolidated list I wanted that week.
Tested with Claude Code 2.1.220 路 macOS

Eight weeks that rearranged the lineup
#

06-09
Fable 5 ships

06-12
export controls
pull it offline

06-30
Sonnet 5 becomes
Claude Code default

07-01
Fable 5
redeployed

07-24
Opus 5 ships at half
Fable's price, becomes
the default Opus

08-05
claude-opus-4-1
retires

06-09
Fable 5 ships

06-12
export controls
pull it offline

06-30
Sonnet 5 becomes
Claude Code default

07-01
Fable 5
redeployed

07-24
Opus 5 ships at half
Fable's price, becomes
the default Opus

08-05
claude-opus-4-1
retires

Compressed into one summer: Fable 5 launched, went dark for about three weeks under US export controls, and came back; Sonnet 5 quietly took over as the default model; then Opus 5 arrived at $5/$25 per million tokens, exactly Opus 4.8’s price and half of Fable 5’s, and became what opus resolves to. Three days from now, claude-opus-4-1 stops existing. If your tooling grew up on the 4.x generation, some of it is already wrong.

The pricing picture in one chart, list prices per million tokens from the pages cited below:

The requests that now return 400
#

These are from Anthropic’s migration guide and the Opus 5 notes, and they fail loudly, which is the good kind of failure:

  1. Manual thinking budgets are gone. thinking: {type: "enabled", budget_tokens: N} returns 400 on the Claude 5 generation. Adaptive thinking is always on; depth is now the effort parameter’s job.
  2. You cannot turn thinking off at high effort. thinking: {type: "disabled"} is only accepted on Opus 5 at effort high or below; combined with xhigh or max it returns 400. Fable 5 refuses to disable thinking at all.
  3. Sampling knobs are dead. Non-default temperature, top_p, or top_k return 400. The official guidance is blunt: omit them and steer with prompting.
  4. Assistant prefill returns 400 on Fable 5 and Mythos 5. The old trick of seeding the assistant turn is over on those models.
  5. A refusal is now a successful response. Fable 5’s safety classifiers decline with HTTP 200 and stop_reason: "refusal". Code that only branches on HTTP errors will treat a refusal as a normal answer.

My own setup passed all five untouched, and the reason is worth a paragraph: everything in my ~/.claude/agents/ fleet names models by alias (sonnet, haiku, opus), not by pinned ID, and none of it sets sampling parameters. When the generation turned over, the aliases quietly re-resolved to Sonnet 5, Haiku 4.5, and Opus 5, and the fleet kept working without an edit. I did not plan that. But I will take the lesson: aliases ride generation shifts for free; pinned IDs buy you reproducibility and hand you a retirement calendar to watch. Pick one on purpose. The deprecation page is the calendar.

The changes that do not error, which makes them worse
#

The 400s announce themselves. These do not.

The tokenizer counts differently. Since Opus 4.7, the same text can cost up to roughly 1.35x the tokens (migration guide). Every max_tokens value and cost estimate calibrated on 4.6-era counts is quietly stale.

Effort changed shape and moved in. Five levels, low through max, default high, documented for the API and Claude Code. Two traps inside:

  • The scale is calibrated per model. The docs say the same level name does not mean the same underlying value across models. high on Opus 5 and high on Sonnet 5 are different animals wearing the same collar.
  • Changing effort mid-conversation invalidates your prompt cache. Cited straight from the effort docs. An innocent-looking /effort toggle in a long session throws away the cached prefix you have been paying to keep warm.
  • And one inconsistency that will bite someone: on first run, Fable 5, Opus 4.8, and 4.7 apply their model-default effort even if you had set something else, but Opus 5 carries your previous setting forward. Same knob, different memory, depending on the model.

Opus 5 verifies without being asked. The official prompting guidance says explicit verification instructions now cause over-verification and should be removed. I have a take on this one, because my config is full of verification. The instructions worth deleting are the prompt-level nagging, the “always double-check your work” incantations. What I am not deleting: the hooks that lint before commit, the CI gates, the checklist subagent. Prompt verification was always the weakest link in that chain, a request the model could ignore or overdo. Deterministic gates cannot be over-eager and cannot be skipped. The Claude 5 advice, read carefully, is not “verify less”. It is “stop asking politely for what your infrastructure should enforce”.

The Claude Code layer has its own facts
#

From model-config and costs:

FactDetail
Defaults movedMax, Team Premium, and API accounts default to Opus 5; Pro and standard Team seats default to Sonnet 5
Fable 5 is never the defaultYou opt in with /model fable or the best alias; on Max it can consume up to 50% of the weekly cap
Version gatesOpus 5 needs v2.1.219+, Sonnet 5 needs v2.1.197+, Fable 5 needs v2.1.170+
Switching models does not reset limitsThe 5-hour and weekly windows are shared across all models; /model is not an escape hatch
Cache TTL shrinks under creditsSubscription usage gets a 1-hour prompt cache; the moment usage credits kick in, it drops to 5 minutes

That phantom billing prompt from my opening? Almost certainly the CLI’s cached account state lagging the 07-24 default switch. The fix was restarting the process. I mention it because the symptom looks exactly like “your plan lost Fable 5”, and the support pages will not reassure you, which brings me to the last section.

The docs have not all caught up, so date what you read
#

While writing this I hit a support article about Pro and Max usage that, as of 2026-08-02, still describes the 4.x world: hour estimates quoted in Sonnet 4 and Opus 4 terms, and a claim that Pro cannot use Opus, which the current model-config page contradicts (Pro’s default is Sonnet 5, and defaults are not caps). As of this writing, no current official page publishes weekly hour figures for the 5-generation models at all. So a practical rule I now follow: when two Anthropic pages disagree, trust the one under code.claude.com/docs, and treat any number you cannot find there as unpublished rather than unchanged.

Lessons
#

  • Name models by alias for daily work and by pinned ID for reproducible pipelines. Aliases survived this generation shift with zero edits; pinned IDs got a retirement date.
  • The loud changes are the safe ones. Budget your migration attention for what does not error: tokenizer drift, effort semantics, cache invalidation.
  • Move verification out of prompts and into infrastructure. Claude 5 made polite verification requests redundant at best and expensive at worst; hooks and CI gates got more valuable, not less.
  • Never toggle effort mid-session in a conversation you care about; the cache you lose costs more than the depth you gain.
  • Date every claim about limits and pricing, including the ones in this post. The 4.x-era support pages are still up, and they read as current until you check.

References
#

Related

Hooks are guarantees, skills are knowledge, subagents are other people.

··1101 words·6 mins
My Claude Code config now holds two hooks, ten skills, and three custom subagents, and most of them started life in the wrong layer. The instruction the model followed nine times out of ten lived in a prompt until I accepted that nine out of ten is a coin I lose every day. The workflow I pasted into chats became a skill. The bulk work that was draining my priciest model's quota became a fleet of cheaper agents. Same features, different failure modes. Taming Claude Code Sessions 路 Part 6 of 6 1 2 3 4 5 6 馃И Tested with Claude Code 2.1.x 路 macOS The four layers # Claude Code has four extension points, and they answer four different questions:

Git worktrees gave each Claude agent its own sandbox. And scattered my sessions.

··978 words·5 mins
I run four or more Claude Code agents at once, and until recently they all shared one working tree. Two agents editing the same repo means one of them eventually builds against the other's half-finished changes. Git worktrees fix that cleanly. What nobody warned me about is that the fix multiplies a different problem I already had: forgetting which folder a session lives in. Taming Claude Code Sessions 路 Part 5 of 6 1 2 3 4 5 6 馃И Tested with Claude Code 2.1.x 路 macOS The symptom # With several agents in one directory, the working tree is shared mutable state. Agent A refactors a partial, agent B runs the build, and B’s “failure” is really A’s work in flight. I had been dodging this by scoping agents to different subdirectories, which works until it does not.

Running Several AI Coding Agents Without Losing Track

··867 words·5 mins
Once you're comfortable with AI coding agents, you start running several at once: one refactoring here, one writing tests there, one stuck waiting for your approval. Keeping them straight is its own little skill. Taming Claude Code Sessions 路 Part 4 of 6 1 2 3 4 5 6 馃И Tested with Claude Code 2.1.x 路 macOS / Linux Here are two ways to do it: a lightweight tmux plugin, and (briefly) dedicated “AI terminal” apps.