Claude Opus 5 Alternatives: Pin 4.6 or Fix Your Prompt

TL;DR

Most Opus 5 complaints trace to documented, prompt-tunable behavior changes rather than a capability regression. Claude Opus 4.5 through 4.8 all remain Active at the same $5/$25 with published retirement floors, so pinning an older version is a one-string experiment. Our token measurements below show what it actually costs: 23% cheaper on input text, more expensive on tool-heavy calls.

The complaint:        r/claude "Opus 5 is so awful", 522 upvotes, 0.83 upvote ratio, 507 comments (read 2026-08-12)
Most-cited symptom:   says a fix is done when it is not
Most likely cause:    thinking disabled, so the tool call is emitted as plain text and never runs
Pin an older Opus:    4.5 / 4.6 / 4.7 / 4.8 all Active, same $5/$25, one-string change
Earliest retirement:  Opus 4.5, "not sooner than 2026-11-24"; 4.6 is 2027-02-05
Notice guaranteed:    at least 60 days before retirement
Cheaper text on 4.6:  1,185 vs 1,541 tokens for identical input (measured 2026-08-12, 1.30x)
Cheaper tools on 5:   286 vs 497 token tool-use system prompt
Do not bother with:   lowering effort to shorten answers (it does not)
Delete from prompts:  "double-check your work" and any verification step

A post titled “Opus 5 is so awful” has been sitting near the top of r/claude since August 9. It is worth reading, and it is worth reading carefully, because most of the complaints in it describe behavior that Anthropic documents in its own prompting guide and treats as tunable.

That does not make the complaints wrong. It makes them fixable, which is more useful. This post maps the loudest symptoms onto documented causes, gives you the model IDs to pin if you would rather not tune anything, and shows what pinning actually costs.

What Are People Actually Reporting About Opus 5?

Five symptom clusters, and none of them is “it scores lower on benchmarks.” Here is what the thread contains as of August 12, 2026.

Three caveats before you treat any of this as data.

The thread’s upvote ratio is 0.83, meaning roughly one in six voters disagreed. That is a real split, not a consensus. Reddit threads also select hard for people having a bad time; nobody posts “my agent loop is fine today.”

The original poster is on a subscription plan, not the API. That matters more than it looks: on the API you can set effort, toggle thinking, and pin a model ID. In a chat product you mostly cannot. Several fixes below only exist if you are calling the API directly or through a gateway.

Finally, this thread contains a widely-repeated theory attributing the change to specific named individuals moving between companies. We are not repeating it. It is unverifiable and it is an accusation about real people.

Is It the Model, or Is It Your Prompt?

Start here, because the answer is “partly your prompt” more often than the thread suggests. Anthropic publishes a prompting guide specifically for Opus 5, and it opens by noting the model “performs well out of the box on existing Claude Opus 4.8 prompts” before listing the behaviors that “most often require tuning.”

Those listed behaviors line up with the thread almost item for item:

• Longer default responses. “Claude Opus 5’s default user-facing responses run longer than prior Opus models’.”
• More narration. “Claude Opus 5 narrates readily during agentic work: it tends to announce what it is about to do.”
• Narrated self-correction. “The model also narrates corrections to its earlier statements more than prior models do, which can be undesirable in user-facing products.”
• Task scope expansion. “Claude Opus 5 can also expand the scope of a task, adding steps that weren’t requested.”
• More subagents. “Claude Opus 5 delegates to subagents more readily than prior models.”

Read that list next to the complaints and the overlap is hard to miss. The top comment in the thread is a near-verbatim description of the self-correction bullet. The “huge side quest for nothing” comment (12 points) is scope expansion. The “used other agents to complete a plan I had rejected” comment (29 points) is subagent delegation.

This was legible on launch day, not only in hindsight. Reading Anthropic’s own release post, Simon Willison wrote that “based on this anecdote in the release post it sounds like it might be relentlessly proactive,” pointing at a Frontier-Bench task where Opus 5 went well past the literal request. Three weeks later the same trait reads, from inside a working session, as a side quest nobody asked for. The behavior is not in dispute. Whether you want it on by default is.

One instruction is actively counterproductive and worth removing today:

If your prompt contains explicit verification instructions (“include a final verification step for any non-trivial task,” “use a subagent to verify”), remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality.

That inverts standard prompting advice. If you maintain a shared prompt library with a blanket “ask the model to self-check” rule, Opus 5 needs a carve-out, not a copy.

Which Symptom Maps to Which Fix?

This table is the working part of this post. Each row pairs a symptom from the thread with the documented cause and the smallest change that addresses it. Nothing here requires leaving Anthropic.

Anthropic’s own wording for the scope constraint, which is the one most worth copying verbatim:

Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked.

Why Does It Say It’s Done When It Isn’t?

Because with thinking disabled, the tool call can be written as prose instead of being executed. This is the single most useful thing in Anthropic’s Opus 5 documentation, and it explains the loudest complaint in the thread better than any theory about model quality.

The exact wording:

With thinking disabled, the model occasionally writes a tool call into its user-facing text instead of emitting a structured tool_use block. The turn completes normally and the call never runs, and in agentic loops the leaked text stays in the conversation history, so later turns are affected as well. This is most common on tool-heavy workloads such as search.

Sit with the failure shape for a second. There is no error. There is no exception. Your harness sees a successful turn, the model says it edited the file, and the file was never touched. Then the fabricated call sits in history and skews everything after it. From the outside, that is indistinguishable from a model that lies about its work.

Two things make this newly relevant on Opus 5:

1. Thinking is on by default on Opus 5, where on Opus 4.8 omitting the field meant no thinking. So this only bites code that explicitly opts out, often a setting carried forward from 4.8 where it was the default behavior.
2. Disabling thinking is now capped at high effort. Pairing thinking: {"type": "disabled"} with xhigh or max returns a 400. The migration guide covers both changes, and our Opus 5 API guide walks the full config diff.

The recommended fix is not a prompt at all. It is to stop disabling thinking:

for most tasks, thinking enabled at low effort performs better than thinking disabled at similar cost.

If you have an integration that must keep thinking off, Anthropic gives one combined instruction that mitigates both artifacts:

When you use a tool, you may say a brief sentence first. If no tool can express
what the user asked for, say so instead of guessing. Do not include internal or
system XML tags in your response.

Note the first clause. The failure appears to come from suppressing the preamble the model wants to write, so giving it explicit permission to speak before calling a tool is part of the fix. Also delete any rule telling the model not to think or not to reason; the prompting guide notes that such rules increase tag leakage rather than reduce it.

Why Does It Argue That Your Bug Isn’t Real?

Partly because of an instruction you probably wrote yourself. Three separate people in the thread describe the same fight: they report a bug, the model insists it is not there, and the argument costs more time than the fix would have.

Anthropic documents an adjacent behavior in the code-review section of the Opus 5 prompting guide:

If your review prompt says “only report high-severity issues” or “be conservative,” the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead.

Be precise about what that does and does not explain. What it covers is under-reporting, where the model investigates properly, decides a finding sits below the bar you set, and stays quiet. It does not directly explain an argument, where the model actively pushes back on a bug you can reproduce. Those are different failure shapes and it would be sloppy to claim the doc covers both.

What connects them is literal instruction-following. Severity language in your prompt sets a reporting bar, and Opus 5 applies that bar more strictly than earlier models did. Once the model has classified your bug as below-bar, asking again reads as a request to justify the classification rather than to re-investigate. You get a defense instead of a second look.

Two things to change, in order:

1. Split finding from filtering. Ask for every candidate issue with a confidence score and a severity estimate attached, then rank in a second pass. Precision does not suffer, and you stop optimizing for a bar the model is enforcing on your behalf.
2. Re-open the investigation explicitly. When you disagree, do not repeat the claim. Give it the reproduction and ask it to run the code, which moves the turn from judgment back to evidence.

One counterintuitive note if you are tempted to add “be more careful, actually verify this time” to your prompt: do not. That is a verification instruction, and per the section above it compounds with behavior the model already has. It buys you a longer answer, not a better one.

Can You Still Pin Claude Opus 4.6 or 4.8?

Yes, and Anthropic publishes a floor date for each one. The “if they ever remove opus 4.6 im out” comment is the most actionable anxiety in the thread, and the model deprecations page answers it directly.

Every Opus version from 4.5 up carries the same list price, so pinning an older one is a behavior decision rather than a budget decision. Anthropic’s stated policy is “at least 60 days’ notice before model retirement for publicly released models,” and it has published commitments on preserving model weights after retirement.

Retirement is not theoretical, though. Claude Opus 4.1 was deprecated on June 5, 2026 and retired on August 5, 2026, one week before this post. It was announced two months ahead, exactly as the policy describes. So the honest read is: 4.6 is safe for a good while, you will get warning, and you should still not build something that cannot survive a model ID change.

Two footnotes if you pin:

• Fast mode is Opus 5 and 4.8 only. On Opus 4.7 a speed: "fast" request returns an error. On Opus 4.6 it runs at standard speed and bills at standard rates, which is the worse failure because it is silent.
• Effort levels differ. xhigh exists on Opus 5, 4.8, and 4.7 but not on 4.6, which tops out at max without the intermediate rung.

Why 4.6 and Not 4.8?

Because 4.6 is the last Opus on the old tokenizer, and that is the only version boundary that changes your bill. The thread picks 4.6 on feel, and the version-specific comments quoted above name 4.6 rather than 4.8. The harder reason sits in the next section. Anthropic switched tokenizers at 4.7, so 4.8 counts your input exactly the way Opus 5 does, and pinning it buys the older behavior at the newer token count.

Pick by what you are trying to undo:

• Behavior and token cost: 4.6. Newest Opus on the previous tokenizer, and 23% cheaper on input text. You give up xhigh and fast mode, and its floor date is almost four months earlier than 4.8’s.
• Behavior only: 4.8. The closest rollback, one version back instead of two, so less of your tuning goes stale. Keeps fast mode and xhigh, floor date runs to 2027-05-28, and its tool-use system prompt is 290 tokens against 497 on 4.6, which matters more than the tokenizer once your traffic is tool-heavy.

Does Pinning 4.6 Actually Cost Less?

On input tokens for the same text, yes, by about 23%. We measured it. This is the part nobody mentions in the thread, and it cuts against the assumption that identical list prices mean identical bills.

Anthropic notes on its pricing page that “Claude 4.7 and later models use a newer tokenizer… This tokenizer produces approximately 30% more tokens for the same text. Claude Sonnet 4.6 and earlier models use the previous tokenizer.”

We sent one identical 4,365-character payload (technical prose plus a Python code block, the shape of a real code-review request) to five models through ofox and read prompt_tokens off the response. Same payload, same request, same day.

Measured 2026-08-12 on api.ofox.ai. A single payload is one data point, not a benchmark, and Anthropic is explicit that “the exact increase depends on the content and workload shape.” Our 1.30x landed inside the ~30% Anthropic quotes, which is the most you should conclude from one sample.

At $5 per million input tokens, the same document costs $0.0077 on Opus 5 and $0.0059 on Opus 4.6. Trivial per request, not trivial across a million agent turns.

Now the counterweight, because this does not run one way. Anthropic publishes per-model tool-use system prompt overhead, and Opus 5 is the leaner model there:

• Opus 5: 286 tokens (auto/none tool choice)
• Opus 4.8: 290 tokens
• Opus 4.6: 497 tokens
• Opus 4.7: 675 tokens

So a tool-heavy request pays 211 extra tokens per call on 4.6 that Opus 5 does not. On short requests with big tool schemas, pinning 4.6 can cost you more, not less. Note where 4.8 lands: at 290 tokens it is within 4 tokens of Opus 5 and 207 below 4.6, so if your traffic is tool-heavy, 4.8 is the version that gives you the older behavior without the tool-overhead penalty. Work out which side of that line your traffic sits on before you treat pinning as a cost optimization. If prompt caching is in play, note that Opus 5 also drops the minimum cacheable prefix to 512 tokens against 4,096 on Opus 4.6, which our prompt caching cost math post covers in more detail.

What If You Want to Leave Anthropic?

Then the cheapest useful move is down the Anthropic ladder before out of it. Ranked by how much has to change on your side.

• Claude Sonnet 5, anthropic/claude-sonnet-5, $2/$10. 60% cheaper than Opus on both input and output, 1M context, and the $2/$10 rate is now permanent after Anthropic cancelled the September 1 increase to $3/$15. Same prompting family, so your tuning mostly transfers. Our Sonnet 5 vs Opus 4.8 comparison has the head-to-head.
• Claude Haiku 4.5, anthropic/claude-haiku-4.5, $1/$5. For subagents and mechanical passes. 200K context, not 1M.
• GPT-5.6 Sol, openai/gpt-5.6-sol, $5/$30. The switch most named in the thread. It leads on output throughput and loses on time-to-first-token; the numbers are in our Opus 5 vs GPT-5.6 Sol post, which is a benchmark comparison rather than a routing one.
• Kimi K3, moonshotai/kimi-k3, $3/$15. 1M context in and 1M out, which is unusual. See Kimi K3 vs GPT-5.5 vs Opus 4.8.

One thing to be clear about: none of these is a drop-in for the symptoms above. Switching vendors to fix verbosity means inheriting a different vendor’s verbosity defaults and rewriting your prompts anyway. Pinning an older Opus is the only option on this page that changes one string and nothing else.

If your complaint is about the coding tool rather than the model, the model may not be the variable at all. Our coding agent harness roundup covers which harnesses let you change the model underneath in the first place.

How Do You Run Two Model Versions Without Two Accounts?

Every fix above needs an A/B, and an A/B across model versions normally means two billing lines and two sets of credentials. That is the awkward part of “just pin 4.6 and see.” You want yesterday’s model and today’s model answering the same prompt, side by side, with token counts you can compare, and the vendor console is not built to make that easy.

Because Opus 4.5 through 5 all speak the same OpenAI-compatible HTTP shape, the difference between them is one string in the request body. Point one client at one base URL, loop over the model IDs, and read usage off each response. That works the same way whether you are comparing two Anthropic versions or an Anthropic model against a Moonshot one.

Python: same prompt, four model versions

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.io/v1", api_key="YOUR_OFOX_KEY")

PROMPT = "Find the race condition in this handler and fix it. Do not refactor anything else."

for model in [
    "anthropic/claude-opus-5",
    "anthropic/claude-opus-4.8",
    "anthropic/claude-opus-4.6",
    "anthropic/claude-sonnet-5",
]:
    r = client.chat.completions.create(
        model=model,
        max_tokens=2048,
        messages=[{"role": "user", "content": PROMPT}],
    )
    u = r.usage
    print(f"{model:32} in={u.prompt_tokens:>6} out={u.completion_tokens:>6}")

Node: same shape

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.ofox.io/v1",
  apiKey: process.env.OFOX_API_KEY,
});

const PROMPT =
  "Find the race condition in this handler and fix it. Do not refactor anything else.";

for (const model of [
  "anthropic/claude-opus-5",
  "anthropic/claude-opus-4.8",
  "anthropic/claude-opus-4.6",
  "anthropic/claude-sonnet-5",
]) {
  const r = await client.chat.completions.create({
    model,
    max_tokens: 2048,
    messages: [{ role: "user", content: PROMPT }],
  });
  console.log(
    `${model.padEnd(32)} in=${r.usage.prompt_tokens} out=${r.usage.completion_tokens}`,
  );
}

That loop is exactly how the token table above was produced. Run it on your own prompts before you conclude anything from ours, and keep the usage numbers rather than just the answers; on this particular comparison the token counts are half the story.

For effort and explicit thinking control, use the Anthropic-native endpoint at https://api.ofox.io/anthropic with the bare claude-opus-5 ID, since those parameters have no OpenAI-compatible equivalent.

Which Should You Actually Pick?

Try the prompt changes first, pin second, switch vendors last. In ascending order of how much they cost you:

1. Delete your verification instructions. Free, takes a minute, and Anthropic says it reduces wasted tokens with no quality loss. Do this even if you are happy with Opus 5.
2. Turn thinking back on if you had disabled it, and pull effort down to low or medium instead. This is the fix for the “says it’s done and it isn’t” complaint.
3. Add the conciseness and scope instructions. Two paragraphs of system prompt against a documented behavior change.
4. Pin Opus 4.6 or 4.8 if you have done all three and still prefer the older behavior. Same list price, published retirement floor at least a year out, one string to change back when you want to retry. Take 4.6 if you want the old tokenizer too, 4.8 if you need fast mode and xhigh.
5. Move to Sonnet 5 if the actual complaint is cost. It is 60% cheaper than Opus on both directions and it is the same prompting family.
6. Change vendors only if the workload genuinely fits another model better, not because a thread was angry. You will be rewriting prompts either way.

The r/claude thread is a real signal about a real behavior change. It is just not a signal that the model got dumber, and one in six voters in that thread already disagreed with the headline.

References

• Prompting Claude Opus 5
• Claude model migration guide
• Model deprecations
• Pricing
• Effort
• Extended thinking
• Prompt caching
• Commitments on model deprecation and preservation
• r/claude: “Opus 5 is so awful” (read 2026-08-12)
• Simon Willison, “Introducing Claude Opus 5”
• ofox model catalog