Six weeks of daily production use across teams shipping with Opus 4.7, including the engineering work behind MemX.
It is Tuesday at 2 PM. You have a deadline at 5. You paste a 400-line file into Claude Opus 4.7 and ask it to add a feature without breaking three other things. A few weeks ago that prompt would have cost an evening of cleanup. With 4.7 it takes twelve minutes.
That is the whole review in one paragraph. Everything below is why.
This is not a benchmark post. Benchmarks lie about almost everything that matters in real work, and the public scores in 2026 are rounded into ties you cannot feel in actual use. I care about what happens when you sit down to ship something real, with people watching.
Quick takeaways: the practical edge of Claude Opus 4.7 is not raw intelligence. It is restraint. The model stops less, asks better, and edits instead of rewriting. The mark of a useful AI is not what it does. It is what it refuses to do. The right comparison is not 4.7 versus GPT-5. It is Opus when the problem is hard, Sonnet 4.6 when the problem is normal, and no model at all when the problem is trivial.
Here is what most reviews won't tell you
Most Claude Opus 4.7 reviews focus on what it can do. The contrarian truth is that the right question is what it refuses to do.
Most daily work does not need Opus. Format a JSON blob. Write a commit message. Sketch a query. Generate a short function. These are Sonnet 4.6 tasks, and using Opus for them is paying for habit, not intelligence. The honest engineer's posture toward Opus 4.7 is to reach for it deliberately and skip it otherwise.
The other thing the loudest reviews skip: the upgrade from 4.6 to 4.7 did not change scores on the private benchmarks teams quietly keep. It changed supervision overhead. That is a different kind of improvement, and it matters more than another point on a public eval.
What actually changed in 4.7
The 4.6 to 4.7 jump is the most useful one in the recent release cadence. Not because it raised the ceiling on what the model can do. Because it lowered the floor on how much an engineer has to babysit.
Five differences that surface every day:
- Speed at the same quality. The wall-clock cost of an Opus request used to feel like a tax. Now it does not.
- Agentic loops hold together. Long tasks where the model has to plan, act, evaluate, replan, used to drift after eight or ten steps. Now they hold for an hour.
- Tool use is sharper. The model picks the right tool the first time more often. When it does not, it recovers fast instead of doubling down.
- Extended thinking is actually useful. With 4.6 it rarely earned the wait. With 4.7 it earns the wait for any task that requires planning, and its absence is noticeable when it is left off.
- The refusal behavior is calibrated. The model used to refuse harmless requests that sounded uncomfortable in isolation. Now it asks clarifying questions. That is the right behavior.
None of these win a press release. They win a workday.
Where 4.7 stood out
Three patterns changed the working model of what 4.7 is for.
The first is the refactor pattern. A typical request: hand Opus 4.7 a database access layer and ask it to migrate from one ORM to another. With 4.6 the workflow was small chunks so the model could keep context. With 4.7 the whole layer fits in one prompt with an instruction to plan first, ask any questions, then execute. In practice it asks four questions. Two of them are questions an experienced engineer would not have asked themselves.
The second is the production-bug pattern. Take a queue worker dropping messages intermittently under load, where a team has been stuck for most of a day. Paste the worker code, the queue config, one crash log, and a one-sentence description. Opus reads for a few seconds and surfaces that the visibility timeout is shorter than the slowest p99 handler under back pressure. That is the bug. The numbers had been read a dozen times and nobody had connected them.
The third is restraint. Ask Opus to add a feature to a Flutter screen that is arguably poorly structured. The model adds the feature. It does not restructure the screen. Prompted somewhat leadingly to fix the structure too, it pushes back. It says the structure is workable, the cost of restructuring does not match the benefit for this change, and offers to draft a separate PR if someone wants to take it on. The bait to do too much is refused. That is the behaviour that makes it feel like a colleague.
Where it still falls short
Three real frustrations that surface across six weeks of daily use.
The cost is real
Opus pricing is high enough that you cannot use it like Sonnet. Set up an agent that loops over Opus for a thousand iterations and the bill will hurt. It is easy to write prompts where the cost-to-value ratio is wrong and Sonnet would have been the right call. The model cannot save you from that judgment. You make it consciously, every time.
Over-conservatism in long sessions
After a few thousand tokens of context, the model sometimes hedges against the conversation history rather than answering the question in front of it. The fix is to start a fresh session, but that costs the context built up across the morning. This is the limitation the next version most needs to fix.
Rare API hallucination
For mainstream libraries the model is almost flawless. For lesser-used packages, especially ones released after its knowledge cutoff, it will sometimes confidently invent a method that does not exist. The pattern is unmistakable once seen twice. The first time it can cost an hour. Verify any API call you have not used before.
None of these are dealbreakers. All of them are worth knowing before you commit your workflow.
The use cases where Opus 4.7 actually pays off
This is the section that took the most field testing to figure out. The model is not equally good at everything, and the cost is high enough that you should be deliberate about when you reach for it. Here are the five places it consistently earns its keep.
Code review on diffs you do not want to read
This is the use case that saves the most time, and the one worth pushing hardest. Paste a diff, ask Opus to review it like a senior engineer who is grumpy about quality but not about pedantry. The model catches the things you would have caught on your second pass through the file, plus a few things you would have missed entirely. PR bug rates drop noticeably once this is part of the workflow.
Debugging production issues stuck for a day
Specifically the ones where the symptom is clear, the logs are available, but no human has connected the dots. The reason this works is that Opus 4.7 has read more code than any human will read in a career, and it pattern matches on failure modes well. Half the bugs you spend a day on are bugs the model has seen a thousand times in someone else's codebase.
Architecture decisions you would otherwise table
Most engineers have a folder of "decide later" docs that never get opened, because making the decision required sitting down with a clear hour that never arrived. Opus 4.7 is the strongest tool available for working through these. Paste the constraints, ask it to enumerate the options with tradeoffs, and have a conversation. The deciding still happens in a human head. The deliberation happens faster.
Writing tests for code that already exists
Opus 4.7 will write a test suite that covers the actual edge cases of a piece of code, not just the happy path. This is rare. Most models will write tests that pass and tell you nothing about whether the code is correct. Opus will write tests that fail when the code is wrong, which is the only kind of test worth having.
Refactoring legacy code that nobody understands
The model is good at this for the same reason it is good at debugging: pattern matching across the corpus of every codebase it has seen. It is the only AI tool currently worth letting touch a fifteen year old codebase, and even then only with careful review on every change.
Sonnet 4.6 versus Opus 4.7: when each one wins
Sonnet handles the majority of AI-assisted work in a typical engineering week. Opus handles the rest. That is the rough split that emerges after a few weeks of deliberate use, and it surprises most engineers when they first notice it.
Sonnet is the right model when the output can be described in one sentence and a competent junior engineer would be trusted to do it. Format a JSON blob. Write a short function. Draft a commit message. Sketch a query. Summarize a meeting. Sonnet is excellent at all of these and the cost stays low enough to stop thinking about it.
Opus is the right model when the problem requires planning or judgment. Code review. Refactors. Debugging. Architecture. Anything where output quality depends on the model thinking through the problem rather than executing on autopilot. The cost difference is real. The quality difference is real. You pay for Opus when you reach for it deliberately.
The most common mistake is using Opus for tasks Sonnet would do equally well. That is not paying for intelligence. That is paying for habit.
Should you switch from GPT-5 or Gemini 3?
This depends on what you build.
If you write a lot of code, Opus 4.7 is the best model available for that work right now. GPT-5.5 is close, and there are individual tasks where it is faster or cheaper. Gemini 3 matches Opus 4.7 at a 1M-token context window rather than beating it, and effective context degrades below the cap on every model, so there is no long-context edge to lean on here. But for the day-to-day work of an engineer in 2026, Opus 4.7 is the default pick. Note: Anthropic shipped Opus 4.8 on May 28, 2026, one day before this post went up. This review covers the weeks since 4.7 launched and the comparison still holds because 4.8 is an incremental refinement on the same architecture.
If you build agentic systems where the model has to plan, use tools, and recover from errors over many steps, Opus 4.7 is meaningfully better than the alternatives. This is the gap to lean on when building an autonomous product today.
If your work is mostly creative writing, customer service, or short-form generation, the gap closes. Sonnet 4.6 is competitive with GPT-5 on those tasks, and the cost difference favors Sonnet.
The boring answer is to try them all on the work you actually do. Public benchmarks are noise. Your private benchmark is what matters.
The honest pricing reality
Opus 4.7 is expensive on a per-token basis. Anthropic publishes the current pricing tiers on their API documentation page, and the gap between Opus and Sonnet 4.6 is large enough that you cannot ignore it for high-volume work.
The right unit of measurement is not dollars per token. It is dollars per feature shipped, dollars per bug avoided, dollars per hour of engineering attention saved. By that measure Opus 4.7 is one of the cheapest tools on an engineer's desk. The work that would have been done by hand costs more in salary than the API bill ever will.
For indie developers and small teams, the trick is selective use. Reach for Opus when the problem deserves it. Reach for Sonnet for everything else. The monthly bill stays sensible.
The bottom line
Six weeks into shipping with Opus 4.7, the pattern that emerges across teams is unexpected. The output quality is excellent, but that is not what makes the difference. What makes the difference is restraint. The model edits instead of rewrites. It asks instead of guesses. It pushes back when the engineer is wrong, which is the rarest and most valuable behaviour any AI assistant has demonstrated to date.
If you are deciding whether to make Opus 4.7 your daily driver, the short answer is yes for most engineers, and try it for everyone else. Run it on the actual work you do for two weeks, with deliberate side-by-side comparisons against your current model. If it does not change your workflow, drop back to Sonnet 4.6 and save the money. If it does change your workflow, you will know in the first week.
MemX, an AI memory app, was built with Claude Opus 4.7 as the primary engineering collaborator. The fact that the product exists and works is partly a vote for the model. If you want to see what shipping with Opus looks like, the result is at memx.app.
01Is Claude Opus 4.7 better than GPT-5.5 for coding?
For coding and agentic work, yes, with the gap widest on long agent loops and code review across big diffs. For short creative or generation tasks the two models are closer than either marketing page admits. The honest test is to run both on the work you actually do for a week.
02Is Claude Opus 4.7 worth the price over Sonnet 4.6?
For about a third of my work, yes. For the rest, Sonnet 4.6 is competitive at a fraction of the cost. The mistake people make is using Opus for everything because they have it. Use it deliberately and the bill stays sane.
03How do I try Claude Opus 4.7 without paying for Claude Pro?
Anthropic offers a metered API where you pay per token, no monthly minimum. A small starter credit is usually enough to tell you whether the model fits your workflow. Check the current pricing on Anthropic's API console before signing up.
04What is the context window for Claude Opus 4.7?
Anthropic publishes the current limit on their API documentation page. The practical limit is lower in long agentic sessions because effective attention degrades well before the hard cap. The model is sharpest in the first portion of a long conversation and tends to hedge near the end.
05Does Claude Opus 4.7 work for non-coding tasks?
Yes, especially work that requires planning or judgment: research, writing, analysis. For routine generation Sonnet 4.6 is competitive and cheaper. Use Opus where the planning matters and Sonnet for the rest.
