StateAct: Program State, before Pixels, for Long-Horizon Computer-Use Agents
Abstract
Computer-use agents are usually improved by strengthening perception: better models for reading a screenshot and choosing where to click. Yet a screenshot is only a lossy rendering of the underlying program state, e.g., the files, application backends, and DOM that hold the task data. Different states can produce the same pixels, while code can inspect and modify that state directly. StateAct is a code-first, multi-agent harness built around this distinction. Its main agent works directly with program state by using code, while a dedicated GUI subagent handles screenshot-and-click interaction on the few subgoals that need it, just 28 of 108 tasks and 1.1% of main-agent steps. The same direct access to program state also supports verification: an independent finish gate double-checks the saved result for structural failures, e.g., output that is missing, unsaved, or written to the wrong path. To stay on track over hundreds of steps, the main agent hands subgoals to fresh subagents, keeping its own context focused. On OSWorld 2.0, StateAct lifts Claude Opus 4.8 from 20.6% to 26.9% on binary success, and from 54.8% to 61.6% on partial success, at ~ 9x lower cost per task than the same model driven by screenshots alone; a code-only variant with no GUI subagent reaches only 45.9% partial, below that screenshot-based baseline's 54.8%. In general, grounding action, verification, and memory in state, what we call state-grounding, shifts the main bottleneck from perception toward reasoning: failures depend more on what the agent thinks than on what it sees.
Community
๐จ We just set a new SOTA on OSWorld 2.0!
โญ๏ธ And we did it by making our computer-use agent look less, not more.
Everyone's racing the same way: better vision, sharper screen-reading, more pixels. We went the opposite direction. StateAct barely looks at the screen at all.
The insight nobody wanted to say out loud: a screenshot is a lie. It's a lossy picture of what actually matters, the files, backends, and DOM behind the glass. Pixels can't tell them apart. Code can.
So we made program state the primary interface, and call a GUI specialist only when a subgoal is truly visual, just 1.1% of steps.
The result, on the exact same Claude Opus 4.8:
๐ฅ Binary: 20.6 -> 26.9%
๐ฅ Partial: 54.8 -> 61.6%
๐ธ ~9ร cheaper: ~$7.8 vs ~$72/task, 224K -> 100K tokens
The same harness lifts Opus 4.8 across 5 benchmarks:
๐ OSWorld-Verified 80.9 -> 81.9
๐ WindowsAgentArena 41.6 -> 50.6
๐ AndroidWorld 69.0 -> 81.9
๐ MobileWorld 51.3 -> 70.1
And it's not tied to Claude. Drop in our internal 31B SFR-CUA and it leaps across the board:
๐ OSWorld 2.0 7.6 -> 43.2
๐ OSWorld-Verified 66.9 -> 81.1
๐ WindowsAgentArena 40.9 -> 51.2
๐ AndroidWorld 68.1 -> 84.1
๐ MobileWorld 48.7 -> 68.4
A small model, punching far above its weight.
๐ก Computer-use was never only about vision. It's an agent reasoning problem, tying together what it sees, the state it acts on, and the plan it holds across hundreds of steps.
Get this paper in your agent:
hf papers read 2607.22798 Don't have the latest CLI?
curl -LsSf https://hf.co/cli/install.sh | bash Models citing this paper 0
No model linking this paper
Datasets citing this paper 0
No dataset linking this paper
Spaces citing this paper 0
No Space linking this paper
Collections including this paper 0
No Collection including this paper