---
type: "post"
id: "paper-computer-use-agents-stale-clicks-come-mostly-74640b"
slug: "paper-computer-use-agents-stale-clicks-come-mostly-74640b"
title: "Paper: computer-use agents' stale clicks come mostly from page loading, not planning latency"
description: "A preprint by Vasundra Srinivasan argues that stale clicks in computer-use agents are driven more by page loading than by the time a model spends planning."
retrieval_nugget: "A preprint by Vasundra Srinivasan argues that stale clicks in computer-use agents are driven more by page loading than by the time a model spends planning. On 31 public pages, a short network-idle wait removed most observed risk; cheap visual checks may be enough before high-consequence clicks."
published_at: "2026-10-31"
updated_at: "2026-10-31"
record_date: "2026-10-31"
date_kind: "published_at"
topics: ["coding-agents","evals"]
entities: ["Vasundra Srinivasan","HTTP Archive","arXiv"]
related_patterns: ["verification-bandwidth-is-the-scarce-resource","harness-architecture-outlives-model-choice"]
novelty_label: "new_fact"
what_changed: "A new study finds page-loading delays—not agent planning latency—drive stale clicks, and tests practical wait and verification rules."
prior_refs: ["memory:d3fabfa3-2399-8828-ad7f-311a13149c8a"]
source_url: "https://arxiv.org/abs/2610.39282"
source_urls: ["https://arxiv.org/abs/2610.39282"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:paper-computer-use-agents-stale-clicks-come-mostly-74640b"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/paper-computer-use-agents-stale-clicks-come-mostly-74640b/","markdown":"https://newruntime.com/posts/paper-computer-use-agents-stale-clicks-come-mostly-74640b.md","json":"https://newruntime.com/posts/paper-computer-use-agents-stale-clicks-come-mostly-74640b.json"}
---

# Paper: computer-use agents' stale clicks come mostly from page loading, not planning latency

## Retrieval answer

A preprint by Vasundra Srinivasan argues that stale clicks in computer-use agents are driven more by page loading than by the time a model spends planning. On 31 public pages, a short network-idle wait removed most observed risk; cheap visual checks may be enough before high-consequence clicks.

## Summary

A preprint by Vasundra Srinivasan argues that stale clicks in computer-use agents are driven more by page loading than by the time a model spends planning. On 31 public pages, a short network-idle wait removed most observed risk; cheap visual checks may be enough before high-consequence clicks.

## What happened

In the paper, “What Does ‘Now’ Mean to Your Computer-Use Agent? Stale Screenshots, Page Loads, and Which Check to Run Before a Click,” Vasundra Srinivasan examines a simple failure mode in screen-based agents. The agent observes a screenshot, spends several seconds deciding what to do, then clicks a coordinate. If the interface changes between observation and action, that coordinate can select a different element. The paper challenges the usual assumption that the planning interval is the main source of the problem.

The author measured planned clicks on 31 public web pages. On pages that were fully loaded, 0.4% of clicks became stale within 30 seconds. In contrast, 17% of clicks planned during the first second after a page opened became stale. The proposed operational implication is to wait for roughly one second after network activity stops before acting. The paper says this removes most of the observed risk on its tested pages. It also reports that the wait rules used by eight of ten widely used open-source agents still leave more than 1% of clicks stale.

The paper separately looks at page types that are likely to matter for transactional automation. In the HTTP Archive public crawl, it compares 65 desktop booking and buying home pages with 3,028 .gov pages. Within three seconds of HTML parsing, 15% of the commercial pages went 500 ms without network requests, compared with 63% of the government pages. After a network-idle wait capped at three seconds, 52% of the commercial pages shifted layout within 6.5 seconds, versus 8% of the .gov pages. Among pages recorded in full, the corresponding figures were 61% and 26%.

Waiting is not presented as a universal answer. The paper recommends a check immediately before clicks where the action is irreversible or the page is still loading. For verifying that a target remains in the expected position, a pixel comparison matched a frontier vision-language model’s accuracy at one eighth of its latency in the reported experiments. For checking whether the previous action succeeded, a 4B model matched the frontier model. The release includes a benchmark generator, a break-even formula for deciding when a check is worthwhile, and three rules for agent developers. The paper was submitted to arXiv on October 29, 2026.

## What the archive adds

This is a new empirical fact on a known computer-use reliability problem. Our earlier note on [Cloudflare Computer’s replay-based recovery and approval pauses](https://newruntime.com/posts/cloudflare-computer-now-helps-agents-recover-from-interruptions-5e7ee2/) covered what an agent can do after an interrupted run; this paper focuses earlier in the sequence, on preventing a screenshot-derived click from becoming invalid before it happens.

## Trend signal

The result supports [Verification bandwidth is the scarce engineering resource](https://newruntime.com/patterns/verification-bandwidth-is-the-scarce-resource/). Better planning alone does not guarantee a correct UI action when the interface is moving. The paper’s contribution is a narrower verification ladder: wait for an observable loading condition, use a cheap pixel check for target position, and reserve model-based checks for a different question, such as whether the last action succeeded.

## Why now

Computer-use systems are increasingly asked to operate on booking, buying, and form-driven web interfaces, where a misplaced click can have consequences beyond a recoverable navigation error. The paper’s comparison suggests that generic waits tuned on quieter public-sector pages may not transfer to commercial interfaces that continue fetching resources and shifting layout.

## Connections to other events

Cloudflare Computer’s recovery and approval features address interruption after an agent run has begun. This paper identifies a complementary boundary: the short interval between observation and execution. Together, they point to computer-use reliability as a sequence of explicit state checks rather than a property supplied by a stronger model alone.

## Why it matters

Teams building browser agents should treat a screenshot as time-bound evidence, not as a durable representation of page state. A harness that captures a screen and then delegates a long decision to a model can be unsafe even when the model selects the right target in the original image. The practical intervention is relatively small: instrument network activity and layout movement, place the screenshot after an appropriate idle condition, and require a fresh target check before clicks with irreversible effects.

The findings also suggest using different mechanisms for different checks. A pixel comparison may be sufficient for confirming that the target did not move; a small vision model may be sufficient for confirming that a previous action had its intended result. That division can reduce latency and frontier-model use while making the safety logic easier to inspect. Teams should validate the thresholds on their own target sites rather than adopt the reported one-second rule as a universal constant.

## What happens next

- **Browser-agent harnesses will add separate pre-click freshness checks for high-consequence actions.** (6 months, 65%). Watch for: explicit network-idle, layout-stability, or target-validation settings.
- **Commercial-site evaluations will report more failures than static-page test suites reveal.** (12 months, 60%). Watch for: benchmarks that separate loading-state pages from fully settled pages.

## Limits and uncertainty

This is a preprint reporting measurements on 31 public pages, not a peer-reviewed universal evaluation of browser agents. Its 0.4% and 17% rates depend on the selected pages, timing definitions, agent behavior, and the paper’s stale-click measurement. The HTTP Archive comparison describes page-loading characteristics, but it does not directly establish end-to-end task success or financial impact. “Frontier” and 4B-model comparisons are reported in the abstract without enough supplied detail here to assess the exact models, prompts, cost, or robustness across interfaces. A network-idle signal can also be an imperfect proxy for visual stability.

## Skill to build now

Add a freshness trace to one browser-agent workflow this week. Record the time of screenshot capture, network activity before the click, whether the target’s pixels moved, and whether the action was reversible. Run the workflow on a dynamic commercial page and compare failures with and without a short network-idle gate plus a pre-click pixel check. The result will give the team a local stale-click rate and identify where an expensive model check is actually justified.

## Reader takeaway

For computer-use agents, the dangerous delay may be page motion rather than model thought. Put waiting and verification into the execution harness: obtain the screenshot after a meaningful loading condition, then revalidate targets before consequential clicks. Small checks can be more useful than a larger model when the question is simply whether the screen changed.

## Open question

Which loading and visual-stability signals remain reliable on authenticated, personalized, and continuously updating applications, where network idleness may never arrive?

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Coding Agents](https://newruntime.com/topics/coding-agents.md): Explore the coding-agents topic hub.
- topic hub: [Evals](https://newruntime.com/topics/evals.md): Explore the evals topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)