PaperlayerView exact revision on arXiv

Source-linked AI summary

LiteCoder-Terminal: Scaling Long-Horizon Terminal Environments for Learning Language Agents

Xiaoxuan Peng, Kaiqi Zhang, Xinyu Lu, Boxi Cao, Yaojie Lu, Hongyu Lin, Xianpei Han, Le Sun

arXiv:2605.29559v1cs.CL

TL;DR

Terminal-agent training needs scalable, diverse environments for long-horizon interactions, but existing reliance on scraped repositories limits controllability and targeted coverage. LiteCoder-Terminal-Gen synthesizes executable, verifiable environments from specifications, and models trained on its data consistently outperform their backbones, with the 32B variant reaching 34.00% pass@1 on Terminal Bench Pro.

  • Problem

    Existing terminal-agent training lacks scalable, diverse environment generation for partially observable, long-horizon tasks requiring dynamic adaptation and persistent goal orientation.

  • Method

    LiteCoder-Terminal-Gen autonomously synthesizes candidate tasks, interactive terminal environments, expert trajectories, and verification tests from high-level domain or skill specifications.

  • Results

    Training on synthesized data improves performance across Terminal Bench 1.0, 2.0, and Pro; the 32B variant achieves 34.00% pass@1 on Terminal Bench Pro.

  • Takeaways & Limitations

    Fully synthetic, executable environments provide a scalable supervision signal for mastering complex, real-world terminal interactions.

  • Takeaways & Limitations

    Generated tasks inherit biases from the LLM producing their instructions, while environments primarily use Ubuntu-based Docker images and GNU/Linux utilities.

Abstract

from arXiv · show

Mastering terminal environments requires language agents capable of multi-step planning, feedback-grounded execution, and dynamic state adaptation. However, training such agents is currently bottlenecked by a reliance on scraped external repositories, which limits domain diversity, environment controllability, and the targeting of specific capability deficits. We introduce LiteCoder-Terminal-Gen, a zero-dependency synthesis pipeline that autonomously generates executable and verifiable terminal training environments directly from domain specifications. Using this framework, we construct two large-scale resources: LiteCoder-Terminal-SFT, comprising 11,255 expert trajectories across 10 domains, and LiteCoder-Terminal-RL, featuring 602 verifiable environments for trajectory-level preference optimization. Supervised fine-tuning of Qwen-family models on our SFT dataset yields agents that significantly outperform their base counterparts. Notably, our 32B variant achieves 29.06%, 18.54%, and 34.00% pass@1 on Terminal Bench 1.0, 2.0, and Pro, respectively. Furthermore, applying Direct Multi-turn Preference Optimization (DMPO) on our RL environments yields additional performance gains. These results systematically demonstrate that fully synthetic, executable environments offer a scalable and verifiable supervision signal for mastering complex, real-world command-line workflows.

1 Introduction

LiteCoder-Terminal-Gen addresses the need for scalable, diverse terminal environments by synthesizing executable tasks, demonstrations, and scoring oracles from scratch without external repositories. The resulting SFT and RL resources improve long-horizon terminal-agent performance across model scales and Terminal Bench evaluations, with further gains from DMPO.

  • Motivation: Terminal tasks require dynamic environment adaptation and persistent goal orientation across long-horizon interactions in partially observable systems.This contrasts with patch-generation tasks evaluated in SWE-bench.
  • Method: LiteCoder-Terminal-Gen is a zero-dependency framework that autonomously generates tailored terminal environments, tasks, demonstrations, and robust scoring oracles from scratch.Its target skill definitions let synthesis focus on specific agent capability deficits.
  • Novelty: The framework eliminates scraping, filtering, and curating issues from external sources, enabling targeted training environments and trajectories to be generated on demand.This architecture departs from synthesis pipelines dependent on human-curated repositories such as GitHub or Stack Overflow.
  • Results: 29.06%, 18.54%, and 34.00% pass@1 are achieved by the best-performing 32B model on Terminal Bench 1.0, 2.0, and Pro, respectively.Supervised fine-tuning improves performance across model scales, and DMPO provides further gains for the 4B SFT model on Terminal Bench 2.0 and Pro.
  • Resources: 11,255 expert interaction trajectories comprise LiteCoder-Terminal-SFT, while LiteCoder-Terminal-RL contains 602 executable and verifiable terminal environments.The resources are open-sourced alongside the LiteCoder-Terminal agent to address the scarcity of system-level training data.

2 Related Work

Prior work has advanced repository-level software engineering and terminal-task evaluation, but long-horizon terminal mastery remains difficult because agents must track latent system states and interpret raw textual feedback. Agentic training methods are increasingly prominent, yet their data and recipes are often opaque and existing released datasets provide limited terminal-task coverage.

  • Scaling Environments for Long-horizon Terminal Tasks: Long-horizon terminal tasks remain challenging because agents must manage latent system states and interpret raw textual feedback across lengthy contexts.This challenge extends beyond pure code maintenance despite progress on repository-level software engineering tasks.
  • Scaling Environments for Long-horizon Terminal Tasks: Terminal-Bench has established rigorous evaluation protocols, while the field still lacks scalable resources for terminal-task research.
  • Language Agents Training: Agentic training has become central to recent frontier-model development, but prominent open-source methods generally do not publicly implement their core data and recipes.
  • Language Agents Training: Released subsets of agentic data generally lack coverage of terminal-task scenarios.

3 LiteCoder-Terminal-Gen: Terminal Tasks Generation at Scale

LiteCoder-Terminal-Gen is a zero-dependency pipeline that generates executable, verifiable terminal environments from domain specifications. It combines domain-conditioned task synthesis with sequential artifact generation and quality controls for training data.

  • Domain-conditioned task generation: The pipeline autonomously generates candidate terminal tasks and materializes them into executable, verifiable environments from high-level domain specifications.It targets ten domains, including AI&ML, build tools, data science, networking, security, system administration, version control, coding, scientific computing, and games.
  • Executable environment synthesis: Each raw task passes through five stages: instruction refinement, environment materialization, solution synthesis, verifier crafting, and configuration derivation.Every stage reads cumulative execution traces from a shared log directory, preserving causal consistency and preventing downstream checks from referencing nonexistent artifacts.
  • Task packaging and validation: The Harbor format packages each task as a self-contained directory containing instructions, environment setup and artifacts, a reference solution, tests, and configuration.The reference solution provides a constructive solvability check, while generated tests evaluate agent success and record rewards.
  • Verifier robustness: Verifier generation uses mandatory draft, attack, refine, and finalize phases to reject lazy solutions while accepting legitimate alternative implementations.The verifier includes a template entry point that writes a binary reward and a pytest suite containing the actual test logic.
  • Data quality control: 13-gram overlap filtering removes generated tasks resembling Terminal Bench queries, producing the decontaminated LiteCoder-Terminal-SFT dataset.Quality control also uses an LLM judge to retain trajectories exhibiting robust task-solving behavior across four behavioral dimensions.

4 Data Analysis

LiteCoder-Terminal-SFT contains 11,255 expert trajectories across 10 broadly balanced task categories, generated by three agent scaffolds. Analysis of executed commands shows that the trajectories cover over 720 distinct real Linux commands.

  • Dataset composition: 11,255 expert trajectories span 10 task categories, averaging 27.4 turns per trajectory.The categories are roughly balanced overall.
  • Dataset composition: 12.0% of trajectories come from build tools, while system administration and networking each account for 11.6%.Scientific computing is the smallest category at 7.3%.
  • Dataset composition: 86.6% of trajectories use the Terminus-2 scaffold, compared with 7.1% for OpenHands and 6.3% for Claude Code.The dataset therefore incorporates trajectories from three agent scaffolds.
  • Command analysis: Over 720 distinct real Linux commands are invoked across the 11,255 expert trajectories after filtering command tokens against the tldr-pages curated Linux command index.The analysis tokenizes the first command of every keystroke entry before intersecting the resulting vocabulary with the index.

5 Experiments

Experiments show that LiteCoder-Terminal’s synthetic SFT trajectories improve terminal-agent performance across scales, benchmarks, and sampling budgets, while DMPO further benefits harder tasks. The learned capabilities also generalize to SWE-bench, and domain ablations indicate distributed reliance on diverse task types.

  • SFT Results: 8.44, 7.82, and 16.87 absolute percentage points are the Terminal Bench 1.0 gains for the fine-tuned 4B, 30B-A3B, and 32B variants over their respective backbones.Training on LiteCoder-Terminal-SFT consistently improves performance across model scales and benchmarks.
  • DMPO Results: 6.10% versus 4.78% on Terminal Bench 2.0 and 23.00% versus 21.50% on Terminal Bench Pro are the DMPO and SFT pass@1 results, respectively.DMPO improves average performance over the SFT baseline on the harder benchmarks.
  • Domain Ablation: Removing any single domain causes only a modest average degradation, indicating distributed reliance on diverse task types rather than one critical domain.The experiment uses a leave-one-domain-out ablation of a balanced subset fine-tuned from Qwen3-4B-Instruct.
  • Test-Time Scaling: 24.4% to 40.0% is the 30B-A3B LiteCoder-Terminal increase on Terminal Bench 1.0 as sampling rises from k = 1 to k = 4, a 15.6-point gain.The increase outpaces the base model’s trajectory and indicates stronger capacity to exploit larger sampling budgets.
  • Cross-Task Generalization: 5.2% versus 1.2% for 4B and 13.0% versus 5.8% for 30B-A3B are the SWE-bench resolution rates of fine-tuned models and their base counterparts.These results demonstrate generalization despite the data pipeline not being explicitly optimized for SWE-bench.

6 Discussion

LiteCoder-Terminal-Gen synthesizes executable terminal-agent environments without external source dependencies, enabling scalable long-horizon skill coverage and improved agent performance through SFT and DMPO. Its current limitations are generator-induced task-distribution bias and reliance on Ubuntu-based GNU/Linux environments.

  • Contributions: LiteCoder-Terminal-Gen replaces source-dependent task mining with target-driven synthesis to provide accurate, scalable coverage of long-horizon command-line skills.The pipeline synthesizes executable terminal-agent environments with zero dependencies.
  • Contributions: Models fine-tuned on synthesized SFT trajectories consistently outperform their backbones across the Terminal Bench suite.The paper also reports additional gains from applying DMPO to verifier-grounded RL environments.
  • Limitations: LLM-generated task instructions can bias the resulting task distribution toward the generator model’s biases.This limitation motivates future work on reducing generator-induced distributional bias.
  • Limitations: Ubuntu-based Docker images and predominantly GNU/Linux utilities constrain environments to fixed operating-system assumptions.Extending the pipeline to other Linux distributions and operating systems could improve generalization.

A Domain-to-Task Generation Prompt

The domain-to-task prompt places an LLM in a Ubuntu Docker container to synthesize concise task descriptions for complex, multi-turn terminal problems. Its standardized format combines domain focus, objective, scenario, and a multi-item todo checklist, with the domain focus replaced for each target domain.

  • Prompt setup: The prompt instructs the agent to solve complex, multi-turn problems by interacting with a Ubuntu Docker container.The task descriptions are concise, but execution is technically demanding.
  • Task format: Each generated task specifies a concise title and identifies its domain focus, such as Data Science & Data Processing.The described Data Science prompt is used to synthesize task queries in the active sampling stage.
  • Task format: The task format states a one-sentence objective summarizing the final goal and a scenario providing realistic background or context.These fields frame the requested data science and data processing task for the agent.
  • Task format: The prompt includes a todo checklist containing 6–10 items to decompose the task into executable subtasks.The checklist is presented as a sequence of unchecked todo entries that continues as needed.
  • Cross-domain adaptation: All domains use the same prompt structure, replacing the domain focus with areas such as Networking & Security, System Administration, or AI & ML.The provided example is labeled as a domain-specific system prompt for Data Science.

B Task Filtering Prompt · C Environment Synthesis Pipeline Prompts · D Trajectory Filtering Prompt

The appendix specifies prompts for filtering infeasible terminal tasks, synthesizing executable benchmark environments through five stages, and filtering collected agent trajectories with an LLM judge. The pipeline emphasizes CPU-only feasibility, shared stage logs, fixed Docker infrastructure, reference solutions, adversarial tests, and resource-aware configurations.

  • B Task Filtering Prompt: Task filtering rejects terminal tasks that an autonomous agent cannot complete on a CPU-only, single-machine Docker environment within a reasonable timeframe.The prompt frames feasibility around terminal interaction and gives an example threshold of less than one hour.
  • B Task Filtering Prompt: The filter rejects tasks that are extreme, vague, dependent on unavailable resources or authentication, or otherwise unreasonable.Examples include building an advanced language model from scratch or creating a full operating-system kernel overnight.
  • C Environment Synthesis Pipeline Prompts: The five-stage synthesis pipeline uses a shared agent_logs/ directory so each stage can read outputs from all preceding stages.The logs provide context for task enhancement, environment and test-data creation, and later resource estimation.
  • C Environment Synthesis Pipeline Prompts: Task enhancement converts descriptions into specific, testable instruction.md files covering requirements, paths, formats, examples, edge cases, and error handling without leaking solutions.The working directory is fixed to /app.
  • C Environment Synthesis Pipeline Prompts: Environment materialization creates input data and a Dockerfile from a fixed Ubuntu 24.04 base image with pre-installed terminal tools, without installing additional packages.The generated sample files must be small, realistic, representative, and consistent with instruction.md.
  • C Environment Synthesis Pipeline Prompts: Reference solutions implement all requirements in solution/solve.sh, begin with a benchmark canary string, use /app paths, and handle specified output formats and edge cases.The quality standard requires a complete, working, clean, efficient implementation with proper input/output handling.
  • C Environment Synthesis Pipeline Prompts: Tests use tests/test.sh and tests/test_outputs.py to produce a binary reward and validate outputs, structure, content, and edge cases through four-phase adversarial iteration.Assertions are drafted, attacked with lazy-agent behaviors, refined against alternative correct implementations, and finalized.
  • D Trajectory Filtering Prompt: The LLM judge filters collected terminal-agent trajectories according to the behavioral criteria described in Section 3.This prompt defines the trajectory-filtering stage but the supplied passage does not enumerate its specific criteria.

Trajectory Filtering

Trajectory filtering evaluates agent traces for failures in adaptability, groundedness, persistence, and explicit refusal while focusing on logical problem-solving behavior. JSON-formatting deviations are explicitly excluded from capability-failure judgments.

  • Adaptability: Adaptability failures include mechanical loops that repeat commands, rigid strategies that preserve the same unsuccessful path, and failure to pivot tools or approaches after errors.A strategic pivot after analyzing an error is not classified as a loop.
  • Groundedness: Groundedness failures include ignoring tool feedback, claiming success without verification, and forgetting previously attempted and failed methods.These categories cover claims such as declaring completion after an error or assuming a file or state exists without tool verification.
  • Persistence: Persistence failure occurs when an agent voluntarily abandons an unfulfilled task after an obstacle without trying reasonable alternatives or workarounds.An abrupt log ending from external constraints is not penalized, and reconsidering before trying another approach demonstrates persistence.
  • Refusal & Stoppage: Refusal is triggered only when the agent explicitly states that it cannot or will not fulfill the request.Explicit refusal includes statements such as “I cannot assist with this” or “I am unable to generate this content.”
  • Evaluation scope: JSON formatting deviations, including field ordering or surrounding conversational text, must be ignored and not classified as rigid strategy or capability failure.The evaluation focuses solely on the logical problem-solving actions contained in the data.

E Training Details

LiteCoder-Terminal models are fine-tuned with AutoAlign and DeepSpeed ZeRO-3 using mixed-precision, long-context training. DMPO starts from LiteCoder-Terminal-4b-sft and applies trajectory-level preference optimization with specified preference-training hyperparameters.

  • Supervised fine-tuning: All models use AutoAlign with DeepSpeed ZeRO-3 parallelism on 8 GPUs per node, AdamW, and a 5 × 10−6 learning rate.Training uses a cosine scheduler, 0.04 warmup ratio, and 0.1 weight decay.
  • Supervised fine-tuning: 3 epochs, per-device batch size 2, and gradient accumulation steps 2 yield an effective batch size of 32.Training uses BF16 precision, gradient checkpointing, and a maximum sequence length of 65,536 tokens.
  • DMPO: DMPO trains LiteCoder-Terminal-4b-sft on trajectory-level preference pairs using 8 GPUs, learning rate 5 × 10−6, β = 0.1, and γ = 0.7.It uses cosine scheduling, 0.04 warmup ratio, 0.1 weight decay, 3 epochs, per-device batch size 1, gradient accumulation 4, and 65,536-token sequences.

F Broader Impacts

The work broadens access to terminal-agent research by open-sourcing its datasets and framework, while recognizing risks from stronger agents executing commands in unconstrained environments. It recommends human supervision and sandboxed use.

  • Access and Safety: Open-sourcing LiteCoder-Terminal-SFT, LiteCoder-Terminal-RL, and LiteCoder-Terminal lowers barriers to building open-source terminal and software engineering agents.This enables broader participation in research and innovation.
  • Access and Safety: Stronger terminal agents may enable malicious or unintended uses when executing commands in unconstrained environments.The paper identifies unconstrained command execution as a particular risk context.
  • Access and Safety: The authors recommend using these models under human supervision and inside sandboxes.The supplied passage states this recommendation but is truncated after “sandboxe”.
Loading 2605.29559v1…