Claude Opus 5.5: Best Uses, Prompts and Effort Settings

Claude Opus 5.5 is worth evaluating when the job involves understanding an existing system, making connected changes and checking the result. Start with a bounded task at medium effort. Give it the relevant code or documents, an explicit definition of done and a way to prove success. Increase effort when you can name what the first attempt missed, not simply because a higher setting exists.

This is a practical guide to where Opus 5.5 is promising, how to brief it and how to avoid paying for impressive work that does not finish the actual job. The workflows below are our recommendations, not a claim that Wavect has independently benchmarked the model.

Why are people excited about Opus 5.5?

Anthropic released Opus 5.5 on 22 September 2026, emphasizing stronger long-running work, clearer communication and lower costs. Its headline 40% task-cost reduction is a vendor measurement against Opus 5, not a universal saving. Read Anthropic's launch evidence.

There is also firsthand enthusiasm beyond the announcement. Every's early-access team reported better coding and creative collaboration, but also unfinished deliverables and unnecessary extra work. Those observations explain some of the excitement; they are not a representative survey of developers. Read Every's hands-on account and disclosure.

Our interpretation: the attraction is not just a better answer. It is less friction while turning an ambiguous request into an artifact you can inspect. That matters when a developer is asking for a reviewable change rather than another explanation of how to make one.

The API model ID is claude-opus-5-5, with a documented one-million-token context window. A model's context capacity and the files an application actually supplies are different things. Do not assume that selecting a model gives it access to your repository or internal systems. Check the model specification.

What is Opus 5.5 best used for?

Prioritize tasks whose quality depends on connecting evidence across files, steps or sources. Anthropic's model-specific prompting guide identifies repository-level coding, code review, knowledge work and visual inputs as relevant strengths. The table below is our proposed starting plan, not a measured ranking. See the Opus 5.5 prompting guide.

Use the same brief structure for each: outcome, inputs, boundaries, evidence and stopping condition. These five fields make the assignment reviewable without prescribing every implementation step. The goal is enough freedom to solve the problem, with little ambiguity about what counts as solving it.

How do you use Opus 5.5 for refactoring without changing behavior?

Make the unchanged behavior a deliverable, not a footnote. For a dependency migration, ask for an inventory of callers and compatibility obligations before allowing edits. Then approve one representative slice. A successful slice should establish the pattern the remaining changes follow.

Anthropic's Claude Code guidance recommends executable verification such as tests, builds and screenshot comparisons. Read its verification workflow.

A useful task is “move the invoice export behind our existing adapter without changing the exported rows,” not “modernize the billing system.” The first has a boundary and an observable result. The second invites unrelated architectural decisions.

Refactor the invoice-export integration to use our existing adapter.
Read the repository instructions, adapter implementation and export tests first.
Before editing, list callers and the behaviors that must remain unchanged.

Preserve public interfaces, row ordering, rounding and error behavior.
Do not change the database schema, dependency versions or unrelated formatting.
Implement one representative path, then run the relevant existing tests.
Add a regression test where current coverage does not protect the contract.

Return the diff, commands actually run, results and remaining risks.
Stop for approval if preserving behavior requires a public-contract change.
Do not merge or deploy.

Protect the reference output outside the agent's writable area. Otherwise a changed implementation and a changed expected fixture can agree with each other while both violate the original requirement. Let the agent propose a fixture update, but require a separate decision before accepting it.

Where can Opus 5.5 help with debugging and code review?

Use it to investigate competing explanations, not just manufacture a plausible fix. Ask what observation would distinguish a bad state transition from a missing retry, or an authorization failure from an unavailable dependency. The most useful artifact is often a failing test plus a small correction.

CodeRabbit's Standard pipeline caught 11 OSS issues its production model mix missed, but missed nine that mix caught and reported higher token use. Standard is a pipeline configuration, not an API effort level. Test complementary coverage rather than assume a replacement catches everything. Inspect CodeRabbit's evaluation methodology.

Sonar reported an 87.7% pass rate for Opus 5.5 High versus 88.6% for Opus 5 Thinking on 544 executable Java tasks. Its broader analysis also found less generated code. This is a different task and setup, not a contradiction that either proves or disproves repository-level gains. Read Sonar's original evaluation.

Investigate why a repeated checkout request sometimes creates a second order.
Use only the supplied repository, redacted logs and synthetic test data.
Do not contact production services or change live orders.

Map the request, state transitions and persistence path.
Give two plausible causes and the evidence that would separate them.
Reproduce the supported cause in a local test before editing the implementation.
Make the smallest fix and test repeated, concurrent and interrupted requests.

Report confirmed findings separately from suspicions.
For each confirmed finding, include file locations, reproduction and impact.
Keep style suggestions out of the defect list. Do not deploy.

For a review pilot, give the candidate model and your current reviewer the same frozen diff and context. Keep their findings separate until adjudication. Measure confirmed defects, false alarms and reviewer time. A longer list of comments is neither proof of better coverage nor proof of worse performance.

How do you get useful frontend work instead of an attractive mockup?

Give Opus 5.5 a complete, small user journey. For example: view an invoice, correct a validation error and download the final document. Specify the existing components and design tokens it must reuse. Ask for the error, empty and loading states, not just the screenshot that sells the idea.

Our Claude Code design-system workflow separates approved visual references, implementation rules and reusable examples. Use that context before asking the model to invent a new visual direction.

Implement the invoice detail flow using our existing design system.
Read the approved reference, design rules and nearest existing component first.
Keep the current routes, API contract, typography and spacing tokens.

Cover success, loading, empty, validation-error and server-error states.
Use synthetic fixtures. Do not invent a working backend integration.
Check the rendered flow at 390 px and 1440 px, including keyboard navigation.
Compare screenshots with the approved reference and fix unintended differences.

Return changed files, interaction checks and screenshot locations.
List anything mocked or not verified. Do not call the flow production-ready
until the actual integration and acceptance checks have passed.

The viewport widths are example acceptance criteria, not an official Opus recommendation. Replace them with your product's real device coverage. If the agent cannot access a browser, ask it to say so and leave visual verification open rather than claim the interface was inspected.

How should you use Opus 5.5 for research and business documents?

Ask it to produce a source ledger before a polished recommendation. A useful ledger connects each consequential claim to a source, date and location. Have it mark contradictions and missing inputs before those gaps disappear into persuasive prose.

For example, a product team comparing two integration options needs the documented limits, switching costs and unresolved assumptions. It does not need an invented score that disguises missing evidence. Preserve a distinction between what the sources say and what the author recommends.

Prepare a two-page decision brief from the supplied integration documents.
Deliver the brief before optional slides or extra analysis.

Start with the decision, constraints and missing inputs.
Compare the options using only supported capabilities and explicit assumptions.
For every consequential factual claim, record source, date and page or section.
Show formulas and input values for calculated figures.
Label an unavailable value as unknown; do not estimate it silently.

End with the next reversible experiment and its acceptance criteria.
Do not contact vendors, send messages or publish the document.
Return the brief, source ledger and unresolved questions.

When using screenshots or dense charts, supply the relevant original data when available and ask which values were read versus calculated. For a branded deliverable, provide the actual template and prohibit replacement logos or invented brand facts. Review the finished file, not only the model's description of it.

How do you keep a long Opus 5.5 session on track?

Give it a deliverable sequence, not permission to keep improving forever. We recommend three checkpoints: investigation with an agreed scope, a minimal working result, then verification and handover. At each checkpoint, require an artifact another person can inspect.

Store stable repository conventions in the tool's supported project instructions. Claude Code documents CLAUDE.md and auto memory, but context management is not the same as an unlimited record of everything that happened. Check Claude Code's memory behavior.

Keep a short task record with the current commit, approved decisions, remaining work and verification results. Tell the next session to re-check the repository state before trusting it. Our coding-agent context guide covers the broader information problem; this article concerns how to apply the new model within that workflow.

Make parallel work genuinely separable. One worker might inspect API compatibility while another runs the existing test suite, with a coordinator reconciling the results. Avoid asking several workers to rewrite the same files without an ownership rule. More agents are not a substitute for a coherent task.

Put spending and permissions outside the prompt. Claude Code's cost documentation covers usage visibility and cost controls; availability depends on the execution surface. Review the relevant Claude Code controls.

Our recommended operational rule is stricter than “please stay under budget”: use a supervisor or supported product limit that can stop additional calls, keep production credentials unavailable, and require approval for external actions. A written time or money limit is a request, not a security boundary.

Opus 5.5 medium vs high: which effort setting should you use?

Start at medium, then test a higher setting against a specific failure. Opus 5.5 supports low, medium, high, xhigh and max; the documented default is medium. Effort labels are model-specific, so matching names across models does not match compute. Read Anthropic's effort reference.

Before raising effort, check whether the missing ingredient is actually a log, a schema, a test fixture or permission to inspect a file. More reasoning cannot supply a private fact the model never received. Change one variable at a time and retain the cheaper configuration when both pass the same checks.

How do you select Opus 5.5 in Claude Code?

Claude Code's current documentation requires v2.1.280 or later for Opus 5.5. Check your installed version, update through the supported installation path and select the explicit model. Provider aliases and organization restrictions can change what is available. See model selection and effort configuration.

claude --version
claude update
claude --model claude-opus-5-5 --effort medium

The example targets a supported direct Claude setup. Use your provider's deployment identifier where required, rather than copying the direct API identifier into every cloud integration. Check the session header and model picker before recording a comparison.

In an existing interactive session, use /model claude-opus-5-5 and /effort medium. An explicit model is especially useful during a pilot: your result should not silently depend on what an alias happens to resolve to. Record the client version and any fallback separately.

For a chat application or another editor, use that product's model selector and available controls. These terminal commands are for Claude Code; API parameters below are not settings you can necessarily paste into a chat interface.

What should API users change before adopting Opus 5.5?

Migration is not just a model-name replacement. Disabled or manually budgeted thinking and forced tool selection are rejected. Thinking-block history also needs preservation, and the earlier computer-use tool changes on the Claude API and Google Cloud. Follow the official migration checklist.

For a small direct API smoke test, save this as opus55-request.json. It supplies its own input instead of pretending the API can see local files. This is a documentation-based request example, not a live call performed for this article.

{
  "model": "claude-opus-5-5",
  "max_tokens": 4096,
  "thinking": { "type": "adaptive", "display": "summarized" },
  "output_config": { "effort": "medium" },
  "messages": [{
    "role": "user",
    "content": "Review this proposed change: retries create a new order before checking the existing request ID. Explain the risk and propose a local regression test. Do not claim to have inspected a repository."
  }]
}

With a configured API key and a funded account, the following request incurs API usage charges. Do not paste credentials into the JSON file or commit them.

curl --fail-with-body --silent --show-error \
  https://api.anthropic.com/v1/messages \
  -H "x-api-key: ${ANTHROPIC_API_KEY:?Set ANTHROPIC_API_KEY first}" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  --data-binary @opus55-request.json

A subtle troubleshooting case is an agent that appears silent between tool calls. Opus 5.5 returns that narration in thinking blocks, omitted by default; display: "summarized" requests readable summaries. This example is non-streaming. Summaries are not a full audit trail: retain tool calls, results and action logs too. Check the response-shape changes.

For machine-readable output, distinguish schema validity from task completion. Strict tool arguments constrain a call's shape; they do not guarantee that the model calls a tool or that its content is factually correct. Validate required actions in your application. Read the structured-output guarantees and limits.

How much does Opus 5.5 actually cost per task?

Standard direct API rates below are USD per million tokens, checked on 24 September 2026. These are token rates, not subscription prices or a promise about another provider's bill. Check the current Anthropic pricing table.

For an invented workload with 200,000 uncached input tokens, 100,000 five-minute cache-write tokens, one million cache-read tokens and 20,000 output tokens, the arithmetic is:

Opus 5.5: $0.80 + $0.50 + $0.20 + $0.40 = $1.90.

Opus 5: $1.00 + $0.625 + $0.50 + $0.50 = $2.625.

That is about 27.6% less for identical token buckets, not 40%. This is arithmetic, not a benchmark. It excludes tools, infrastructure, additional attempts, pricing modifiers and human review. Actual token usage may differ between models, in either direction.

Prompt caching reuses eligible matching prefixes; it is not permanent project memory. Keep stable instructions and reusable context ahead of changing task details, then inspect reported cache usage rather than assume every repeat is discounted. Read the cache matching and accounting rules.

Fast mode is a separate trade-off: the direct API preview lists $8 input and $40 output per million tokens, targeting output speed rather than a guaranteed reduction in total task duration. Test it only where waiting is the measured bottleneck. Check Fast mode's scope and pricing.

For adoption, use cost per accepted task: model and tool spend across all attempts, plus review and rework cost, divided by accepted tasks. Keep review time visible even when you do not convert it into money. A rejected task is still part of the spend.

When is Opus 5.5 the wrong tool?

Do not default to it for a deterministic transformation a script already handles correctly, a routine task your cheaper model passes reliably, or a workflow where the necessary information cannot be shared with the approved service. These are task-selection principles, not claims that the model lacks the capability.

Likewise, do not use a convincing answer as the only release gate for permissions, payments or destructive changes. Define the independent check first. If you cannot inspect the result, reduce the task's authority or keep it advisory.

Avoid asking for an entire product when the business decision is still unresolved. Have a person settle the user problem, scope and acceptance criteria. Then let the agent do the implementation work within those decisions. A model upgrade does not decide what customers need.

How do you evaluate Opus 5.5 on your own repository?

Run a small, controlled pilot before changing everyone's default. We suggest ten historical tasks that span refactors, reproduced bugs, interface changes and a source-based brief. Use completed tasks for which a reviewer can recognize a valid outcome, but do not include their solutions in the agent's inputs.

Give Opus 5.5 at medium and your existing configuration the same frozen starting state, tools, permissions and task brief. Repeat difficult cases because one run can be misleading. Escalate failed cases selectively to high; do not quietly mix settings into one result.

Choose the configuration that meets your acceptance bar at an appropriate total cost. Keep the old configuration available for regressions. The result may be Opus 5.5 for substantial engineering, a smaller model for routine work and human approval for consequential decisions.

Wavect's AI enablement work focuses on turning tool access into repeatable team workflows. The Twinsoft AI case study is separate implementation experience, not an Opus 5.5 benchmark or deployment claim. Use the pre-launch QA decision guide to define evidence, or discuss an agent-workflow pilot around your actual repository.

Sources, date and limits of this guide

Reviewed on 24 September 2026, two days after release. We checked Anthropic's documentation and the original evaluations linked above. This article is a source-based analysis with proposed prompts and evaluation criteria, not a hands-on Wavect benchmark. No live API request, production migration or latency experiment was performed for it.

Recheck model availability, prices and client requirements before rollout. Pin the configuration used in your pilot and repeat its acceptance tasks after a model or client change.