SETA: Scaling Environments for Terminal Agents

Authors: Qijia Shen^1,2, Jay Rainton³, Aznaur Aliev⁴, Ahmed Awelkair^1,2,4,5, Boyuan Ma³, Zhiqi (Julie) Huang^6,7, Yuzhen Mao⁸, Wendong Fan^1,2, Philip Torr⁹, Bernard Ghanem⁴, Changran Hu³, Urmish Thakker³, Guohao Li^1,2

1. CAMEL-AI.org
2. Eigent.AI
3. SambaNova
4. KAUST
5. University of Malaya
6. Imperial College London
7. University College London
8. Stanford University
9. University of Oxford

TL;DR: In SETA, we start with building robust toolkits to empower the agent’s planning and terminal capability, and achieved SOTA performance among the same model families. We performed extensive analysis on the results, and built up the scalable environment synthesis pipeline for RL training to further improve the models’ terminal capability.

• SOTA Terminal Agent on Terminal-Bench
  • We achieved SOTA performance with a Claude Sonnet 4.5 based agent on Terminal-Bench 2.0 & a GPT-4.1 based Agent on Terminal-Bench 1.0 (SOTA compared against agents with the same model)
• Scalable RL training with synthetic terminal environments
  • We are releasing an initial synthetic dataset containing 400 terminal tasks with continuous scaling, 260 of which have been used for RLVR finetuning for a Qwen3-8B model.
• A clean agent design generalizes across training and evaluation frameworks

‍

Resources:

• Synthetic Terminal Environment:
  HuggingFace link: https://huggingface.co/datasets/camel-ai/seta-env
  Github link: https://github.com/camel-ai/seta-env
• Terminal Agent Repository: https://github.com/camel-ai/seta
• RL trained model: https://huggingface.co/camel-ai/seta-rl-qwen3-8b
• Continuous updating results Page: https://eigent-ai.notion.site/SETA-Scaling-Environment-for-Terminal-Agent-2d2511c70ba280a9b7c0fe3e7f1b6ab8

‍

Terminal provides a powerful and efficient interface for agent to complete a wide range of tasks with LLMs. Its versatility, however, also introduces significant challenges to agents as the exploration space and the breadth and complexity of tasks extend far beyond that of conventional coding agents.

In this post, we demonstrate how we leverage the CAMEL framework (https://github.com/camel-ai/camel) to build an effective terminal agent harness, focusing on the design of toolkits, which enables strong performance on Terminal-Bench (https://www.tbench.ai/leaderboard), a benchmark evaluating on real-world terminal tasks. We evaluate the agent across a range offrontier and open-source models and conduct extensive analysis of common failure modes observed in terminal tasks.

To further improve the terminal capability of open-source model, we further curated a synthetic dataset through scalable and automated synthesis and verification pipeline. We also demonstrated an example of RL training for Qwen3-8B based terminal agent to outperform the baseline model.

Our Harness Performance on Terminal-Bench

• # 1 (46.5% Accuracy) on Terminal-Bench 2.0 with Claude Sonnet (3% higher than 2nd)
  ‍CAMEL agent powered by Claude Sonnet 4.5 achieves a 46.5% success rate across 89 real-world terminal tasks, excelling at standard developer workflows—particularly Git operations (80%), DevOps automation (83%), and security analysis (75%)—where Claude's training combines effectively with CAMEL's terminal toolkit for multi-step execution.

Key efficiency insight: successful tasks averaged 79.8 tool calls versus 128.8 for failures, suggesting efficient problem-solving or strategic retreat. However, some failures reveal unproductive loops (e.g., 452 calls on metacircular evaluator), indicating limitations in progress monitoring.

Strong performance in standard workflows:

• Git operations (4/5 tasks: 80%)
  • git-multibranch (100%), fix-git (100%), git-leak-recovery (100%), configure-git-webserver (100%)
  • sanitize-git-repo (20%) [FAILED]
• DevOps workflows (3/3 tasks: 100%)
  • nginx-request-logging (100%), openssl-selfsigned-cert (40%), pypi-server (100%)
• ML model management (3/6 tasks: 50%)
  • hf-model-inference (100%), pytorch-model-cli (100%), pytorch-model-recovery (100%)
  • caffe-cifar-10 (0%), train-fasttext (0%), count-dataset-tokens (20%)
• Code security & debugging (3/3 tasks: 100%)
  • fix-code-vulnerability (100%), custom-memory-heap-crash (100%), vulnerable-secret (100%)

This reflects the scenario where Claude-CAMEL synergy performs best, with structured APIs and straightforward feedback loops enabling consistent multi-step success.

The system struggles with specialized domains:

• Cryptography (1/3 tasks: 33%)
  • feal-differential-cryptanalysis (20%), feal-linear-cryptanalysis (0%), crack-7z-hash (60%)
• Low-level compilation (1/3 tasks: 33%)
  • make-doom-for-mips (0%), compile-compcert (80%), make-mips-interpreter (0%)
• Polyglot programming (0/2 tasks: 0%)
  • polyglot-rust-c (0%), polyglot-c-py (0%)
• Advanced ML infrastructure (0/4 tasks: 0%)
  • llm-inference-batching-scheduler (40%), torch-pipeline-parallelism (0%), torch-tensor-parallelism (20%), model-extraction-relu-logits (0%)
• Bioinformatics (0/3 tasks: 0%)
  • dna-assembly (0%), dna-insert (0%), protein-assembly (0%)
• Video processing (0/2 tasks: 0%)
  • extract-moves-from-video (0%), video-processing (0%)

‍

• # 1 (35.0% Accuracy) on Terminal-Bench 1.0 with GPT-4.1 (4.7% higher than 2nd)
  GPT-4.1 performs strongly on well-defined tasks that involve clear APIs, documentation, and structured workflows—such as software engineering and ML evaluation—where its instruction following and coding capabilities have been specifically improved.

However, like other large language models,  it struggles with problems requiring deep system integration, extensive low-level programming expertise (such as memory management, hardware interfacing, or kernel-level programming), or extended sequences of trial-and-error reasoning in unfamiliar problem domains. In these contexts, successful performance requires carefully crafted prompts and iterative human feedback rather than autonomous problem-solving based on deep understanding of complex system architectures.

• (3.4% Accuracy) on Terminal-Bench 2.0 with Qwen3-8B
  ‍The three successful tasks covered a range of complexity, from the relatively straightforward modernize-scientific-stack (5 calls) to the more involved fix-ocaml-gc (41 calls). The most complex successful task involved 41 iterative tool calls, indicating that Qwen can manage multi-step workflows when provided with explicit error messages, execution outputs, and pass/fail indicators at each iteration. All of the successful cases were in the

Testing/Maintenance or ML/AI categories, suggesting the model performs reliably on code-related tasks with familiar patterns rather than on entirely novel problem domains.

‍

0% accuracy with Terminus 2 agent https://huggingface.co/open-thoughts/OpenThinker-Agent-v1-SFT

Note: The results presented here represent analysis from one complete evaluation run of all 89 tasks. We conducted 5 total evaluation runs to ensure reliability, and this analysis focuses on the detailed metrics from one representative run while noting overall consistency across runs.

Toolkits Equip the Agent with Terminal Control and Planning Capability

Terminal Toolkit: Turning LLMs into Executable Agents

Terminal-Bench tasks can’t be solved with a single command: they require managing long-running jobs, interacting with stateful programs, recovering from errors, and coordinating multi-step workflows. To support that, CAMEL provides a Terminal Toolkit that exposes safe, high-level primitives for controlled execution and session interaction. This reduces failures caused by the model’s instruction-following errors — for example, instead of asking the model to compose a complex, nested echo "..." command to write a Python script, the agent can call shell_write_content_to_file to write the file directly.

‍Design diagram of the TerminalToolkit

At a high level, the toolkit enables two essential capabilities:

1. Controlled command execution
2. Interaction with running processes

• Controlled Command Execution
  Terminal agents must be able to combine one-off short commands to explore around and long-living process running in the background without blockage. CAMEL distinguishes between blocking and non-blocking execution to support both short commands and long-running jobs‍
  • shell_exec
    Executes shell commands in either blocking mode (waiting for completion) or non-blocking mode (running in the background). This enables agents to launch servers, training jobs, or build processes without freezing execution.‍
  • shell_write_content_to_file
    Writes content directly to files, allowing agents to create scripts, configuration files, source code, or documentation as part of a workflow. This tool was found especially useful for models (e.g., Qwen3-8B) with limited instruction following capability which can struggle with multiple nested “” if usingechoto create file.

These primitives allow the agent to construct and execute solutions.

• Interaction with Running Processes
  ‍Many real-world terminal tasks involve programs that require sequential input or produce output over time. CAMEL exposes explicit controls for interacting with these sessions.‍
  • shell_write_to_process
    Sends commands or input to an active interactive process, such as a REPL, debugger, or installer prompt.E.g., play-zork task requires playing an interactive game using terminal. The task needs to spawn a non-block game session, and use this toolkit to control the actions input to the game.

Example using shell_write_to_process to interact with the terminal game

--- Starting non-blocking session at Mon Aug 25 16:48:42 2025 ---
> bash -c "cd frotz && ./frotz zork1.z5"
 West of House Score: 0 Moves: 0      ZORK I: The Great Underground Empire
Copyright (c) 1981, 1982, 1983 Infocom, Inc. All rights reserved.
ZORK is a registered trademark of Infocom, Inc.
Revision 88 / Serial number 840726
West of House
You are standing in an open field west of a white house, with a boarded front
door.
There is a small mailbox here.
>> open mailbox
open mailbox
1
Opening the small mailbox reveals a leaflet.
>> take leaflet
take leaflet
2
Taken.
>> read leaflet
read leaflet
3
"WELCOME TO ZORK!
ZORK is a game of adventure, danger, and low cunning. In it you will explore
some of the most amazing territory ever seen by mortals. No computer should be
without one!"
>> north
north
North of House4
North of House
You are facing the north side of a white house. There is no door here, and all
the windows are boarded up. To the north a narrow path winds through the trees.
>> east
east
Behind House  5
Behind House
You are behind the white house. A path leads into the forest to the east. In onecorner of the house there is a small window which is slightly ajar.
>> open window
open window
6
With great effort, you open the window far enough to allow entry.
>> enter window
enter window
Kitchen     107
Kitchen
You are in the kitchen of the white house. A table seems to have been used
recently for the preparation of food. A passage leads to the west and a dark
staircase can be seen leading upward. A dark chimney leads down and to the east
is a small window which is open.
On the table is an elongated brown sack, smelling of hot peppers.
A bottle is sitting on the table.
The glass bottle contains:A quantity of water
>> take bottle
take bottle
8
Taken.

...

‍

• shell_view
  Retrieves output from background processes without blocking, enabling the agent to monitor progress or check intermediate results. E.g., install-windows-xp task requires installing large packages which can take minutes to download and build. After the agent launched the shell session, it can come back to check from time to time.

• shell_wait
  Waits for a background process to produce new output, supporting event-driven interaction rather than blind polling.

• shell_kill_process
  Terminates running background sessions, allowing the agent to clean up failed experiments, restart services, or avoid resource exhaustion.

This design allows CAMEL agents to engage in dialogue with programs, not just fire-and-forget execution.

‍

Note-Taking Toolkit: Persistent Memory for Long-Horizon Tasks

Terminal-Bench tasks often span dozens of steps, multiple files, and branching decision paths. Relying on the LLM’s implicit context alone quickly saturates the attention and is insufficient for maintaining coherence over long executions. CAMEL therefore pairs its terminal toolkit with a persistent note-taking toolkit.

This toolkit enables agents to externalize memory, track progress, and coordinate information across different phases of execution.

• Persistent, Structured Memory
  • create_note
    Creates a new note with a title and initial content, typically used to store task goals, plans, or hypotheses.‍
  • append_note
    Adds incremental findings, command outputs, or decisions to an existing note as the task progresses.‍
  • read_note
    Retrieves the contents of a note, allowing the agent to revisit prior context, decisions, or partial results.‍
  • list_note
    Lists all available notes, providing a lightweight index of what has been documented so far.

Rather than treating memory as an opaque prompt buffer, CAMEL exposes it as a first-class, queryable resource.

Example of note-taking tool calls

Task (caffe-cifar-10)

Install the original BVLC Caffe deep learning framework (version 1.0.0) and train aconvolutional neural network to classify CIFAR-10 images. Clone Caffe to /app/caffe and build for only CPU execution, training for exactly 500 iterations. Write the training output to /app/caffe/training_output.txt and verify that the test accuracy (for 100 iterations) is no more than 5% less than train and greater than 45%. The model file should be available in the examples/cifar10 directory and be named cifar10_quick_iter_{number_of_iterations}.caffemodel.

• Create task_requirements.md

Task Requirements Checklist:
  1. Install BVLC Caffe version 1.0.0
  2. Clone Caffe to /app/caffe
  3. Build for CPU-only execution
  4. Train CNN on CIFAR-10 dataset
  5. Train for exactly 500 iterations
  6. Write training output to /app/caffe/training_output.txt
  7. Verify test accuracy (100 iterations) is:
     - No more than 5% less than train accuracy
     - Greater than 45%
  8. Model file should be at: examples/cifar10/cifar10_quick_iter_500.caffemodel
     Success Criteria:
  - Caffe 1.0.0 installed and built for CPU
  - CIFAR-10 training completed (500 iterations)
  - Training output saved to specified file
  - Test accuracy meets requirements
  - Model file exists at correct location

• Create execution_plan.md

Execution Plan:
  Phase 1: Install Dependencies
  - Install Python, Git, build tools
  - Install OpenCV, BLAS, Boost, protobuf, etc.
  - Install Caffe dependencies
    Phase 2: Clone and Build Caffe
  - Clone BVLC/caffe v1.0.0 to /app/caffe
  - Configure for CPU-only build
  - Compile Caffe
    Phase 3: Prepare CIFAR-10
  - Download CIFAR-10 dataset
  - Convert to Caffe format (lmdb)
  - Verify data preprocessing scripts
    Phase 4: Train Model
  - Navigate to examples/cifar10
  - Modify solver to train for exactly 500 iterations
  - Run training
  - Capture output to /app/caffe/training_output.txt
    Phase 5: Verify
  - Check model file exists: cifar10_quick_iter_500.caffemodel
  - Extract train and test accuracy from output
  - Verify test accuracy > 45%
  - Verify test accuracy within 5% of train accuracy
    Fallbacks:
  - If build fails: try with different dependencies
  - If training fails: check data paths, modify config files
  - If accuracy low: verify training is actually occurring

• Append progress log to task_requirements.md

Progress Before Container Restart:
  1. ✅ Installed basic dependencies (git, cmake, build-essential)
  2. ✅ Installed Caffe dependencies (protobuf, OpenCV, HDF5, Boost, ATLAS, etc.)
  3. ✅ Cloned BVLC Caffe to /app/caffe
  4. ✅ Checked out version 1.0
  5. ✅ Configured Makefile.config for CPU-only build
  6. ✅ Fixed OpenCV 4 compatibility issues:
     - Added /usr/include/opencv4 to include path
     - Fixed CV*LOAD_IMAGE*\_ constants to cv::IMREAD\_\_ in:
       - src/caffe/util/io.cpp
       - src/caffe/layers/window_data_layer.cpp
       - src/caffe/test/test_io.cpp
     - Fixed protobuf SetTotalBytesLimit API change
  7. ⏳ Build was in progress (make all) when container stopped
  
  Next Steps When Container Restarts:
  1. Check if build completed successfully
  2. If build completed: proceed with CIFAR-10 training
  3. If build failed: debug remaining issues and complete build
  4. Download CIFAR-10 dataset
  5. Configure solver for 500 iterations
  6. Train model and save output
  7. Verify accuracy requirements
  
  Build Issues Fixed:
  - OpenCV 4 compatibility (CV_LOAD_IMAGE constants)
  - Protobuf 3.x compatibility (SetTotalBytesLimit signature)
  - HDF5 library paths
  - OpenCV header paths

When the Agent Fails—and What Those Failures Reveal

Domain Knowledge Gaps

Some tasks require highly specialized knowledge that LLM doesn’t usually encounter during general training. This is known as out-of-distribution knowledge, and it shows up in areas like bioinformatics, cryptography, and advanced machine learning. When an agent lacks this context, it’s more likely to make mistakes. One potential mitigation is to improve the agent’s access to external knowledge, such as through more effective use of browser-based search tools.

In tasks where the agent completely failed (pass@5 = 0), about 37% of all tasks, we found that roughly one third of these failures are likely related to the absence of external search capabilities in the current experimental setup. These failures mostly fall into three categories:

The CAMEL’s Browser Toolkit can help bridge this gap, which we’re adding next. It gives the agent access to up-to-date references, official documentation, example code, and mature methods. Instead of guessing, the agent can look things up and follow the correct solution path, making it far more reliable on specialized tasks.

Teaching the Agent with Scalable Synthetic Environments

Seed Task Collection

We collected around 1,300 Q&A pairs to generate high-quality tasks that align with terminal-type questions. Since we can’t use the precursor datapoints to train our model, our next step is to pass them through our pipeline to generate Terminal-Bench-compatible questions.

title:
	How do I find out the name of the SSID; connected to from the command line?

answer_text_markdown:
	Run `nm-tool | grep \\*`. That should show just the line with the SSID you are connected to.\r\n\r\nEdit: The `nm-tool` utility had ceased to exist, so in 16.04 and newer releases, please use any of the methods suggested by my esteemed colleagues below.\r\n\r\nFor example: `nmcli -t -f active,ssid dev wifi | egrep '^yes' | cut -d\\' -f2` works well.

question_text_markdown:
	Neither `iwconfig` nor `iwlist` seem to be able to do this for me.

‍

Synthetic Dataset Categorization & Difficulty Distribution

Each generated task has the category and task difficulty embedded into its task.yaml file. Based on the collected seed data, we currently have 7 categories across the whole synthetic dataset: software-engineering, system-administration, security, debugging, systems-programming, networking, devops , with continuous efforts to expand the categories for more diverse training data that can cover all categories in the Terminal-Bench and beyond.

The distribution of the complexity and difficulty of the synthetic data was mostly medium-level, filling the gap between limited terminal capability of small models and difficult terminal-bench tasks, making it an ideal choice for RL training of models like Qwen3-8B/32B. We prompt the Idea Generation agent to autonomously reason about the task difficulty based on the content of the seed data.

Technical Diversity

Language Coverage: Vary programming languages while maintaining core skills
Tool Variety: Expose model to different frameworks and libraries
Problem Types: Mix debugging, building, refactoring, and configuration tasks
System Complexity: Range from few-file to multi-component systems

‍

After that, the Idea Generation Agent was asked to autonomously reason about the difficulty of the generated ideas.

Example reasoning of idea agent during evaluation of difficulty

 **Appropriate Difficulty**: Medium - requires basic Linux competency but not
 expert-level knowledge\n\n

‍

Note, only one of the tasks were considered easy in the current synthetic dataset, while most of them are medium, since technical diversity is enforced via prompt.

‍

Data Generation Pipeline

To reuse terminal-bench harness and be consistent across evaluation and training, we compose the scraped web contents to following components.

• A Docker environment (a Dockerfile and docker-compose.yaml)
• task.yaml
• solution.yaml or solution.sh
• run-tests.sh (optional if using pytest without dependencies)
• tests/ (any dependencies of the test script -- e.g. a pytest file)
• Any other dependencies of the task

‍

• Terminal Environment Generation Factory

‍

Our goal was to generate “high-quality” terminal-bench tasks. We utilized the Claude Sonnet 4.5 model via the Claude Agent SDK to ensure the quality. We first prepared the /tasks list where all the tasks’ JSON files are listed, then by running execute_agent.py, we start the generation pipeline.

It iterates through the task directory, then checks for the existence of intermediate or final outputs. We designed the pipeline to have two agents, namely the Idea Generation Agent, which transforms raw data into detailed task specifications into draft_spec.md with constraints for RL training, and the Datapoint Creation Agent, which outputs a complete, executable Terminal-Bench task given the draft_spec.md with solution and validator scripts to aid in the validation step.

Specifically, for the Idea Generation Agent, we list out workflows, reminders, constraints and quality guidelines to guide the synthesis of a clear and complete terminal task problem. For the Datapoint Creation Agent, we use the modified quickstart document intended for contributors to Terminal-Bench as the guide to agent.

A summary of our findings, along with the generated tasks and corresponding draft_spec.md files, is available in our dataset. This resource provides insight into the diversity and structure of the tasks created and illustrates their alignment with Terminal-Bench requirements.

‍

• Terminal Environment Validation Pipeline

The validation pipeline was inspired by the SWE-bench, with difference being that our solution is synthesized from Q&A pair instead of the Github PRs. It was designed to verify that the generated tasks work correctly with Terminal-Bench. Remember that we generated the solution script earlier, so to test the test case quality, you can run validate_tasks.py with the --mock flag set. Otherwise, we can keep the solution script to validate its correctness. The core of the validation pipeline is this command:

tb run --agent "oracle" --dataset-path ./path --task-id x # other arguments

‍

This command runs the Terminal-Bench harness given the dataset path and task id. We utilize the default Oracle agent to validate if our task is compatible with Terminal-Bench. Quoting what we said earlier:

Terminal-Bench evaluates agents across real-world, end to end tasks with various levels of difficulty.

The “various levels of difficulty” is not an easy target to determine, especially given our very limited ground truth data per task. To try to predetermine the difficulty, the driving wheel is given to our Idea Generation agent to spread the diversity via the system prompt. Perhaps a more arduous yet reliable way to do is to assess the success rate at runtime for each task.

Preliminary Terminal Agent RL results on Qwen3-8B

To test out the efficacy of the synthesized data, we first integrate our agentic inference workflow into training frameworks. We then used Qwen3-8B as our baseline model and RL finetuned on a subset of the synthetic data with 400 tasks. Among the complete Terminal-Bench 1.0 dataset, we first filter out the tasks which sometimes failing to build up and the tasks which the Qwen3-8B model fail to pass any unit test. After the filtration, a subset of 79 tasks were kept which we use as the evaluation the model performance before and after training.

The RL trained model managed to solve 4 new tasks compared to the baseline model.

We also compared the unit test pass ratio for each task averaged across 8 runs, and the RL trained model surpassed the baseline model. Across the 79 tasks, the averaged unit test pass ratio was also improved from 0.38 → 0.45, achieving 20.2% improvement.

The model was trained for 10 Epochs and showed positive reward improvement during the training.

Note: the reward value could be larger than 1 since we add a bonus for full completion trajectories as presented in the reward function below.

Training Recipe

Our model was trained with AReal (https://github.com/inclusionAI/AReaL) framework, but the CAMEL agent design allows convenient integration with common training frameworks. CAMEL agent supports fully asynchronous model request and tool calling for efficient rollout. We also provide an example of integration with rLLM (https://github.com/rllm-org/rllm) framework.

Example of CAMEL Agent integration with RL training framework

# pseudo code example of camel agent integrate with RL training framework
async def arun_episode(engine, data):
	# 1. Initialize the environment
	env.init()

	# 2. Start chatagent loop
	model_backend = ModelBackend(engine)
	agent = ChatAgent(model_backend)

	response = await agent.astep(task_instruction) # async multi-turn tool call

	# 3. Evaluate and return reward
	reward = await env.aeval()

	# 4. Close the environment
	env.stop()

	return reward

‍

How We Taught the Model: Reward Function Design

We followed GRPO training setup. The binary 0/1 reward based on task success or failure is too sparse for calculating advantage (the model doesn't learn from its near-misses), so we turn to calculate the unit test pass ratio for each rollout as reward. An additional bonus reward 1 was assigned to fully succeeded rollout to encourage completing the tasks. To be more specific:

Decoupled Terminal and Training Environment

During RL training, each rollout trajectory requires an independent Docker container for the terminal agent to interact with. At high concurrency (256+ containers), running these on the local training machine creates severe CPU/IO bottlenecks that significantly slow down training engine.

Therefore, we decouple the Terminal Environment from the Training Host by offloading execution to an AWS server fleet. A modular Remote Environment Manager orchestrates container lifecycles across remote hosts, exposing them via TCP to the terminal toolkit.

Architecture of Remote Docker for Scalable RLVR Training

Overcoming Challenges

1. Dynamic Filtering: To improve training efficiency, we skipped tasks that provided little learning signal: tasks with consistent reward among all trajectories. Training was focused only on tasks where the model showed partial success and thus had room to improve.

2. Retry Loop: Small models like Qwen3-8B sometimes struggle with formatting (e.g., json format compliancy during tool calling). Instead of exiting the tool calling loop, the error message will be treated as tool call output prompting model to correct the format in the response of next iteration. This retry mechanism encourages the model to improve the instruction following capability of tool calling.

Acknowledgements

We are grateful to the AReal, rLLM, Terminal-Bench, and SambaNova teams for support; Pengxiang Li for helpful discussions; and the open-source repository terminal-bench-rl (https://github.com/Danau5tin/terminal-bench-rl).