// blog/claude-opus-4-7-for-long-running-coding-tasks
Claude Opus 4.7 for Long-Running Coding Tasks
Claude Opus 4.7 is Anthropic's new generally available flagship model for advanced software engineering. Its most useful change is to reliability: Anthropic says the model can sustain complex work for longer, follow instructions more closely, and devise checks for its own output before it reports completion. At $5 per million input tokens and $25 per million output tokens, the same pricing as Opus 4.6, it changes the default model-selection question for teams running expensive coding-agent loops. Anthropic's announcement positions the release around difficult engineering tasks, better visual understanding, and deployment safeguards for cybersecurity use.
What is Claude Opus 4.7?
Claude Opus 4.7 is the successor to Claude Opus 4.6. It is available through Claude products, the Claude API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry. API users can select it as claude-opus-4-7. Anthropic lists those availability details and prices here.
The release is aimed at work that carries state across many steps: modifying a repository, running tests, inspecting failures, using tools, revising a plan, and checking the result. That is different from asking for a function in a fresh chat window. A model can look strong on a one-shot implementation task while still losing track of constraints halfway through a long session or stopping when the first tool call fails.
Anthropic's description makes three distinct operational claims:
- Opus 4.7 handles complex, long-running tasks with more rigor and consistency.
- It pays closer attention to instructions and verifies outputs before reporting back.
- It improves on Opus 4.6 across a range of benchmarks, while remaining less broadly capable than Claude Mythos Preview.
The first two claims matter more to an engineering workflow than a headline benchmark score. Coding agents already have ways to write files and run commands. They fail most often in the handoff between those actions: whether the agent understands which failing test matters, whether it returns to the original requirement after several detours, and whether it can distinguish "the command passed" from "the requested change is complete."
Why long-running coding tasks fail
Long-running work has failure modes that do not show up in a small prompt-response exchange.
An agent may make a plausible edit, run only a narrow test, and miss a broken integration path. It may encounter an unfamiliar error message, propose a workaround, then forget that the workaround violates a requirement established earlier. It may call a tool incorrectly and abandon the task after the failure. Or it may continue using a brittle fallback despite signals that the required data is missing.
The release feedback focuses repeatedly on those points. Hex reported that Opus 4.7 correctly reports missing data instead of supplying plausible-but-incorrect fallbacks, and that its low-effort setting was roughly equivalent to medium-effort Opus 4.6 in the company's testing. Replit reported the same quality at lower cost for log and trace analysis, bug finding, and proposed fixes. Vercel reported stronger completeness on one-shot coding tasks and greater honesty about limits. These are early-access tester reports collected by Anthropic.
Those observations come down to whether a coding agent knows when evidence supports a result and when it does not. A polished explanation of an unverified patch is a poor terminal state for an automated engineering workflow.
Genspark highlighted loop resistance, consistency, and graceful recovery from errors, while noting that a model that loops on one in 18 queries consumes compute and blocks users. That is a deployment issue: if an agent can enter an unproductive loop, increasing its token budget or giving it more tool permissions can make the failure more expensive.
How Opus 4.7 changes coding-agent loops
A coding agent should be treated as a loop with explicit checkpoints, rather than a single model call.
Read task and repository context
↓
Plan a bounded change
↓
Edit code or configuration
↓
Run targeted validation
↓
Inspect failures and repository state
↓
Revise or report evidence-backed limits
Opus 4.7's reported gains fit several places in that loop.
| Stage | What to look for from Opus 4.7 | Why it matters |
|---|---|---|
| Planning | More precise instruction following and identification of logical faults | Reduces drift before files change |
| Tool use | Fewer tool errors and follow-through after failures | Keeps a task from ending on an avoidable command failure |
| Validation | Self-checking before reporting completion | Makes test output and repository state part of the answer |
| Review | Better detection of difficult bugs without lower reported precision | Helps distinguish a meaningful finding from noise |
| Long context | More consistent behavior over extended work | Supports work that exceeds a short edit-test cycle |
Several early testers reported results consistent with this shape. Cursor reported a 70% result on CursorBench for Opus 4.7, compared with 58% for Opus 4.6, plus a 14% improvement on complex multi-step workflows with fewer tokens and one-third of the tool errors. Factory reported a 10% to 15% lift in task success, fewer tool errors, and more reliable validation follow-through. Those figures are company-reported evaluations in Anthropic's announcement.
Factory's phrase "carries work all the way through" should be tested as a behavior rather than accepted as a vendor attribute. Give the model tasks with an explicit completion contract: required files, required tests, constraints on dependencies, and a request to state which checks ran. Then inspect whether it reaches that contract over repeated tasks.
How should developers evaluate Claude Opus 4.7?
A serious evaluation should use the work that has been failing or consuming review time, with controlled conditions. A generic benchmark can indicate direction, but it cannot reveal how a model handles a particular repository's tooling, conventions, flaky tests, generated code, or CI rules.
Start with a set of tasks that represent the agent workflow:
- A bug fix requiring a failing test, a code change, and a regression check.
- A repository investigation where the correct answer may be "the supplied evidence is insufficient."
- A multi-file change with a strict no-new-dependency constraint.
- A task that deliberately includes a recoverable tool failure.
- A visual task involving a screenshot, technical diagram, or interface implementation.
For each task, retain the prompt, model configuration, tool transcript, changed files, commands run, final answer, and human review result. The output is then reviewable as an engineering artifact rather than a subjective impression.
The most useful measures are also fairly direct:
| Measure | What it reveals |
|---|---|
| Task completion rate | Whether the requested end state was reached |
| Validation coverage | Whether the agent ran relevant checks rather than only a convenient command |
| Tool-error recovery | Whether recoverable failures terminate the task |
| Review corrections | How much human repair remains after the agent stops |
| Token and wall-clock cost | Whether stronger performance is affordable at the chosen effort level |
| False completion rate | How often the model claims success without sufficient evidence |
Do not compare models using only a successful final patch. A model that produces a good patch after several unnecessary restarts, broad changes, or unsupported assumptions may be unsuitable for an unattended loop. Conversely, a model that stops and explains an evidence gap can be the safer result for an investigation task.
Anthropic says Opus 4.7 is better at greater-resolution image understanding, including professional interfaces, slides, and documents. Solve Intelligence reported improvements in interpreting complex technical diagrams and chemical structures for life-sciences patent workflows. XBOW reported 98.5% on its visual-acuity benchmark versus 54.5% for Opus 4.6. Both reports appear in the release announcement. For software teams, the near-term test is simpler: evaluate whether screenshot-based debugging, UI implementation, and diagram-driven changes improve under the same tool harness.
When should teams use Opus 4.7 instead of Opus 4.6?
The case for trying Opus 4.7 is strongest when the task is expensive because it is hard to supervise.
Examples include:
- Repository changes that require repeated edit, test, inspect, and revise cycles.
- Debugging from logs, traces, and code spread across multiple files.
- Code review where missing a subtle issue is costly.
- Agent workflows that must recover from tool failures.
- Interface work or technical analysis that depends on image resolution.
Anthropic reports that CodeRabbit saw recall improve by more than 10% while precision remained stable in its code-review workload. Warp reported that Opus 4.7 completed Terminal Bench tasks earlier Claude models had failed and worked through a concurrency bug Opus 4.6 could not solve. Qodo reported that the model found issues previous models missed, including a race condition. These are useful signals for evaluation design, especially because they point to difficult classes of work rather than cosmetic code generation. They remain individual tester reports rather than a universal performance guarantee.
The pricing parity with Opus 4.6 matters here. When two models have the same posted token price, the comparison shifts toward total cost per accepted task: tokens used, retries, tool calls, human review, and remediation. A model that reaches a verified result in fewer steps can reduce that total even if a single response uses more reasoning.
What are the cybersecurity limits and safeguards?
Anthropic says Opus 4.7 is the first less-capable model on which it is testing new cybersecurity safeguards before a broader release of Mythos-class models. The company says it experimented during training with reducing certain cyber capabilities and is releasing Opus 4.7 with automated detection and blocking for requests that indicate prohibited or high-risk cybersecurity uses. Anthropic describes the safeguards and their connection to Project Glasswing here.
That means security teams should expect behavior differences between ordinary software-engineering requests and requests that trigger the model's cyber protections. A workflow that is legitimate in context can still need a clear authorization trail and a well-defined scope.
Anthropic has opened a Cyber Verification Program for security professionals who want to use Opus 4.7 for legitimate vulnerability research, penetration testing, or red-teaming. For everyone else, the practical boundary is straightforward: evaluate the model's security-adjacent behavior within approved systems and expect safety controls to be part of the product behavior.
Claude Opus 4.7 is most interesting where agentic coding has been weakest: staying oriented across a difficult task, recovering after a failed action, validating its own work, and saying when the evidence does not support a confident answer. Those are the behaviors to test before changing a production agent's default model.