PaperlayerView exact revision on arXiv

Source-linked AI summary

Correct Answers, Closed Gates: SolveBind for GUI Agents at the Verification Barrier

Xinhao Song, Haoxuan Peng, Su Su, Hongliang Wu, Sirui Song, Gongshen Liu, Linfeng Zhang, Dongrui Liu

arXiv:2610.32223v1cs.AI

TL;DR

Protected GUI agents must satisfy behavioral verification, not merely produce correct answers, to complete workflows. SolveBind combines hierarchical solving with evidence-grounded runtime supervision. It improves success across evaluated verification backbones and all six evaluated AndroidWorld backbones, while controlled evaluations bound the demonstrated scope.

  • Problem

    Protected GUI environments use behavioral signals such as trajectories and timing, so correct verification answers alone may not complete a task.

    Source: §1 · pp. 1–2

  • Method

    SolveBind combines a hierarchical solving tree with a runtime supervisor that binds tool evidence to revisable action commitments and mediates execution.

    Source: §1 · pp. 2–3, §4.2 · p. 6

  • Results

    SolveBind leads on eight of nine verification backbones, exceeding the strongest baseline by 13.3–34.5 percentage points, and leads on all six evaluated AndroidWorld backbones.

    Source: §1 · p. 3, §6 · p. 10

  • Takeaways & Limitations

    The results support evidence-grounded execution control for improving success in the evaluated verification and GUI settings.

    Source: §6 · p. 10

    Evaluation used controlled HLL environments and the AndroidWorld simulator, not real third-party websites, production verification systems, or user data.

    Source: ETHICS STATEMENT · p. 10

Abstract

from arXiv · show

Websites and applications deploy CAPTCHAs and anti-automation mechanisms that use behavioral signals such as interaction trajectories and timing, not outcomes alone, to distinguish humans from automated agents. We call these protected GUI environments, where correctly solving a verification task is insufficient for end-to-end task completion. Agents must turn solver outputs into accepted interactions and adapt execution to runtime feedback under time constraints. We introduce SolveBind, a GUI-agent framework combining hierarchical solving with runtime supervision. A hierarchical solving tree decomposes verification into interdependent Perceive, Ground, Solve, Act, and Verify capabilities. A runtime supervisor grounds action commitments in tool-derived evidence, revises them as evidence arrives, and mediates execution under explicit recovery budgets. Across nine CAPTCHA task families and nine backbone models, SolveBind achieves the highest success rate on eight backbones, outperforming the strongest baseline by 13.3-34.5 percentage points. It achieves the highest success rate on all six AndroidWorld backbones. In a paired GPT-5.5 analysis, MobileAgent produces correct answers but fails dynamic verification on 13 of 90 tasks; SolveBind succeeds on seven of these tasks. With automatic submission, removing binding reduces success from 82.22% to 71.56% and increases latency and token usage. Recovery caps reduce execution cost with a small observed success trade-off: removing them raises success from 82.22% to 83.56%, while increasing latency and token usage to 3.7x and 2.4x their full-supervision values, respectively. These results support evidence-grounded execution control while identifying a success-cost trade-off in recovery and failure boundaries of heuristic submission rules.

1 INTRODUCTION

Protected GUI tasks can fail even when an agent finds the correct solution, because behavioral checks also govern whether interactions are accepted. SolveBind coordinates hierarchical solving with evidence-grounded runtime supervision, and improves success across evaluated verification and GUI settings.

1 INTRODUCTION

  • Protected GUI environments assess interaction behavior as well as outcomes, so a viable solution may still fail to advance the task.Trajectory and timing checks can reject even a correctly targeted interaction, while repeated attempts consume verification budget and time.Source: §1 · pp. 1–2
  • SolveBind combines a hierarchical solving tree with runtime supervision that binds tool-derived evidence to revisable action commitments and mediates execution.Task adapters connect the protocol to environment-specific primitives, tools, and completion interfaces.Source: §1 · pp. 2–3
  • Across nine verification families, SolveBind has the highest success rate on eight of nine backbones, beating the strongest baseline by 13.3–34.5 percentage points.It leads on all six evaluated AndroidWorld backbones as well.Source: §1 · p. 3
  • The framework’s design principles include evidence-grounded commitment, progress-checked transition, and feedback-directed bounded recovery.The principles coordinate solving with execution state rather than treating solver outputs as detached answers.Source: §1 · p. 3

2 RELATED WORK

Prior GUI-agent work emphasizes planning, grounding, verification, or CAPTCHA solving, while protected environments also require accepted interaction behavior. SolveBind focuses on coordinating evidence-supported dispatch with feedback-aware, bounded recovery.

GUI agent harnesses and native policies

  • GUI-agent evaluations often measure grounding accuracy and goal achievement rather than whether interaction behavior is accepted by the environment.SolveBind extends the external-harness approach by coordinating task solving with environmental acceptance.Source: §2 · p. 3

Execution verification and recovery

  • Prior execution-verification systems vary in when they intervene, which decisions they constrain, and how they bound recovery.SolveBind routes every dispatch through a supervisor, which gives admissible pending commitments precedence and updates their evidence from execution feedback.Source: §2 · p. 3

Protected interaction and execution efficiency

  • CAPTCHA research distinguishes puzzle solving from behavior-based acceptance, while SolveBind leaves the backbone unchanged and coordinates execution at runtime.The comparison is about acceptance criteria and execution control, not whether the task itself is interactive.Source: §2 · p. 4

Runtime supervision and metareasoning

  • SolveBind adopts supervisory separation without formal guarantees of correctness or non-blocking behavior, and its metareasoning principles remain empirical design choices.Ablations report that relaxing mediation, fail-safe defaults, or supervision reduces success while increasing latency and token usage; removing only recovery caps raises observed success at greater cost.Source: §2 · p. 4

3 PROBLEM FORMULATION AND DESIGN RATIONALE

The formulation treats verification as part of GUI environment dynamics: task completion requires both achieving the goal and satisfying acceptance checks. Its design rationale balances evidence gathering and recovery against execution cost.

3.1 GUI TASK EXECUTION IN PROTECTED ENVIRONMENTS

  • A protected GUI environment combines a GUI with verification mechanisms that evaluate execution evidence in context.Evidence may cover a single action, a local sequence, or a longer history.Source: §3.1 · p. 4
  • Actions generate evidence such as interaction events and timing, and verification feedback can permit, renew, or block execution.Agents observe only environment-exposed observations and feedback, not internal states or undisclosed verification rules.Source: §3.1 · pp. 4–5
  • Task success requires both goal achievement and satisfaction of the verification requirements for completion.The framework overview depicts a protected GUI workflow with a supervisor mediating dispatched operations.Source: §3.1 · p. 5, Figure 2 · p. 5
  • End-to-end latency runs from the first model call to success or failure termination and includes inference, tools, environmental responses, verification, and recovery.The table caption reports success rate, end-to-end time, and token usage as separate measures.Source: §3.1 · p. 5, Table 1 · p. 6

3.2 DESIGN PRINCIPLES FROM A RATIONAL METAREASONING PERSPECTIVE

  • The design rationale weighs the possible decision benefit of additional computation and evidence gathering against their execution-time costs.This motivates coordinating computation and execution through explicit principles.Source: §3.2 · p. 5
  • Evidence-grounded commitment keeps a supported operation active while its conditions hold, but reconsiders it when observations indicate relevant conditions changed.The commitment constrains conflicting proposals and redundant solving while execution constraints remain satisfied.Source: §3.2 · p. 5
  • Progress-checked transitions require evidence that a capability or task completion criterion is met, while unresolved outcomes prompt further observation.Feedback-directed recovery revises affected hypotheses and commitments, preserves applicable evidence, and uses explicit budgets for recovery operations.Source: §3.2 · pp. 5–6

4 SOLVEBIND: HIERARCHICAL SOLVING WITH RUNTIME SUPERVISION

SolveBind organizes task solving hierarchically and places a runtime supervisor between proposals and external actions. The supervisor uses tool evidence and feedback to govern dispatch, verify progress, and bound recovery.

4 SOLVEBIND: HIERARCHICAL SOLVING WITH RUNTIME SUPERVISION

  • SolveBind combines a hierarchical solving tree with a runtime supervisor to coordinate execution, progress verification, and recovery.Tool-derived evidence supports revisable action commitments, while feedback updates shared protocol state for later decisions.Source: §4 · p. 6

4.1 FRAMEWORK OVERVIEW

  • The model selects capabilities and proposes operations, while the supervisor chooses dispatch using retained evidence, pending commitments, and execution constraints.Only selected operations are dispatched, and feedback informs subsequent decisions.Source: §4.1 · p. 6
  • The shared protocol state tracks the active stage, retained evidence, pending commitment, outcome history, and remaining recovery budgets.The supervisor may dispatch an operation, hold, or stop, then updates state from available observations and feedback.Source: §4.1 · p. 6

4.2 HIERARCHICAL CAPABILITY ORGANIZATION

  • The solving tree organizes Perceive, Ground, Solve, Act, and Verify capabilities, with task adapters selecting branches for interaction needs and available tools.Its structure represents required subgoals and alternative capabilities.Source: §4.2 · pp. 6–7
  • Each capability node has an entry predicate, parameterized operations, and a completion predicate, while tree edges encode required or alternative subgoals.Grounding tools and target descriptions differ across grid and slider tasks.Source: §4.2 · p. 7

4.3 RUNTIME SUPERVISION

  • A tool output that passes binding checks can support a commitment linking an operation to its capability and evidence; admissible commitments take dispatch precedence.Admissibility requires valid supporting evidence, satisfied stage and budget checks, and no terminal condition; dispatch alone does not establish progress.Source: §4.3 · p. 7
  • The supervisor classifies outcomes as progress, failure, or unresolved, advancing only when completion criteria are met and using feedback to revise affected hypotheses or branches.Recovery uses attempt history and configured budgets; when no permitted continuation remains, the run terminates.Source: §4.3 · p. 7

5 EXPERIMENTS

The experiments assess both interaction acceptance in dynamic verification and workflow completion in AndroidWorld, comparing SolveBind with several agent harnesses and foundation-model backbones. Results cover overall performance, paired verification failures, task-side efficiency, and runtime-control ablations.

5.1 EXPERIMENTAL SETUP

  • The evaluation compares SolveBind with MobileAgent, AppAgent, and UI-TARS configurations across nine HLL backbones, using AndroidWorld on six of those backbones.HLL tasks require correct answers and corresponding interaction evidence; reported metrics are success rate, end-to-end wall-clock time, and mean total-token usage.Source: §5.1 · pp. 7–8

5.2 RESULTS ON VERIFICATION-SIDE INTERACTION ACCEPTANCE

  • On GPT-5.5 and Gemini 3.1 Pro Preview, SolveBind improves verification success over MobileAgent while reducing mean E2E by 33.05% and 84.66%, respectively.GPT-5.5 E2E falls from 167.3 to 112.0 seconds; Gemini E2E falls from 577.7 to 88.6 seconds, with a 34.5-percentage-point success increase.Source: §5.2 · p. 8
  • UI-TARS-1.5-7B with its native harness completes 325 of 900 verification tasks, for 36.11% success.The evaluation uses distraction level 2 and hard difficulty where supported, otherwise normal; success requires both a correct answer and corresponding interaction evidence.Source: §5.1 · p. 7, §5.2 · p. 8
  • In 90 paired GPT-5.5 tasks, 13 MobileAgent answers passed static correctness but failed dynamic verification; SolveBind succeeds on seven of those tasks.Across the panel, 13 tasks change from MobileAgent failure to SolveBind success and one changes in the opposite direction.Source: §5.2 · p. 9

5.3 RESULTS ON TASK-SIDE EXECUTION EFFICIENCY

  • Across six AndroidWorld backbones, SolveBind achieves higher success than MobileAgent while reducing mean E2E by 68.47%–80.01% and token usage by 41.86%–59.56%.Table 2 reports SR, E2E, and Tok for each backbone and agent policy.Source: Table 2 · p. 8, §5.3 · p. 9

5.4 ABLATING RUNTIME CONTROLS

  • With automatic submission fixed, relaxing binding reduces success from 82.22% to 71.56%, while mean E2E rises from 112.13 to 128.71 seconds and tokens from 41.82k to 49.32k.This comparison isolates binding’s contribution in that configuration.Source: §5.4 · p. 9
  • Bypassing mediation reduces success by 9.33 percentage points, while removing fail-safe defaults reduces it by 7.11 points and adds 46.00 seconds and 18,818 tokens per run.Jointly relaxing binding and submission lowers success by 13.78 points.Source: §5.4 · p. 9
  • Removing recovery caps raises success from 82.22% to 83.56%, but increases E2E and token usage to 3.7× and 2.4× their full-control values.The authors characterize this as a small completion gain at substantially higher cost.Source: §5.4 · p. 9

6 CONCLUSION

The conclusion presents SolveBind as a framework for separating goal achievement from environmental acceptance and coordinating solving with supervised execution. Its evaluation remains in controlled environments and does not establish performance against deployed protections.

6 CONCLUSION

  • SolveBind combines a hierarchical solving tree with a runtime supervisor that binds tool outputs to revisable action commitments, mediates dispatch, and budgets recovery by category.Across evaluated backbones, it improves success in most verification settings and all AndroidWorld comparisons while reducing latency in several cases.Source: §6 · p. 10
  • The authors identify extension to deployed protections and investigation of backbone properties underlying runtime supervision as future work.The authors also state that interaction-success techniques could potentially be misused against real anti-automation systems.Source: §6 · p. 10, ETHICS STATEMENT · p. 10
  • The evaluation uses controlled HLL and AndroidWorld settings, not real third-party websites, production verification systems, or user data.The verification evaluation relies on HLL-recorded interaction evidence rather than production detectors.Source: ETHICS STATEMENT · p. 10, §6 · p. 10

A EXTENDED PROBLEM FORMULATION

The appendix formalizes protected GUI tasks through interaction evidence, verification, acceptance, and end-to-end evaluation, and specifies how capability and runtime protocols use accessible evidence and feedback to guide execution. It also describes a runtime cycle for controlled dispatch, outcome-based state updates, evidence acquisition, and bounded recovery, distinguishing logical binding from model-call scheduling.

A.1 PROTECTED INTERACTION DYNAMICS AND OBSERVATIONS; A.2 PROTECTION EVIDENCE AND VERIFICATION RULES

  • Protected interactions distinguish GUI actions from the execution evidence and protection outcomes they produce; verification rules may inspect one action, a local window, or longer histories.The agent-visible history need not expose internal states, complete execution evidence, or undisclosed verification outcomes; interaction-validity checks and human-versus-automation discrimination can both affect acceptance.Source: §A.1 · p. 14, §A.2 · pp. 14–15

A.3 ENVIRONMENTAL ACCEPTANCE AND TASK COMPLETION

  • Task completion requires both the user goal and task-specific environmental acceptance; a local pass, rejection, or missing determination alone does not establish completion.Acceptance may depend on retained verification history, and a rejection may permit correction or irreversibly block continuation.Source: §A.3 · p. 15

A.4 END-TO-END LATENCY AND EVALUATION

  • End-to-end latency is elapsed wall-clock time across computation, tool use, execution, feedback, verification, and recovery, with failed runs and external cutoffs retaining their actual elapsed time.All-run latency includes failures; successful-run latency is conditional on completion, so comparisons should report success rates and termination conditions alongside latency.Source: §A.4 · pp. 15–16

B EXECUTION PROTOCOL DETAILS; B.1 CAPABILITY INSTANCES AND DEPENDENCIES

  • The execution protocol instantiates a reusable capability skeleton from task-specific goals, tools, and evidence interfaces, with prerequisites and AND/OR dependencies governing readiness and completion.Capabilities need not map to separate calls or modules, and changed targets can invalidate dependent grounding while leaving unrelated evidence intact.Source: B EXECUTION PROTOCOL DETAILS · p. 16, §B.1 · pp. 16–17

B.2 EVIDENCE SUPPORT AND BINDING CONDITIONS

  • A runtime commitment binds a candidate operation to accessible evidence only when interface-supported stage, target, and context checks pass; binding does not certify semantic correctness.Changed challenges, targets, or contradictory feedback can trigger reassessment; dispatch remains subject to stage and budget constraints.Source: §B.2 · pp. 17–18

B.3 COMMITMENT LIFECYCLE AND DECISION RESOLUTION

  • Commitments progress from unbound to pending, dispatched-but-unresolved, and resolved or reconsidered, with precedence limited to currently admissible support and latest accessible feedback.When support changes, the runtime reconsiders the continuation; rejection, deferral, or recovery need not each dispatch a GUI action.Source: §B.3 · p. 18

B.4 PROGRESS ASSESSMENT AND FEEDBACK-DIRECTED RECOVERY

  • Runtime progress is assessed as progress, failure, or unresolved from accessible feedback and observations; unresolved outcomes are not success, and recovery is constrained by explicit budgets.The protocol does not assume hidden ground-truth failure causes, and its count-based budget accounting does not itself bound all model calls or external waiting time.Source: §B.4 · p. 19

B.5 RUNTIME INTERFACES AND EXECUTION CYCLE

  • The runtime cycle uses accessible context to select and refine a request, dispatches the supervisor-approved action or tool call, and updates protocol state from feedback.A hold dispatches no request and does not automatically provide new information; tool calls and GUI interactions need not correspond one-to-one.Source: §B.5 · p. 20
  • The runtime retains tool-supported pending commitments even when the model proposes another operation.Candidate continuations are selected and refined using the task capability structure and permitted model view.Source: §B.5 · p. 20
  • Before dispatch, the runtime checks terminal conditions and constraints, reassesses commitments, and accepts, replaces, or withholds the proposal.When evidence is missing, it can acquire evidence instead of directly changing task state.Source: §B.5 · p. 20
  • The runtime executes only the selected request, retains its supporting context, and distinguishes execution status from task progress.It obtains feedback after dispatch to inform subsequent decisions.Source: §B.5 · p. 20
  • Outcome evidence updates protocol state and can advance a capability, revise a commitment, acquire evidence, or select a bounded recovery direction.The cycle then continues or terminates.Source: §B.5 · p. 20
  • The cycle links model proposals, runtime dispatch, and outcome evidence rather than introducing an additional search algorithm.Source: §B.5 · p. 20
  • Logical binding does not ensure that every continuation saves a model call, because call scheduling and binding are distinct concerns.Source: §B.5 · p. 20

B.6 TASK INSTANTIATION AND ILLUSTRATIVE TRAJECTORIES

The appendix illustrates how SolveBind coordinates evidence, commitments, execution, and feedback, then relates that design to metareasoning’s trade-off between decision improvement and processing cost. These principles are design choices, not claims of optimal control, and their effects are evaluated empirically.

B.6 TASK INSTANTIATION AND ILLUSTRATIVE TRAJECTORIES

  • Feedback can undermine a proposed slider displacement or reveal that a setting change has not taken effect, prompting renewed evidence acquisition or revised commitments.The examples illustrate protocol behavior, not measured benchmark trajectories.Source: §B.6 · p. 20

C RATIONAL METAREASONING AND DESIGN RATIONALE

  • Metareasoning treats computation as valuable when its expected contribution to subsequent decision quality justifies its cost, rather than as an objective in itself.The framework borrows this benefit–cost perspective for reasoning, solving, evidence acquisition, and verification while distinguishing tool calls from realized interactions.Source: §C.1 · p. 21

C.1 DECISION IMPROVEMENT AND PROCESSING COST

  • The appendix applies metareasoning’s benefit–cost perspective to model reasoning, tools, evidence acquisition, and verification, which contribute to end-to-end latency.Some tools both return information and execute GUI actions, so tool invocations are distinguished from realized interactions.Source: §C.1 · p. 21

C.2 IMPLICATIONS FOR PROTECTED EXECUTION

  • Reliable protected execution requires coordinating information acquisition, action, verification, and feedback-guided recovery rather than maximizing reasoning or minimizing interaction count alone.The design reuses applicable evidence, verifies consequential uncertainty, and directs recovery toward unresolved issues within configured budgets.Source: §C.2 · pp. 21–22

C.3 SCOPE OF THE THEORETICAL CONNECTION

  • The three design principles are metareasoning-inspired choices, not theorems or claims that SolveBind optimizes computation value.The framework uses accessible evidence, execution history, and budget constraints; their effects on success and latency are evaluated empirically.Source: §C.3 · p. 22

D SUPPLEMENTARY EXPERIMENTAL DETAILS AND ANALYSIS

  • Supplementary experimental analysis includes configurations, statistical stability, runtime ablations, paired correctness-versus-acceptance analysis, and failure cases.It also presents two text-based SolveBind case studies of runtime decisions and outcomes.Source: D SUPPLEMENTARY EXPERIMENTAL DETAILS… · p. 22

D.1.1 EVALUATION ENVIRONMENTS AND EPISODE INITIALIZATION

The evaluation uses locally controlled CAPTCHA and AndroidWorld environments, preserves each method’s own execution procedure, and applies shared scoring and information boundaries. It also compares dynamic-verification success across backbone–harness combinations while reporting remaining failures and distinct latency–token trade-offs.

D.1.1 EVALUATION ENVIRONMENTS AND EPISODE INITIALIZATION

  • CAPTCHA instances run in a local Android emulator, while AndroidWorld uses a Pixel 6 emulator and official task lifecycle; the runtime ablation is a separate 225-episode-per-configuration batch.The nine CAPTCHA families provide 100 instances each, with backbone–harness comparisons scoring 90 instances and the native UI-TARS evaluation scoring all 900.Source: §D.1.1 · p. 22

D.1.2 AGENT INTEGRATION

  • Each approach retains its own prompting, history, action interpretation, and device execution; a common evaluation layer fixes task lifecycle and final success determination.UI-TARS Harness and the native UI-TARS-1.5-7B policy are separate configurations.Source: §D.1.2 · p. 23

D.1.3 OBSERVATION, ACTION, AND INFORMATION BOUNDARIES

  • Agents do not receive evaluator-only state, and success is determined independently by environment verification or the official terminal evaluator.SolveBind tools use permitted interface observations and cannot query evaluator-only state.Source: §D.1.3 · p. 23

D.1.4 INFORMATION-ISOLATION CHECKS

  • Information-isolation checks found no CAPTCHA answers or evaluator-only fields exposed through inspected interfaces, but they are not a formal proof or exhaustive execution-path audit.Deterministic perception and OCR do not contribute language-model tokens.Source: §D.1.4 · pp. 23–24

D.1.5 BUDGETS, TERMINATION, AND ERROR HANDLING

  • Model, tool, timeout, budget, and unrecoverable failures count as failures; after an action or interaction, a failed episode is not replaced by a later successful rerun.A zero-action infrastructure interruption may be retried under a predetermined policy while retaining the original record.Source: §D.1.5 · p. 24

D.1.6 EPISODE SELECTION AND METRIC AGGREGATION

  • E2E measures wall-clock time through success or failure, Tok sums model-call tokens, and all three metrics use the same scored episodes, including failures.E2E includes inference, tools, runtime control, GUI execution, environmental responses, and recovery; deterministic perception is excluded from Tok.Source: §D.1.6 · p. 24

D.2.1 DYNAMIC VERIFICATION ACROSS BACKBONES

  • SolveBind improves over the strongest baseline across backbone–harness combinations; the strongest baseline is UI-TARS Harness for three backbones and MobileAgent for the others.Table 10 reports success rates and percentage-point differences relative to each backbone’s highest-success baseline.Source: Table 10 · p. 25, §D.2.1 · p. 25
  • MiniMax-M2.7 improves 22.2 percentage points over its strongest baseline but reaches 32.2% success; Claude Opus 4.6 trades lower E2E for lower success versus MobileAgent.For Claude Opus 4.6, E2E decreases from 202.2 to 185.2 seconds while success decreases from 38.9% to 34.4%; token totals can also be higher or lower alongside latency gains.Source: §D.2.1 · p. 25

D.2.2 APPLICATION WORKFLOW EXECUTION

SolveBind improves application-level execution outcomes against multiple harnesses, while success and efficiency vary by baseline and backbone. Parser failures also identify an execution-interface failure mode distinct from task failure.

D.2.2 APPLICATION WORKFLOW EXECUTION

  • Against MobileAgent, SolveBind improves success while reducing E2E by 68.47%–80.01% and total-token usage by 41.86%–59.56%.The reported token reductions accompany the E2E reductions.Source: §D.2.2 · p. 25
  • Against AppAgent, SolveBind achieves higher success across reported backbones, but uses more tokens and has mixed E2E results.E2E is lower for four named backbones and higher for Claude Opus 4.8 and Qwen3.7-Plus.Source: §D.2.2 · p. 25
  • SolveBind exceeds UI-TARS on every compared backbone by 8.67 to 38.78 percentage points, although baseline rankings vary by backbone.UI-TARS success ranges from 37.07% with GPT-5.5 to 15.52% with GLM-5v-turbo among the reported examples.Source: §D.2.2 · pp. 25–26
  • AppAgent with MiniMax-M3 reaches 16.4% success, 268.9 seconds E2E, and 15,142 mean tokens; frequent ParseErrors mark a distinct interface failure.Case A-A2 illustrates parser rejection after a valid action was selected.Source: §D.2.2 · p. 26

D.3 NATIVE UI-TARS EVALUATION

The native UI-TARS-1.5-7B evaluation shows low overall verification completion and sharply uneven success across task families. Families that are harder for the policy also consume more runtime and generation cost.

D.3 NATIVE UI-TARS EVALUATION

  • UI-TARS-1.5-7B completes 325 of 900 verification tasks, for 36.11% success; its separate AndroidWorld result is 23/116, or 19.83%.Verification and application results use separate scored populations.Source: §D.3 · p. 26, Table 13 · p. 27
  • Natural-image sequence selection reaches 98/100 successes, while board reconfiguration reaches 5/100 and logic-and-arithmetic interaction 12/100.The per-family table covers 100 instances per family and sums to 325 overall successes.Source: §D.3 · p. 26, Table 14 · p. 27
  • Family success counts correlate −0.99 with mean total tokens and −0.88 with mean E2E; board reconfiguration averages 28,418 tokens for 5 successes.Natural-image sequence selection averages 4,080 tokens for 98 successes; slider alignment has the longest mean runtime at 157.94 seconds.Source: §D.3 · p. 27
  • The costly low-success families are consistent with repeated unproductive attempts rather than early abandonment, including retries on targets the agent cannot discriminate.The text connects this pattern to UI-TARS trajectories and to runtime ablations where lower success accompanies higher E2E and token usage.Source: §D.3 · p. 27

D.4 STATISTICAL STABILITY ANALYSIS

Across three repetitions on fixed task instances, SolveBind has the highest mean success and lowest mean E2E among four systems for all three tested backbones. The authors describe dispersion but do not infer significance from the three run summaries.

D.4 STATISTICAL STABILITY ANALYSIS

  • Across three backbones, SolveBind records the highest mean success and lowest mean E2E among four systems.The repeated evaluation reports mean and standard deviation over three runs.Source: §D.4 · p. 27, Table 15 · p. 28
  • With GPT-5.5, SolveBind reaches 87.4±8.3 success against MobileAgent’s 60.0±6.9; with Gemini 3.1 Pro Preview, E2E is 130.9±19.9 versus 514.4±174.8 seconds.SolveBind’s E2E standard deviations range from 12.6 to 19.9 seconds across the three backbones.Source: §D.4 · p. 27
  • The three runs reuse fixed instances and settings, and their aggregate summaries are descriptive rather than a basis for significance claims.Seeds are 42, 43, and 45, with 90 tasks per run.Source: §D.4 · p. 28

D.5 PAIRED ANALYSIS OF STATIC CORRECTNESS AND DYNAMIC ACCEPTANCE

The paired analysis distinguishes correct-answer dynamic rejection from overall matched-task improvement, while supplementary trace counts describe supervisor control paths rather than their corrective success. The ablation settings isolate selected controls while holding the principal task and execution conditions fixed.

D.5 PAIRED ANALYSIS OF STATIC CORRECTNESS AND DYNAMIC ACCEPTANCE

  • The paired analysis defines targeted failures as submitted correct answers rejected dynamically with final episode failure; the paired success difference is 13.33 percentage points.The comparison uses 90 GPT-5.5 HLL tasks and matches each task to the SolveBind outcome.Source: §D.5 · p. 28, Table 16 · p. 28

D.6 MECHANISM-LEVEL TRACE STATISTICS

  • The trace counts come from separate 90-episode batches per backbone, using hard difficulty where supported and distraction level 2; offline analysis required no extra model calls.The batches are separate from the main table and the 225-episode ablation.Source: §D.6 · pp. 28–29, Table 17 · p. 29
  • Across three supplementary batches, 61 of 183 overrides change operations according to commitments, while 37 normalize equivalent operations; these are control-path frequencies, not corrective-success estimates.Override categories vary by backbone, and an override does not necessarily correct a mistaken proposal.Source: §D.6 · p. 29, Table 18 · p. 29

D.7.1 SHARED SETTINGS AND CONTROL CHANGES

  • The 225-instance ablation holds tools, evidence, instructions, interfaces, limits, and evaluator permissions constant; no-binding removes forced dispatch precedence but retains other controls.Relaxed supervision jointly removes forced binding and automatic submission; no condition receives answers or additional evaluator information.Source: §D.7.1 · pp. 29–30, Table 19 · p. 30

D.7.2 SUCCESS–COST ANALYSIS

The ablations show full control's success-and-cost advantage over mediation, defaults, binding, and relaxed-supervision variants, while unbounded recovery trades substantially greater cost for slightly higher success. Selected traces and case studies illustrate failure mechanisms and protocol behavior; the information-isolation audit supports the interface boundary but is not formal or exhaustive verification.

D.7.2 SUCCESS–COST ANALYSIS

  • Bypassing mediation lowers success by 9.33 percentage points and raises mean E2E by 11.79 seconds and output by 6,273 tokens; removing fail-safe defaults adds 46.00 seconds and 18,818 tokens while reducing success by 7.11 points.The defaults ablation has the largest cost increases among the mediation, defaults, binding, and relaxed-supervision variants.Source: §D.7.2 · pp. 30–31
  • Full control outperforms the mediation, defaults, binding, and relaxed-supervision variants in success and aggregate cost; unbounded recovery slightly improves success at higher cost.Removing recovery caps raises success from 185 to 188 episodes while increasing E2E from 112.13 to 417.45 seconds and tokens from 41.82k to 101.40k.Source: Table 20 · p. 31, §D.7.3 · p. 31, §D.7.2 · p. 31
  • With automatic submission retained, removing binding reduces success from 185 to 161 episodes, increases mean E2E by 16.58 seconds, and raises mean tokens from 41.82k to 49.323k.Removing automatic submission as well yields seven fewer successes than the no-binding configuration; these comparisons do not establish effects in every setting or their interaction.Source: §D.7.2 · p. 31

D.7.3 CONNECTION TO RUNTIME DESIGN PRINCIPLES

  • The aggregate comparisons motivate weighing added processing against task completion, but they neither localize which execution steps incur cost nor establish an optimal metalevel policy.The analysis says per-episode execution traces would be needed to connect configuration-level cost differences to particular steps.Source: §D.7.3 · p. 31

D.8 FAILURE MODE ANALYSIS

  • The twelve selected baseline traces illustrate unchanged-state retries, unsupported completion claims, fine-grained grounding and action errors, repeated wrong operations, and harness-format rejection; they explain mechanisms, not population failure frequencies.Failure labels are assigned only when supported by recorded traces.Source: §D.8 · p. 32, §D.8.1 · p. 34, §D.8.2 · p. 35

D.9 SOLVEBIND CASE STUDIES

  • SolveBind case studies record proposal, supervision decision, dispatched operation, and feedback, illustrating target-bound input and both accepted and prematurely submitted interactions.The episodes are illustrative recorded runs, not controlled comparisons against matched baseline trajectories.Source: §D.9 · p. 39, §D.9.1 · p. 39, §D.9.2 · p. 39

D.10 INFORMATION ISOLATION AUDIT

  • The information-isolation audit found no exposed answers or evaluator-only signals in inspected records, but it is not a formal information-flow proof or exhaustive verification of every execution path.The audit consists of observation and dependency-isolation tests for UI-TARS configurations and a field-level audit in the protected-interaction environment.Source: §D.10 · p. 41

Related papers

Loading 2610.32223v1…