Terminal-Corpus: Executable Terminal Resources

• Terminal-Corpus is a class of terminal-grounded resources that provide executable, shell-native tasks for agent training, evaluation, and evidence verification.
• It integrates synthesized expert trajectories, reinforcement learning environments, and benchmark suites with metrics like pass@k and trajectory pass ratios.
• Robust data engineering and DMPO optimization techniques ensure controllable synthesis, verifier hardening, and realistic terminal interactions.

Terminal-Corpus denotes a class of terminal-grounded research resources in which supervision, evaluation, or evidence access is mediated through executable command-line interaction rather than static text alone. In its most explicit usage, "LiteCoder-Terminal: Scaling Long-Horizon Terminal Environments for Learning Language Agents" defines LiteCoder-Terminal as a purpose-built terminal environment corpus composed of LiteCoder-Terminal-SFT, LiteCoder-Terminal-RL, and LiteCoder-Terminal-Gen (Peng et al., 28 May 2026). Closely related work uses the same label for the large-scale supervised fine-tuning dataset produced by Terminal-Task-Gen (Pi et al., 24 Feb 2026), while benchmark and retrieval work extends the idea to general-purpose terminal-use evaluation and terminal-style corpus interaction over massive document collections (Chen et al., 26 Jun 2026, Lu et al., 12 Jun 2026). This suggests that "Terminal-Corpus" functions less as a single canonical dataset than as an emerging umbrella term for executable, verifiable, shell-native corpora.

1. Scope and principal forms

The literature attaches the notion of a terminal corpus to several distinct but technically adjacent objects: synthesized task-and-trajectory datasets for CLI agents, evaluation suites for terminal-use agents, mined corpora of terminal-related usage problems, and shell-executable interfaces for searching large text collections. The common invariant is that the terminal is not merely an output channel; it is the operative environment in which planning, state tracking, verification, and evidence resolution occur.

Resource	Primary object	Reported scale
LiteCoder-Terminal	Terminal environment corpus with SFT and RL components	11,255 expert trajectories; 602 RL environments
Terminal-Corpus via Terminal-Task-Gen	Large-scale SFT dataset for terminal agents	490,520 trajectories
TUA-Bench	General-purpose benchmark for terminal-use agents	120 tasks across five task families
DR-DCI	Retriever-steered terminal-style corpus interface	Effective from 100K to 10M documents; 20M-scale Wiki-18 QA
Terminal Lucidity corpus	Mined high-signal terminal-related question corpus	1,489 questions over a 15-year period

LiteCoder-Terminal is the most corpus-centric formulation. It replaces scraping from external repositories with controllable synthesis, producing executable tasks, expert interaction traces, and verifier artifacts end-to-end (Peng et al., 28 May 2026). Terminal-Task-Gen, by contrast, defines Terminal-Corpus as a mixed supervised dataset combining prompt-to-terminal adapters with synthetic generation, optimized for scaling studies and data-engineering ablations (Pi et al., 24 Feb 2026). TUA-Bench is primarily evaluative rather than generative, but it packages realistic tasks with deterministic setup scripts and automatic verifiers, making it corpus-like in operational form (Chen et al., 26 Jun 2026). DR-DCI uses "terminal-corpus" in a different sense: a bounded visible workspace over a hidden large corpus, manipulated by shell operations such as rg, grep, find, and read after retriever-steered expansion (Lu et al., 12 Jun 2026). Terminal Lucidity contributes a usage-oriented corpus mined from Unix & Linux Stack Exchange, emphasizing terminal pain points rather than agent training (MacInnis et al., 18 Apr 2025).

2. LiteCoder-Terminal as a synthetic executable corpus

LiteCoder-Terminal consists of two datasets and one generation pipeline. LiteCoder-Terminal-SFT contains 11,255 expert trajectories spanning 10 domains: AI/ML, build tools, data science, networking, security, system administration, version control, coding, scientific computing, and games. The dataset is roughly balanced across domains, with build tools at approximately 12.0%, system administration at approximately 11.6%, networking at approximately 11.6%, and scientific computing at approximately 7.3%. On average, trajectories have 27.4 turns per interaction. They are collected in Harbor using MiniMax M2 and M2.1 through Terminus-2, OpenHands, and Claude Code, with scaffold shares of 86.6%, 7.1%, and 6.3%, respectively. After intersecting the trajectory vocabulary with tldr-pages, the corpus exhibits over 720 distinct Linux commands, including ls, cat, grep, apt, pip, cargo, make, gcc, go, python3, systemctl, ufw, curl, wget, openssl, nginx, mongod, kubeadm, grafana-cli, and lvcreate (Peng et al., 28 May 2026).

LiteCoder-Terminal-RL contains 602 executable and verifiable environments for trajectory-level preference optimization. Each environment is complete: it includes an instruction, a Dockerized setup, a solution, tests, and configuration, and supports verifier-grounded rollouts. Preference pairs are produced from two independent rollouts per environment using differences in pass ratio.

LiteCoder-Terminal-Gen is the zero-dependency synthesis pipeline that constructs these resources. It converts high-level domain specifications into executable Harbor task directories by means of five sequential agents. The Refiner Agent rewrites raw tasks into instruction.md with deterministic I/O under /app, deterministic output formats, and no solution leakage. The Environment Agent creates environment/ using an Ubuntu 24.04 base with tmux, asciinema, uv, Python 3.13, OpenHands, and Claude Code pre-installed, while enforcing the constraint, "Do NOT install any additional packages; rely solely on the base image configuration." The Solver Agent generates solution/solve.sh, beginning with a canary GUID for decontamination audits. The Verifier Agent creates tests/test.sh and tests/test_outputs.py through a mandatory four-phase adversarial iteration, Draft → Attack → Refine → Finalize. The Config Agent emits task.toml with timeouts, quotas, tags, and difficulty labels. Shared agent_logs/ and end-of-stage retries enforce causal consistency and artifact completeness.

This construction makes executability central. Tasks are not abstract prompts; they are containerized terminal environments with reference solutions and adversarially hardened verifiers. The resulting corpus is therefore both a dataset and a procedural substrate for agent rollouts.

3. Verifiability, scoring, and trajectory-level optimization

A defining property of Terminal-Corpus resources is verifier-grounded supervision. In LiteCoder-Terminal, each Harbor task directory contains instruction.md, environment/, solution/solve.sh, tests/, and task.toml. Agents act inside the container, while tests/test.sh invokes pytest and writes a binary reward to /logs/verifier/reward.txt. Tests verify existence, schema, content, and edge cases; success is determined by passing all assertions (Peng et al., 28 May 2026).

The primary benchmark metric is pass@k. For a benchmark with $N$ tasks and $k$ independent rollouts per task, aggregate pass@k is defined as

$$\mathrm{Pass@k} = \frac{1}{N}\sum_{i=1}^{N}\mathbf{1}\!\left[\max_{1 \le j \le k}\mathrm{success}(i,j)=1\right].$$

For RL environments, correctness is refined to trajectory pass ratio:

$$r(\tau)=\frac{\#\text{ passed assertions}}{\text{total assertions}}.$$

This scalar supports trajectory-level preference construction rather than single-step reward shaping.

LiteCoder-Terminal applies Direct Multi-turn Preference Optimization (DMPO) to these rollouts. Two trajectories, $\tau_w$ and $\tau_l$, are sampled independently in each environment; the higher-$r(\tau)$ rollout is the winner. DMPO then optimizes a trajectory-level Bradley–Terry-style preference objective with discounted occupancy weights

$$\alpha_t = \frac{\gamma^{t-1}(1-\gamma^{T-t+1})}{1-\gamma^T},$$

pairwise score difference $\Delta(\tau_w,\tau_l)$ defined over log-ratios against a fixed reference policy $\pi_{\mathrm{ref}}$, and loss

$k$0

The paper motivates this design by treating multi-turn interactions as stateful trajectories, thereby avoiding the "single-step bandit" simplification.

The broader ecosystem makes the same verifier-first commitment in different ways. Terminal-Task-Gen uses pytest-based verification with weighted tests and partial credit, while TUA-Bench evaluates success by inspecting final environment state and produced artifacts. This convergence indicates that Terminal-Corpus research treats automatic execution checks as the principal mechanism for trustworthy supervision and evaluation.

4. Data engineering and alternative corpus construction

"On Data Engineering for Scaling LLM Terminal Capabilities" formalizes a second major construction paradigm. Its Terminal-Task-Gen pipeline yields Terminal-Corpus through two streams: dataset adaptation and synthetic task generation. The adapter stream converts 163K Stage-2 math prompts, 79K Stage-2 code prompts filtered to 35K, and 127K SWE instances filtered and deduplicated to 32K unique prompts into Terminus 2 tasks. The synthetic stream includes seed-based generation from problem descriptions and optional reference solutions, and skill-based generation from a curated taxonomy spanning nine domains: data processing, data querying, data science, debugging, dependency management, file operations, scientific computing, security, and software engineering (Pi et al., 24 Feb 2026).

Skill-based generation composes 3–5 primitive skills per task and outputs XML-tagged sections <prompt>, <tests>, <weights>, <info>, <files>, and <test_requirements>. Shared execution structure follows the standardized Terminal-Bench layout with instruction.md, task.toml, environment/Dockerfile, solution/solve.sh, and tests/test.sh. Unlike LiteCoder-Terminal, Terminal-Task-Gen relies on nine pre-built domain Docker images that pre-install common dependencies, while still allowing agents to install additional runtime packages.

The resulting Terminal-Corpus contains 226,313 adapter-derived samples and 264,207 synthetic samples, for a combined scale of 490,520 trajectories when mixed for supervised fine-tuning. The paper’s ablations make several specific data-engineering claims. For synthetic tasks with Qwen3-8B, "No filter" yields 264,207 samples and $k$1 on Terminal-Bench 2.0, whereas "Complete-only" yields 104,603 samples and $k$2, and "Success-only" yields 83,448 samples and $k$3. The paper concludes that strict filtering is detrimental and adopts no filtering. It likewise reports that mixed single-stage training across all sources outperforms a two-stage adapters-to-synthetic curriculum, and that default Qwen3 context settings outperform extended 65,536-token settings, which slightly hurt performance.

These results differentiate two corpus philosophies. LiteCoder-Terminal emphasizes controllable environment synthesis and verifier hardening with reference solutions. Terminal-Task-Gen emphasizes scale, data mixing, and empirical study of filtering, curriculum, and context length. Both, however, center on executable terminal tasks rather than static instruction-response pairs.

5. Benchmarks and empirical performance

Terminal-Corpus resources are evaluated primarily on execution-grounded benchmarks. LiteCoder-Terminal reports results on Terminal Bench 1.0, 2.0, and Pro using the Terminus-2 scaffold; Terminal-Task-Gen evaluates Nemotron-Terminal on Terminal-Bench 2.0; TUA-Bench provides a broader benchmark for general-purpose terminal-use agents across office, web, system, multimedia, and expert scientific workflows (Peng et al., 28 May 2026, Pi et al., 24 Feb 2026, Chen et al., 26 Jun 2026).

System or benchmark	Setting	Reported result
LiteCoder-Terminal 32B	Terminal Bench 1.0 / 2.0 / Pro pass@1	29.06% / 18.54% / 34.00%
LiteCoder-Terminal 4B + DMPO	TB-2.0 / TB-Pro pass@1	4.78% → 6.10%; 21.50% → 23.00%
Nemotron-Terminal-8B / 14B / 32B	Terminal-Bench 2.0	13.0 ± 2.2 / 20.2 ± 2.7 / 27.4 ± 2.4
TUA-Bench strongest agent	Overall mean success rate	65.8%

LiteCoder-Terminal states that supervised fine-tuning of Qwen-family backbones on LiteCoder-Terminal-SFT yields agents that significantly outperform their base counterparts, and that DMPO on LiteCoder-Terminal-RL gives further gains. Leave-one-domain-out ablations indicate that removing "games" or "security" produces the largest average drops, which the paper interprets as evidence that these domains stress edge-case reasoning and dependency management.

Terminal-Task-Gen reports substantial improvements over Qwen3 baselines on Terminal-Bench 2.0: Qwen3-8B rises from $k$4 to $k$5, Qwen3-14B from $k$6 to $k$7, and Qwen3-32B from $k$8 to $k$9. Category breakdowns show especially large gains in Data Querying, Model Training, Data Processing, Security, SWE, System Administration, and Debugging, while Scientific Computing and Mathematics remain difficult.

TUA-Bench shifts evaluation from shell-centric technical workflows to general-purpose terminal use. It includes 120 real-world tasks across five task families, with deterministic setup and execution-based scoring in Harbor containers. Claude Code with Claude Opus 4.8 at maximum reasoning effort achieves 65.8% mean success rate, with Pass@1 of 58.8%, Pass@5 of 64.2%, and All-5 of 51.7%. The benchmark is described as unsaturated, with Office and Multimedia remaining notably difficult.

Taken together, these evaluations show two complementary trends: terminal corpora can materially improve long-horizon CLI performance on technical tasks, and current agents remain far from ceiling on broader terminal-mediated computer use.

6. Terminal-Corpus as a large-scale corpus interface

DR-DCI broadens the meaning of Terminal-Corpus from training data to evidence interface. Its starting point is that retriever-mediated systems such as BM25 and ColBERT expose only ranked snippets or bounded document views, which limits an agent’s ability to reorganize, compare, and verify evidence across documents. Direct Corpus Interaction (DCI) instead exposes shell-executable operations such as rg, grep, find, ls, read, and cat. Raw DCI, however, becomes slow and unstable at scale because filesystem-wide terminal commands over very large corpora are expensive, prone to timeouts, and can flood the agent context with irrelevant output (Lu et al., 12 Jun 2026).

DR-DCI addresses this by treating retrieval as an agent-callable workspace expansion action:

$$\mathrm{Pass@k} = \frac{1}{N}\sum_{i=1}^{N}\mathbf{1}\!\left[\max_{1 \le j \le k}\mathrm{success}(i,j)=1\right].$$0

The agent alternates between pull(query, topK) actions, which materialize newly relevant documents into a local workspace $$\mathrm{Pass@k} = \frac{1}{N}\sum_{i=1}^{N}\mathbf{1}\!\left[\max_{1 \le j \le k}\mathrm{success}(i,j)=1\right].$$1, and local DCI operations over that workspace. Pull returns newly added documents, a ranked preview, and workspace statistics. Because inter-document search and exact-span verification happen inside the bounded workspace rather than across the full corpus, terminal operations scale with $$\mathrm{Pass@k} = \frac{1}{N}\sum_{i=1}^{N}\mathbf{1}\!\left[\max_{1 \le j \le k}\mathrm{success}(i,j)=1\right].$$2 rather than $$\mathrm{Pass@k} = \frac{1}{N}\sum_{i=1}^{N}\mathbf{1}\!\left[\max_{1 \le j \le k}\mathrm{success}(i,j)=1\right].$$3.

Empirically, DR-DCI reaches 71.2% accuracy on BrowseComp-Plus, improving over raw DCI and ablated variants by up to 8.3 points while reducing tool usage, wall time, and estimated cost. With workspace-preserving context reset, accuracy improves further to 73.3%. In controlled scaling experiments, DR-DCI remains effective from 100K to 10M documents, whereas raw DCI becomes unstable and BM25 search-only baselines perform substantially worse. On a 20M-scale file-per-document Wiki-18 QA setting, DR-DCI achieves an average score of 63.0 across six benchmarks.

In this formulation, a terminal corpus is not primarily a dataset of trajectories but a bounded, dynamically materialized shell-visible document universe. This suggests that Terminal-Corpus research spans both agent training environments and terminal-native information access architectures.

7. Limitations, failure modes, and open directions

The current literature identifies several recurrent limitations. LiteCoder-Terminal notes synthetic bias, since task and domain distributions inherit biases from generator models; OS and shell coverage is narrow, with all environments based on Ubuntu Docker and predominantly GNU/Linux utilities; and verifier robustness remains imperfect, since some tasks may admit valid corner-case solutions that fail over-specified checks or, conversely, allow invalid behaviors that slip through (Peng et al., 28 May 2026). Terminal-Task-Gen similarly acknowledges that the lack of oracle solutions biases tasks toward structures amenable to programmatic verification, that pre-built domain images enforce a stable but simplified environment baseline, and that Scientific Computing and Mathematics remain weak spots (Pi et al., 24 Feb 2026).

TUA-Bench reports coverage limits of its own. The professional track is limited to a small set of expert domains and is English-only. Some applications lack mature CLI or headless support, constraining what can be represented in a terminal-only benchmark. The benchmark also requires maintenance because fixed tool versions and containers can age, while public release may expose tasks to future training contamination (Chen et al., 26 Jun 2026). Its error analysis emphasizes persistent failures on precise slide-formatting tasks, multimedia operations, brittle tool invocation, premature termination under lower time budgets, and weak execution monitoring when outputs are missing or misnamed.

DR-DCI exposes a different failure profile: tasks with weak lexical anchors may benefit less from rg- or grep-first workflows; extremely noisy corpora or layouts with many short files can fragment evidence; very long documents increase intra-document navigation difficulty; and accuracy-efficiency trade-offs depend sensitively on topK budgets, preview length, and reset triggers (Lu et al., 12 Jun 2026). Terminal Lucidity, finally, shows that terminal users continue to experience large pain concentrations around remote work, multiplexers, job control, integration, scrollback, and colors, while collaborative or social terminal features appear surprisingly infrequently in the mined question corpus (MacInnis et al., 18 Apr 2025).

A plausible implication is that future Terminal-Corpus work will be defined less by raw scale than by three interacting properties: controllable synthesis, verifier quality, and interface realism. The present corpus family already supports supervised fine-tuning, trajectory-level preference optimization, general-purpose benchmarking, and large-scale evidence navigation. The unresolved problem is not whether terminal corpora are useful, but how to make them simultaneously diverse, portable, resistant to shortcut exploitation, and representative of real terminal practice.