Hi, Lena is coming~ Claude Code Opus 5.5 is one of those model choices I would make explicitly rather than assume is already active. The reason is simple: the opus alias does not resolve the same way on every provider, and a resumed Claude Code session may reopen with the model it used before.
So before testing anything meaningful, I want three things to line up: the model Claude Code says it is running, the repository I have allowed it to touch, and the result I will use to judge the trial.
Evidence note: Anthropic announced Opus 5.5 on September 22, 2026. I checked current documentation on September 24. Claude Code is not installed here, so the exercise below is a reproducible procedure, not a completed model test.
Check Access and Update Claude Code
Start with:
claude --version
Anthropic says Opus 5.5 requires Claude Code v2.1.280 or later. If your installation is older, run:
claude update
Then check the version again. If the installation behaves strangely, claude doctor is the more useful next step than repeatedly reinstalling or changing model settings.
Model availability also depends on the account behind Claude Code. You need an eligible paid Claude plan, a Console account, or access through a supported cloud provider. A free Claude.ai account by itself is not enough.
Organization settings matter here as well. If Opus 5.5 simply does not appear, I would check the account, provider, and managed model restrictions before assuming the local Claude Code installation is broken.
Select Opus 5.5 for the Session
Use the Current Model Picker
Inside Claude Code, enter:
/model
Then look for Opus 5.5.
Anthropic's Claude Code model configuration guide gives the picker two slightly different behaviors:
sswitches the current session without changing the saved default.- Enter selects the model and also saves it for future sessions.
For a trial, I prefer s. I do not want an evaluation session quietly changing the model I normally use.
You can also enter:
/model claude-opus-5-5
That saves the selection.
One detail is easy to miss: opus is an alias, not a version pin.
At the time of writing, it maps to Opus 5.5 on Anthropic's API, Claude Platform on AWS, Amazon Bedrock, and Google's Agent Platform, while Microsoft Foundry still resolves it differently. If the purpose of the exercise is specifically to evaluate Opus 5.5, I would use the full model name rather than trust the alias.
Use the Full Model Name in the CLI
For a fresh session against Anthropic's API:
claude --model claude-opus-5-5
This applies the model to that launch without rewriting your saved default.
Cloud deployments can be less tidy. Depending on the provider, the equivalent may be an inference profile ARN, deployment name, or provider-specific model version rather than Anthropic's plain model string. In that case, the provider configuration is part of the test setup, not an implementation detail to ignore.
Verify Which Model Is Active
After selecting the model, run:
/status
This is the check I would trust. It shows the active model, version, and account, and a configured status line can expose the model as well.
The distinction matters because asking Claude Code to use a model is not quite the same thing as proving that the session actually started on it. Organization allowlists, provider configuration, fallbacks, and resumed sessions can all complicate that assumption.
If /status shows something unexpected, stop there and fix the selection first. I would not try to identify the model from its writing style, coding behavior, or a label remembered from an earlier session.
I would also record the provider alongside the model name. Two sessions can show similar human-readable model names while resolving to different provider deployment identifiers underneath.
Give It One Small, Reversible Repository Task
For the first test, I would avoid a feature build.
Use a disposable repository or a safe test branch with no secrets, production credentials, or customer data. First confirm the working tree:
git status --short
Then run the repository's normal local test command. Once you know the starting state is healthy, create a branch:
git switch -c trial/opus-5-5
That gives you a clean comparison point without pretending that a Git branch is a security boundary.
A useful first brief might look like this:
“Add one regression test for empty input in the named function. Change its implementation only if the test fails. Touch only that function and test file. Add no dependencies, use no network, and stop before commit or push. Run the existing local test command; report changed files and results.”
I would replace the generic references with real paths, the exact function name, and the known test command before running it.
The task is intentionally boring. That is useful.
For a first model check, I care less about whether the model can invent an impressive implementation and more about whether it respects scope, notices the existing test structure, makes the smallest necessary change, and stops where I told it to stop.
Keep permission prompts enabled and approve only what the task actually requires.
Review the Diff, Not Just the Test Result
Once Claude Code finishes, I would inspect:
git status --short
git diff --check
git diff
Git's current diff documentation explains exactly what those comparisons show, but the important review still belongs to you: did the model touch the files you allowed, and does the change actually match the brief?
One trap here is that plain git diff does not show untracked files. Check those separately rather than treating a clean-looking diff as proof that nothing else appeared.
Then run the local test command yourself and record the exit status.
A passing test is useful evidence, but it is not enough. A model can pass the requested test and still create an unnecessary file, edit something outside the agreed scope, or introduce a dependency that the brief explicitly ruled out.
If the trial does not survive review, I would restore only the files involved in the experiment, inspect and remove any newly created files, and return to the starting branch.
Keep the test output even if you throw the code away. Failed trials are often more informative than clean demos because they show where the model ignored scope or where the brief was underspecified.
For an EvoX Code review, the artifacts I would bring are simple: the branch name, the actual diff, and the test log. Local EvoX material may support repository review, but that does not imply an automatic Claude Code session handoff.
Return to Your Normal Model
If the test used s or --model, start a fresh Claude Code session without an override and run /status again.
If you pressed Enter in /model, choose your normal model—or Default—and press Enter so that selection becomes the saved default again.
Project and organization settings can still override user-level preferences, so I would verify the fresh session instead of assuming the reset worked.
The same applies when reopening the trial later. A resumed Claude Code session may restore the model associated with that earlier session.
FAQ
Can organization administrators restrict which models users select in Claude Code?
Yes. Managed availableModels settings and Enterprise controls can limit what appears in the model picker.
If Opus 5.5 is absent in a managed environment, check with the administrator before troubleshooting the local installation.
Can a project pin Opus 5.5 without changing a user's global default?
Yes. A project's .claude/settings.json can specify:
"model": "claude-opus-5-5"
That is useful when a repository is intentionally standardized on one model, although shared project settings should be reviewed with the rest of the team.
For a one-off evaluation, I still prefer --model because it leaves the global default untouched.
Does resuming an older Claude Code session preserve its original model?
Often, yes, when using Anthropic's API.
There are exceptions. Retired models, organization restrictions, explicit launch overrides, and provider-specific deployment behavior can change what is actually available when the session resumes.
That is why /status belongs at the start of a resumed test as well.
How do usage limits differ between Opus 5.5 and other Claude models?
Anthropic announced higher five-hour usage limits for Pro, Max, and Team plans, but there is no universal “X tasks per model” number that applies cleanly to every workload.
Use /usage to check the allowance attached to your own account. I would not assume two models consume that allowance identically simply because they are available in the same picker.
Is Opus 5.5 available through every supported cloud provider?
Anthropic lists its own platform, AWS, Google Cloud, and Microsoft Foundry.
That does not mean every account, region, deployment, or organization automatically has access. Provider naming also differs, and the opus alias does not resolve to Opus 5.5 everywhere.
For a real comparison, verify both the provider deployment identifier and the model shown in /status before you start judging the output.
Previous Posts:
- If you want another Claude Code workflow built around a bounded repository task, Obsidian Claude Code vault-to-code workflow shows how to retrieve controlled context, apply it to code, run checks, and write back only after review.
- For evaluating whether a stronger reasoning setting actually improves repository work, Muse Spark 1.3 agent reasoning compares completion quality, intervention, latency, and task cost under a fixed coding task.
- If your main concern is keeping coding-agent work reviewable, T3 Code review focuses on repository scope, session control, diff inspection, and human handoff around one coding surface.
