SETA: Scaling Environments for Terminal Agents

1 Introduction

• Terminal-agent training is difficult to scale because tasks require stateful tool coordination, executable environments, instructions, and verification without natural grounding signals.Existing synthesis approaches also lack natural difficulty control, so their task distributions can reflect source characteristics.Source: §1 · p. 2
• SETA-Synth converts diverse online sources into grounded terminal environments with execution-based verification, while SETA-Evol reshapes difficulty and category distributions around the training model’s capability frontier.SETA-Synth uses a source-adaptive architecture that separates source-format adaptation from task construction; SETA-Evol supports iterative, model-agnostic scaling.Source: §1 · pp. 2–3
• Qwen3-8B trained on SETA-Env reaches 12% pass@1 on Terminal-Bench 2.0, while DeepSeek-V4-Flash improves from 40% to 43% pass@1 and 54% to 58% pass@5.The Qwen result is reported as the highest among 8B-scale RL-trained models.Source: §1 · p. 3
• SETA-Env contains over 4,500 verified environments, including 3,255 synthesized and 1,312 evolved tasks.The contributions describe the dataset as spanning 14 categories and the largest open-source verifiable terminal RL dataset to date.Source: §1 · p. 3
• SETA reports transfer beyond terminal benchmarks, including CompileBench gains from 6.7% to 40% and CRUST-Bench gains from 15% to 24%.The introduction also reports crossbackbone gains on DeepSeek-V4-Flash.Source: §1 · p. 3

Agent environments

• Repository-based training and CLI benchmarks provide executable verification, but many are static evaluations or rely on repository tasks grounded in pull requests.Examples include SWE-bench, SWE-Gym [15], R2E-Gym, and SWE-smith [29]; InterCode and AgentBench [12] cover Bash, SQL, and Python tasks.Source: §2 · p. 3

Synthetic generation for agents

• SETA addresses broad terminal workflows by converting diverse sources into verified, trainable environments rather than relying on repository-centric supervision.Prior terminal synthesis efforts include TermiGen [35], TerminalTraj [24], and Endless Terminals [3], while SETA grounds synthesis in human-validated data.Source: §2 · p. 4

Instruction and task evolution

• Unlike text-level instruction evolution, SETA-Evol adapts environment difficulty upward or downward, or shifts context, according to the training model’s current capability.This contrasts with Evol-Instruct’s uniform difficulty increase.Source: §2 · p. 4

3.1 SETA-Synth: Verifiable Environment Synthesis from Diverse Sources

• SETA-Synth collects and groups problem–solution sources, including community Q&A, data-science and machine-learning notebooks, and curated command datasets.The pipeline is described as extensible to additional sources.Source: §3.1 · pp. 4–5
• An Idea Agent turns each source example into a source-adaptive draft, then a Datapoint Agent instantiates the draft as a complete environment.The Idea Agent combines a source-specific adapter prompt with a shared base prompt; the Datapoint Agent produces the environment, solution, tests, instructions, and configuration.Source: §3.1 · pp. 5–6
• Generated tasks must fail no-op tests and pass oracle tests; a separate judge audits tasks with 100% rollout failure and discards those classified as design flaws.The judge identified 94 tasks, around 2% of audited tasks, as design flaws.Source: §3.1 · p. 6

3.2 SETA-Evol: Adaptive Evolution for Environments

• For GRPO-style training, consistently solved or failed tasks provide little or no signal, motivating SETA-Evol to counter source-shaped difficulty and category distributions.Evolved environments pass through the Synth validation pipeline and are re-assessed on the training model.Source: §3.2 · pp. 6–7
• SETA-Evol selects per-environment mutations using model performance, targeting tasks that are challenging but learnable and diversifying tasks already in the model’s effective range.Difficulty increase adds constraints or dependencies; context shift changes domain or toolset at approximately the same difficulty; difficulty decrease removes steps or edge cases.Source: §3.2 · pp. 6–7, Table 2 · p. 7

3.3 Dataset Characterization

• 4,567 tasks span 14 tech-stack categories, with difficulty centered on medium tasks and substantial easier and harder regions.Difficulty is measured using the mean pass rate of four models after per-task-mean imputation; the pattern extends from Qwen3-8B to GPT-5.4 and Kimi-K2.5.Source: §3.3 · p. 7, Figure 3 · p. 8
• 77% of slight-decrease pairs and 60% of pooled increase-difficulty pairs move in the declared direction; 46.1% of context-change pairs cross a tech-domain category boundary.Median Qwen3-8B pass rates shift from 6% to 38% for SLIGHT_DECREASE and from 83% to 69% for the pooled increase bucket.Source: §3.3 · p. 7, Figure 4 · p. 9

3.4 Agentic RL Training

• GRPO training uses dynamic sampling and filters uniform-reward samples; a partial-progress reward based on tests passed raises the share of tasks with meaningful reward variability from 49% to 86%.A 0.2 bonus rewards trajectories that pass all unit tests.Source: §3.4 · p. 8

4.1 Experimental setup

• Training uses 560 uniformly subsampled SETA-Env environments after filtering tasks too difficult for the base model, to preserve task diversity and stable RL optimization.The main controlled Qwen3-8B run uses non-thinking mode because thinking mode often exceeds the response-length limit early in training.Source: §4.1 · p. 9

4.2 Results on Terminal Bench

• SETA training improves DeepSeek-V4-Flash Terminal-Bench 2.0 pass@1 from 40% to 43.0 ± 2.5% and pass@5 from 54% to 58%.Evaluation used a 500k-token context window and at most 200 agent iterations.Source: §4.2 · p. 10, Table 3 · p. 10
• 12% pass@1 on Terminal-Bench 2.0 for the best SETA-trained Qwen3-8B run, versus 3.6% for the base model, a 3.3× improvement.It outperforms the listed RL-trained models and approaches the 13.0% result of Nemotron-Terminal-8B, an SFT model.Source: Table 3 · p. 10, §4.2 · p. 10

4.3 Generalization to related benchmarks

• SETA (RL) improves over the Qwen3-8B base across all three code benchmarks, with especially pronounced gains on CompileBench and QuixBugs.The 8B model also surpasses the Qwen3-30B-A3B base on CompileBench and QuixBugs.Source: Table 4 · p. 11, §4.3 · p. 11

4.4 SETA-Env Incentivizes Reasoning during RL

• During RL, the model learns to reason about situations and produce correct tool calls, unlike the base model’s immediate, reactive command execution.In the Nginx task, SETA (RL) solves the task completely while both base variants fail; the thinking-mode base produces about 11× more tokens than the other base variant.Source: §4.4 · pp. 11–12

5 Discussion and Conclusion

• SETA combines SETA-Synth, which converts diverse sources into executable environments, with SETA-Evol, which adaptively expands task difficulty and diversity.The authors conclude that scalable synthesis with strong verification can support RL training for agents in interactive settings.Source: §5 · p. 12
• Experiments cover Qwen3-8B and DeepSeek-V4-Flash, but do not establish behavior across broader model scales, families, or larger training budgets.The environments are limited to terminal-based interaction; GUI and multimodal settings remain future directions.Source: §5 · p. 12
• The authors identify possible misuse for unauthorized system access or automated exploitation, and say public, non-sensitive sources and sandboxed environments partially mitigate this risk.They frame these design choices as support for responsible research, not a complete mitigation.Source: §5 · p. 12

• The main Stack Overflow question asks how to convert a date string into a Calendar object to retrieve its year and month.The asker also asks whether manual substring parsing is advisable.Source: Seed Source · p. 16
• The accepted answer parses the timestamp with SimpleDateFormat using the pattern EEE MMM dd HH:mm:ss z yyyy and Locale.ENGLISH.The passage advises setting the locale to match the environment or requirement.Source: Seed Source · p. 16
• Related posts from the main question’s Linked section provide the Idea Agent with additional reference material for expanding the source question into a richer task.The related examples concern parsing date strings and formatting Calendar instances.Source: Seed Source · p. 16
• One related post illustrates a zero-based Calendar month field, which explains why a displayed month can differ from the expected value.The related question reports March being formatted as February.Source: Seed Source · p. 16

• The task is to repair EventProcessor.java so it reads events.csv, parses timestamps, and writes a monthly event-count summary to report.txt.The visible task brief says the program currently crashes with a ParseException and may still produce incorrect output after that crash is fixed.Source: Draft Specification · p. 17
• Acceptance requires a successful run without exceptions, a generated report, and numerically correct monthly event counts.The reasoning steps include recompiling and rerunning the program before checking the report.Source: Draft Specification · pp. 17–18
• The task uses Java 17 and requires no internet access because the input data is on disk.The base image is Ubuntu 24.04.Source: Draft Specification · pp. 17–18
• The seeded Java program contains two bugs that must be fixed: a date-format parsing problem and an incorrect month value.Both are present in the seeded file, and the agent must discover and repair them.Source: Draft Specification · pp. 17–18
• The dependency chain requires compiling and running the processor, addressing the initial ParseException, then fixing the month error before report counts match expectations.The specification describes the parse failure as surfacing first.Source: Draft Specification · p. 17

Generated Task Folder

• The folder includes a task specification, environment sources and data, a solution script, and test files.The displayed tree also includes a Dockerfile and run script.Source: Generated Task Folder · pp. 18–19
• The task asks the agent to repair a Java event-log processor so it compiles, runs, and produces the expected monthly summary report.Its acceptance criteria require five monthly totals with one-based calendar-month keys.Source: Generated Task Folder · p. 19
• The task targets timestamp-parsing failure and a downstream month-reporting bug that produces incorrect output.The example source parses timestamps and constructs monthly keys; the shown changes update the timestamp format and add one to the month value.Source: Generated Task Folder · pp. 19–20

NL2Bash source adapter prompt

• NL2Bash prompts use command complexity scores to target medium tasks for scores 1–2 and hard tasks for scores 3–5.The prompt describes medium as 4–7 reasoning steps and hard as 8 or more.Source: §A.2 · p. 22
• NL2Bash prompts embed the core command in a realistic scenario that requires understanding the environment, rather than asking the agent to run the seed directly.They suggest task patterns such as file operations, log parsing, process management, and backup pipelines.Source: §A.2 · p. 22
• The NL2Bash prompt warns against making a low-complexity seed hard through unrelated requirements.It describes a focused find/awk scenario as a valuable medium task.Source: §A.2 · p. 22

StackOverflow source adapter prompt

• StackOverflow prompts extract the problem, symptoms, solution, commands, and technical stack, then inspect related questions for edge cases and interacting failures.When related files exist, combining the main question with a related one is described as usually producing stronger tasks.Source: §A.2 · p. 23
• StackOverflow task patterns include build and CI/CD failures, multi-service debugging, code migration, and network or TLS issues.The prompt says a related question can introduce a second issue that appears after the primary issue is partially fixed.Source: §A.2 · p. 23

A.3 False-Negative Example Caught by the Post-Rollout Verifier

• All five rollout trials failed the same two JSON-report tests, while all other tests passed in most trials.The failures were reported with identical assertion errors.Source: §A.3 · p. 23
• The tests enforced four report literals that the instruction did not specify, and all five rollouts chose different values for those fields.The instruction described the report in natural language without key names or literal values.Source: §A.3 · p. 23, Table 6 · p. 23
• The oracle check missed the mismatch because the same evolution agent wrote the solution and tests, while the trajectory judge uses a fresh context and independent rollout-failure evidence.Prompting the datapoint agent to self-review consistently failed because it treated its own conventions as self-evident.Source: §A.3 · p. 24

A.4 Prompts for SETA-Evol pipeline.

• Difficulty increases add meaningful steps, constraints, scale, failure handling, or deeper domain knowledge while keeping the original domain and avoiding artificial difficulty.The prompt calls for at least five distinct non-trivial steps and cautions against merely increasing the amount of repetitive work.Source: §A.4 · p. 25
• When generating multiple harder variants, the prompts require different difficulty dimensions and filter out tasks that remain too simple.Examples of distinct dimensions include error handling, scale, and multi-service coordination.Source: §A.4 · pp. 25–26
• Context shifts port a task to a genuinely different, realistic technology or domain while preserving its step count, difficulty, structural complexity, and deterministic testability.The target should be commonly used and well documented, not an obscure technology or a superficial renaming.Source: §A.4 · p. 26
• Context-shift variants must still require at least five non-trivial steps, and their draft specifications should include researched documentation and relevant configuration examples.The prompts direct the evolution agent to use web tools and include URLs and excerpts for the datapoint agent.Source: §A.4 · p. 26
• Difficulty decreases simplify tasks within the same technology by removing steps, pre-seeding files, narrowing scope, relaxing constraints, or using simpler tooling while retaining testability.The simplified task should remain non-trivial and require multiple commands rather than becoming a single copy-paste action.Source: §A.4 · pp. 26–27
• Simplified variants are exempt from the five-step threshold but must retain at least two non-trivial steps; multiple variants should simplify different dimensions.The prompt rejects trivial tasks, domain changes, and removing tests instead of reducing task scope.Source: §A.4 · p. 27
• The evolution agent must inspect the original task files, map solution steps into a DAG of capabilities, prerequisites, and expected states, and research relevant external context before designing variants.The prompt also says to write only in the provided variant directories and not modify the original task files.Source: §A.4 · pp. 27–28
• Each non-filtered variant requires a self-contained draft specification with a task description, precise agent instruction, stepwise DAG, environment setup, and one to four deterministic tests.Instructions should specify observable outcomes; the evolution agent marks skipped variants with a FILTERED file rather than writing implementation or test code.Source: §A.4 · p. 28

A.5 Within-category technology swaps

• 298/553 (53.9%) of CHANGE_CONTEXT pairs change the task’s whole category, while within-category examples swap technologies such as python+sklearn→R+caret and pytorch→tensorflow.The appendix reports 12 and 10 ML pairs for python+sklearn→R+caret, and 4 MODELTRAIN pairs for pytorch→tensorflow; the figure caption says 165 of 298 diagonal pairs make a two-sided swap and 91.3% show at least one one-sided change.Source: §A.5 · p. 29, Figure 6 · p. 30

A.6 Qualitative case studies of CHANGE_CONTEXT shifts

• Four representative CHANGE_CONTEXT cases preserve the parent task’s steps, deliverable type, and verification mode while changing its load-bearing technology.The examples span ImageMagick-to-Apache, Docker-to-Nginx, GRUB-to-Nginx, and SSH-to-Apache task pairs.Source: §A.6 · p. 31, §A.6.1 · p. 31, §A.6.2 · p. 32

A.7 Agent and Terminal Toolkit

• The CAMEL-based agent uses a sandboxed per-task Docker terminal toolkit that strips ANSI, truncates outputs at 1,000 characters, logs calls, and supports tracked sessions for timed-out commands.For RL-stable rollouts, the agent also handles truncated or text-format tool-call arguments, caps parallel calls, and logs categorical termination reasons.Source: §A.7 · pp. 34–35

A.8 Hyperparameters used for RL training

• The training appendix points readers to Tables 8 and 9 for environment configuration, infrastructure settings, and key RL hyperparameters.Source: §A.8 · p. 35

A.9 SETA-Env as SFT Training Data

• SETA (SFT) reaches 31.3% on TB 1.0 and 15.7% on TB 2.0 pass@16, improving over the Qwen3-8B base by 3.8× and 6.3×, respectively.The results use 1,112 successful trajectories filtered from 1,488 collected on SETA-Env; training uses full-parameter Qwen3-8B SFT and the same agent harness for inference.Source: §A.9 · pp. 35, 38, Table 11 · p. 38

A.10.1 Divergence 1: Diagnosing Environment Constraints

• SETA (RL) diagnoses the missing-sudo constraint and installs sudo and Nginx together, while BASE repeats the failing command and BASETHINK installs Nginx two turns later.All three models first issue sudo apt install nginx and receive “sudo: command not found.”Source: §A.10.1 · p. 38, BASETHINK – Turn 2 · p. 39, BASE – Turn 2 · p. 39

A.10.2 Divergence 2: Iterative Configuration Debugging

• SETA (RL) resolves two successive Nginx configuration errors across three turns, while the base models never reach a working configuration.Source: §A.10.2 · p. 39
• After wrapping nginx directives in http {}, the fix adds the required events block, and nginx -t reports that the syntax is ok.Source: §A.10.2 · p. 40

BASETHINK – Turn 6

• BASETHINK’s echo-to-tee attempt ends with invalid limit_req_zone arguments and an unresolved task.Source: BASETHINK – Turn 6 · p. 40

BASE – Turns 4–6

• BASE writes a partial config without log_format or a limit_req_ zone, leaving Nginx unable to start.Source: BASE – Turns 4–6 · p. 40
• SETA (RL) quotes the exact error, identifies the root cause, and applies targeted fixes; BASETHINK ends unresolved with incorrect syntax, while BASE never attempts a structured config.Source: BASE – Turns 4–6 · p. 40, BASETHINK – Turn 6 · p. 40

A.10.3 Divergence 3: Adapting to Docker Constraints

• When systemctl is unavailable in the Docker container, SETA runs nginx directly and curl confirms HTTP/1.1 200 OK and task completion.Source: §A.10.3 · p. 40

BASE – Turns 7–9

• BASE’s systemctl start fails with “Failed to connect to bus” inside the container.Source: BASE – Turns 7–9 · p. 40
• BASE installs more than 200 MB of systemd ineffectively, then retries systemctl start nginx.Source: BASE – Turns 7–9 · p. 40