En 30 secondes
After a day with Opus 4.7, Theo Browne finds impressive moments alongside interruptions and inconsistent coding results. He examines release claims, tool behavior and practical failures, while acknowledging the limits of his personal tests.
- 1Benchmarks have limitsLaunch scores vary by task and configuration, so Theo supplements them with practical tests.
- 2Client rollout mattersAnthropic attributed a malware reminder to older client versions and said a fix was rolling out.
- 3Check the planThe modernization plan targeted Next 15 without verifying the latest release, and the eventual build failed.
- 4Test all requirements togetherFixes to a clone script repeatedly broke other requested behavior.
- 5A limited personal testTheo found the model inconsistent after a day of use, but encourages readers to test their own workflows.
À retenir
- Benchmark gains do not guarantee reliable performance on every real task.
- Safety filters and client rollout issues can interrupt otherwise ordinary workflows.
- Verify current dependency versions, review agent plans and run the actual build.
- A repair should be tested against all requirements, not just the latest failure.
- Model, harness, settings and workload all affect observed results.
Lire le texte remanié, chapitre par chapitre
A promising model, uneven experience
Theo reviews the launch claims and benchmark table. He finds both stronger results and reasons to test real workflows.
I spent a day testing Anthropic's Opus 4.7. Some of its work impressed me, yet other sessions produced puzzling failures. My verdict is mixed: the model can reach impressive highs, but the experience was inconsistent enough that I struggled to rely on it.
Anthropic describes Opus 4.7 as a stronger software engineering model with improved instruction following, vision and long-running work. Its own release compares it with Opus 4.6 and other models, while also saying the limited Mythos Preview is more broadly capable. These are release claims, so I wanted to see what happens in practical use.

The benchmark table is not uniformly better: I notice a lower result on agentic search than Opus 4.6, alongside stronger results on coding tests. I am cautious about treating benchmark scores as the whole story, especially where tests may have become familiar to models. The results depend on the benchmark and test setup.
Safety and integration
A malware reminder and a paused cryptography puzzle show interruptions he encountered. An Anthropic representative identifies a client-version issue.
Anthropic says it tested cybersecurity safeguards on Opus 4.7 before a broader release of more capable models. The release describes automatic detection of prohibited or high-risk cyber requests and a verification program for legitimate security researchers. The intended protection has to be weighed against interruptions to ordinary work.
When I asked the Claude Code desktop app for design ideas for my personal site, the assistant reported that system reminders had treated the site as malware. It said it ignored them. The warning was a poor first impression, though the visible exchange alone does not tell us exactly how the reminder arose.
At launch, Anthropic listed the same API prices as Opus 4.6: $5 per million input tokens and $25 per million output tokens. It also warned that the model follows instructions more literally, so prompts and harnesses written for older versions may need adjustment. That makes integration quality part of the evaluation.
The announced vision improvements include support for images up to 2,576 pixels on the long edge, roughly four megapixels. That matters for dense screenshots, diagrams and visual references. Anthropic also reports better filesystem-based memory across sessions and stronger performance on selected professional-work evaluations.
The release adds an xhigh effort setting and describes an intensive review workflow. Higher effort gives users another way to trade latency and token consumption for more work; my concern is that the maximum setting can consume a great many tokens. Evaluate the setting against the task and its cost rather than assuming it is always worthwhile.
An Anthropic representative said the malware reminder was associated with older Claude Code and desktop versions and that a newer version had a fix. I showed that my app had appeared current when I saw the problem; the update button arrived later. This is a rollout and integration issue worth checking independently of the model's advertised capabilities.
I also tried a DEF CON Gold Bug cryptography puzzle called Sea Shanty. It presents twelve labeled bottles and a verse; the solver must infer a hidden phrase. My team had spent days on it, and I had seen another model solve it quickly, so I wanted to see whether Opus could make progress.
Opus explored possible ciphers and ran commands, then the conversation was paused by a safety filter. The interface offered a retry with Sonnet. In my view this was an ordinary puzzle, so the interruption undermined a promising attempt. One false positive is evidence of my experience, not a measurement of the filter's overall accuracy.

Modernizing a project
The agent produces a readable plan but misses a newer Next.js version and leaves a broken build. Theo discusses harness behavior and the need to verify.
My next test was modernizing Ping, an old video-service codebase that had not been maintained for years. It used Next.js 12 and React 17. I asked for updated dependencies, modern Node and React, pnpm, removal of LogRocket and a plan before implementation.
The initial plan was concise and readable, and I told the agent to build without checking it carefully. That was my mistake: the plan proposed migrating Next.js 12 to 15, even though version 16 was already available. Despite my request for the latest dependencies, it had not checked the current version online.

Earlier models from other providers had made a similar mistake until I made the prompt explicit. Here, the explicit wording still did not produce the necessary research. The agent ran for almost an hour, then spent another half hour correcting the target; the build ultimately broke. A polished plan does not substitute for checking assumptions and validating the result.
I also saw repeated attempts to update package.json fail because the harness required the file to be read first. I suspect some apparent model regressions come from the surrounding Claude Code tools, instructions and permissions. That is a hypothesis based on these examples, not proof that every regression is caused by the harness.
I speculate that internal and external tool environments may differ enough to change how a model feels. I do not have a controlled comparison of those environments. What I can observe is that the same underlying model can behave differently when its tools and instructions differ.
When I revisited the modernization run, I initially thought it had worked. On checking again, the migration from Next 15 to 16 had broken other parts of the build. That correction matters: a successful-looking agent report is not a replacement for actually running the checks.
The clone script
A small shell utility repeatedly misses requirements or breaks earlier fixes. Theo uses the task to show why end-to-end validation matters.
To run a fresh comparison without disturbing the long-running job, I asked Opus to create a zsh function that clones a repository to a new directory, copies environment files, excludes bulky dependencies and changes into the clone. I later asked for the clone to switch to main as well.

The assistant initially supplied code and asked whether I wanted it added to .zshrc, although I had already requested that. When I asked about switching branches, it again offered a snippet rather than making the change until I repeated the request. The mismatch between an authorized task and repeated permission-seeking was frustrating.
The script also copied unwanted uncommitted changes. An attempted correction used Git clone for tracked files and rsync for ignored material, but another run failed to switch branches and stopped copying the environment file. The agent then asserted a .gitignore explanation that did not match my repository.
I supplied diagnostics showing that .env was indeed ignored. A subsequent attempt restored that file but again brought over unwanted changes. The sequence illustrates a regression in the ordinary sense: a fix for one requirement can break another, so the complete set of requirements needs to be tested together.
Comparing runs and interfaces
The same prompt behaves differently across runs, and Theo tries another harness and model. He also discusses the Claude Code interface and permissions.
I reran the same modernization request on a clean copy. This time the model created a plan and immediately started rather than waiting for discussion, but it still selected Next 15 without checking the latest version. The differing behavior on the same prompt made it harder to predict what would happen.
I tried Opus in Cursor to see whether another harness would help, but the run I observed also stayed focused on Next 15. I then tried GPT-5.4 on the task. It sought current information and identified Next 16; that is a useful contrast in this particular run, not a controlled head-to-head benchmark.
There were also improvements in Claude Code itself: I found its full-screen interface less laggy and text selection better. Anthropic described an auto permission mode in which a model-based classifier assesses commands. I could not activate it in my demonstration, so I could not verify the mode in that session.
More confusingly, I had enabled bypass permissions but still encountered an edit-approval prompt. I recorded the prompt because I could not believe what I was seeing. That is a concrete usability problem in my session; it does not by itself establish why the permission behavior occurred.
Consistency and final verdict
Theo compares his experiences with other user reports and calls for reliability. He emphasizes that his sample is limited.
After the initial successes, several of my later tasks failed, while my retries with GPT-5.4 went better. Other users shared both positive and negative accounts, including a case where web search had apparently been disabled. Such reports are useful leads, but differences in tools, settings and tasks make broad conclusions difficult.
I asked whether users had noticed comparable regressions in Codex or OpenAI models. Several replies reported relatively stable experiences, while an OpenAI representative mentioned a prior Codex infrastructure investigation. These are selected responses to my question, not evidence that OpenAI models never regress or that Anthropic alone has reliability issues.
Is Opus 4.7 the best coding model? Sometimes it can look that way. A user described it working through a bug involving 30 files and then reversing a Boolean in the fix. That combination captures my concern: impressive capability at the top end alongside mistakes that make the output harder to trust.
After roughly twelve hours of testing, I had a poor overall experience despite some promising moments. If you already have access, try it on your own tasks and compare the results. I am one person with a limited sample, and I cannot know all the things this model does well or badly.
Sur la même chaîne
38:47EN
36:07EN
30:37EN
0:43EN
29:22EN
31:13EN