Claude Opus 5.5 for WordPress Plugin Work: What We Know

Short answer: Claude Opus 5.5 is the model we would put on writing, fixing and reviewing plugin code, at a lower list price than the Opus 4.7 many of us used in the spring. It costs $4 per million input tokens and $20 per million output tokens, against $5 and $25 for Opus 4.7, and Anthropic says that at its default medium effort it matches or beats the previous Opus at high effort on agentic coding tasks, in fewer steps. We have not run a controlled benchmark and will not pretend to. What follows is what the documentation actually says, how our team routes work between models, what changes if your plugin calls the API, and a method you can use to test it on your own tickets before you change anything.

If you read my posts from the Opus 4.7 days, this is the update. A lot of the money and the limit anxiety in an agency is not in which model is smartest. It is in which model does which job, how hard you let it think, and what you do when a long run stops early. Those are the parts we can speak to honestly.

What is Claude Opus 5.5, in plain facts?

Everything in this section comes from Anthropic’s own documentation, and we link it so you can check it yourself.

• Name and ID. Claude Opus 5.5, model ID claude-opus-5-5 on the Claude API.
• Released on September 22, 2026. Anthropic lists retirement as not sooner than September 22, 2027.
• Purpose. Anthropic describes it as built for long-running agentic coding and knowledge work.
• Size. A 1M token context window and up to 128K tokens of output in a single response.
• Price. $4 per million input tokens and $20 per million output tokens. Cache reads cost $0.20 per million tokens, and the Batch API takes 50 percent off.
• Thinking. Adaptive thinking is always on and cannot be turned off. You steer it with the effort setting, which defaults to medium.
• Knowledge cutoff. June 2026.

The same documentation lists the rest of the current lineup, and it is worth knowing because routing is the whole game. Claude Sonnet 5.5 is $2 and $10 and is described as the best combination of speed and intelligence. Claude Haiku 5.5 starts at $0.10 and $0.50 and is meant for high-volume, latency-sensitive jobs. Claude Fable 5.1 is $10 and $50, for demanding reasoning and long-horizon agentic work, or when your own tests on Opus 5.5 at higher effort still fall short. Anthropic’s own advice for most workloads is to start with Opus 5.5. You can read the model page at platform.claude.com.

How does Opus 5.5 compare with Opus 4.7 on paper?

Item	Opus 4.7	Opus 5.5
Input price per million tokens	$5	$4
Output price per million tokens	$25	$20
Cache read per million tokens	$0.50	$0.20
Batch API discount	50 percent	50 percent
Context window and max output	See the Opus 4.7 model page	1M tokens and 128K tokens
Thinking	See the Opus 4.7 model page	Always on, controlled by effort, default medium

The list-price drop is 20 percent on input and output, and cache reads are cheaper still. One more detail from the docs that matters for budgeting: the tokenizer Opus 5.5 uses was introduced with Opus 4.7, so token counts for the same text are comparable between the two. Models before 4.7 fit about 750,000 words in a million tokens, while the current tokenizer fits roughly 555,000.

We left the Opus 4.7 capability rows pointing at its own model page rather than guess. The documentation compares Opus 5.5 with Opus 5, and we will not invent a comparison where it does not give one.

What did Anthropic say actually improved?

Anthropic’s prompting guide for the model lists what it calls the capabilities that matter most. Read these as the vendor’s claims from its own testing, not as our measurements.

• Agentic coding and code review. The model is strongest on multistep work in a real repository, such as carrying a change through a large code base until its tests pass. Anthropic says that at default medium effort it matched or beat Opus 5 at high effort on such tasks, in fewer steps and with fewer tokens. It also reports that early testers saw stronger code review, with more bugs caught and fewer false alarms, and that the model explains its changes in plain language.
• Long runs with little oversight. Anthropic says it sustains long-running autonomous work better than Opus 5, such as multihour audits and migrations of large code bases with parallel subagents.
• Knowledge work. Anthropic says it is much less likely to state an incorrect figure or cite the wrong source, and that documents and spreadsheets need less editing before sharing.
• Reading charts and screenshots. Anthropic says it reads dense charts and layout-dependent visuals more accurately without extra tooling. For a plugin team, that is relevant to screenshot-based QA.

Notice the reference point in those claims. Anthropic compares Opus 5.5 with Opus 5, not with Opus 4.7. So any statement that it is a fixed amount better than 4.7 would be our invention. What we can say is that Opus 5 priced at $5 and $25 sat where 4.7 did, and Opus 5.5 now sits below both.

Which model does which job on our team?

This part is ours, and it is the part you can copy. Our team splits models by the kind of work, and the rule is written down so nobody argues about it mid-ticket.

• Opus for code. Writing code, fixing it and reviewing it. That includes plugin features, REST endpoints, tests, security and performance reviews, and the work of turning a bug report into a patch.
• Sonnet for everything else. Investigating and reproducing a bug, releases, support drafts, content, documentation, site operations and research.
• Find the cause on Sonnet, then write the fix on Opus. The investigation produces a short brief: the evidence, the root cause with the file and line and how it was established, the reach (every place the bad data is read or written), and what is not yet verified. The coding step checks only the load-bearing claims in that brief, then plans.
• Escalate on purpose. If a root cause survives one fix attempt, or the work is a cross-plugin architecture decision or a security review of a money or authentication path, we flag it in one line and recommend the bigger model. A person decides.

Why split like this? Because the expensive mistakes in plugin work are rarely typing mistakes. They are fixes that land on the one path the ticket named while three sibling callers stay broken. A cheaper model that investigates carefully, plus a stronger model that fixes at the shared point, costs less than a strong model doing both and still missing the reach. The split also keeps the pricey model off jobs like drafting a release note where it adds nothing.

What does that mean for Opus 5.5 specifically?

Opus 5.5 does not change the rule. It changes the price of following it. If it really does reach a passing test in fewer steps at medium effort, as Anthropic reports, the code step gets cheaper twice: a lower rate and fewer turns. We will believe that when we have measured it on our own tickets, which is why the next section matters more than any claim here.

How can you test it on your own plugin tickets?

You do not need a lab. You need ten tickets and a notebook. This is the method we would follow, and we would suggest it to any agency before moving a whole team to a new model.

1. Pick ten closed tickets you already know the right answer for: three bug fixes, two small features, two REST or database changes, two review tasks and one documentation task.
2. Freeze the starting point. Check out the repository at the commit before each fix. Give each run the same ticket text and the same project guidance file.
3. Run each ticket on each candidate at an explicit effort level. Do not rely on the default, because the default differs between models. Anthropic’s own advice is to set effort explicitly and test several levels against your own evaluations.
4. Score the same things every time: did the tests pass, did the fix reach every caller, did the diff stay small, how many turns, how many output tokens, and how long did a person take to review it.
5. Add a negative case. For each bug, write the test that fails on the old code. A model that passes your tests but would also pass the old code has proved nothing.
6. Decide by cost per accepted change, not cost per run. A cheap run that a person has to redo is the most expensive run you can buy.

Our habit with git, hooks and release rules is covered in Claude Code and Git across 100+ repos, and the same discipline applies here: the test harness is what makes any model’s work trustworthy.

What does a typical session cost, in list-price arithmetic?

This is arithmetic from published prices, not a measurement. It ignores caching, batching and the thinking tokens a model spends, which count as output. Treat it as a way to see the shape of the numbers.

Suppose a long coding session reads 200,000 tokens of input and writes 20,000 tokens of output.

Model	Input cost	Output cost	Total
Opus 4.7 ($5 / $25)	$1.00	$0.50	$1.50
Opus 5.5 ($4 / $20)	$0.80	$0.40	$1.20
Sonnet 5.5 ($2 / $10)	$0.40	$0.20	$0.60
Fable 5.1 ($10 / $50)	$2.00	$1.00	$3.00

Two points. First, the gap between Opus 4.7 and Opus 5.5 is real but modest on a single session, a matter of cents. It adds up over a month of agency work, and caching changes it a lot: cache reads on Opus 5.5 are $0.20 per million tokens, so a project guidance file that is read on every turn costs little once cached. Second, Anthropic notes that at a given effort level Opus 5.5 tends to think more per turn than Opus 5, especially at the two highest levels. More thinking means more output tokens, so a setting carried over from an older model can quietly raise your bill. That is why the docs say to reserve the top levels for work where you have measured a quality gain, and to lower effort first when you want less thinking.

If you want a wider view of what an AI line item does to an agency, our posts on LLM cost guardrails and the economics of an AI-first agency cover the business side.

What breaks if your plugin calls the Claude API?

Most people reading this use Claude as a coding assistant. If you ship a plugin that calls the API, or run an internal tool that does, there are changes to handle when you move to this model. These come straight from Anthropic’s migration notes for moving from Opus 5.

Thinking can no longer be switched off

• Symptom: requests that set thinking to disabled, or set a manual thinking budget, return a 400 error.
• Quick check: search your code for the thinking field in every request builder.
• Fix: remove the field, or set it to adaptive, and choose an effort level instead. For fast, simple calls, start at low effort and measure.
• Prevention: keep model settings in one place rather than scattered across call sites.

Forced tool use returns an error

• Symptom: a request that forces a specific tool, or forces any tool, fails with a 400 error.
• Quick check: search for the tool choice setting.
• Fix: use automatic tool choice, and for schema-valid output use strict tool use or structured outputs.
• Prevention: validate model output on your side no matter what the schema promises.

An interface that streams progress text goes quiet

• Symptom: a chat panel stops showing the short notes the model wrote between tool calls.
• Quick check: look at the block types in the response; those notes now arrive as progress-update thinking blocks.
• Fix: set the thinking display option so progress updates are returned, as the migration guide describes.
• Prevention: read responses by block type rather than assuming the first block is text.

Output gets cut off

• Symptom: long replies end abruptly.
• Quick check: compare your maximum output setting with the model’s limit.
• Fix: thinking counts toward the limit, so leave room for it. Anthropic reports that a limit of 128,000 tokens, the maximum, has worked well for long agentic turns.
• Prevention: log the stop reason on every call.

One related WordPress point. WordPress 7.0 added a core AI client, and our own standard is to prefer it where available and keep a provider adapter as the fallback for older installs. Whatever you call, a model change belongs in one adapter, not in twenty call sites.

How do long, unattended runs behave?

This one affects anyone who lets an agent work for hours on a migration or an audit. Anthropic’s guide says Opus 5.5 keeps the user updated on long, multipart tasks, and that some of those updates end the turn with text instead of a tool call. A loop that treats any text-only turn as “finished” will stop early.

The guide’s advice is practical, and we have adopted its spirit:

• Treat a text-only end of turn as a report, not as proof the task is done.
• Keep the task’s parts in a checklist the model updates, such as a to-do file.
• If a turn ends with items still open and no stated blocker, send a short message naming them.
• Stop after two or three automatic continuations on the same task, so a run that is genuinely stuck ends and can be reviewed.
• If a background command or subagent is still running, the task is not done yet.

This is as much about people as about code. A checklist file lives in the repository, shows in a diff and survives a context reset, which is also why we keep our project guidance files short. Our post on keeping Claude Code skills small explains why long instructions hurt after compaction.

Where is it better, and where is it not?

We said we would be honest, so here is the boundary of what we know.

Where the evidence points to better

• Price. Lower list price than Opus 4.7 and Opus 5. That is a fact.
• Effort per result. Anthropic reports medium effort matching or beating Opus 5 at high on coding and knowledge work. That is the vendor’s claim, from the vendor’s tests.
• Reading screenshots. Anthropic reports sharper chart and screenshot reading. We would test that on real admin-screen screenshots before trusting it for QA sign-off.

Where we have no data

• Our own speed and quality numbers. We have not published any, because we have not run the controlled test above across a full set of tickets.
• Comparison with Sonnet on your tasks. Sonnet 5.5 costs half as much per token. If your tickets are mostly small, it may be the right default for more of them than you expect. The only way to know is to score them.
• Usage-limit behaviour. Limits differ by plan and change. Read your own plan’s page, not a blog post.

That last point is the usage-limit planning part. Plan in terms of what you control: set effort explicitly, keep prompts and guidance files short and cacheable, send bulk work through the Batch API at half price when it does not need an immediate answer, and give small jobs to the smaller model.

What should an agency change this week?

1. Write your routing rule down. Opus for code, a smaller model for investigation, releases, content and research, with an explicit escalation line.
2. Set effort on purpose. Do not inherit a default. Start at medium for code and test low for small jobs.
3. Run the ten-ticket test before moving everyone.
4. Audit your API call sites for the thinking and tool-choice settings, if you ship anything that calls Claude.
5. Treat text-only turns as reports, and keep a checklist file for long runs.

What should a non-technical agency owner take from all this?

If you run the business and do not write the code, three things matter. First, the price per unit of work went down, which is good news, but the bill depends far more on how the team uses the model than on the rate card. Second, ask your lead developer to show you the routing rule and the effort settings; if neither exists in writing, spend is drifting. Third, ask what the team measured. A claim such as “it feels faster” is a feeling. A sheet that says how many of ten tickets passed, at what cost and how long review took is a decision you can defend to a client.

Frequently asked questions

Is Claude Opus 5.5 better than Opus 4.7 for WordPress plugin work?

It is cheaper on list price, and Anthropic reports strong results on agentic coding and code review. We have not measured a fixed improvement over 4.7, so test it on your own tickets with the method above.

What is the model ID for Claude Opus 5.5?

On the Claude API it is claude-opus-5-5. Other platforms use their own ID format, listed on the model page.

How much does Opus 5.5 cost?

$4 per million input tokens and $20 per million output tokens, with cache reads at $0.20 per million and half price on the Batch API.

Can I turn thinking off?

No. Adaptive thinking is always on. Lower the effort level to get shorter thinking, and check the docs for the setting names.

Should I use Opus or Sonnet for debugging?

On our team, Sonnet investigates and reproduces, and Opus writes the fix once the root cause is documented. Escalate to the larger model if a root cause survives one fix attempt.

Does it make documentation and release notes better?

Anthropic reports that its documents need less editing. We still assign documentation and releases to the smaller model on cost grounds, and we review the output ourselves.

Why did my agent stop before the task was finished?

A text-only turn ends the turn. Treat it as a report, check your task list, and send a short message naming the open items, as described above.

A closing thought

A new model name always brings the temptation to rewire everything in a week. The better habit, and the cheaper one, is dull: write the routing rule, set effort deliberately, test ten real tickets, and move the work that scores well. Everything else is a headline.