TimeTraj: Plan-Based Web Trajectory Collection

Updated 4 July 2026

TimeTraj is a plan-centric method that collects version-invariant teacher trajectories by refining a single high-level plan for web tasks.
It overcomes static training limitations by reusing human-refined plans to drive teacher rollouts across multiple UI versions.
Empirical evaluations with TimeWarp-BC demonstrate significant performance gains for complex, multi-step web navigation tasks.

TimeTraj is a data-collection and training recipe for web agents that must operate on websites whose UI, layout, and even HTML structure change over time. It is introduced together with the TimeWarp benchmark and is defined as a simple, hybrid (human + model) algorithm for collecting high-quality teacher trajectories across multiple web UI versions using plan distillation: a single, human-refined high-level execution plan per task is reused to drive teacher rollouts in every version (Ishmam et al., 5 Mar 2026).

1. Problem setting and benchmark context

TimeTraj is motivated by the mismatch between static web-agent training and the evolving web. In the underlying problem formulation, websites change layout and styling, change front-end technologies, and introduce new UI affordances such as search icons, autocomplete, and pop-ups. Agents trained on one static version of a site often perform poorly when the site evolves, especially visual agents. The central observation is that both zero-shot and fine-tuned agents are fragile across versions, and performance can swing dramatically when the same task is instantiated on older or newer interfaces (Ishmam et al., 5 Mar 2026).

The algorithm is tightly coupled to TimeWarp, a benchmark constructed to study “time-varying web.” TimeWarp contains three containerized environments—Wiki, News, and Shop—each with six front-end versions, $v_1$ – $v_6$ , designed to mimic different eras of web design, including early 2000s, mid-2000s, modern complex layouts, and minimal UIs. It contains 231 human-authored goals, each instantiated on all six versions, yielding 1386 tasks. A key design point is that the underlying backend and task goal are held constant across versions, while the UI, HTML, AXTree, and visual presentation change. The tasks are explicitly described as realistic and complex, including multi-step navigation, multi-article retrieval, multi-site navigation across Wiki, News, and Shop, visual questions, counting, and hallucination traps (Ishmam et al., 5 Mar 2026).

Within this setting, standard behavior cloning is characterized as insufficient for three reasons. First, trajectories collected on a single UI version produce version-specific overfitting. Second, action-only cloning discards chain-of-thought, planning, and memory text generated by stronger teacher models, which weakens performance on complex multi-step tasks. Third, recollecting trajectories for every future version is expensive and tedious, while automatic recollection with an imperfect teacher produces failures and imbalanced data. TimeTraj is introduced specifically to address these three failure modes.

2. Definition and plan-distillation paradigm

The core conceptual shift in TimeTraj is from collecting trajectories separately for each version to collecting plans once and reusing them across versions. Traditional behavior cloning is summarized as “collect trajectories for each version, then clone them,” whereas TimeTraj is summarized as “collect plans once, refine them with a human, and then use those version-invariant plans to automatically generate trajectories on all versions” (Ishmam et al., 5 Mar 2026).

Formally, the method begins with a goal dataset $\mathcal{D}_{\text{goal}}$ , where each entry contains a task goal $g$ and a desired outcome $a$ . The plan-distillation stage constructs a planning dataset $\mathcal{D}_{\text{plan}}$ of pairs $(g, p^*)$ , where $p^*$ is a version-invariant high-level plan. A planner LLM, implemented in the paper as an LLM council using GPT-5, Gemini, and Grok, takes $(g,a)$ and produces a draft execution plan $\hat{p}$ . Humans then refine $v_6$ 0 while interacting with one environment version to produce a plan $v_6$ 1 that is version-independent, checkpointed, and detailed enough for a teacher agent to follow.

The paper formalizes this as a human-in-the-loop plan-distillation algorithm. For each $v_6$ 2, the system resets a planning environment $v_6$ 3, samples a draft plan $v_6$ 4, refines it with a human $v_6$ 5, and appends $v_6$ 6 to $v_6$ 7. The important constraint is that the final plan should refer to anchoring concepts such as a search box, article title, or confirmation code rather than version-specific selectors. This makes the plan reusable across $v_6$ 8– $v_6$ 9 without explicit DOM- or coordinate-level alignment.

This plan-centric formulation is the defining feature of TimeTraj. Human effort is concentrated in a single refinement step per goal rather than repeated across versions, and the stable object becomes the plan rather than the trajectory.

3. Multi-version teacher rollouts and trajectory collection

Given the planning dataset $\mathcal{D}_{\text{goal}}$ 0 and a set of environment versions $\mathcal{D}_{\text{goal}}$ 1, with $\mathcal{D}_{\text{goal}}$ 2 in TimeWarp, a teacher policy $\mathcal{D}_{\text{goal}}$ 3 implemented with GPT-5 executes each plan on every version and produces trajectories (Ishmam et al., 5 Mar 2026).

A trajectory for one task on one version is written as

$\mathcal{D}_{\text{goal}}$ 4

where $\mathcal{D}_{\text{goal}}$ 5 is the observation history and

$\mathcal{D}_{\text{goal}}$ 6

Here $\mathcal{D}_{\text{goal}}$ 7 denotes action tokens such as click('53'), fill('23', 'Brazil'), or send_msg_to_user(...); $\mathcal{D}_{\text{goal}}$ 8 denotes chain-of-thought or “thinking” tokens; $\mathcal{D}_{\text{goal}}$ 9 denotes planning tokens; and $g$ 0 denotes memory tokens.

The rollout procedure iterates over every $g$ 1 and every version $g$ 2. For each pair, the environment is reset, a teacher trajectory $g$ 3 is sampled, and a judge $g$ 4 evaluates the trajectory against the goal, producing a binary reward $g$ 5. Successful rollouts are appended to the trajectory dataset $g$ 6.

The resulting dataset is

$g$ 7

Using this procedure, the paper reports a $g$ 8 success rate on training tasks, corresponding to 757 successful trajectories out of 768 tasks, with GPT-5 as the executor after human plan refinement (Ishmam et al., 5 Mar 2026).

A notable design choice is that TimeTraj does not explicitly align states or actions across versions: there is no explicit mapping of DOM ids or coordinates. Alignment is instead achieved implicitly through the shared plan $g$ 9, the teacher’s ability to interpret each UI, and multi-version training on the resulting trajectories.

4. TimeWarp-BC and full-response imitation

TimeTraj is paired with a specific behavior-cloning variant called TimeWarp-BC. The distinction is central. Standard behavior cloning parses teacher responses into actions $a$ 0 and trains only on those actions, with the loss

$a$ 1

This discards the non-action components $a$ 2, $a$ 3, and $a$ 4 (Ishmam et al., 5 Mar 2026).

TimeWarp-BC instead trains on the entire teacher response: $a$ 5 The student therefore imitates how the teacher thinks, how it maintains memory, how it expresses its plan step by step, and how it acts. The training pipeline is correspondingly simple: initialize the student with pretrained weights, collect plans via human-in-the-loop distillation, collect teacher trajectories across versions, and optimize the student on $a$ 6 using $a$ 7.

The paper also studies partial-response variants in which $a$ 8. The best performance is obtained when the full response is retained, $a$ 9. In the token-type ablation, using all tokens yields the best overall success, including $\mathcal{D}_{\text{plan}}$ 0 for Qwen-3 4B on $\mathcal{D}_{\text{plan}}$ 1. This is presented as evidence that reasoning, planning, and memory supervision are not ancillary but part of the effective control policy.

The reported training regime mainly targets text-only LLMs, specifically Qwen-3 4B Instruct, Qwen-3 4B Thinking, and Llama-3.1 8B Instruct. Accessibility tree input is used for training. Test-time observations can include HTML, AXTree, screenshot, and Set-of-Marks settings, but the main training setup is AXTree-based.

5. Empirical performance and ablations

The primary evaluation metric is success rate, defined as the percentage of tasks judged correct. The main comparisons are zero-shot prompting, vanilla behavior cloning on a single version ( $\mathcal{D}_{\text{plan}}$ 2), vanilla behavior cloning on pooled multi-version data but action-only targets ( $\mathcal{D}_{\text{plan}}$ 3), and TimeWarp-BC trained on TimeTraj trajectories across all versions (Ishmam et al., 5 Mar 2026).

Model (AXTree)	Zero-shot / $\mathcal{D}_{\text{plan}}$ 4 / $\mathcal{D}_{\text{plan}}$ 5 / TW	Best average success
Qwen-3 4B	20.4 / 19.5 / 18.5 / 37.7	37.7
Llama-3.1 8B	0.7 / 3.3 / 0.3 / 27.0	27.0

These figures supply the headline result associated with TimeTraj. For Qwen-3 4B, average AXTree success improves from $\mathcal{D}_{\text{plan}}$ 6 zero-shot to $\mathcal{D}_{\text{plan}}$ 7 with TimeTraj plus TimeWarp-BC. For Llama-3.1 8B, the model moves from $\mathcal{D}_{\text{plan}}$ 8 zero-shot, with $\mathcal{D}_{\text{plan}}$ 9 at $(g, p^*)$ 0, to $(g, p^*)$ 1 under TimeWarp-BC. The paper further states that these gains are consistent across Wiki, News, Shop, and Multi tasks, and that TW-trained agents maintain fairly stable success rates across versions $(g, p^*)$ 2– $(g, p^*)$ 3.

The ablation studies sharpen the interpretation. Training on a single version yields good performance on similar versions but poor transfer to dissimilar ones, whereas training on versions $(g, p^*)$ 4– $(g, p^*)$ 5 with TimeWarp-BC improves performance even on held-out $(g, p^*)$ 6, indicating cross-version generalization. When the fraction of TimeTraj data is varied, performance under TW scales roughly monotonically with data size, while standard BC on $(g, p^*)$ 7 saturates early. Token ablations show that actions alone are weakest, any non-action token type helps, and the full tuple $(g, p^*)$ 8 is best. Training also benefits from longer context windows, improving up to 64k tokens, and performance peaks around 3 epochs. In continual-learning experiments, naïve sequential fine-tuning, such as first on $(g, p^*)$ 9 and then on $p^*$ 0, causes catastrophic forgetting, which the paper presents as an argument for joint multi-version training.

6. Mechanisms, limitations, and broader significance

The paper attributes TimeTraj’s behavior to four interacting mechanisms. First, plan-based abstraction drives collection by task semantics rather than brittle UI details. Second, exposure to multiple UI variants broadens the distribution of layouts, HTML or AXTree patterns, and visual structures encountered during training. Third, TimeWarp-BC imitates reasoning rather than actions alone, preserving planning, memory, and replanning behavior needed for multi-step and multi-site tasks. Fourth, the combination of a powerful teacher and human-refined plans yields high-quality, balanced trajectories rather than collections dominated by easy versions (Ishmam et al., 5 Mar 2026).

The limitations are equally explicit. TimeTraj depends on both a strong teacher and human plan refinement. Without human refinement, the paper states that the success rate of trajectory collection drops to 60–70%, implying that 30–40% of trajectories could be missing. The method is more scalable than manual per-version recollection, but it still incurs teacher-model cost and human time, and multi-version collection scales compute roughly with the number of versions. The paper also reports action–reasoning misalignment cases in which the model’s thinking tokens support one answer but the final action emits another, and it notes brittleness in “Thinking” variants of Qwen-3, where training can improve the structure of thinking tokens but slightly degrade overall task performance.

A persistent source of confusion is terminological. In the TimeWarp paper, TimeWarp denotes the benchmark and environment suite; TimeTraj denotes the trajectory-collection algorithm based on human-refined, version-invariant plans and teacher rollouts across versions; and TimeWarp-BC denotes the full-response behavior-cloning objective. This use is specific to web agents. In separate literatures, trajectory-based supervision denotes different mechanisms, including forecast-enhanced pseudo-label refinement in semi-supervised 3D detection (Jacobson et al., 2024), trajectory-only motion priors for LiDAR single-object tracking (Fan et al., 14 Sep 2025), and recurrent mixture-density trajectory estimation for multiple object tracking (Girbau et al., 2021). Those works are conceptually adjacent in their use of temporal or trajectory structure, but they do not define the same method.

The broader significance claimed for TimeTraj is a shift from treating trajectories as the primary human-authored artifact to treating plans as the reusable asset. The paper positions this as a paradigm in which plans are collected once and then reused to gather new trajectories whenever websites evolve. It further suggests extensions beyond web navigation, including desktop apps, mobile apps, and OS-level control; a behavior-cloning phase followed by RL alignment such as PPO or DPO/DMPO; active or curriculum learning over versions; and continual-learning schemes that avoid catastrophic forgetting as new UI versions appear.