A compiled GUI routine repays itself after 1.4 to 15.5 uses, and failed compiles took two thirds of the tokens; phoneshell records macros for free and has replayed one once

Ming, Xu, Wu and Jia put a price on the idea that a phone agent should stop re-deriving routes it already found. The per-use saving is near total. The cost is in the compiles that fail and the routines nobody reuses. We compared it with phoneshell's own answer, which costs nothing to make and checks less.

Turning a repeated GUI task into a program saves 93.6% to 99.9% of the agent's tokens on every later use, but the first program takes 1.39 to 15.5 uses to repay, and 9 of 20 compilation attempts produced nothing usable while consuming 67.7% of the compilation tokens. That is the measurement in PACE, posted on 2 October 2026. phoneshell avoids the compile cost entirely by recording sessions as macros. Its runtime holds one, with no post-step checks, replayed once in 785 logged actions.

What PACE measured

Yulong Ming, Jie Xu, Zihan Wu and Xiaohua Jia (City University of Hong Kong, arXiv:2610.02932) take seven task families: four from AndroidWorld (Contacts add, Markor delete, Calendar add event, OsmAnd marker), LibreOffice Calc and Writer tasks in an OSWorld-based container, and a WebArena Reddit comment. Three models, GLM-5.3-flash, DeepSeek-V4-flash-vision-exp and Qwen3.8-flash, each try to compile each family into a program from successful agent traces, giving 20 cells with records (Qwen's provider refused the web task). A program counts only if it passes 3 of 3 source tasks, with up to 3 refinements per task. Costs are in weighted tokens: one unit per uncached input token at the model's reference price.

The payback column is short because the per-use saving is nearly total. DeepSeek on Markor needs the most uses, 15.5, because its agent was already cheap at 10.8K a run. GLM on Calendar is expensive to compile, 3,424K, and still repays in 10.9 uses because the agent burns 314K per run. Compiled programs were also more reliable in the matched Android replays: GLM Calendar's agent succeeded 14 of 30 times against the program's 30 of 30. In a live OpenApps Calendar study the agent succeeded 7 of 12 times with mean cost bounded between 8.142 and 21.590 milli-USD; program plus fallback succeeded 11 of 12 between 1.202 and 4.564, and all 8 runs on a changed interface fell back to the agent, 7 successfully.

The cost the payback column leaves out

Only 3 programs passed before repair. Summing Table 1, successful first attempts used 8,924K weighted tokens and failed ones 18,743K. The paper's payback counts exclude that failed two thirds by construction, and a team choosing which families to compile does not know in advance which third it will land in: OsmAnd marker failed for all three models. PACE's online algorithm exists for exactly this, weighing estimated savings against compile cost including failures, inside a cumulative budget, and on recorded arrival traces it saved in 9 of 12 conditions. It lost to never compiling on all three Sepsis-log conditions. The headline figures, 17.3% against ReAct and 24.9% against an AutoRPA adaptation, are averages of ratios across those 12. The ToolPro figure equals the ReAct one because ToolPro never compiled in any tested condition.

phoneshell compiles for free and checks less

phoneshell's answer to the same problem is in agent/macros.py. A Recorder keeps the last 200 steps of a session; phone_macro_save writes them to YAML with no model call, so compilation costs zero tokens and payback starts at the first reuse, if the replay works. Each step can carry an anchor, text that must be on screen before it fires, and an expect, text that must be on screen after. A missing anchor stops the replay and hands the screen back to the model, which is PACE's fallback in another form.

What phoneshell does not do is PACE's verification. Nothing replays a macro against fresh inputs before it is saved, and the recorder fills expect only when a caller passes one. In the runtime directory on 5 October 2026 there is one macro, about-screen.yaml: open Settings, tap General, tap About, with anchors "", "Settings", "Settings" and three empty expects, runs: 1, failures: 0. The audit log from 7 September to 1 October 2026 holds 785 events, two macro names saved (about-screen, and an 8-step test-grab-order learned from a demonstration on 30 September, which is no longer in the directory) and one macro_run. The module's docstring says replay is "worth roughly twenty points of task success" and "cuts token use by most of an order of magnitude". It cites nothing. PACE's per-use saving supports the token half. Our usage supports neither, because the macros are not being reused.

What it means if you are deciding what to automate on a phone

• Count arrivals before building anything. With per-use savings above 93%, the only number that decides payback is how many times the task recurs before the app changes. A routine run once, like ours, never pays for any compile.
• Budget for failed compiles as the main cost. In PACE they were two thirds of spend, and the cheapest predictor of failure was the family, not the model.
• Recording is the cheap end of the curve, and it is only safe with a post-step check. With expect empty, a replay that lands on the wrong screen counts as a success. PACE notes the same risk from the program side: some drift failures reach a wrong state silently, which breaks the assumption that failures are detected.
• Keep the fallback. PACE's live study shows every changed-interface run handed back to the agent; phoneshell's anchor stop does the same thing and should stay.

Check it yourself

• Payback and costs: Table 1 and Table 5 of https://arxiv.org/abs/2610.02932; measurement records and policies at https://github.com/myl7/computer-use.
• The two-thirds figure: sum the 11 successful and 9 failed attempt costs in Table 1, python3 -c "s=[137,138,144,156,212,3424,3057,473,259,487,437];f=[605,2872,1936,3082,1701,1552,2544,3054,1397];print(sum(s),sum(f),round(sum(f)/(sum(s)+sum(f))*100,1))" prints 8924 18743 67.7.
• Where PACE lost: Table 3, Sepsis rows, where ReAct cost over PACE cost is below 1.
• phoneshell's macro format: phoneshell/agent/macros.py, classes Step, Recorder and function replay.
• Usage: grep -c macro_run runtime/logs/audit.jsonl prints 1; ls runtime/macros lists about-screen.yaml. The runtime directory is local to the rig, not in the repo.

What would prove this wrong

Our claim is that a recorded macro without post-step checks will sometimes succeed on paper and fail on the phone. Test: fill expect for every step from the recorded post-step screen, replay each saved phoneshell macro 30 times with varied inputs, and compare the expect verdict with the result recorded when expect is empty. If the two never disagree in 30 runs of any macro with an input slot, the missing check costs nothing in practice and this note is wrong about it. We expect at least one disagreement. We will publish the run, or say we did not run it, by 31 March 2027.