Nemotron-Terminal: Terminal Task Fine-Tuning

• Nemotron-Terminal is a family of terminal-capable models fine-tuned with synthetic and adapted datasets tailored for terminal-task execution.
• It employs Terminal-Task-Gen to generate and adapt tasks through seed-based and skill-based methods, resulting in nearly 494K unique tasks.
• Empirical results show marked improvements with gains up to 27.4% on Terminal-Bench 2.0, emphasizing robust data engineering strategies.

Searching arXiv for the Nemotron-Terminal paper and directly related cited works to ground the article. Nemotron-Terminal is a family of terminal-capable LLMs obtained by supervised fine-tuning Qwen3-8B, Qwen3-14B, and Qwen3-32B on a large synthetic and adapted corpus of terminal tasks. The system was introduced together with Terminal-Task-Gen, a lightweight synthetic task generation pipeline, and Terminal-Corpus, a large-scale open-source dataset for terminal tasks. The reported objective is to make the data engineering practices behind terminal agents more explicit, with emphasis on filtering, curriculum learning, long context training, and scaling behavior (Pi et al., 24 Feb 2026).

1. Model family and problem setting

Nemotron-Terminal-8B, 14B, and 32B are all derived by supervised fine-tuning of Qwen3-8B, Qwen3-14B, and Qwen3-32B, respectively. The weights and tokenizer are inherited directly from the corresponding Qwen3 checkpoints. In the reported setup, the models are trained specifically for terminal-task execution rather than for general conversational use, and they are evaluated through a terminal agent stack centered on Terminus 2 (Pi et al., 24 Feb 2026).

The work positions terminal capability as a data engineering problem as much as a model architecture problem. This is reflected in two design choices. First, the training corpus is assembled from both adapted existing SFT prompt datasets and newly synthesized tasks. Second, the study explicitly compares alternative choices for data filtering, task ordering, and context length, rather than treating these as implementation details. This suggests that Nemotron-Terminal is defined less by a new base architecture than by a reproducible terminal-oriented SFT pipeline.

2. Terminal-Task-Gen and task construction

Terminal-Task-Gen is described as a two-pronged framework consisting of dataset adaptation and synthetic task generation (Pi et al., 24 Feb 2026).

In the dataset adaptation branch, the process starts from existing SFT prompt datasets in math, competitive coding, and software-engineering. The reported sources are 163 K math prompts from OpenMathReasoning to Nemotron-Cascade Stage 2, 35 K code prompts from OpenCodeReasoning to Nemotron-Cascade Stage 2, and 32 K SWE prompts from SWE-Bench, SWE-Smith, and SWE-Fixer. Each prompt is converted into a Terminal-Bench style task by filling the instruction placeholder in the Terminus 2 system prompt, instantiating required source files in the Docker environment, and appending dataset-specific suffixes such as “Write Python code…” for coding prompts. Agent trajectories are then generated by rolling out a high-performing teacher model, DeepSeek-V3.2, inside Terminus 2. Post-processing removes near-duplicates, decontaminates test overlap, and optionally filters by task completion (Pi et al., 24 Feb 2026).

In the synthetic branch, two complementary methods are used. Seed-based generation takes structured seed records of the form $$\{\text{description}, \text{optional domain tag}, \text{optional reference solution}\}$$. An LLM adapter prompt transforms each seed into a self-contained terminal task by specifying installation steps, input/output file paths, synthesizing realistic input data and pytest test suites, and enforcing tolerances for numeric outputs and boundary cases. The reported conversion principles are decomposition of complex problems, concrete constraints on input size and precision, and uniform output formats (Pi et al., 24 Feb 2026).

Skill-based generation uses a primitive skill taxonomy with 6 skill types and 9 domains, yielding approximately 60 primitives. The domains are Data Processing, Data Querying, Data Science, Debugging, Dependency Mgmt, File Ops, Scientific Computing, Security, and SWE. Specialized domain modules enumerate domain focus areas, such as SQL joins for Data Querying. A master prompt samples 3–5 primitives from the taxonomy of a chosen domain, generates XML output, parses that output into task components, and saves the result as a terminal task directory. The implementation uses nine pre-built Docker base images, one per domain, to avoid per-task Dockerfile validation, and it enforces “no solution leakage”: solutions are never shown in the prompt, and reference code is used only to derive ground-truth tests (Pi et al., 24 Feb 2026).

Across both streams, the task format is standardized into instruction.md, task.toml, environment/, solution/, and tests/. The scoring example is weighted: if tests $i=1,\ldots,k$ have weights $w_i$ with $\sum_i w_i = 1.0$, the agent solves the task if

$$\sum_{i:\,\text{test}_i\_\text{pass}} w_i \ge \text{threshold}.$$

This formulation allows partial test success to be aggregated into a pass criterion (Pi et al., 24 Feb 2026).

3. Terminal-Corpus: scale, composition, and filtering

Terminal-Corpus combines adapted datasets and synthetic tasks into a corpus of approximately 494 K unique tasks. The adapted portion contains 230 K tasks, comprising 163 K math, 35 K code, and 32 K SWE tasks. The synthetic portion contains 264 K tasks, comprising 124 K seed-based and 140 K skill-based tasks. All prompts, instructions, and tests are written in English, and the corpus covers 9 high-level domains and approximately 60 primitive skills (Pi et al., 24 Feb 2026).

Component	Task count	Notes
Dataset adapters	230 K	163 K math, 35 K code, 32 K SWE
Synthetic tasks	264 K	124 K seed-based, 140 K skill-based
Combined corpus	$\approx 494$ K	Unique tasks

The paper reports several filtering rules. Decontamination removes any prompt with $> 14$-gram overlap to Terminal-Bench 2.0 test tasks. Quality filters strip identity leaks and remove non-ASCII and Chinese characters. For trajectory filtering, the reported result is counterintuitive: for dataset adapters, “no filter” performed best; for synthetic tasks, retaining failed and incomplete runs boosted Terminal-Bench 2.0 performance from approximately 6% to approximately 12.4% (Pi et al., 24 Feb 2026).

A central implication is that terminal learning benefits from exposure to imperfect executions. The paper states this as a best practice: retaining “failed” trajectories provides richer error-recovery signals. A plausible implication is that the training signal includes not only successful action sequences but also corrective patterns that are difficult to recover from success-only datasets.

4. Training protocol, context handling, and scaling behavior

The reported SFT hyperparameters are uniform unless otherwise noted: learning rate $2 \times 10^{-5}$, AdamW with $\beta_1=0.9$, $\beta_2=0.95$, and $i=1,\ldots,k$0, cosine decay with 10% warmup, gradient clipping 1.0, 2 epochs, maximum sequence length 32 768 tokens, and global batch size 128 with micro-batch 1 GPU. The infrastructure differs by model scale: 8B and 14B use 32 GPUs arranged as 4 nodes by 8 GPUs with sequence parallelism 2, while 32B uses 128 GPUs arranged as 16 nodes by 8 GPUs. CPU offloading is performed via the veRL framework. Trajectory generation uses Harbor and Singularity on HPC, and evaluation uses Daytona Cloud sandboxes with the Terminus 2 agent and 5 randomized seeds (Pi et al., 24 Feb 2026).

The comparison between curriculum and mixed training is explicit. A single-stage mixed sampling of all tasks, proportional to dataset sizes, attained 13.03% on Terminal-Bench 2.0 for the 8B model, while a two-stage curriculum in which adapters precede synthetic data dropped to 10.39%. The study also reports no per-sample weighting or dynamic difficulty scheduling, and instead uses uniform sampling across all data sources per batch (Pi et al., 24 Feb 2026).

Long-context handling is examined rather than assumed beneficial. The default Qwen3 context window is 32 768 tokens for SFT and 40 960 tokens for evaluation. Extended windows of 65 536 tokens, with and without YaRN2, showed no gain; the default settings yielded the best results. The stated conclusion is that the majority of valuable supervision fits within 32 768 tokens and that long-tail trajectories are lower-quality (Pi et al., 24 Feb 2026).

The empirical scaling law is reported in logarithmic form:

$i=1,\ldots,k$1

where $i=1,\ldots,k$2 is fine-tuned Terminal-Bench 2.0 accuracy as a function of synthetic training data volume $i=1,\ldots,k$3. For Qwen3-8B, $i=1,\ldots,k$4 at $i=1,\ldots,k$5 total and $i=1,\ldots,k$6. For Qwen3-14B, $i=1,\ldots,k$7 and $i=1,\ldots,k$8. The paper notes that larger models both start higher and exhibit steeper gains from added data (Pi et al., 24 Feb 2026).

5. Benchmark performance and comparative position

The reported benchmark is Terminal-Bench 2.0 under the Terminus 2 agent. Baseline Qwen3 scores are 2.47% $i=1,\ldots,k$9 for Qwen3-8B, 4.04% $w_i$0 for Qwen3-14B, and 3.37% $w_i$1 for Qwen3-32B. After terminal-oriented fine-tuning, Nemotron-Terminal-8B reaches 13.0% $w_i$2, Nemotron-Terminal-14B reaches 20.2% $w_i$3, and Nemotron-Terminal-32B reaches 27.4% $w_i$4 (Pi et al., 24 Feb 2026).

Model	Baseline Qwen3	Nemotron-Terminal
8B	2.47% $w_i$5	13.0% $w_i$6
14B	4.04% $w_i$7	20.2% $w_i$8
32B	3.37% $w_i$9	27.4% $\sum_i w_i = 1.0$0

The absolute gains are reported as +10.5 percentage points for 8B, +16.2 percentage points for 14B, and +24.0 percentage points for 32B. Comparative results against larger systems are also included: Nemotron-T-14B at 20.2% outperforms GPT-OSS-120B at 18.7% and Gemini 2.5 Flash at 16.9%, while Nemotron-T-32B at 27.4% exceeds Qwen3-Coder-480B at 23.9% and matches or surpasses some 100 B+ systems (Pi et al., 24 Feb 2026).

These comparisons are significant because the paper attributes the improvement to data and training strategy rather than to a larger base model. This suggests that terminal competence, at least in the evaluated regime, is strongly bottlenecked by task construction and supervision quality.

6. Reported best practices, limitations, and open directions

The paper enumerates four high-impact decisions. First, blending dataset adapters and skill-based synthetic tasks “unlocks broad and targeted capabilities.” Second, retaining failed trajectories provides richer error-recovery signals and, on synthetic tasks, doubles Terminal-Bench 2.0 gains. Third, single-stage mixed training outperforms staged curricula. Fourth, pre-built domain Docker images drastically reduce generation cost and failure modes (Pi et al., 24 Feb 2026).

The limitations are also explicit. There are no human-verified oracle solutions, so reliance on synthetic tests may miss real-world edge cases. Long-tail, high-complexity trajectories were truncated or de-prioritized. The current approach uses only SFT, and the paper identifies reinforcement learning from execution feedback as a potential extension that could further boost planning and self-correction (Pi et al., 24 Feb 2026).

The future directions proposed in the report are RLHF or policy-gradient fine-tuning with actual task success rewards, active task generation targeting model weaknesses via closed-loop performance-driven prompts, and expansion to multilingual terminal prompts and non-Linux environments. These are not presented as established capabilities of Nemotron-Terminal, but as directions for subsequent work. A plausible implication is that the Nemotron-Terminal study defines a data-centric baseline for terminal agents rather than a final closed methodology.

7. Position within terminal-agent research

Nemotron-Terminal is notable for making the data pipeline itself a primary research object. The study does not merely release checkpointed models; it also releases Terminal-Corpus, most synthetic datasets, and the generating methodology. In that sense, its contribution lies in specifying a reproducible recipe for terminal-task SFT: convert existing reasoning and software datasets into terminal form, synthesize additional tasks from seeds and skill taxonomies, retain imperfect trajectories, mix training data in a single stage, and avoid assuming that longer context windows or more elaborate curricula necessarily help (Pi et al., 24 Feb 2026).

Within the technical report’s framing, this is intended to address a disclosure gap in terminal-agent training practice. The resulting picture is that Nemotron-Terminal is both a model family and a documented data engineering program for terminal capability scaling.