DeltaReplay's similarity router gains up to 25 points by deciding when a stored route still applies; phoneshell's macro store has no such decision, only an exact name lookup

DeltaReplay gains 10.3 points on AndroidWorld and 25.0 on SPA-Bench over the same backbone's base agent, entirely from deciding, per step, whether a stored route matches a new task closely enough to replay outright, replay with swapped parameters, or hand off to the model. phoneshell already stores and replays action sequences of its own, but the only way one ever runs is by a caller naming it exactly. Nothing in the code asks whether a new task looks like a saved one.

DeltaReplay: Task-Relative Memory Reuse for Mobile GUI Agents (arXiv:2610.11707, Bai, Chen, Yao, Wang, submitted 8 October 2026) tackles a specific failure of memory-augmented GUI agents: stored successful trajectories rarely match a new task exactly, so forcing one in misleads the agent and discarding it wastes a route the agent already found. DeltaReplay stores trajectories as a transition graph, pages as nodes and actions as edges, with each action split into a task-independent operation and task-specific parameters. At reuse time it compares a recorded step against the new task and the live screen and picks one of three routes: Route A, replay the step as recorded; Route B, re-ground it by swapping in new parameters; or Route C, discard the memory and defer to the base agent entirely. On AndroidWorld-116 it lifts Qwen3-VL-30B from 43.1% to 53.4% (+10.3 points) and Qwen3.8-Flash from 49.1% to 56.9% (+7.8 points); on SPA-Bench-60 it lifts the same two backbones from 23.3% to 48.3% (+25.0 points) and from 41.7% to 58.3% (+16.6 points).

What the router gains, and what it costs to decide wrong

DeltaReplay's Table 2 reports success rate and latency per step for both backbones on both benchmarks, plus three prior memory-reuse baselines, GUI-explorer, RAG-prompting, and GUI-Owl's own built-in memory, none of which beat the base agent by more than a few points and one of which, RAG-prompting, scores below the base agent outright (41.4% versus 49.1% for Qwen3.8-Flash on AndroidWorld). The gain is concentrated in how often the router gets the route right: on 150 sampled steps, 50 per route, DeltaReplay's own precision was 83.7% for Route A (replay), 78.0% for Route B (re-ground), and 75.5% for Route C (discard). Table 7 breaks down which route actually fires by how closely the new task matches stored memory: when the task matches an existing memory exactly, 56.1% of steps replay outright and the rest discard, with zero re-grounding needed; when it only matches the same app with no closer template match, the router discards 89.9% of the time and almost never tries to force a stored step in.

Source: arXiv:2610.11707, Table 2, success rate by backbone and benchmark, read 29 October 2026.

What phoneshell's own macro store does when a task is close but not identical

phoneshell already has the mechanism DeltaReplay is routing between, in a simpler form. agent/macros.py states its own payoff plainly: "merging a verified sequence of steps into one replayable unit is worth roughly twenty points of task success on repeat work and cuts token use by most of an order of magnitude." Its safety mechanism is an anchor, a piece of text that must be on screen before each step fires; if the anchor is missing, "the macro stops and hands the screen back to the model," which is phoneshell's version of DeltaReplay's Route C. Its Macro dataclass even has a inputs field for exactly DeltaReplay's Route B idea, swapped parameters, for example a saved dish name a step can refer to as {dish} with a different value passed at run time.

What is missing is the part that makes DeltaReplay's gain possible: a way to decide, automatically, that a new task is close enough to a stored one to be worth trying at all. agent/macros.py's own lookup function is get(name), a dictionary read by exact string. A repository-wide search for anything that compares a new task's description against a stored macro's name, description or bundle id finds nothing: no embedding, no fuzzy string match, no template graph. Whatever decides a macro is relevant to the current task has to already know its exact name ahead of time, which in practice means a human or the calling code chose it, not the agent reasoning about similarity. DeltaReplay's own coverage-group table shows exactly where that gap bites: its "same template" row still replays 41.5% of steps outright and re-grounds another 14.8%, work phoneshell's exact-name lookup cannot attempt because it never gets to the question of whether a near-match exists.

What it means for a macro store that already has the primitives

• phoneshell is not missing the replay primitive or the parameter-substitution primitive; inputs and anchor-gated replay already do the job of DeltaReplay's Route A and Route B once a macro has been selected. What is missing is everything upstream of that choice: a way to ask "is there a stored macro close enough to this new task to be worth trying," the question DeltaReplay's router answers per step with 75 to 84 percent precision.
• DeltaReplay's own numbers warn against assuming the fix is free: Route C, discard, still carries 75.5% precision, meaning roughly one in four discard decisions in its own sampled set was arguably wrong, either a route that should have fired or one that should not have. A similarity router added to phoneshell's macro store would inherit the same risk of wrong calls, not just the gain.
• DeltaReplay measures its backbones on AndroidWorld-116 and SPA-Bench-60, Android benchmarks with Android app sets; the percentage-point gains quoted above do not transfer directly to phoneshell's 80 iOS tasks. What transfers is the mechanism gap: phoneshell's macro store currently cannot benefit from a near-match at all, on any platform, because nothing in it looks for one.

Check it yourself

# phoneshell's own stated payoff for macro replay
sed -n '1,12p' phoneshell/agent/macros.py

# the only macro lookup function that exists, by exact name
grep -n "^def get" -A6 phoneshell/agent/macros.py

# confirm there is no similarity or fuzzy-match code for macro selection
grep -rln "difflib\|embedding\|similarity\|fuzzy" --include="*.py" phoneshell/agent/ || echo "no match"

# the inputs field that already supports DeltaReplay's "re-ground" idea
grep -n "inputs:" -A3 phoneshell/agent/macros.py

# DeltaReplay's own route-breakdown table
curl -s https://arxiv.org/html/2610.11707v1 | grep -iE "Table 7|Route A|Route B|Route C"

What would prove this wrong

We claim phoneshell's macro store has no code that measures similarity between a new task and a stored macro, and that get(name) is the only lookup path that exists. That is wrong the moment a similarity check, embedding comparison, or fuzzy match turns up anywhere in phoneshell/agent/, and the grep above is how to check. We also claim DeltaReplay's gains, up to 10.3 points on AndroidWorld and 25.0 on SPA-Bench, come specifically from the per-step routing decision rather than from the replay or parameter-substitution mechanisms phoneshell already has; that is a claim about the paper's own ablation design, not about phoneshell, and would be undermined by a version of the paper showing the gain holds even with routing disabled. We will treat either a repository change adding macro-selection logic, or a later version of this paper isolating the routing decision's contribution more precisely, as grounds to revisit this piece by 30 April 2027.