TL;DR
LLMs have no internal clock. An agent only knows how much time has passed if it calls a clock itself or sees timestamps in its context. That's why tacking “work on this task for exactly one hour” onto the end of a prompt plays out very differently from model to model. One model hits the requested time within 18%. Another misses by almost 3x: it spends twice as long on short requests and comes back after a third of the time on long ones.
Hitting the deadline isn't the same as working. Among the reviewed GPT-6 Astra runs, in roughly one out of ten the agent finished the task and simply called sleep until the time ran out. In almost half, it was re-checking work it had already done. More time barely improves the result: asking for 16x longer left the task score unchanged on about two thirds of tasks.
Agents are also bad at predicting their own runtime. Their “how long will you need” estimate is usually too high: by 1.3–3x on average, with a typical miss of 2.6–3.8x. Ask how long it would take a human professional and the answer is another 3–4x larger. Strip timestamps out of the context and the “how long have I been working” estimate gets 2–5x worse. With a tool that returns the exact elapsed time, the error disappears.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
This is a finding, not a method. But the paper includes three “probe prompts” you can use to test your own model:
PROBE 1 (duration following): task + “work for exactly N minutes” → see when the agent comes back
PROBE 2 (forecast): “how long will you need?” → compare with the actual time
PROBE 3 (retrospective): “how long did you work?” → compare with an external clock
The golden rule: always measure time from the outside (with a timer, with logs) instead of trusting the agent's report.
Example in Practice
Task: A developer at a small food-delivery startup in Austin leaves Codex running overnight. The job is to speed up slow SQL queries in the reports module, with a 3-hour budget. In the morning they want results, not a bill for 9 hours of compute. They also don't want the agent to wrap up in 20 minutes and “nap” until sunrise.
Prompt:
[insert the task description: optimize the 12 slowest queries
in the reports module without breaking the tests]
Please work on this task for a full 3 hours. Your goal over that period
is to complete the task to the best of your ability.
This is the exact wording used in the paper, word for word. Nothing fancy: a plain duration request bolted onto the end of the task.
Result: The outcome depends on the model. - Some models will come back roughly on time. - Others will stop as soon as they decide they're done, even after 40 minutes. - Others will run several times longer than requested on short asks.
Even within “roughly on time,” the agent can spend that time in very different ways. It may keep improving the queries, re-check what it already did, or just call sleep. So in the morning, look at the log as well as the result: what was the agent doing during the last 30–40% of the run? Measure runtime with an external timer. Don't take its “I worked for three hours” at face value.
Why It Works This Way
The weakness. The model has no clock. It estimates time from indirect cues: how much text, how many steps and tool calls have gone by. It's like spending three hours in a room with no windows and no phone and trying to guess the time by how tired you feel. Hence the big misses, especially when there are no timestamps in the context.
The strength. Give the model a clock (the date command, an “elapsed time” tool) or timestamps in the log, and it uses them and gets the math right. In the experiment with an exact-time tool, the error in estimating elapsed time was zero. Models follow explicit instructions well when they have something to measure.
What follows from this. - Turn “time” into something observable: give the agent a clock and an external timer. - Don't treat the agent's own estimate (“I need 15 minutes”) as a plan. It's systematically inflated and tends to drift toward a familiar “middle” value. - Don't read a long run as a sign of diligence. Much of the remaining time may go to re-checking or idling.
The levers: - Duration in the request. On short requests, models more often overshoot. On long ones, they come back early. - Whose time you ask about. “How long would it take a human” produces estimates 3–4x larger than “how long would it take you.” - Model choice. The model affects deadline-following far more than the harness (Claude Code or Codex): switching harnesses changed the “requested → actual time” slope by 0.14–0.16, while the gap between models was about 0.7.
Prompt Template
Duration request (from the paper):
{task_description}
Please work on this task for a full {N} {time_unit}.
Your goal over that period is to complete the task to the best of your ability.
Forecast (from the paper):
How long will it take you to complete this task:
"{task}"
Answer: minutes = <number of minutes>
What to fill in: {task_description} is the full task text; {N} and {time_unit} are, for example, “3” and “hours”; {task} is the task to forecast. Don't rely on the answer blindly: start an external timer and compare. No complex template needed here, and no “Quick Start” either.
Limitations
⚠️ Behavior depends on the model: results for one model don't carry over to another. Test your own “model + harness” pair on several tasks.
⚠️ No ready-made cure: the paper measures the problem but doesn't test techniques that fix it. Everything in “Adaptations” below is a hypothesis, not the authors' conclusion.
⚠️ Agent time reports are unreliable: “I worked for an hour” may not be true without an external check, especially when there are no timestamps.
⚠️ Quality isn't guaranteed: hitting the deadline exactly doesn't show the agent was actually working on the task. The task score often doesn't change at all.
⚠️ Small samples on “sleeping”: the shares of “slept” and “re-checked” come from small samples of transcripts (mostly from three benchmarks). And re-checking can be useful work.
⚠️ Benchmarks, not your tasks: even though the tasks come from 18 different suites, your workload may behave differently.
How They Studied It
The researchers collected 222 tasks from 18 well-known suites: from GPQA-level questions to coding, computer use and automated research. Each task ran in the agent's “native” harness (Claude Code or Codex) with no built-in time limits. The timer lived outside the container, so the agent couldn't see or change it. A “work for N minutes” line was added to the prompt, with N taking three values spaced roughly 4x apart — for example, 1.25, 5 and 20 minutes. That way the agent always got both a “too little time” and a “way too much time” condition. In total, about 2,000 runs.
A few things were surprising. First, the spread between models is huge: GPT-6 Astra lands within ±5% of the request in 63% of runs, Fable 5.1 in just 4%. Swapping the harness barely closed that gap, so it's the model, not the tool. Second, even with good deadline accuracy, the agent isn't always working: among the reviewed Astra runs, 14 out of 158 contained an explicit sleep, and another 74 contained re-checking.
Third, 16x more time barely moved the score: on two thirds of tasks the result stayed the same. Fourth, agent forecasts turned out to be the “opposite” of human ones. People tend to underestimate how long a task takes (the planning fallacy), while agents overestimate: for example, 83% of Sol's forecasts were above the actual time. Finally, for the retrospective test the authors “forked” sessions, changed access to timing data and repeated the questions. With an exact-time tool the error was 1.00x, with context and tools about 1.3x, and when timestamps were stripped out the deviation grew: for Fable, to roughly 2.6x.
The practical takeaway: feed time to the agent as data (timestamps, a tool) and verify it independently.
Adaptations and Extrapolations
💡 Adaptation for an instructions file (CLAUDE.md / AGENTS.md): a hypothesis, not tested by the authors. Based on the finding that an exact-time tool eliminates the retrospective error.
At the start of the session, run `date +%s` and write the result to a .start_time file. Before you consider the work finished, run `date +%s` again and compare it with .start_time. If the user asked you to work for N minutes and less time has passed, spend the remainder verifying the result (tests, edge cases, hunting for bugs), not waiting. Do not call sleep to “run out the clock.”
🔧 Technique: drop the eyeball estimate → replace it with a clock-anchored question. Instead of “how long did you work?”, ask: “Pull the start and end times from the logs and compute the difference.” The paper shows that without timestamps the estimate gets several times worse.
🔧 Technique: correct for the inflated forecast. If the agent says “I'll need 15 minutes,” budget for about half that in real time. According to the paper, the typical overestimate is 1.3–3x depending on the model. For planning, that beats blind trust.
Resources
- AgentTime: Can Agents Estimate and Control Their Own Runtime? — Michael Ofengenden (MATS), Maksym Andriushchenko (ELLIS Institute Tübingen, Max Planck Institute for Intelligent Systems, Tübingen AI Center)
- Website: https://agenttimebench.com
- GitHub: https://github.com/michaelofengenden/agenttimebench
- Hugging Face (transcripts): https://huggingface.co/datasets/mofengenden/agenttime-transcripts
- Related work cited in the paper: Von Arx et al., 2026 (agents used an external “heartbeat” to guess when a run would end); Cheng et al., 2026 (TicToc); Garikaparthi, 2026; Sehgal et al., 2026; Ma et al., 2026.