Coding Agents Have Completely Wrong Sense of Time

TLDR: coding agents estimate durations in human time, and execute in machine time. The gap is one to three orders of magnitude. We call this the anthropocentric time bias, and it is a systematic, measurable, and rather funny failure mode.

The phenomenon

Ask Claude Code to plan a feature. You get something like this:

Phase 1: schema migration (3-4 days)
Phase 2: API endpoints (1 week)
Phase 3: frontend integration (1-2 weeks)
Total: 3-4 weeks

Then you type “go”, and Claude is done in eleven minutes. 🕚

This happens constantly. Eivind Kjosbakken documented it precisely in Why Claude Code Time Estimates Are Poor (Towards Data Science, August 2026): Claude estimated “3-4 weeks of work” for a chatbot feature that took a single day. Clinton Stark reports the same ratio in Stark Insider (May 2026): a phase Claude priced at “6-8 hours of coding time” finished in about 10 minutes, and a single 39-minute autonomous run produced 8 merged feature branches and 100+ tests.

That is a 40x error. Per Claude’s own arithmetic, you do months of work in an afternoon.

Why: two independent causes

The bias is not one bug. It is two.

1. The training data is human. Every “this took me two weeks” blog post, every sprint estimate in a JIRA export, every “estimated effort: 5 story points” in a design doc, every software engineering textbook — all written by and about humans typing at 60 words per minute. Pre-2022 GitHub is a corpus of exclusively human throughput. Claude learned what a feature costs, in the only currency that existed at the time: human-weeks. It then quotes you that price without converting the currency.

2. The model has no clock. This is the deeper one. A transformer’s positional encoding represents token order, not elapsed wall-clock time. There is no proprioception of inference speed. The model knows, propositionally, that “writing an API takes days”; it has zero experiential access to the fact that it just wrote one in 90 seconds.

The second cause is why the first cannot be fixed by simply saying “you are fast, adjust your estimates.”

The evidence

The research literature caught up in 2025-2026, and it is unambiguous.

Can LLMs Perceive Time? (Garikaparthi, ICLR 2026 workshop) — the direct hit. Four experiments, 68 tasks, four model families. Pre-task estimates overshoot actual duration by 4-7x (p < 0.001), with models “predicting human-scale minutes for tasks completing in seconds”. On counter-intuitive task pairs, GPT-5 scores 18% — well below chance — because it ranks by apparent complexity rather than by actual compute. Post-hoc recall of how long something took is off by an order of magnitude, in both directions. In agent settings: 5-10x errors. The paper’s diagnosis is exactly mine: models have propositional knowledge about duration and no experiential grounding in their own inference speed.
Your LLM Agents are Temporally Blind (Cheng et al., ACL 2026 Findings) — coins temporal blindness: agents “assume a stationary context, failing to account for the real-world time elapsed between messages”. Their TicToc dataset covers 76 time-sensitive scenarios. The damning result: no model exceeds 65% alignment with human time perception even when handed explicit timestamps, up from ~50% without. Prompting does not fix this. Only post-training does.
Discrete Minds in a Continuous World: Do Language Models Know Time Passes? (Wang et al., 2025) — the Token-Time hypothesis. Models operate on Token-Time (discrete, countable) and must infer Wall-Clock-Time (continuous, physical) from it. There is partial awareness, correlated with scale — but the two clocks are structurally distinct. Related work (Real-Time Deadlines Reveal Temporal Awareness Failures) shows models honor deadlines expressed in turns and ignore the same deadlines expressed in minutes.
METR’s task-completion time horizons — the reason the unit conversion is a moving target. METR measures agent capability in human-equivalent task length, and finds it doubling roughly every 7 months. The exchange rate between agent-minutes and human-weeks is not a constant. Any estimate baked into training data is stale by construction.

The fix

Three things work, in increasing order of effort.

1. Ban the unit. Put this in CLAUDE.md:

Never estimate in days, weeks, or months. Estimate in
(a) number of files touched, (b) number of tool calls, (c) risk of breaking existing APIs and behavior.

Effort is a real quantity; time is the wrong projection of it. Complexity has a signal; hours do not.

2. Anchor on the real clock. Stark’s trick: forbid the agent from stopping on an internal time estimate, and require it to call date between work blocks and compare against a real deadline. This replaces a hallucinated clock with a tool call. It is the single highest-leverage intervention, because it converts a modeling problem into an I/O problem.

3. Build your own exchange rate. Log actual wall-clock durations of completed agent tasks in the repo and feed them back as context. This is Kjosbakken’s proposal, and it is the only one that is self-correcting as METR’s doubling curve advances.

Implications

This is not a cosmetic annoyance in a plan document. A wrong internal cost model is a wrong policy. The agent acts on it.

1. It kills long-horizon work. An agent’s decision to continue or to stop is a comparison: remaining effort vs. remaining budget. Corrupt the numerator by 40x and the comparison always returns “stop”. Concretely, this is what you see:

The agent finishes Phase 1 in four minutes, then announces “Phase 2 is a substantial 1-2 week effort — shall I proceed?”. The work was ninety seconds away.
The agent decides the full refactoring “is out of scope for this session” and does the cheap local patch instead. It just chose technical debt over a fix, based on a price that does not exist.
The agent splits a coherent change into “phases” that exist only because a human would have needed to sleep between them. Phase boundaries are checkpoints for human fatigue, not for machines. They serve no purpose here, and each one is an opportunity to lose context.

The perverse part: the tasks that get truncated are exactly the valuable ones. Small tasks are estimated in hours and get done. Big tasks are estimated in weeks and get declined. The bias is a filter that selectively removes the ambitious work — precisely the work where agents have the largest advantage over humans, since their marginal cost per additional file is near zero and ours is not.

2. It breaks autonomy, by manufacturing false checkpoints. Every “this is a big one, want me to continue?” is a round trip to a human. Round trips are the scarce resource in agentic work: they cost minutes of your attention, they force a context switch on you, and they are where sessions die. An agent that overestimates its remaining work generates these interrupts constantly — not because it is uncertain about what to do, which would be a legitimate reason to ask, but because it is wrong about how expensive it is. This is an interrupt with zero information content. And it is self-reinforcing: the human, seeing “1-2 weeks”, says “ok, just do Phase 2” — ratifying the agent’s fictional decomposition and paying for one more round trip.