Source-linked AI summary
Recursive Synthesis for Long-Horizon Terminal Tasks
Zhongzhi Li, Yucheng Shi, Zongxia Li, Ruhan Wang, Anhao Li, Zixun Huang, Junyao Yang, Lei Ke, Ninghao Liu, Haitao Mi, Leowei Liang
TL;DR
Long-horizon terminal-agent training tasks are costly and difficult to produce at scale while keeping their instructions, environments, solutions, and verifiers consistent. RST recursively synthesizes and validates such tasks, producing 37,484 verified tasks across 15 rounds at approximately $0.05 per accepted task, with difficulty increasing and no observed ceiling in synthesis yield or validation rates.
Problem
High-quality verified long-horizon terminal-agent tasks remain expensive to produce, and existing automation does not yet provide a scalable construction method.
Method
RST recursively extends reference solutions, realigns instructions and verifiers, validates complete tasks in fresh sandboxes, and reuses accepted tasks as seeds.
Results
37,484 verified tasks were produced across 15 rounds at approximately $0.05 per accepted task, while difficulty increased and supervised fine-tuning improved two Qwen3.5 models across three terminal benchmarks by up to 10 points.
Takeaways & Limitations
After 15 rounds, synthesis yield and validation rates remained stable as task difficulty climbed, indicating that recursive synthesis can continue scaling within the evaluated setting.
Abstract
from arXiv · showhide
High-quality long-horizon training data for terminal agents is expensive to produce, often costing hundreds to thousands of dollars per task, because each task must keep the instruction, environment, reference solution, and verifier mutually consistent. Human authoring does not scale, and direct generation with large language models (LLMs) often breaks these dependencies. We present Recursive Synthetic Terminal Tasks (RST), a recursive verified synthesis framework for constructing long-horizon terminal-agent tasks at scale. Starting from verified seed tasks, RST extends the reference solution, realigns the verifier and instruction to the new workflow, validates the result in a fresh sandbox, and reuses accepted tasks as seeds for subsequent rounds. Across fifteen recursive rounds, RST produces 37,484 synthesized terminal-agent tasks at roughly $0.05 per task. Task difficulty increases substantially over rounds: the median reference solution grows from 67 to 374 lines, the median number of executed commands grows from 40 to 244, and DeepSeek-V4-Pro pass@4 drops from 90% at R1 to 2.5% at R15. To demonstrate training utility, we collect rejection-sampled Qwen3.5 trajectories on the synthesized tasks and use them for supervised fine-tuning. Fine-tuning on these trajectories improves Qwen3.5-27B and Qwen3.5-122B-A10B by up to 10 points on Terminal-Bench 2, Terminal-Bench Hard, and Long-Horizon Terminal Bench, while agentic PPO lifts Qwen3.5-27B to 49.44%, 32.00%, and 22.07% on the three benchmarks, corresponding to relative gains of 20.0%, 41.2%, and 21.9% over the base model. Moreover, after 15 rounds, the recursion shows no ceiling: synthesis yield and validation rates remain stable as difficulty keeps climbing, indicating that the process can continue well beyond the scale reported here.
1 Introduction
RST addresses the cost and consistency challenges of producing verified long-horizon terminal-agent tasks with recursive, solution-first synthesis. Across fifteen rounds, it scales task generation and training utility while increasing difficulty without an observed synthesis ceiling.
- Scalable synthesis: RST extends a seed reference solution, realigns the verifier and instruction, validates the complete task in a sandbox, and reuses valid tasks as seeds.The framework uses DeepSeek-V4-Pro to recursively produce increasingly difficult tasks and corresponding trajectories.
- Difficulty growth: 5.6×: median solution length increased across rounds, while command use grew 6.1× and instruction length grew only 1.4×.Under the strictest criterion, DeepSeek-V4-Pro pass rates fell from 72% to 4%, while GPT-5.6-sol fell from 72.2% to 7%.
- Scalable synthesis: $0.05 per passed task: fifteen rounds expanded 639 seed tasks into 37,484 verified terminal tasks without human authoring in the loop.Each accepted task carries an executable proof of solvability.
- Training utility: Up to 10 points: Qwen3.5 self-collected trajectories improved Qwen3.5-27B and Qwen3.5-122B-A10B through plain supervised fine-tuning.Improvements were measured on Terminal-Bench 2, Terminal-Bench Hard, and Long-Horizon Terminal Bench.
- No observed ceiling: After fifteen rounds, passed-task yield and candidate pass rates remained stable while structural growth and domain, operator, and rewrite-family diversity persisted.Solver pass rates nevertheless fell from above 70% to 4–7%, with no observed saturation or collapse.
2 Related Work
Prior work evaluates terminal agents on repository-level and interactive, long-horizon workflows, while separately advancing synthetic task generation and recursive self-improvement through executable or learned feedback. These approaches establish the evaluation, environment-construction, and feedback-filtering foundations surrounding terminal-agent task synthesis.
- Terminal-agent benchmarks and long-horizon evaluation: Repository-level benchmarks evaluate whether agents can modify codebases and satisfy executable tests.SWE-Bench and Multi-SWE-Bench provide representative examples.
- Terminal-agent benchmarks and long-horizon evaluation: Terminal-Bench evaluates interactive command-line workflows, while Harbor standardizes sandboxed execution and verifier-based grading.SWE-Bench++ and SWE-Marathon broaden software-engineering evaluation, and Long-Horizon-Terminal-Bench measures partial progress on stateful tasks requiring hundreds of interactions.
- Synthetic tasks and verifiable environments: Recent systems generate synthetic tasks and environments for tool use, coding, agent training, and evolving digital interaction settings.This includes scaling web, desktop, and general digital environments, as well as continual world generation and automatic environment construction.
- Recursive synthesis and agent self-improvement: Self-training, self-play, and self-rewarding methods improve reasoning models by generating examples and filtering them with learned or executable feedback.Recursive training can become unstable when filtering is weak or rewards are misspecified.
3 Preliminaries
The paper defines terminal tasks as self-contained executable problems with public configuration, an initialized environment, a reference solution, and a private verifier. It also specifies isolated-sandbox rollouts, dual validity criteria for synthesized tasks, and a fifteen-round recursive process beginning from 639 verified bootstrap tasks.
- Task representation: A terminal task comprises instruction.md, task.toml, an environment/Dockerfile, solution/solve.sh, and private verifier files tests/test.sh and tests/test_state.py.These components respectively provide the public description, runtime metadata, initial workspace, reference solution, and verifier.
- Rollout protocol: Harbor uses Terminus-2 to run each agent rollout in an isolated sandbox, exposing the public instruction and workspace while withholding the reference solution and private verifier.The agent may inspect files, execute commands, and modify the workspace; Harbor runs the verifier on the final state.
- Acceptance criteria: A synthesized task is accepted only if its reference solution passes the private verifier in a fresh sandbox and every verifier-checked requirement is public or inferable from the workspace.These conditions are called oracle validity and contract validity, respectively, and prevent hidden requirements from private tests.
- Recursive process: Fifteen synthesis rounds, R1 through R15, begin with 639 verified bootstrap tasks, which are excluded from the synthesis-round count.For r = 2, . . . , 15, selected tasks from Rr−1 are transformed and validated, and accepted candidates form Rr.
- Recursive process: Accepted tasks can seed later synthesis rounds, supply verifier-based reinforcement learning, and provide successful rollouts retained as supervised fine-tuning trajectories.This connects task acceptance to both subsequent synthesis and downstream training data.
4 Method
RST recursively synthesizes harder terminal-agent tasks by extending verified workflows while realigning their solutions, environments, verifiers, and instructions. Candidates undergo static and sandbox validation, and accepted tasks seed later rounds and support verifier-based RL and supervised fine-tuning.
- Recursive synthesis: Each round extends a verified seed’s executable workflow, updates its reference solution, verifier, instruction, and environment, then validates the candidate in a fresh sandbox.Accepted candidates enter the next synthesis seed pool.
- Training integration: Accepted tasks seed subsequent synthesis rounds and supply tasks for verifier-based reinforcement learning, while successful rollouts provide supervised fine-tuning trajectories.The verified pool connects recursive task generation with both training pathways.
- Recursive synthesis: The four-stage pipeline selects a feasible rewrite operator, defines expected outcomes, preserves task consistency, audits candidates, and applies bounded repair to recoverable failures.Audits include static checks, anti-shortcut checks, leakage checks, and fresh-sandbox validation.
- Rewrite design: 40 rewrite operators span five families covering configuration, data and schema, filesystem and resources, build and artifacts, and runtime, tooling, and diagnostics.Operators are selected after inspecting each seed’s files, tools, dependencies, and existing workflow.
- Rewrite design: The generator first extends executable behavior and runtime conditions, modifies the environment, then updates the verifier to reject shortcuts and revises the public task specification.Environment changes can add dependencies, tools, files, fixtures, services, permissions, paths, limits, and runtime settings.
- Validation: Validation first removes duplicates, missing files, invalid metadata, and leaked verifier details; surviving candidates run their reference solutions and private verifiers in fresh sandboxes, with limited approved-file repairs before discard.Candidates whose reference solution passes the private verifier are designated oracle-passed.
5 Experiments
Across fifteen rounds, recursive synthesis remains stable while producing increasingly complex, instruction-aligned, difficult, and diverse terminal tasks. Training on synthesized trajectories improves performance across model sizes and terminal benchmarks, while PPO reward also increases during training.
- Synthesis stability: 498.2–572.2 passed tasks per 1,000 seed attempts and 74.5%–81.5% candidate pass rates remain stable across fifteen rounds.Passed-task yield is 530.0 in R15 versus 551.6 in R1, while candidate pass rate is 78.0% versus 77.5%.
- Structural growth: 374 median solution lines, 244 commands, 71 unique CLI tools, 45 control-flow operations, 14 file operations, and 57 verifier assertions in R15 mark substantial executable growth from R1.Instruction length grows more slowly, from 85 to 122 words, compared with solution length increasing from 67 to 374 lines.
- Instruction alignment: 63.5% hidden-check protection and 0.57 median requirement coverage in R15 coincide with lower short-instruction risk and fewer weakly grounded tasks.Short-instruction risk falls from 41.6% to 7.5%, while weakly grounded tasks decline from 32.8% to 1.2%.
- Task difficulty: 2.5% DeepSeek-V4-Pro pass@4 and 0.170 mean partial credit in R15, down from 90% and 0.970 in R1, show sharply increased task difficulty.The solver and inference configuration remain unchanged across rounds, and failed attempts below half of verifier checks rise from 0% to 97.5%.
- Diversity: 2.26–2.31-bit rewrite-family entropy and 0.464 median R15 nearest-neighbor similarity preserve diversity without collapse into duplicates.The largest rewrite family represents only 24.9%–28.9% of accepted tasks, and a typical R15 task shares fewer than half of combined tokens with its closest neighbor.
- Training utility: 47.9% Terminal-Bench 2 performance for Qwen3.5-27B and 49.4% for Qwen3.5-122B-A10B at three synthesis rounds exceed their respective base-model scores.Performance improves monotonically across training stages on both model sizes and transfers across Terminal-Bench 2, Terminal-Bench Hard, and Long-Horizon Terminal Bench.
6 Conclusion
RST recursively constructs verified terminal-agent tasks by extending workflows, aligning instructions and verifiers, and validating candidates in fresh sandboxes. Across fifteen rounds, it scales task production economically while increasing difficulty substantially and supplying tasks for verifier-based reinforcement learning.
- 6 Conclusion: RST extends each reference solution, updates the verifier and public instruction to match, and validates the complete candidate in a fresh sandbox.Candidates are accepted only when the reference solution passes the private verifier and every tested requirement is stated or discoverable.
- 6 Conclusion: 37,484 verified tasks were produced across fifteen synthesis rounds at approximately $50 per 1,000 accepted tasks while maintaining stable validation yield.Accepted tasks seed subsequent rounds and directly form the task pool for verifier-based reinforcement learning.
- 6 Conclusion: 5.6× median solution-length growth and 6.1× command-use growth from R1 to R15 coincided with only 1.4× instruction-length growth.DeepSeek-V4-Pro pass@4 fell from 90% to 2.5%, while mean partial credit fell from 0.970 to 0.170, confirming substantially harder later tasks.
A Bootstrap Seed Pool Diversity
The bootstrap pool contains 639 oracle-valid tasks, analyzed using broader domain groupings derived from the original fine-grained categories.
- A Bootstrap Seed Pool Diversity: 639 oracle-valid bootstrap tasks form the seed pool, with their domain distribution shown in Figure 4 and category mappings detailed in Table 6.The original fine-grained category labels were consolidated into broader analytical domains.
B Recursive Synthesis Implementation
RST is implemented as a manifest-driven, contract-based task factory that selects file-aware rewrites, constructs aligned solutions and verifiers, and validates candidates in fresh sandboxes. Deterministic gates, lineage-aware seed selection, and diversity constraints govern recursive round-to-round orchestration.
- Rewrite selection and contracts: 40 rewrite operators span five families and are selected by local affordance scans over instructions, solutions, verifiers, configurations, and environments.Operators are converted into transformation contracts specifying preserved behavior, terminal-native requirements, execution stages, artifacts, evidence, outputs, and rejection conditions.
- Task construction: The oracle-solution stage extends solve.sh for the new requirement, while the verifier derives semantic and state checks from the transformation contract and preserves relevant parent checks.This avoids copying incidental solution commands and rejects placeholder artifacts.
- Deterministic validation: At least three task files, eight oracle-solution lines, and twelve verifier lines must change to pass the generation-quality gate.The gate also rejects private test-path disclosures, step-by-step command recipes, and excessive implementation detail in instructions.
- Round orchestration: Passed tasks are deduplicated into the next-round pool, retaining source and lineage metadata used for scoring, deterministic selection, and recursive ancestry protection.Selection scores static risk, environment cost, rewrite metadata, and validation history before applying diversity constraints.
- Round orchestration: The standard selector targets 1,000 seeds with caps of four descendants per parent, 160 tasks per category, 320 per rewrite family, and 280 per source cohort.Constraints are relaxed only according to a predetermined schedule when they prevent reaching the target size.
C Operator Taxonomy
The synthesis factory classifies rewrite targets into five executable-difficulty families, spanning operating environments, workflows, artifacts, persistent state, and diagnostic evidence. The taxonomy is designed to cover terminal complexity while enabling observable, automatically verifiable task transformations.
- Taxonomy: Five families organize executable difficulty around runtime environment, build and execution, artifacts, configuration or persistent state, and diagnostics.The diagnostic family covers actions inferred from logs, traces, failures, permissions, or other system evidence.
- Design criteria: The division covers principal terminal-complexity sources and instantiates each family as observable file, process, command, or system-state changes for automatic verification.The criteria connect transformation mechanisms to executable and verifiable generated tasks.
D Local Filters, Preflight, and Repair Policy
RST applies local quality filters, static preflight, and sandbox-based validation before accepting synthesized tasks. Recoverable failures may trigger bounded repair, but repaired tasks must clear all validation gates without weakening semantic protections.
- Generation quality filter: Candidates are rejected for unknown operators, fewer than three tracked-file changes, fewer than eight solution-line changes, or fewer than twelve verifier-line changes.These thresholds target substantive, publicly solvable rewrites rather than measuring task difficulty.
- Static preflight: Static preflight detects malformed Dockerfiles, missing COPY sources, unavailable required artifacts, and undiscoverable promised evidence before costly sandbox validation.Missing shell-safety conventions, such as a shebang or set -e, generate warnings rather than rejection.
- Sandbox oracle validation and feedback repair: Candidates pass only when the reference solution earns full verifier reward in a fresh Daytona sandbox without an execution exception.Failures are classified as zero reward, build failure, runtime error, timeout, or unknown failure.
- Sandbox oracle validation and feedback repair: Recoverable failures enter a bounded repair loop, and repaired tasks must pass static preflight and Daytona validation again without weakening semantic checks or exposing private requirements.Tasks still failing after the configured repair rounds are excluded from the accepted manifest.
D.1 Task Quality Control and Validation
The quality-control pipeline ensures every reward-relevant condition is either stated in the instruction or discoverable from the workspace. It separates public task requirements from verifier internals and can vary instruction specificity while keeping the environment and oracle fixed.
- Requirement discoverability: Every verifier-relevant condition is classified by whether it must be stated directly, made discoverable, or omitted as non-semantic.The pipeline checks whether agents can know each reward-changing condition before acting.
- Requirement discoverability: The verifier cannot require behavior that is neither stated in the instruction nor discoverable from the workspace.This is the resulting requirement-discoverability constraint.
- Public-instruction boundary: The public instruction states the objective and undiscoverable reward-relevant conditions while pointing to local evidence instead of exposing verifier implementation details.Private test paths and oracle-solution commands remain undisclosed; local README, specification, configuration, or fixture contents need not be repeated.
- Contract-granularity variants: Five optional instruction-verifier variants span exploratory to nearly complete contracts while keeping the environment and oracle solution fixed.At lower granularities, omitted conditions are removed from the verifier; at higher granularities, retained conditions are stated.
E Synthesis Prompt Templates … STEP 5: Consistency Repair Prompt
The appendix reproduces RST’s prompt templates, showing how transformations preserve seed workflows while adding terminal-native requirements, generate aligned solutions and verifiers, maintain discoverable instructions and environments, and repair cross-file inconsistencies.
- E Synthesis Prompt Templates: RST reproduces fixed prompt instructions verbatim while replacing execution-time inputs with function-labeled angle-bracket placeholders.The templates cover seed-task files, operator cards, task contracts, and Daytona feedback.
- SYSTEM Prompt: The system prompt requires recognizable tasks, narrowly scoped file rewrites, full file contents, JSON-only output, and terminal workflows with observable artifact checks.It also bans benchmark canaries, unnecessary dependencies, network-only requirements, and acceptance criteria hidden only in tests.
- AFFORDANCE RANKING Prompt: The affordance-ranking and contract prompts select natural operators and define a controlled task chain that preserves the seed workflow while adding one terminal-native requirement.The contract emphasizes discoverability, semantic verifiability, and a workflow spanning inspection, derivation, execution, validation, and finalization.
- AFFORDANCE RANKING Prompt: At least four reward checks must cover required evidence, intermediate artifact validity, final semantic correctness, and rejection of shortcuts.The prompt also requires the public instruction to remain compact and solvable without verifier access.
- STEP 1: Oracle Solution Prompt: The oracle-solution prompt instructs implementations to preserve seed behavior, execute every contract stage in order, inspect inputs, and create meaningful expected artifacts.It forbids no-op substitutions, verifier-only hardcoding, external services, internet access, and unbounded background work.
- STEP 2: Verifier Prompt: The verifier prompt checks user-visible goals, preserved seed behavior, expected artifacts, semantic content, and distinct dense reward subchecks.It favors deterministic, fast, robust predicates and diagnostic errors without leaking a complete solution recipe.
- STEP 3: Public Instruction Prompt (Part 1/2): The instruction-rewrite prompts enforce compact, imperative public requests that point to local documentation instead of exposing schemas, path inventories, tests, or operational walkthroughs.They limit absolute paths to usually 1–2 and at most ~3 total, while requiring undiscoverable hard requirements to be published.
- STEP 4: Environment Alignment Prompt: Environment alignment uses the contract as its source of truth, defaults to no environment-file changes, and preserves self-contained, resource-bounded, locally discoverable execution.Consistency repair then audits verifier paths, solution-created paths, contract artifacts, and reward checks, fixing genuine mismatches without weakening checks or changing the selected operator.
F Training and Evaluation Implementation · DAYTONA FEEDBACK REPAIR Prompt
The implementation separates distributed SFT orchestration from experiment configuration and defines a Daytona-feedback repair workflow for correcting generated tasks. Evaluation runs base and fine-tuned Qwen3.5 checkpoints through SGLang, Harbor, and Daytona across three terminal benchmarks.
- F Training and Evaluation Implementation: The SFT launcher separates cluster orchestration from experiment configuration for distributed training.A multi-node wrapper initializes Ray and submits SLIME training as a Ray job, while a YAML launcher provides the same training configuration.
- F Training and Evaluation Implementation: The 64-GPU Qwen3.5-27B setup uses eight eight-GPU nodes, trajectory metadata records, Qwen3.5-specific masking, TP4/PP2/CP2 parallelism, Adam, cosine decay, CPU offload, and flash attention.The configuration stores terminal-agent trajectories as message and metadata records and uses optimizer CPU offload.
- DAYTONA FEEDBACK REPAIR Prompt: Daytona oracle validation supplies dynamic failure logs as the source of truth, and repairs are limited to files needed for solution/solve.sh to pass.The repair task applies to an already generated task that has been run in Daytona oracle validation.
- DAYTONA FEEDBACK REPAIR Prompt: Repairs map build failures to environment or task configuration, missing artifacts to solution generation, malformed content to generation logic, and contract disagreements to minimal verifier fixes.The rules require preserving anti-shortcut checks and prohibit weakening the verifier merely to pass.
- DAYTONA FEEDBACK REPAIR Prompt: The repair prompt keeps instruction.md compact and forbids copying verifier failures, hidden values, complete artifact lists, schema fields, reward checks, or exact assertions into it.Instruction edits are allowed only when necessary for consistency or startability, with at most two concrete entry points.
- DAYTONA FEEDBACK REPAIR Prompt: The repair response returns full contents only for changed files and restricts output paths to the specified whitelist.The whitelist includes solution/solve.sh, test files, instruction.md, environment/Dockerfile, and task.toml.
- F Training and Evaluation Implementation: Evaluation uses a local OpenAI-compatible SGLang endpoint with Harbor and Daytona to serve checkpoints, record trajectories, and launch sandbox evaluation.Each run starts the model server, checks readiness with a chat-completions request, generates a Harbor configuration, and launches evaluation.
- F Training and Evaluation Implementation: The checkpoint queue evaluates base and fine-tuned Qwen3.5-27B and Qwen3.5-122B-A10B checkpoints on Terminal-Bench 2, Terminal-Bench Hard, and Long-Horizon Terminal Bench.The three benchmarks share one serving configuration.