How long AI agents wait for people: the 2026 data

Agents now work for minutes at a stretch and then stop for a person. In Microsoft Research's study of sampled GitHub Copilot agent traces from June 2026, the median user idle time between turns was 25.2 minutes (idle intervals that span a turn boundary, measured per resource, have medians of 243 and 172 seconds), and at Anthropic, staff sessions were about 80% idle waiting for human input.

Acting on an alert can be quick. In a 2007 Microsoft Research field study, 40.8% of email alerts and 71% of instant message alerts drew a switch to the alerting app within 15 seconds. The rest took 7 to 9 minutes on average. Much of the wait is the alert sitting unseen, so the fix is to put the question where the person already is, and to follow up only when it is missed.

Key numbers

Every row is public. All sources were read on Nov 13, 2026.

Agents work longer before they stop

Most Claude Code turns are short. Anthropic puts the median at around 45 seconds, and says it stayed between 40 and 55 seconds over recent months. The tail is where it changed: "Between October 2025 and January 2026, the 99.9th percentile turn duration nearly doubled, from under 25 minutes to over 45 minutes."

People also run more of them at once. The Codex paper found that in the week before June 11, 2026, more than 10% of users ran three or more concurrent Codex agents at some point. At OpenAI itself, on June 11, 2026, the median employee had Codex turns running for 2.5 hours that day.

METR's time horizon research is often quoted here, so a caution. It measures the length of tasks, "measured by how long they take human professionals," that frontier agents complete "with 50% reliability," and in March 2025 it found that length doubling approximately every 7 months. That is how long the task would take a person, not how long an agent runs. METR also marks parts of that post as out of date.

Why agents stop

Anthropic classified why Claude Code stops itself, from a sample of 500k completed turns:

Most of those are real questions. "Option A or B" and "what is the staging URL" need someone who reads the question and types an answer. Clicking Allow does not cover them. Anthropic's summary of the study says that "on the most complex tasks, Claude Code stops to ask for clarification more than twice as often as humans interrupt it," and the same post adds its own caveat: "Claude may not be stopping at the right moments, it may ask unnecessary questions."

Most of a session is waiting

Anthropic's employment study measured idle time "by subtracting each agent's active working time from each interactive session's total wall-clock time." The result: "Claude sessions amount to around 80% idly waiting for human input." That is Anthropic's own staff, a company of heavy users, so read it as one company and not as every agent session.

The Microsoft Research paper on Copilot is the largest public dataset. It analyses a sampled subset of one week of traces, and its sentence is: "The median user idle time is 1,512 s (25.2 minutes), with a long tail extending beyond one day (users picking up an unattended session the next day)." The authors describe these gaps as times when "the agent waits for user input before continuing the workflow." The same section gives a second, shorter view. When idle intervals are measured per resource and split at turn boundaries (Table 8), the ones that cross a turn boundary have medians of 243 s for containers and 172 s for KV caches, and more than 90% of idle intervals sit inside a turn, with medians of 5.8 s and 1.2 s. So read 25.2 minutes as the paper's figure for user idle time between turns, with that table beside it. Either way it counts every gap between turns, including reading the output, thinking, and walking off because the work was done. It is not only approvals.

The Codex paper points the same way from its methods section. It drops gaps over 30 minutes from runtime because they "predominantly reflect periods during which Codex is awaiting user input."

Approval prompts: mostly yes, and attention fades

When the stop is a permission prompt, the answer is almost always yes. Anthropic said users accept 93% of prompts (March 2026) and later 97% (August 2026), without a published method for either. The same August article says people reject 39% of plans but only 3% of individual permission requests.

Attention drops as the prompts pile up. In Anthropic's controlled test with 1,053 paid testers, people caught 13.6% of dangerous commands overall, and the block rate fell from about 17% early in a session to about 5% after 50 or more prior prompts. Anthropic also says that in its internal usage, sandboxing cut permission prompts by 84%.

The lesson is to ask fewer, better questions and send the ones that matter to the person. More on that in Claude Code approval fatigue.

What waiting costs the person

What the research does show:

• Some alerts pull you away for hours. Iqbal and Horvitz logged 27 people at Microsoft for two weeks. "On average, 27% of the alerts resulted in users being diverted from these prior active windows for more than 2 hours into the resumption phase."
• Getting back into code takes a while. Parnin and Rugaber looked at 10,000 recorded programming sessions from 85 programmers and found "only 10% of the programming sessions have coding activity start in less than a minute."
• Interruptions cost stress more than time. In a lab study with 48 people, Mark, Gudith and Klocke (CHI 2008) found that people "completed interrupted tasks in less time with no difference in quality," but with "more stress, higher frustration, time pressure and effort."

Phones are fast, not instant

Pielot and colleagues logged 24 Android users for two weeks and 6,423 notifications from messaging apps such as SMS and WhatsApp. "A participant attended to a message within a median delay time of 6.15 minutes." Attending meant opening the notification drawer or the messaging app. Half the messages waited longer than that before the person looked.

The Iqbal and Horvitz data shows a split. 40.8% of email alerts drew an immediate switch to the email app (under 15 seconds), with a mean of 2 seconds for those. 71.01% of instant message alerts did too, at a mean of 1.72 seconds. For the rest, the switch came 7 min 32 s later on average for email and 8 min 48 s for instant messages. These measure switching to the app, not answering.

Put those together and the shape is plain. An alert that is noticed at once gets acted on within seconds. The minutes go to alerts that sit where nobody is looking.

What this means for your setup

• Put the question where the person is. For most people away from the desk, that is the phone, with the question text in the notification so they know which agent needs them.
• Let rules answer the routine ones. With 97% of permission prompts approved, most should never reach a person. Save attention for the few that matter.
• Follow up only when the question is missed. A single push can sit unseen for minutes, so the second try should be louder and rare. Pushary does this with a phone call when the push is still unanswered after your Call after time (2 minutes by default for Claude Code, 1 minute for Codex), only inside your calling hours (08:00 to 22:00 by default), at most 5 in any 24 hours by default, and only as a beta: numbers in Germany, calls in English, for supported agents including Claude Code and Codex. See Claude Code phone call.
• Keep a record. If rules decide most stops, someone needs to be able to see what was decided and by whom.

Methodology and sources

What counts: public sources with a date, a stated method and a stated sample. Figures are quoted as the source states them, with nothing rounded up. Where a vendor gives a number without a method, the table says so. All sources were opened and read on Nov 13, 2026.

What is left out: Pushary's own answer-time data (not published), figures we could not open and read ourselves (JetBrains developer surveys, OpenAI's claim that GPT-5-Codex works on its own for more than 7 hours, clinical alert-fatigue override ranges), and push open rates from marketing benchmarks, which measure a different kind of notification.

Sources:

1. Liu, Qiu, Goiri, Fonseca, Bianchini, Choukse. Agentic Coding in the Wild: Characterizing GitHub Copilot at Production Scale. Microsoft Azure Research and UIUC, Aug 2026. https://www.microsoft.com/en-us/research/wp-content/uploads/2026/08/ghcp_traces-6.pdf
2. Wilmers, Catipon, Massenkoff, McCrory. How employment is changing at Anthropic. Anthropic, Oct 16, 2026. https://www.anthropic.com/research/employment-at-anthropic
3. Measuring AI agent autonomy in practice. Anthropic, Feb 18, 2026. https://www.anthropic.com/research/measuring-agent-autonomy
4. Johnston, Holtz, Richmond, Ong, Tambe, Chatterji. The Shift to Agentic AI: Evidence from Codex. arXiv 2606.26959, Jun 25, 2026. https://arxiv.org/abs/2606.26959
5. How we built Claude Code auto mode. Anthropic Engineering, Mar 25, 2026. https://www.anthropic.com/engineering/claude-code-auto-mode
6. Auto mode is now the default in Claude Code. Claude, Aug 7, 2026, updated Oct 22, 2026. https://claude.com/resources/articles/auto-mode-default-in-claude-code
7. Beyond permission prompts: making Claude Code more secure and autonomous. Anthropic Engineering, Oct 20, 2025. https://www.anthropic.com/engineering/claude-code-sandboxing
8. Measuring AI Ability to Complete Long Tasks. METR, Mar 19, 2025. https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/
9. Mark, Gonzalez, Harris. No Task Left Behind? Examining the Nature of Fragmented Work. CHI 2005. https://www.ics.uci.edu/~gmark/CHI2005.pdf
10. Robison. Too Many Interruptions at Work? Interview with Gloria Mark. Gallup Business Journal, Jun 8, 2006. https://news.gallup.com/businessjournal/23146/Too-Many-Interruptions-Work.aspx
11. Mark, Gudith, Klocke. The Cost of Interrupted Work: More Speed and Stress. CHI 2008. https://www.ics.uci.edu/~gmark/chi08-mark.pdf
12. Iqbal, Horvitz. Disruption and Recovery of Computing Tasks: Field Study, Analysis, and Directions. CHI 2007. https://www.erichorvitz.com/CHI_2007_Iqbal_Horvitz.pdf
13. Parnin, Rugaber. Resumption Strategies for Interrupted Programming Tasks. ICPC 2009. https://sites.cc.gatech.edu/reverse/repository/resumptionstrategies.pdf
14. Pielot, de Oliveira, Kwak, Oliver. Didn't You See My Message? Predicting Attentiveness to Mobile Instant Messages. CHI 2014. https://www.ic.unicamp.br/~oliveira/doc/CHI2014_Didnt-you-see-my-message.pdf

Last checked: Nov 13, 2026.