AI Agent Time Horizons: What ‘Hours of Work’ Really Means

When someone says an AI agent can do "hours of work," ask which clock they mean. The phrase is currently used for at least three different measurements:

1. Human-equivalent task horizon: how long a comparable task takes a human expert.
2. Uninterrupted agent runtime: how long an agent operates before it finishes, pauses, fails, or a person intervenes.
3. Aggregate parallel agent-hours: the sum of active time across several agents running at once.

These numbers can all be true and still describe very different systems. A benchmark can label a task "five hours" even if the agent executes it in less than an hour. One person can generate 60 agent-hours in a day by running many agents concurrently. An agent can also run for six hours and produce nothing that passes a real acceptance test.

Task horizon estimates task difficulty, runtime is a proxy for deployed autonomy, and aggregate agent-hours measure parallel activity. None of them measures verified throughput or value on its own.

The three clocks

The fix is not to choose one clock. It is to label each one, then connect it to outcomes.

Clock one: human-equivalent task horizon

METR's task-completion time horizon is the most frequently cited version of the first clock. For each task, researchers estimate how long a human expert would need. They then fit a curve that predicts agent success as task duration increases. The 50% horizon is where that curve crosses a predicted 50% success rate. An 80% horizon uses the same method at a stricter reliability threshold.

The crucial point is in METR's own FAQ: this is a measure of task difficulty, not the amount of time the agent spends executing. The agent may complete a task much faster than the human baseline. It may also consume different amounts of time across inference providers and harnesses.

The current Time Horizon 1.1 suite contains more than one hundred tasks drawn mainly from software engineering, machine learning, and cybersecurity. They are deliberately self-contained, well specified, and automatically gradable. METR says measurements above 16 hours are unreliable with the current suite, and notes that its human estimates may overstate the time a professional with deep project context would need.

That gives the metric a precise interpretation:

On this task distribution, with this agent harness and scoring method, what human expert task duration corresponds to a given predicted probability of success?

It does not support these broader conclusions:

• the agent can do every kind of work below that duration;
• the agent can run unattended for that duration;
• the agent can replace a high-context professional for that many hours;
• the same result will hold on ambiguous, social, or weakly scored work;
• the measured model will retain that capability in another tool harness.

Time horizon is useful because it combines difficulty and reliability in one curve. It becomes misleading when the task distribution, success threshold, or harness disappears from the retelling.

Clock two: uninterrupted runtime

Runtime asks a different question: how long does the deployed agent act before the interaction stops? Anthropic studied this directly in Claude Code sessions. Its February 2026 analysis reported that the median turn was about 45 seconds, while the 99.9th percentile increased from under 25 minutes to over 45 minutes between late September 2025 and early January 2026.

Those observations do not conflict with multi-hour capability horizons. Anthropic explicitly compared the two and said they are not directly comparable. METR measures the difficulty of benchmark tasks in human time under an idealized evaluation. Claude Code turn duration measures behavior in a product where the model can ask questions and a person can interrupt.

Runtime is also an imperfect autonomy metric. A stronger agent could finish the same work faster, which shortens the run. A confused agent could loop for longer, which lengthens it. A subagent could perform work concurrently, which changes how much activity fits inside one parent turn. Product defaults, approval settings, user experience, and task ambition all affect the number.

That makes a runtime percentile valuable for oversight design, not as a standalone capability score. If long-tail runs are growing, the system needs durable checkpoints, recoverable state, clear interruption controls, and alerts that do not require someone to watch every tool call.

Clock three: aggregate parallel agent-hours

Aggregate hours are capacity accounting. If ten agents each run for one hour at the same time, the operator waited roughly one hour while the system generated ten agent-hours. That is the point of parallel orchestration, and it is physically possible without stretching a day.

OpenAI's June 2026 report provides a concrete example. It said users at the 99th percentile of daily activity within OpenAI regularly generated more than 60 hours of Codex agent turns per day, distributed across multiple parallel agents. The same report said 70.2% of a sample of individual users had made at least one request estimated to exceed one hour of human work by May 2026.

Those are two clocks in the same report. The first is aggregate agent activity. The second is an estimated human-equivalent request horizon. OpenAI notes that the request estimates came from an LLM judge with access to transcripts and should be treated as directional, not exact.

Aggregate hours matter for queue capacity, budgets, rate limits, and the amount of work one operator can supervise. They do not establish that the work was independent, non-duplicative, correct, or useful. Counting agent-hours without counting accepted outputs is the automated equivalent of measuring a project by keyboard time.

Long sequences have a reliability tax

An agent that can take more steps gets access to harder tasks. It also gets more opportunities to make a consequential error. In a simplified sequence of independent steps, total success is the product of the success probabilities of those steps:

P(whole task succeeds) = P(step 1) x P(step 2) x ... x P(step n)

Real agent steps are not independent, so this is not a production estimator. Errors can cascade, or later checks can repair earlier mistakes. The formula is still a useful warning: extending a loop without strengthening its gates does not automatically extend reliable capability.

This is why loop engineering treats the external gate, repair path, budget, and termination condition as part of the system. A long trace ending in a confident completion message is not evidence. The artifact must pass something outside the trajectory.

Parallelism changes the clock, not the dependency graph

Adding agents can compress elapsed time when work is genuinely decomposable. It can also add coordination overhead or fragment a task that needs one coherent sequence.

Google Research evaluated 180 agent configurations across single-agent, independent, centralized, decentralized, and hybrid architectures. In its reported experiments, multi-agent coordination improved parallelizable financial reasoning but degraded sequential planning tasks. Its predictive selector identified the best architecture for 87% of unseen task configurations in that experimental setting.

The important result is not a universal percentage. It is the dependency test: parallelize independent evidence gathering, not tightly coupled reasoning steps. More agents can increase aggregate hours while making the final result worse. Report both the parallel activity and the verified task outcome.

A measurement stack that survives contact with production

A useful dashboard should keep the three clocks separate and add a fourth category for outcomes.

Two details keep this honest.

First, distinguish active time from waiting time. A three-hour job that spent most of its life waiting on a queue or human approval is not a three-hour autonomous reasoning run. Track model activity, tool execution, backoff, queueing, and input-required time separately.

Second, preserve the acceptance evidence. Store the test result, schema validation, policy decision, reviewer rubric, or artifact hash that justified completion. The principle in do not let the agent grade itself becomes more important as traces get longer: completion must be a state established by the system, not a sentence generated by the actor.

Designing a system that can safely run for hours

Long-horizon work should be a chain of recoverable work packets, not one enormous conversation.

1. Define a verifiable deliverable. Turn the goal into an artifact with explicit acceptance criteria.
2. Persist state outside the context window. Checkpoints, decisions, evidence, and verified progress need durable storage.
3. Gate irreversible actions. Sending, publishing, paying, deleting, deploying, and changing permissions need policy checks or approval at the action boundary.
4. Make side effects idempotent. A retry after a timeout must not repeat a charge, message, or mutation.
5. Budget every level. Cap wall time, model turns, tokens, cost, delegation depth, and concurrent workers.
6. Separate progress from success. Files created and tools called are activity. Tests passed and artifacts accepted are outcomes.
7. Escalate with evidence. When the system stops, return the last verified checkpoint, the failing gate, and the missing decision.
8. Re-evaluate on environment drift. A run can outlive credentials, data versions, deployments, and assumptions. Validate them again before acting.

An agent becomes easier to trust when it can stop cleanly. The most advanced long-running system is not the one that never asks for help. It is the one that knows what it has verified, what remains uncertain, and which boundary it cannot cross alone.

How to read the next “hours of work” claim

Use this checklist before comparing a number or repeating it:

• Is the unit human task time, wall-clock runtime, active model time, or summed parallel time?
• What event starts and stops the clock?
• What success probability is attached to the horizon?
• Which tasks, domains, tools, and agent harness were measured?
• Was task duration observed from humans, estimated by experts, or inferred by a model?
• Does the number describe a median, a tail percentile, or selected examples?
• Were human interruptions and agent clarification requests included?
• Was the output accepted by an external gate?
• Are retries, duplicated work, and failed runs counted?
• Does parallel agent time get reported separately from elapsed time?

If those answers are missing, the number may still be interesting. It is not yet an operational fact.

Sources

• METR: Task-Completion Time Horizons of Frontier AI Models (opens in a new tab)
• Anthropic: Measuring AI agent autonomy in practice (opens in a new tab)
• OpenAI: How agents are transforming work (opens in a new tab)
• Google Research: When and why agent systems work (opens in a new tab)