Prime Intellect's Verifiers v1 Rewrites AI Agent Training From the Ground Up

Training agents with reinforcement learning has a dirty secret: the environment layer is usually the bottleneck. Wiring up a benchmark, an agent harness, and a sandboxed runtime into something that can generate thousands of verified rollouts per day is painful, bespoke work. Prime Intellect's verifiers v1 is a ground-up rewrite of their environment stack designed to fix exactly that.

The Three-Part Split That Changes Everything

The central idea in v1 is a clean decomposition of what used to be a monolithic "environment" into three independent pieces:

• Taskset , defines the work: the data, tools, and scoring logic. It knows nothing about how the task gets solved.
• Harness , the program that actually runs the agent: a simple ReAct loop, a CLI agent like Codex or Kimi Code, or your own custom agent.
• Runtime , where execution happens: a local subprocess, Docker, or a remote sandbox like Prime Sandboxes or Modal.

Any taskset can run under any compatible harness, inside any runtime. This sounds simple, but it's a significant unlock: you can benchmark the same coding task against Codex, Mini-SWE-Agent, and your own agent without rewriting any environment code. You can also swap from a local Docker runtime during development to a horizontally-scaled remote sandbox for production runs, with no changes to the task definition.

The Interception Server: The Trick Behind Harness-Agnosticism

Making any harness work with any taskset requires solving a hard problem: agents like Claude Code speak Anthropic's API dialect, while Codex uses OpenAI Responses. The core abstraction that makes the v1 design work is the interception server -- a verifiers-managed HTTP server that proxies requests between the agent's runtime and the inference server.

The interception server does three things at once:

• Records the full agent trace on the fly without modifying the rollout
• Normalizes API dialects (OpenAI Chat, OpenAI Responses, Anthropic Messages) into a canonical internal format
• Allows rewriting of server-side tool responses, which is useful for mitigating reward hacks during training

For scalability, interception servers are multiplexed -- one server handles a constant number of rollouts (default: 32), and a pool of interception servers is elastically scaled up or down depending on observed concurrency.

From O(n²) to O(n): The Trace Overhaul

One of the most practically important changes in v1 is how rollout traces are stored. In the old system, every turn stored the full prompt-completion pair -- meaning if your agent ran for 50 turns, turn 50 stored all 50 prior messages again. This led to a quadratic blowup in turns, making long-horizon agentic rollouts expensive to store and process.

In v1, traces are message DAGs (directed acyclic graphs): every message is stored exactly once, as a unique node linked to its predecessor. Trace size is now O(n) in turns instead of O(n²). For a 100-turn rollout where each turn is ~1K tokens, this is the difference between storing 5,000 tokens and storing 500,000 tokens. The gap widens further when traces carry heavy training data like multimodal content or router replay buffers.

Branching: Training Past the Context Window

Real agentic rollouts aren't linear sequences. Agents compact their context when it gets too long, and some harnesses spin up subagents. v1 treats these branches as first-class citizens in the message graph.

A branch is any root-to-leaf path on the message graph. Each branch represents a linear trajectory and is trainable as one contiguous sample -- meaning a trace with N branches yields N trainable samples. This makes it possible to train across compaction boundaries, effectively enabling long-horizon training past a model's context window without any special-casing in the training loop.

Harbor Integration and Supported Harnesses

Harbor has gained traction as an abstraction for agentic tasks in the community, and verifiers v1 ships with a built-in Harbor taskset adapter that makes adding any Harbor dataset trivial. Porting Terminal Bench 2 into verifiers, for example, takes about 10 lines of Python. Prime Intellect also reports alpha support for NeMo Gym and OpenEnv.

Out-of-the-box supported harnesses include:

• Codex (OpenAI)
• Kimi Code
• Terminus 2
• Mini-SWE-Agent
• Custom BYO harnesses

Running an eval is a two-step process: write a TOML config that specifies the model, taskset, and harness, then run uv run eval @ path/to/config.toml from the CLI. The same config is consumed directly by prime-rl for training, so there's no translation layer between evaluation and production training runs.

Proven in Production

Prime Intellect has been using v1 internally for all their production training runs. As a concrete example, they trained GLM-4.5-Air on ScaleSWE tasks with under-4-minute step times and 35-turn rollouts, completing 1,000 training steps in 2 days on just 6 H200 nodes.

RL environments and agent evals are basically the same thing -- dataset plus harness plus scoring rules -- but current open-source efforts generally treat them as fundamentally separate. verifiers v1 is a direct bet that unifying them under one composable abstraction will accelerate the whole field. The legacy v0 code path is now frozen and will not be actively maintained.

What's on the Roadmap

v1 ships today as a preview under the verifiers.v1 namespace. The team has flagged the following items for the 1.0.0 release:

• Multi-agent environments
• Training with any API dialect, including the upcoming Interactions format
• Full support for OpenEnv, NeMo Gym, and OpenReward

verifiers is tightly integrated with the Environments Hub, as well as the prime-rl training framework and Prime Intellect's Hosted Training platform. You can get started by installing the verifiers library and browsing the research-environments repo for working v1 examples. The official docs cover taskset authoring, harness configuration, and CLI usage end to end.