Long-Running AI Tasks Depend on Adaptability, Not Just Context
Adaptation, not just endurance
For long-running AI work, the harder test may be coping with change rather than handling more steps. METR’s February–March 2026 Frontier Risk Report estimated when a model’s success rate on a software task falls to 50%. Claude Opus 4.6 reached about 17.8 hours on cleaner tasks, versus 6.4 hours when environments shifted, resources were constrained, feedback was costly, or mistakes were hard to undo.
That gap points to the work ahead: systems need to retain progress, adjust to changing conditions, and recover when assumptions fail. Task duration alone tells only part of the story. A system that can continue a task for many hours under stable conditions may still struggle when an expected tool becomes unavailable or an earlier decision proves wrong. The distinction matters because useful work rarely unfolds in a perfectly controlled environment.
What the estimate measures
The report’s 50% success point is a way to describe task difficulty in terms of time. In plain language, it asks how long a software task can run before the model’s chance of completing it successfully reaches an even split. That can help compare performance across tasks of different lengths, but it shouldn’t be mistaken for a guarantee that a model will reliably work for that many hours in a particular job.
The conditions in the comparison also matter. “Cleaner” tasks provide a more favorable setting, while shifts in the environment, limited resources, expensive feedback, and difficult-to-reverse errors add friction. Those factors test more than whether a model can generate code or follow a sequence of instructions. They test whether it can notice that the situation has changed, decide what information it needs, and avoid compounding an earlier mistake.
Here’s the thing: a long task is often a chain of smaller judgments. Each step can depend on files, tools, data, or decisions made earlier. If one assumption goes stale, later work may still look coherent while heading in the wrong direction. A duration estimate can capture some of the challenge, but it doesn’t, on its own, explain which part of the chain failed.
Why changing conditions are difficult
Software work is full of dependencies. A model may need to inspect existing code, make a change, run a check, interpret the result, and then revise its approach. When the environment shifts during that process, the model can’t simply repeat its original plan. It has to distinguish between a temporary obstacle and evidence that the plan itself no longer fits.
That’s a demanding problem for any automated system. A tool might behave differently than expected; a constraint might limit what can be tested; or feedback might arrive only after a costly action. In these situations, reliable performance depends on keeping track of what has already been tried and why, while also being willing to revisit a conclusion. Persistence helps only if it’s paired with judgment.
Recovery is especially important when mistakes are hard to undo. In a low-stakes step, a wrong choice may be easy to correct. In a longer workflow, that same choice can alter files, consume limited resources, or make later results harder to interpret. The practical question isn’t merely whether a model can finish after a setback. It’s whether it can recognize the setback early enough to limit its effects.
Progress tracking is part of the work
Retaining progress sounds simple, but it involves more than remembering a list of completed actions. A system needs a useful account of the task’s current state: what it changed, what it observed, which assumptions remain untested, and what should happen next. Without that record, a model may repeat work, overlook a warning, or treat an earlier guess as a confirmed fact.
There’s a tradeoff, too. Carrying too little context can make a system lose important details, while carrying too much can make it harder to identify what matters now. Similar systems typically need some way to summarize the task without flattening uncertainty or hiding unresolved problems. That’s a design challenge as much as a raw capability question.
Feedback adds another complication. When it’s cheap and immediate, a system can try an approach, inspect the result, and adjust. When feedback is costly or delayed, each action carries more weight, and the system has fewer chances to catch a bad direction early. The report’s comparison highlights that performance can change sharply when those conditions become less forgiving.
What the gap says about evaluation
This is more significant than it looks. The contrast between about 17.8 hours on cleaner tasks and 6.4 hours under harder conditions suggests that a single headline about task length can conceal important weaknesses. A benchmark result under favorable conditions tells us something about capacity, but it may say less about how that capacity holds up amid interruptions, constraints, or uncertain feedback.
That doesn’t make duration measures useless. They offer a compact way to discuss how performance relates to task length, and the report’s estimate gives readers a specific comparison to consider. But anyone interpreting the result should ask what the tasks demand and how much room they allow for recovery. A model’s ability to stay on task and its ability to adapt are related, yet they aren’t interchangeable.
One limitation is that a success rate compresses many possible outcomes into one figure. Two systems could reach the same success rate for different reasons: one might fail early on a small set of difficult steps, while another might make progress consistently but struggle at the final check. The supplied figures don’t resolve that distinction. That’s why the conditions surrounding a task, and the path through it, deserve attention alongside its length.
Implications for people building with AI
If you’re working in this space, the practical takeaway is to test for changing conditions as well as longer workloads. A system may appear capable when every dependency behaves as expected, then falter when a tool fails or a result contradicts its plan. Evaluations that include those disruptions can reveal whether the model tracks uncertainty and changes course, rather than simply continuing to produce plausible next steps.
People using AI for extended software tasks may also need to think carefully about checkpoints. Breaking work into stages can make it easier to inspect progress, confirm important assumptions, and limit the cost of an error. That doesn’t remove the underlying challenge; it makes the system’s state easier to review. The value of those checkpoints depends on whether they capture meaningful decisions rather than just a record of activity.
And yet, adding more monitoring isn’t a complete answer. If a system can’t identify when its assumptions have stopped matching the environment, a checkpoint may preserve a flawed plan with impressive clarity. Better long-running performance will require progress tracking, adaptation, and recovery to work together. More steps are useful only when the system can handle what changes along the way.
What comes next
The report’s comparison puts a useful question in focus: how well can AI systems maintain competent work when the task stops being predictable? The reported estimates show a sizable difference between cleaner conditions and environments with added friction. They don’t, by themselves, tell us how every model will behave in every software workflow, or which design changes will close the gap.
For now, the clearest lesson is that endurance and adaptability should be assessed together. A system that can work for longer under favorable conditions has demonstrated one kind of capability. To be dependable across extended tasks, it also has to preserve the right context, respond to new evidence, and recover without turning a local error into a larger failure. The harder test is what happens when the plan meets reality. And then what the system does next.
