What Claude Opus 4.7 Can Actually Do Now

Claude Opus 4.7 arrived with a behavioral claim that is easy to underestimate: the model follows your prompt more literally. That phrasing is easy to read past, but I think it is the most consequential thing in the release, because the failure mode it addresses is the one that most reliably produces rework. This article takes apart what that claim means mechanically, how adaptive thinking works as an effort dial, why first-attempt reliability matters more than benchmark scores for practical business use, and what the copyright refusal behavior signals about deploying this model in a commercial context.

The Literal-Prompt Mechanism: What It Does and Why It Changes the Workflow More Than Speed

The behavioral shift Anthropic describes as closer prompt analysis means the model reads what you wrote, weighs the specifics you included, and builds output that honors them, rather than treating your description as a starting point for its own elaboration. In practice, a bare timeline request produces exactly a timeline, without additional navigation, extra panels, or organizational enhancements the model decided to add because they seemed useful. A detailed spec for an AI-comparison website with specific filter requirements, a dark mode, and a mobile-optimized layout produces all of those features without requiring a separate follow-up prompt to add each one.

That might sound like a small improvement, but the compounding effect over a real work session is substantial. Every time an earlier model added something you did not ask for, you had to describe it in a correction, wait for a regeneration, and then check whether the correction introduced problems elsewhere in the artifact. A model that generates closer to what you specified skips that loop on most builds. The iteration cycles that remain are genuine refinements on an artifact that is already close to correct, not corrections of things the model decided on its own. Over a build session with three or four components, this difference can mean the difference between shipping a working tool in an afternoon and debugging a generated artifact for most of that afternoon.

The inverse of this behavior is equally important. Simple prompts do not get over-engineered. Asking for a button that changes color on hover produces a button that changes color on hover, not a fully animated micro-interaction system with easing curves and accessibility considerations the model added on its own initiative. That restraint matters in the context of iterative development, because it means you can make targeted requests and receive targeted outputs rather than managing the scope creep that previous models introduced as a side effect of trying to be helpful.

Adaptive Thinking as an Effort Dial: When to Turn It Up and When to Leave It Off

Adaptive thinking is the name Anthropic uses in the Claude app for the reasoning effort control that the API exposes as explicit effort levels. In the app, there is a single toggle. In the API, you get max, high, and a default very-high level that the model selects based on the apparent complexity of the request. The underlying mechanism is the same in both cases: the model allocates more computation to reasoning through the problem before generating a response, which improves quality on hard tasks at the cost of increased latency.

The practical decision rule is straightforward and worth committing to early: turn adaptive thinking on for hard builds and leave it off for simple passes. A multi-feature web app with authentication, multiple interacting components, and specific design constraints is a hard build. The reasoning overhead is worth it because the quality improvement on the first attempt reduces the number of iterations needed, and each iteration on a complex artifact is expensive in time and context. A simple color change on an existing component is not a hard build. Leaving adaptive thinking on for that request produces slower output and sometimes more elaborate changes than you asked for, which is the over-engineering problem that the literal-prompt behavior exists to prevent.

The most important comparison that demonstrates this tradeoff is the Sims-style city builder test. The same prompt, run on Claude Opus 4.6 and then on Opus 4.7 with adaptive thinking enabled, produced starkly different results. The 4.6 run took nearly five times longer and threw an error before completing. The 4.7 run with adaptive thinking produced a working artifact on the first attempt. That is not a benchmark number from a controlled evaluation. It is the kind of result you see on a real build, and it is the category of difference that changes whether AI-assisted development is a reliable tool in a time-constrained session or a source of unpredictable delays.

First-Attempt Reliability as the Practical Metric That Benchmarks Systematically Miss

Benchmark scores measure accuracy on standardized tests under conditions that do not reflect the typical business use case. They are useful for comparing models against each other on a shared scale. They are not useful for answering the question that matters most for a solo operator building a tool in an afternoon: what percentage of the time does the model produce something usable on the first attempt, without a failed generation I have to debug before I can start working?

First-attempt reliability is the metric that changes what is practically possible in a work session. A model that produces a usable artifact 90 percent of the time on the first attempt lets a solo operator plan a session around building four things and reasonably expect to build four things. A model that produces a usable first attempt 60 percent of the time introduces a probabilistic element into every session that makes planning unreliable and often means finishing the day with half of what was planned because the failures consumed the time.

The visual demos from the 4.7 release illustrate this consistently. A full AI-comparison website with working filters, dark mode, and mobile optimization generated on the first attempt. A documentary-style data visualization covering 200 years of world data, working on the first attempt with one small bug fixed by a single targeted follow-up. A photorealistic 3D Earth with clickable cities, first attempt. A cluttered historical image rebuilt as a clean interactive timeline, with one section running nearly 1,500 lines of code in a single HTML file, first attempt. The pattern is not that the model never needs iteration. It is that the first attempt is close enough to correct that the iteration is refinement rather than reconstruction. That distinction is the one that changes what a solo operator can ship in a day.

The Context Window and Effort Levels as Working Parameters

One specific clarification is worth making about the context window, because it affects how you plan sessions involving long documents or large codebases. The Claude app shows 200K context for Opus 4.7. The API provides 1 million tokens. That gap matters if you are planning to feed the model a very large document, a full codebase, or a lengthy transcript and expect it to work with the entire thing in one session. The app is the right environment for most everyday builds. The API is the right environment for document-heavy tasks where the 200K limit would cut off material you need the model to have access to.

The effort level controls available in the API give more fine-grained control than the app's single adaptive thinking toggle. Max effort is appropriate for the hardest reasoning tasks where time is less important than getting the answer right. High effort covers most complex builds. The default very-high level handles the broad middle of use cases where the model self-selects an appropriate reasoning depth based on the apparent complexity of the input. In the app, adaptive thinking on maps roughly to the high and max range, and off maps to the default. Learning which inputs benefit from which level is a matter of a few sessions of observation, not a complex tuning problem.

The pricing point that carries practical weight is that the API cost stayed the same as the previous model version. Access to more reliable first-attempt outputs, better literal-prompt following, and finer control over reasoning effort, all at the same per-token price as before, changes the cost-per-useful-output calculation in favor of Opus 4.7 for workloads where quality on the first attempt saves meaningful iteration time.

The Copyright Refusal Behavior and What It Signals About Commercial Deployment Safety

During a deliberate test, Opus 4.7 was asked to generate content based on a Nintendo-owned character. The model flagged the trademark and copyright concern explicitly, described why the request created a legal problem, and offered to build something original instead. It did not silently generate something adjacent to the trademarked character. It did not partially comply and omit the specific character name. It identified the issue and redirected clearly.

That behavior is worth examining carefully because it has direct implications for anyone building client-facing tools or deploying generated assets in a commercial context. A model that silently generates something that creates legal exposure, even when the user did not intend to trigger the problem, puts the responsibility for the violation on the user who published the output. A model that flags the problem before generating forces the issue into view at the right moment, which is before anything is published rather than after.

For the typical business use case, this matters most in situations where content generation intersects with intellectual property that is not immediately obvious. A request for a character design that happens to resemble a trademarked brand mascot. A generated image that incorporates elements of a copyrighted illustration. A piece of marketing copy that uses a phrase that is registered as a trademark. The model catching these cases proactively rather than generating and hoping the user reviews carefully is a meaningful reduction in the risk that AI-assisted content creation creates unexpected legal exposure.

Prompt Specificity as the Actual Ceiling on What Opus 4.7 Produces

The literal-prompt following capability that defines Opus 4.7's behavioral improvement also defines the most important constraint on what it can produce. The model follows what you specify. If you specify vaguely, you receive output built on the model's interpretation of a vague brief, which is better than what an older model would have done with the same brief but not as good as what Opus 4.7 produces from a specific one. The ceiling on output quality is not the model's reasoning capability at this point. It is the quality of the specification you provide.

This is a shift in where effort should be invested in the workflow. With older models, significant effort went into correcting and redirecting output after generation, because the model's interpretation of the brief was often far enough from the intent that the first output required substantial reworking. With Opus 4.7, the leverage is at the front of the process. Spending five extra minutes on a clear, specific prompt, describing exact layout decisions, naming the specific features you need, calling out what you explicitly do not want, produces a noticeably better first output and reduces the total time to a finished artifact.

A concrete way to think about this: a prompt that says build me a service estimate calculator produces a generic calculator with arbitrary services and default styling. A prompt that specifies six named services with typical price ranges, a two-column layout on desktop and single-column on mobile, a specific brand color, a summary section that shows total cost and time, and a call to action that opens a contact form produces something substantially closer to a deployable tool rather than a prototype that needs three rounds of refinement to become usable. The difference in prompt specificity represents about ten minutes of additional upfront thinking. The difference in output quality represents far more than ten minutes of saved iteration time afterward.

Treating Opus 4.7 as a collaborator that works from a real brief, rather than a generator that will figure out what you wanted from a rough description, is the operating model that produces the most consistent results. The capability is there. The prompt specificity is what unlocks it.

There is also an important point about what to do when an output is close but not quite right. The single targeted follow-up prompt is underused by most people who reach immediately for a full regeneration when something is off. Opus 4.7's surgical editing capability, its ability to fix a specific broken component without disturbing the surrounding code, is one of its practically useful strengths. Before regenerating the whole page because one section looks wrong, try describing exactly what is wrong in that one section and asking for only that fix. The result is usually faster and leaves the parts that were working intact rather than introducing new variation into areas that did not need to change. That discipline, precise targeted corrections on a strong first-attempt base, is the workflow that gets the most out of what this model is actually capable of.