Anthropic shipped Claude Opus 4.8 on May 28, and like a lot of people, I opened Claude Code, ran /model, and… it wasn’t there.
If you’re staring at a model picker that stubbornly refuses to list Opus 4.8, this post is the two-minute fix — plus an explanation of why it happens, because the reason turns out to be more interesting than “just update.”
TL;DR
Claude Opus 4.8 requires Claude Code v2.1.154 or newer. If you’re on anything below that line, the model simply won’t appear in the picker. Run:
claude update
Restart, open /model, and Opus 4.8 should be there. If it still isn’t, jump to the provider and duplicate install sections below.
The Most Common Cause: You’re One Patch Behind
Here’s the part that tripped me up. I was on 2.1.153. Opus 4.8 needs 2.1.154. I was exactly one patch version below the threshold.
That’s worth internalizing: it’s not about how far behind you are, it’s about whether you’ve crossed one specific minimum-version line. Being “close” to the required version means nothing — 2.1.153 and 2.1.154 are one digit apart, but only one of them shows the model.
The fix is the obvious one:
claude update
After updating to 2.1.156 (the current build at the time of writing), Opus 4.8 showed up in the picker immediately.
The Sneaky One: Two Claude Code Installations
When I ran claude update, I got this warning:
Warning: Multiple installations found
- npm-global at /Users/me/.nvm/versions/node/v22.20.0/bin/claude
- native at /Users/me/.local/bin/claude (currently running)
This matters. If you have two copies of Claude Code installed — a leftover npm global install and the newer native install — then which one launches when you type claude depends on your PATH order.
claude update only updated the native copy. The old npm-global copy is still sitting there at an ancient version. If your shell ever resolves claude to that stale binary, you’ll open an old client with no Opus 4.8, even though you “updated.”
Clean up the duplicate:
npm -g uninstall @anthropic-ai/claude-code
Then verify which binary you’re actually running and what version it is:
which claude
claude --version
which claude should point at the install you expect (for me, /Users/me/.local/bin/claude), and the version should be 2.1.154 or higher.
It’s Not Anthropic Direct — It’s a Cloud Gateway
This one is easy to miss. The opus alias does not resolve to the same model across providers. As of the 4.8 launch:
| Provider | What opus resolves to |
|---|---|
| Anthropic API (direct) | Opus 4.8 |
| AWS | Opus 4.7 |
| Bedrock / Vertex / Foundry | Opus 4.6 |
So if you route Claude Code through Bedrock, Vertex, or Azure Foundry, the opus entry in your picker is not 4.8 — and updating the client won’t change that. On those gateways you need to either select the full model name explicitly, or set the default with an environment variable:
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-8
# or for Sonnet:
export ANTHROPIC_DEFAULT_SONNET_MODEL=...
If you’re on Bedrock specifically, remember the model IDs there carry a region prefix (e.g. us.anthropic...), so use the exact ID your gateway expects.
The Escape Hatch: Name the Model Directly
If you don’t want to wait on the picker — or you’re debugging which layer is the problem — you can bypass alias resolution entirely and point at the full model ID:
claude --model claude-opus-4-8
You can also set it via the ANTHROPIC_MODEL environment variable or pin it in your settings. This is the fastest diagnostic: if even an explicit claude-opus-4-8 errors out, you’ve ruled out the picker and the problem is almost certainly your provider or your plan tier, not your client version.
Two caveats with the manual approach:
- An older client may reject a model ID it doesn’t recognize.
- Even if it runs, model-specific defaults (reasoning effort, 1M-context handling) may not be applied correctly. Updating is still the clean path; naming the model directly is for emergencies and edge cases.
Don’t Forget Plan Access
Opus 4.8 is available to Pro, Max, Team, and Enterprise users. If you’re on a free tier, you may not have full Opus access at all. Confirm the account you’re logged into is on a paid plan before chasing client-side fixes.
Why Does a New Model Need a Client Update Anyway?
This was the question that actually nagged at me. The model runs on Anthropic’s servers — so why can’t the server just tell the client “hey, there’s a new model”? Why does shipping a model almost always come bundled with a client release?
The answer: the model lives on the server, but how the client recognizes and presents that model ships with the client version.
The picker’s list of selectable models — and the per-model behavior wrapped around each one — is baked into the client, not fetched live. For a new model to appear as a clean, correctly-behaving option, the client needs to know a bunch of model-specific things:
- How aliases resolve — what
opuspoints to, and the fact that it differs by provider (Anthropic → 4.8, AWS → 4.7, Bedrock/Vertex → 4.6). - Default reasoning effort — Opus 4.8 defaults to
high, while Opus 4.7 defaulted toxhigh. The client applies the right per-model default on first run. - Capability flags — 1M-context variants, fast-mode support, and so on.
All of that is implemented in client code and ships with a version. So a new model showing up as a first-class, correctly-defaulted picker entry almost always comes attached to a minimum client version. That’s exactly why 2.1.153 couldn’t see Opus 4.8 and 2.1.154+ can.
The model is server-side. Knowing how to talk to it travels with the release. That’s the whole story.
The Checklist
If Opus 4.8 isn’t showing up, run through this in order:
- Update.
claude update→ need2.1.154+. - Kill duplicate installs.
npm -g uninstall @anthropic-ai/claude-code, then confirm withwhich claudeandclaude --version. - Check your provider. On Bedrock/Vertex/Foundry,
opusisn’t 4.8 — set the full model ID. - Try naming it directly.
claude --model claude-opus-4-8to isolate the problem. - Verify your plan. Opus 4.8 needs a paid tier.
Nine times out of ten it’s step one. Mine was.