GUIFlow — Cross-step KV reuse for GUI agents — What does it mean?
The news. On October 26, 2026, a new paper introduced GUIFlow, a method that retains computation across successive steps of multi-image GUI agents. It reports up to 3.39× geometric-mean speedup on offline benchmarks and 3.49× in closed-loop OSWorld, with task performance broadly comparable to dense inference. Read the paper →
Picture an editor who gets a fresh photo of the same floor plan every shift. The wasteful editor re-annotates the whole plan from scratch each time. A better editor keeps yesterday's notes, uses a highlighter to mark what moved, and rewrites only those notes. A GUI agent is in the same position: after each click, the screen is mostly the same as before.
In dense inference over a multi-image context, the model recomputes the whole context at each step. GUIFlow keeps the KV states from earlier steps and injects them into the current context. The stored states are position-aligned to the current context before they are injected. This is the same idea as prefix caching, but across the steps of one agent loop, where the new screenshot is not an exact match for anything cached.
The new screenshot is the hard part, because it is not an exact prefix match. The paper uses change signals to select which current-observation states to update, in both the vision encoder and the language model. Think of a click that opens a menu: most of the screen is the same, so most old states can stay. States the signals do not select keep their reused values. The exact signal and thresholds are not described in the source summary used here, so treat the details as the paper's to specify.
The second saving is on the output side. The action the agent produced last step becomes a draft for this step. The target model verifies the draft in one pass, as in speculative decoding, so no separate draft model is needed. The paper reports no additional training and no change to what the model sees as input.
| Approach | What is recomputed per step | Needs training or a draft model? |
|---|---|---|
| Dense inference | Every screenshot, every step | No |
| Prefix caching | Only the part after the first changed token | No |
| GUIFlow | Only the states of the newest screenshot that change signals select, plus verification of the draft action | No additional training or separate draft model, per the paper |
Here is a worked example with illustrative numbers. Suppose an agent is on step 8, holds 7 earlier screenshots at about 1,000 vision tokens each, and the new screenshot is also 1,000 tokens. Dense prefill reads 8,000 tokens. Now assume, purely for illustration, that the change signals select 15% of the new screenshot and everything else is reused: that is about 150 tokens of new work, so prefill work drops from 8,000 to about 150 tokens (hypothetical). The end-to-end gain is far smaller than that ratio, because decoding, the verification pass, and the remaining model work still run. That is why the paper reports up to 3.49×, not 50×.
The lesson reaches beyond GUI agents. Advancing a decision need not require rebuilding every supporting representation, which is the paper's own framing. It matters wherever an agent loop appends a little new state to a large, mostly stable context, as covered in context engineering. The risk is stale state: a missed change signal could leave an old state in place where the screen did change. The paper reports task performance broadly comparable to dense inference, not identical.
Goes deeper in: LLM Serving → Prefix Caching & RadixAttention → Why Full-Prompt Hashing Fails