Roller

Agent trajectory collection across models and Harnesses

Roller runs tool-using agents in disposable Docker containers and stores, for every task and model combination, the native session, a unified trace, SFT training data and the generated files.

English · 简体中文
Documentation · Getting started · CLI reference · Examples

News · Architecture · Features · Quick start · Harnesses · Outputs · Benchmarks · Docs · Contributing

Introduction

Roller is infrastructure for agent runtimes that provides agent rollout and evaluation services. Users supply tasks and custom environments; Roller runs the agent in an isolated Docker container, collects the complete agent trajectory and evaluates the task result. Roller currently supports seven mainstream Harnesses, including OpenClaw, Codex and Claude Code, and five benchmarks, including WildClawBench and SkillsBench.

Roller provides the following capabilities:

• Benchmark integration. One command converts benchmark tasks into Roller tasks, collects the trajectories and grades each sample in the container where it ran.
• Batch collection. Rollouts run in parallel across tasks and models, with retries for failed attempts and Resume for interrupted runs.
• SFT data export. Each successful rollout yields a messages + tools training record; rollouts with compacted context are exported as separate segment records.
• Multi-turn conversations and User Simulator. User turns are predefined in the task or generated by a second model that acts as the user.
• Viewer. A built-in read-only web interface for browsing tasks, comparing models and inspecting each step.

_{Recordings of the built-in Viewer. Left: step-by-step inspection of the reasoning, tool calls and tool results of one rollout. Middle: one task compared across four models. Right: the complete Viewer layout. Select an image to view it at full size.}

News

• 2026-11-15: Roller is on PyPI as roller-agent. roller init writes the example tasks and configuration templates into the working directory.
• 2026-11-11: SFT export for compacted context. When the Task Agent compacts its context, each verified context window is exported as a separate SFT record under sft_segments/.
• 2026-11-08: QwenClawBench adapter: 100 tasks in 8 domains, with automated grading, hybrid grading and repeated runs per task.
• 2026-11-05: One-command evaluation for SkillsBench and PinchBench. SFT records support images.
• 2026-11-01: Hermes, OpenCode, DeepSeek Harness and Pi Agent added, for a total of seven Harnesses.

Architecture

Roller runs as a single host process. The Collector schedules rollouts in parallel and starts one Docker container per rollout. Inside the container, the Harness runtime executes the agent loop in a workspace that contains the declared inputs and Context. Depending on the Harness and the --wire-trace setting, model requests either pass through Roller's request proxy, which records them before forwarding, or go directly to the model API. After the last turn, Roller collects the native session and the output directory, and the trace converters write the sample to the run directory.

_{Green arrows: model calls. Dashed elements: optional components and conditional paths.}

Each rollout follows the lifecycle below. The Collector first checks whether a valid sample already exists. Otherwise it starts the container, and the Harness executes the turns. With a User Simulator, each Task Agent reply is passed to the Simulator, which returns the next user message or ends the conversation. For bench runs, the grader runs before teardown. After teardown, Roller converts the native session to the normalized trace; the Collector then either retries a failed attempt (up to --retries times) or finalizes the sample.

Features

• Unified Harness interface. OpenClaw, Codex, Claude Code, Hermes, OpenCode, DeepSeek Harness and Pi Agent read the same task format and are selected with --harness. Samples from every Harness use the same directory layout and the same normalized trace structure.
• Step-level traces. Each step in the normalized trace records the visible reasoning, tool calls, tool results, token counts and timing. With --wire-trace full, Roller also stores every request body that its proxy forwards to the model API.
• Evaluation in the task container. roller collect --bench exports the benchmark tasks, runs them and executes each grader in the container where the task ran, before teardown. Grading failures are recorded separately from zero scores, and bench-report.json aggregates the results.
• Reproducible batch collection. Roller snapshots and hashes all inputs before a container starts, and lock.json records the settings that determine sample content. --resume skips completed samples and reruns the remaining ones; if a recorded setting has changed, it reports the difference and exits. --retries N allows up to N additional attempts for each failed rollout.
• Training data with images and compaction segments. SFT records include an images field when the trace contains images. When the Task Agent compacts its context, each verified context window is exported to sft_segments/ with a target_start_index that marks the supervised messages.
• Dynamic conversations. The User Simulator runs in its own Harness, reads the conversation so far and either sends the next user message or ends the task. It can use a different Harness and model from the Task Agent.
• Local Viewer. roller view reads an existing run directory without modifying it, requires no additional dependencies and listens on 127.0.0.1 by default.

Quick start

The following procedure collects a first batch of trajectories with OpenClaw, the default Harness.

1. Installation

Requirements: Python 3.10 or later and a running Docker daemon.

# uv
uv tool install roller-agent

# pip
python -m pip install roller-agent

docker pull ghcr.io/openclaw/openclaw:2026.7.1-2

With Docker Desktop on macOS, enable Enable host networking under Settings → Resources → Network and restart Docker Desktop. To install the image offline from a docker save archive, run docker load -i <archive> instead of docker pull.

Create a working directory and write the example tasks and configuration templates into it. The remaining steps run from this directory:

mkdir roller-quickstart && cd roller-quickstart
roller init

roller init creates examples/tasks, examples/config, examples/benchmarks and examples/env, and leaves files that already exist untouched.

Install Roller from source if you want the latest changes or plan to contribute. A clone already contains examples/, so roller init is not needed there:

git clone https://github.com/Valen-Team/Roller.git
cd Roller
uv venv && source .venv/bin/activate
uv pip install -e ".[test]"

2. Model configuration

Copy the environment template, set MY_PROXY_BASE_URL and MY_PROXY_API_KEY, and export the variables to the current shell. examples/env/api.env is excluded by .gitignore.

cp examples/env/api.env.example examples/env/api.env
# Edit examples/env/api.env, then export its variables:
set -a; source examples/env/api.env; set +a

In examples/config/openclaw/models.json, set the model id to the model name used by the service. Commands reference a model as <provider>/<id>, where <provider> is the key under providers. With the example file, the model reference is my-openai-proxy/my-model. For services that support only /chat/completions, change api from openai-responses to openai-completions. Store API keys only in environment variables; do not include them in tasks, commands or version-controlled files.

3. Dry run and collection

roller collect \
  --tasks examples/tasks/tasks.jsonl \
  --model my-openai-proxy/my-model \
  --model-config examples/config/openclaw/models.json \
  --parallel 4 \
  --dry-run

A dry run parses the tasks, validates the input files and prints the planned rollouts. It does not start containers or call the model API, so it does not detect a missing image or an invalid API key. After verifying the plan, remove --dry-run, set a run name and enable one retry per failed rollout:

roller collect \
  --tasks examples/tasks/tasks.jsonl \
  --model my-openai-proxy/my-model \
  --model-config examples/config/openclaw/models.json \
  --parallel 4 --retries 1 --timeout 600 \
  --output runs --run-name quickstart

To compare models, repeat --model; each task then runs once per model. To continue an interrupted run, rerun the same command with --resume. If a setting recorded in lock.json has changed, use a new --run-name.

4. Viewer

roller view runs/quickstart

Open the URL printed in the terminal (default http://127.0.0.1:17865). The Viewer shows the messages, reasoning, tool calls, tool results and final reply of each task.

Getting started guide →

Harnesses

A Harness is the agent runtime inside the container. It starts the agent, provides its tools and calls the model API. Specify the Harness for all tasks with --harness, or for an individual task with the harness field.

Harness	Model API	Description
OpenClaw (default)	OpenAI Responses or Chat Completions	Custom and open models; multimodal input
Codex	Responses	Codex CLI with GPT or Responses-compatible services
Claude Code	Anthropic /v1/messages	Claude Code with native thinking
Hermes	OpenAI Chat Completions	Hermes Agent with terminal and file tools
OpenCode	OpenAI Chat Completions	OpenCode CLI sessions with text and file tools
DeepSeek Harness	DeepSeek Chat Completions	Official SDK with a single persistent Bash tool
Pi Agent	OpenAI Chat Completions	Pi SDK with seven tools: read, bash, edit, write, grep, find, ls

OpenClaw reads model definitions from --model-config. The other six Harnesses use --api-base and --api-key-env. In runs that combine several Harnesses, each Harness takes its own prefixed pair, for example --hermes-api-base and --hermes-api-key-env.

Every Harness can serve as the Task Agent or the User Simulator. Docker images, API settings and reasoning options differ per Harness and are described in the Harness guides: OpenClaw · Codex · Claude Code · Hermes · OpenCode · DeepSeek · Pi Agent.

Outputs

Each run is stored in one directory. Run-level files are at the top level, and each sample has its own directory under samples/:

runs/quickstart/
├── info.json            settings, progress and total usage
├── lock.json            settings compared by --resume
├── sft.jsonl            SFT records of successful, uncompacted samples
└── samples/<model>/<index>_<task>/
    ├── trace.jsonl      Harness-native session
    ├── trace_ACTF.json  unified trace: reasoning, tool calls, results, tokens, timing
    ├── trace_SFT.json   SFT record of this sample
    ├── info.json        status, attempts, usage, versions and input digests
    └── results/         files written to the task's output directory

Use sft.jsonl for training and trace_ACTF.json for analysis. trace.jsonl retains the Harness-native events for debugging and re-conversion and is not cleaned for training.

The following figure shows how each file is produced. Dashed paths are enabled by the flag shown on the arrow.

The following files are produced only under specific conditions:

• sft_segments/: written when the Task Agent compacts its context. The rollout is then excluded from sft.jsonl, and each verified context window is exported as a separate record. Segment records are listed in the sample's info.json and aggregated in the run-level sft_segments.jsonl. target_start_index identifies the first supervised assistant message; training loaders must mask all preceding messages.
• wire_trace.jsonl: written with --wire-trace full. It contains every request body that Roller's proxy forwarded to the model API. Its content can differ from the native session when a Harness compacts, truncates or rewrites context.
• conversation.json: written for User Simulator tasks. It contains the dialogue visible to both participants.

The trajectory output guide specifies when each file is written or omitted.

Reasoning

--keep-thinking is enabled by default and stores the visible reasoning returned by the model service. --thinking sets the requested reasoning level. The stored content depends on the model family:

Model family	Stored reasoning
GPT reasoning models	Visible summary or content returned by the service
Claude	Visible thinking or summary returned by the service
Open models such as Qwen and GLM	Plain-text reasoning returned by the service

When a service returns only reasoning token counts or encrypted state, reasoning_content is empty. reasoning_content contains only reasoning text returned by the service; tool arguments remain in tool_calls. The reasoning levels available for each OpenClaw model are listed in Thinking configuration.

Tasks

A task is a JSON object. A minimal task contains a schema version, an ID and a prompt:

{"schema_version":"roller.task/v1","id":"hello","prompt":"Compute 2+3. Reply with the number only."}

A task list can be a .jsonl file, a JSON array or an object of the form {"tasks": [...]}. Optional fields define files, Context, conversation turns and runtime settings:

Field	Purpose
messages	Predefined user turns for a multi-turn conversation
file_root, files.inputs	Local files copied into the workspace
files.context	Context files such as AGENTS.md, USER.md, MEMORY.md and skills, which the Harness places where the agent discovers them automatically
files.output_dir	Output directory of the agent; Roller collects its full contents
runtime	Environment variables, setup commands and task-level thinking
harness	Harness for this task (also agent_harness or task_agent.harness); overridden by --harness
user_simulator	Harness and model that act as the user and generate user turns

messages and user_simulator are mutually exclusive. All fields are specified in the task format reference; dynamic conversations are described in the User Simulator guide.

Benchmarks

Bench adapters convert benchmark tasks into Roller tasks and grade each sample in the container where it ran.

Bench	Default Harness	Scope
WildClawBench	openclaw	60 real-scenario tasks in 6 categories
SkillsBench	opencode	One built environment per task; with-skill and no-skill runs scored by official verifiers
PinchBench	openclaw	Automated, LLM-judge, hybrid and multi-session tasks
QwenClawBench	openclaw	100 tasks in 8 domains, with repeated runs per task
SWE-Bench Pro	openclaw	731 software-engineering tasks in 11 repositories, scored by hidden tests in official instance images

The following example runs WildClawBench. With the upstream repository checked out and its .env loaded, one command converts the tasks, collects trajectories, grades every sample and writes tasks.jsonl and bench-report.json to the run directory:

roller collect --bench wildclawbench --bench-root ~/WildClawBench \
  --model <provider>/<model> --model-config <models.json> \
  --harness openclaw --openclaw-image wildclawbench-ubuntu:v1.3 \
  --parallel 4 --output runs --run-name wildclaw

The same run can also be described in a YAML file and started with roller bench run --config ...; see Benchmark run configuration.

Each bench guide lists the settings that must match the upstream configuration and the environment variables required by its graders. Scores are directly comparable only when these settings match upstream. To add a bench, see Bench integration and scoring.

Documentation

New users should start with Getting started and refer to Task format when writing tasks. The complete handbook is in docs/en. To build it as a website, run python -m pip install -r docs/requirements-docs.txt followed by cd docs && make html.

Guide	Contents
Introduction	Core concepts: task, Harness, rollout, run and trace
Getting started	Installation, dry run, first collection and result verification
CLI reference	All flags, their defaults and the Harnesses they apply to
Docker builds and package mirrors	apt, npm and Python mirrors and proxies for image builds
Task format	Prompts, multi-turn messages, inputs, Context and output directories
Files, Task Bundles and result storage	Input snapshots, run layout, retries and Resume
User Simulator	Dynamic conversations driven by a second model
Trajectory outputs	Output files and their conditions; comparison of raw, normalized, SFT and wire traces
SFT format	Record structure, images and compaction segments
Viewer	Startup, ports and remote access
Bench integration and scoring	Bench runs, grading and new bench adapters
Examples (Chinese)	Runnable commands for each Harness
Coverage suite	1,624 functional test tasks across all seven Harnesses

Security and privacy

• Before a container starts, Roller rejects inputs and Context that contain symlinks or special files, escape their declared paths or exceed the size limits, and records a digest of every file.
• API keys are read from the host environment or from external configuration and are not written to run metadata.
• Only regular files and directories inside the task's output_dir are collected.
• wire_trace.jsonl stores full request text, including prompts, reasoning and tool results. Treat it as sensitive data.
• The Viewer listens on 127.0.0.1 by default. Use SSH port forwarding for remote access.

The complete rules are specified in Security and privacy boundaries.

Contributing

Report defects through Issues. New Harnesses, new benches and documentation improvements are accepted as Pull Requests. The code is organized as follows:

Area	Location
Harness adapters	src/roller/harnesses/, with trace converters in src/roller/*_actf.py
Bench adapters	src/roller/benches/
SFT export	src/roller/sft.py, src/roller/compaction_sft.py
Viewer	src/roller/viewer/

Run the test suite before submitting a pull request:

python -m pip install -e ".[test]"
python -m pytest

Contributors

Liuziyu77

yph22

SYuan03

Dodojordi

Nina-Hyn

Credica

Orion-DH

MqLeet

yuhangzang

License and acknowledgements

Roller is licensed under the Apache License 2.0.

Roller invokes the following third-party agent runtimes and benchmarks: OpenClaw, Codex, Claude Code, Hermes Agent, OpenCode, DeepSeek Harness, Pi Agent, WildClawBench, SkillsBench, PinchBench, QwenClawBench and SWE-Bench Pro. Their images, code and data are subject to their respective licenses. We thank the authors of these projects.