Fara1.5: Scalable Native Computer Use Agents

• Fara1.5 is a family of native computer use agents built from scalable trajectories generated by the FaraGen1.5 pipeline.
• The system employs a modular design with environments, solvers, and verifiers to ensure task correctness, efficiency, and safety.
• It iteratively refines training data via failure analysis, leading to improved performance in complex browser automation tasks.

Fara1.5 is a family of native computer use agents (CUAs) at three scales built on Qwen3.5—4B, 9B, and 27B—trained using data generated by FaraGen1.5, a scalable data pipeline for computer use agents composed of three modular components: environments, solvers, and verifiers (Awadallah et al., 18 Jun 2026). The system is positioned around a core data-generation problem: collecting computer use data from human demonstrations is expensive and slow, so scalable generation requires both environments in which agents can act and verifiers that can judge whether their demonstrations succeeded. Within that framing, FaraGen1.5 combines live websites, synthetic environments, a solver harness that can be powered by multiple models including GPT-5.4, a user simulator for multi-turn rollouts, and three complementary verifiers covering task correctness, efficiency, and critical-point adherence; Fara1.5 is the model family trained on the resulting trajectories (Awadallah et al., 18 Jun 2026).

1. System definition and scope

Fara1.5 refers specifically to the trained model family, whereas FaraGen1.5 denotes the data-generation pipeline that produces the training trajectories (Awadallah et al., 18 Jun 2026). The architecture is modular at the pipeline level: environments provide executable task settings, the solver produces trajectories in those settings, and verifiers filter trajectories before they become training examples. This separation is operationally important because the paper treats scalable data generation, trajectory quality control, and supervised finetuning as distinct but tightly coupled components.

The target domain is browser-based and GUI-mediated task completion rather than static question answering. The downstream action space includes actions such as click, type, scroll, visit_url, mouse_move, pause_and_memorize_fact, ask_user_question, and terminate (Awadallah et al., 18 Jun 2026). The inclusion of ask_user_question and pause_and_memorize_fact indicates that the training setup is not limited to single-turn webpage navigation; it explicitly models ambiguity resolution, cross-page information retention, and multi-step interaction.

A central design premise is that high-quality CUA data cannot be obtained only from open websites. The pipeline therefore combines live-web tasks with synthetic environments that faithfully simulate domains gated by authentication or that require irreversible actions (Awadallah et al., 18 Jun 2026). This suggests a training objective broader than benchmark optimization alone: the system is engineered to cover realistic productivity tasks that are either unavailable or unsafe to execute directly on the public web.

2. FaraGen1.5 pipeline

FaraGen1.5 is organized into three stages—Environments, Solver, and Verifiers—and these stages interact to yield training examples (Awadallah et al., 18 Jun 2026). The environment layer contains both live-web environments and synthetic environments; the solver layer contains a single-policy tool-calling loop and a user simulator; the verifier layer applies three independent checks, and a trajectory is admitted only if it passes all three (Awadallah et al., 18 Jun 2026).

The live-web component begins from seed URLs drawn from a public index, ClueWeb22. Each site is auto-explored to build a cached “site summary” containing structure, forms, and navigation patterns, and that summary is then fed to an LLM prompt that proposes tasks (Awadallah et al., 18 Jun 2026). Tasks are sampled along seven categorical dimensions—site, complexity, phrasing, interaction type, solvability, intent, and persona—and a coverage tracker ensures that every bucket is hit (Awadallah et al., 18 Jun 2026). The task proposal stage is further constrained by a two-stage filter: deterministic rejects for bare URLs or LLM refusal, followed by an LLM judge that flags under-specified or unrealistic tasks.

The synthetic component, called FaraEnvs, comprises six deep, sandboxed replicas covering Email, Calendar, Media-Streaming, ML Experiment Management, Marketplace, and Scheduling (Awadallah et al., 18 Jun 2026). These environments are built via a semi-automated “coding agent” loop using Copilot: record human trajectories on the real system, generate a React+FastAPI+SQLite clone, perform human review, and iterate 3–5 times until functional (Awadallah et al., 18 Jun 2026). The task-proposing LLM has direct MCCP tool access to the live clone through SQLite introspection and Playwright UI browsing, and every task carries an exact state-predicate for post-hoc verification via SQL diff or reference-answer (Awadallah et al., 18 Jun 2026).

The significance of this design lies in the combination of breadth and control. Live-web environments contribute heterogeneity and site realism, whereas synthetic environments provide instrumented domains in which success criteria can be specified exactly. The paper’s broader training recipe later exploits this distinction by assigning 60.0% of the data mixture to FaraGen1.5 web trajectories and 12.8% to synthetic-env trajectories (Awadallah et al., 18 Jun 2026).

3. Solver harness and interaction model

The solver in FaraGen1.5 is a single-policy tool-calling loop built on GPT-5.4, replacing a prior multi-agent Magentic orchestration (Awadallah et al., 18 Jun 2026). The solver tools mirror the downstream student action space in order to keep generated trajectories learnable by the student models. The system explicitly prohibits “super-URLs” or API sniffing in the solver harness for that reason (Awadallah et al., 18 Jun 2026).

The user simulator is invoked in two situations: when a task is ambiguous or missing information and the solver issues ask_user_question, and when the pipeline aims to generate multi-turn follow-ups (Awadallah et al., 18 Jun 2026). Before questions reach the simulator, a lightweight LLM gate blocks potentially harmful questions, including real checkouts and PII leaks (Awadallah et al., 18 Jun 2026). This interaction design is connected directly to the critical-point verifier discussed below, because ambiguous or under-specified tasks are not treated as noise but as cases in which proper deferral behavior must be learned.

One distinctive tool is pause_and_memorize_fact, which teaches the agent to carry cross-page facts (Awadallah et al., 18 Jun 2026). This is not merely an interface detail: it operationalizes a memory behavior within the action space and therefore within the demonstration distribution. A plausible implication is that the training corpus encodes not only GUI motor actions but also explicit latent-state management conventions, which can matter for long-horizon browser tasks.

4. Verification and safety-critical filtering

Trajectory admission in FaraGen1.5 requires passing three independent checks: task correctness, task efficiency, and critical-point adherence (Awadallah et al., 18 Jun 2026). This verifier design is central to the pipeline because it defines what constitutes usable supervision.

For task correctness, the criterion depends on the environment type. On the live web, correctness is judged by a Universal Verifier ensemble with a process-rubric score threshold of at least 0.8. In synthetic environments, mutating tasks are checked by exact state diff using sqldiff + LLM judge, while reading tasks are checked by reference-answer match (Awadallah et al., 18 Jun 2026). The explicit threshold is given as

$\text{rubric\_process\_score}(\tau) \ge 0.8.$

For task efficiency, an LLM judge flags unnecessary loops or clicks and assigns an integer rating $r \in [1,5]$; a trajectory is accepted only if $r \ge 4$ (Awadallah et al., 18 Jun 2026). The paper reports that efficiency filtering removes meandering successes and that models trained without it take 20–30% more steps in evaluation (Awadallah et al., 18 Jun 2026). This ties verifier design directly to rollout length and practical usability, not only to binary success.

For critical-point adherence, each task is classified by three booleans—$$\{\text{Permission Granted}, \text{Fully Specified}, \text{PII Provided}\}$$—yielding 8 types (Awadallah et al., 18 Jun 2026). The verifier injects this classification into its rubric and rejects any trajectory that crosses an irreversible step without prior ask_user_question. The rule is stated as: let $C=(p,f,i)\in \{0,1\}^3$; trajectory $\tau$ must ask_user_question at each step where $p=0 \wedge (f=0 \vee i=0)$ (Awadallah et al., 18 Jun 2026). The paper further reports that critical-point compliance training yields a 0% regression in proper deferral rates versus Fara-7B, even as models grow more capable (Awadallah et al., 18 Jun 2026).

Taken together, these verifiers define a narrow admissible set of demonstrations: correct, non-meandering, and procedurally compliant with irreversible-action safeguards. This suggests that FaraGen1.5 is not simply a large-scale self-play generator; it is a filtered trajectory-generation system whose inductive bias is shaped by explicit procedural norms.

5. Supervised finetuning and model construction

Fara1.5 is trained by supervised finetuning from Qwen3.5 base models at 4B, 9B, and 27B (Awadallah et al., 18 Jun 2026). The data mixture is carefully balanced across multiple sources: FaraGen1.5 web trajectories at 60.0%, synthetic-env trajectories at 12.8%, form-filling/user-interaction at 12.5%, grounding datasets (Jedi, GroundCUA, Click100k) at 8.8%, VQA datasets (RICO-SCA, InfographicsVQA) at 4.9%, GUI-drag at 0.8%, and instruction plus safety at 0.1% (Awadallah et al., 18 Jun 2026). These ratios were swept to maximize agentic accuracy without regressing grounding or VQA.

The model input at each timestep consists of the last 3 screenshots plus a “Current URL” token, together with the full history of user query, thoughts, and actions (Awadallah et al., 18 Jun 2026). The loss is cross-entropy over newly generated thought and action tokens for those last 3 turns only, with older images dropped:

$$\mathcal{L} = -\sum_{\text{token}\in T_t} \log P(\text{token} \mid \text{history}).$$

This training formulation encodes a recency-biased visual context while retaining complete textual interaction history.

Optimization uses AdamW with $\beta_1=0.9$, $\beta_2=0.95$, and $r \in [1,5]$0, peak learning rate $r \in [1,5]$1, cosine decay with 10% warmup, 2 epochs, batch size 128, and bfloat16 (Awadallah et al., 18 Jun 2026). Training runs on 4 nodes × 8 B200 GPUs, taking approximately 4 days for 4B and 9B and approximately 5 days for 27B (Awadallah et al., 18 Jun 2026). The recipe is iterative: initial student failures, especially long-tail tasks the 9B model fails, are fed back into FaraGen1.5 to close coverage gaps, and high-value tasks such as forms and gated domains are oversampled via synthetic environments (Awadallah et al., 18 Jun 2026).

This iterative loop is important because it connects model evaluation to data generation. Rather than fixing a static dataset, the system uses failure analysis to shape subsequent supervision. A plausible implication is that the pipeline is intended as a continual curriculum-generation framework as much as a one-time training recipe.

6. Evaluation, empirical performance, and interpretation

Evaluation uses WebVoyager (100 tasks), Online-Mind2Web (300 tasks), and WebTailBench v1.5 (Awadallah et al., 18 Jun 2026). Execution is performed via Browserbase to reduce blocking, with failed tasks re-run without Browserbase; each agent is run 3 times and results are reported as mean ±95% CI (Awadallah et al., 18 Jun 2026). The judges are benchmark-specific: GPT-4o for WebVoyager, o4-mini WebJudge for Mind2Web, and a multi-stage judge using GPT-5.2 and o4-mini for WebTailBench (Awadallah et al., 18 Jun 2026). At evaluation time, every ask_user_question is automatically returned with “continue” to avoid indefinite pause (Awadallah et al., 18 Jun 2026).

The headline results reported for WebVoyager and Online-Mind2Web are as follows (Awadallah et al., 18 Jun 2026):

Model	WebVoyager	Online-Mind2Web
Fara1.5-4B	80.8	57.3
Fara1.5-9B	86.6	63.4
Fara1.5-27B	89.3	72.3
GPT-5.4 Solver	93.4	83.4

According to the paper, Fara1.5-9B outperforms all open-weight 7–9B agents by at least +6.4 percentage points on WebVoyager and +14.8 percentage points on Online-Mind2Web (Awadallah et al., 18 Jun 2026). The 27B model is reported to match or beat much larger proprietary systems in the tabled comparison, including OpenAI Operator on WebVoyager and Yutori n1 on Online-Mind2Web (Awadallah et al., 18 Jun 2026). The abstract states that each model sets a new state of the art for its size class on browser-use benchmarks (Awadallah et al., 18 Jun 2026).

The ablations attribute these outcomes to several components. Replacing Magentic multi-agent orchestration with the GPT-5.4 single-policy solver raises teacher success on Online-Mind2Web from 67% to 83%, thereby boosting training yield (Awadallah et al., 18 Jun 2026). Synthetic environments materially affect gated-domain competence: Fara-7B, without synthetic training, scores 18.8% average on held-out FaraEnvs, whereas Fara1.5-9B scores 71.8% and GPT-5.4 scores 79.4% (Awadallah et al., 18 Jun 2026). The paper also reports synthetic-to-real transfer, stating that adding four domain-replica trajectories to Qwen3.5 raises live-web domain performance from 73.4 to 83.4 average (Awadallah et al., 18 Jun 2026). Finally, longer trajectories correlate with failure, and larger models both solve more tasks and do so in fewer steps on average (Awadallah et al., 18 Jun 2026).

7. Relation to adjacent work and name disambiguation

Fara1.5 is a computer-use-agent system and should not be conflated with work on the Farrow structure in digital signal processing. The paper “A Unified Analytical Nullspace-Based Least-Squares Design of the Farrow Structure” concerns variable fractional-delay filters, linear-phase FIR subfilters, nullspace parameterization, and least-squares design under group-delay constraints (Linares et al., 15 Jun 2026). By contrast, Fara1.5 concerns scalable learning environments, verifier-filtered trajectory generation, and supervised finetuning of native browser-acting agents (Awadallah et al., 18 Jun 2026).

This disambiguation matters because the two names are visually similar while the research areas are unrelated. One belongs to browser automation and multimodal agent training; the other belongs to FIR filter design and variable fractional-delay realization. The orthographic overlap is therefore nominal rather than conceptual.

Within the CUA literature, the more substantive relation is between Fara1.5 and systems that differ in model scale, openness, and training source. The evaluation table places Fara1.5 alongside GUI-Owl-1.5-8B, MolmoWeb, Holo2, o3 SoM, GPT-5 SoM, OpenAI Operator, Gemini 2.5 CU, and Yutori n1 (Awadallah et al., 18 Jun 2026). The paper’s empirical claim is not merely that a larger model helps, but that a specific combination of live-web breadth, synthetic depth, verifier filtering, and iterative failure-driven data generation can produce strong results even at 4B and 9B scale (Awadallah et al., 18 Jun 2026).