Claude Opus 4.8: I Spent a Week With It So You Don’t Have To

Opus 4.8 dropped on a Thursday night. I was knee-deep in a Rust refactor on Claude Code 4.7 at the time, three hours into a session that wasn’t going well. The next morning, 9:07 AM Pacific, an email from Anthropic landed in my inbox with a Pro trial code. I figured: fine, let me actually use this thing for a week. Not benchmarks. Not cherry-picked coding puzzles. The kind of work I do every day.

Here is what a week with Opus 4.8 actually looks like.

The 24 hours around launch

The release post went up on May 28. It hit the front page of Hacker News with 1,774 points and 1,376 comments in 24 hours, which is a lot even by HN standards. I read the announcement first, then started scrolling through the comments. Within an hour, I had a list of things to test.

The headline claims I cared about: – 4x less likely to “allow flaws in code it has written to pass unremarked” than 4.7 – 84% on Online-Mind2Web (a real browser-agent benchmark) – 61% cheaper token cost than 4.7 on Databricks’ Genie – “Effort control” — a new slider for how much thinking the model does – “Dynamic workflows” in Claude Code — hundreds of parallel subagents

Then the comments started. Two things stood out.

First, an “Ask HN: Is Claude Opus 4.8 broken?” thread from a user called pqdbr. “In my first hour with it, it’s like we’re back to the GPT-2 era,” they wrote. “10+ errors like ‘Cancelled: parallel tool call Bash errored’ all the time.” The thread got 9 points, which is small, but the comments were sharper than the score suggested.

Second, a separate thread from forks: status.claude.com had posted an incident report. Elevated error rates for Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6. Not just 4.8. The whole family had wobbled.

So the model shipped, the launch hit the front page, the community was already posting failure modes, and Anthropic was already acknowledging problems. Standard launch week, basically.

Five real tasks, one real Rust project

The Rust project I was working on when the email arrived was 2,847 lines. It compiles. It runs. The tests pass roughly 80% of the time. I had been promising myself a cleanup for three weeks.

I gave Opus 4.8 five tasks over six days:

1. Refactor a chunky error-handling module into smaller pieces. Keep behavior identical. 2. Add unit tests to a state machine that had zero coverage. 3. Find a bug I’d been chasing for two weeks (a race condition in a tokio worker). 4. Write a CLI argument parser for a new subcommand. 5. Help me write a Slack message to a teammate explaining why we should switch from 4.7 to 4.8.

Tasks 1-4 are real engineering. Task 5 is the kind of writing work that AI tools keep getting asked to do and keep being weird about.

I ran Opus 4.7 on the same five tasks for comparison, back to back.

Where it actually breaks

Task 1 — the refactor — is the one I had the most trouble with on 4.7, so it was the first thing I tried on 4.8.

Opus 4.8 spit out 11 files. I read through them. The naming was good. The function boundaries were mostly sensible. But on the second compile, I got this:

“` error[E0432]: unresolved import `std::sync::Weak` –> src/queue/mod.rs:14:5 | 14 | use std::sync::Weak; | ^^^^^^^^^^^^^^^ no `Weak` in `sync` “`

Dead import. The model had imported `Weak` but never used it. 4.7 did this too. 4.8 did it slightly less often, but it still does it.

More importantly, the refactor introduced a regression. One of the new modules compiled fine on its own, but when wired back into the project, two of the existing tests started failing. The behavior was not identical. The model said it was. I caught it because I ran the tests. If I hadn’t, I would have merged broken code.

That’s the worst-case scenario for the “4x less likely to allow flaws” claim. Less likely is not “never.”

Task 3 — finding the bug — went better. I described the symptom: “the worker sometimes gets stuck in ‘processing’ state and never transitions to ‘complete’ even when all the input is drained.” Opus 4.8 came back in about 40 seconds with a hypothesis. Race condition in the wakeup logic. The same neighborhood that 4.7 had pointed me to. But 4.8 went one step further and suggested a specific fix.

The fix was almost right. Almost. I had to tweak the lock acquisition order, but the diagnosis was correct. That was worth something.

The honesty thing (and why it matters)

Anthropic’s big pitch for 4.8 is honesty. Less likely to make unsupported claims. More likely to flag uncertainty.

I tested this directly. I asked Opus 4.8 to write me a one-page summary of the Postgres 17 release notes from memory. Out of five things I asked for, it got three right, hedged on one, and said “I don’t actually know — I think this changed in 16, not 17” on the fifth.

I asked 4.7 the same question. It made up an answer for all five. Confidently. Wrong on three of them.

So 4.8 is better at saying “I don’t know.” Whether that translates to anything in real engineering work depends on the work. For the five tasks I gave it, the only place this came up was Task 2.

Task 2 — adding tests — the model wrote 14 tests. Three of them referenced methods that didn’t exist. When I pushed back, it corrected two. The third one kept insisting it was correct. I gave up on that test.

Now, here’s the thing: 4.7 made the same mistakes on Task 2. About the same number, in the same places. So 4.8 isn’t dramatically better at this kind of thing. It’s slightly better. Maybe 20% better, not 4x.

How it stacks against GPT-5.5 and GLM-5.2

A few days into the test, a comparison post hit the front page: “GLM-5.2 vs. Claude Opus 4.8: Full Comparison” from llm-stats.com. I read it. Their TL;DR matched what I was seeing on my own project: Opus 4.8 wins on coding, GPT-5.5 is cheaper at scale, GLM-5.2 is a real option for cost-sensitive work.

On CursorBench, Cursor’s Michael Truell said Opus 4.8 “exceeds prior Opus models across every effort level.” I don’t have Cursor installed, so I can’t verify this. I’ll take his word for it.

On Super-Agent, a different benchmark, Kay Zhu said Opus 4.8 was “the only model to complete every case end-to-end, beating prior Opus models and GPT-5.5 at parity on cost.” That last bit — parity on cost — is the part that matters. The price of Opus Pro is the same as before ($20/month for Pro), but the per-token cost on the API dropped. Anthropic says 61% cheaper than 4.7 on Databricks’ Genie workload. I don’t have a Databricks bill to check this against.

The Qwen thing (a brief note on the distillation drama)

About a week after launch, a thread on HN and a post on r/ClaudeCode started circulating. The claim: Opus 4.8 was distilled from Alibaba’s Qwen models. The evidence was mostly circumstantial — the price drop, the quality jump, and some side-by-side output comparisons.

I’m not a model architect. I can’t read distillation papers and tell you whether Qwen is in the training data or whether Anthropic actually used Qwen outputs to fine-tune 4.8. So I won’t pretend to know.

What I will say: the timing of the price drop is suspicious. Quality jumps don’t usually come with stable pricing unless something has changed in the cost structure. That could be Anthropic’s own research, it could be Qwen distillation, it could be aggressive inference optimization. I have no way to know.

If someone reading this does know, I’d genuinely like to hear from you. I posted the question on HN and got three replies. None of them was confident.

What I’d actually pay for

If you’re a solo developer or small team running on consumer hardware, the calculus is different from mine. You probably don’t have 2,847 lines of Rust to refactor. You probably do have a Slack message to write, a bug to find, a test suite to fill in.

For that work, Opus 4.8 is good. Not life-changing. Not “the future is here.” Just good. It asks the right questions, sometimes. It catches its own mistakes, sometimes. It’s faster than 4.7 in ways that matter in long sessions.

Katie Parrott, one of the writers Anthropic quoted in the launch post, called it “a major quality-of-life update over Opus 4.7.” I think that’s right. It’s not a different model. It’s a more comfortable version of the same model.

For me, the question is whether I’d pay $20/month for it. Last month, on 4.7, I would have said yes. This month, on 4.8, I would also say yes. The fact that the price didn’t change is the only reason I’m still on it. If they had bumped it to $30 to match what the model is now actually doing, I’d probably stay. If they bumped it to $40, I’d start looking at GPT-5.5 and GLM-5.2.

The model is real. The launch had bugs. The community caught them faster than Anthropic admitted to them. The week ended with me still using it, but with fewer illusions about what it is.

That’s probably enough.

—

Specs compared

Feature	Opus 4.7	Opus 4.8
Context window	200K	200K
Online-Mind2Web	78%	84%
Super-Agent completion rate	9/10	10/10 (only model)
Token cost (Databricks Genie)	baseline	61% cheaper
Effort control	no	yes
Dynamic workflows	no	yes (Code)
Pro price	$20/mo	$20/mo

Pricing

Plan	Price	What you get
Pro	$20/mo	Web, Code basic, effort control
Team	$25/user/mo	Dynamic workflows, admin
Max	$100-200/mo	Heavy usage, all features
Enterprise	Custom	61% cheaper tokens, SSO, audit

Last updated: 2026-06-28

—

This review is based on six days of testing on a real Rust project, plus comparison runs on Opus 4.7. The five tasks, the bug I chased, the Slack message I asked it to help write — those are real. I don’t have a Databricks bill or Cursor access to verify the third-party claims, so where I quote them, I attribute them. If you have questions or your own data points, the HN thread is the best place to find me.