verifiers is Prime Intellect's environment library and the input format for prime-rl. An environment is a Python package, vf-<name>, exposing load_environment() that returns a vf.Environment: SingleTurnEnv, MultiTurnEnv, ToolEnv, StatefulToolEnv, or SandboxEnv, each with a dataset, a parser and a rubric that produces rewards. vf-eval runs an environment against any OpenAI-compatible model; prime-rl trains against it. The Environments Hub hosts hundreds.

verifiers v1 added a built-in Harbor taskset: hand it a Harbor dataset and the reward is inherited from the dataset's verifier, with no reward function to write. That is the shortest path to training on a denv environment, so it comes first.

Path 1: Harbor taskset, denv as the backend

Fig. 1 What the adapter does, call by call.

Export the environment as Harbor tasks and point the taskset at them:

denv export --harbor ops-world@ver_01… ./dist/ops-world
harbor publish ./dist/ops-world --tag v1      # optional; a local path works too

import verifiers as vf

env = vf.load_environment(
    "harbor",
    dataset="you/ops-world@v1",
    agent="claude-code",
    environment="denv.harbor:DenvEnvironment",   # Harbor's -e flag, passed through
)

Every rollout is a Harbor trial with denv as the sandbox: the task's environment is forked from the exported version in about a second, the agent runs inside with caps and no egress, the verifier writes the reward, and verifiers reads it. prime-rl sees a normal taskset. The denv deployment record for each trial is available by environment id when you need to show how a reward was produced.

Prime's own sandboxes and Modal are the other backends the taskset supports. Choose denv when the task is more than one container, when you want fork instead of rebuild across n rollouts of the same prompt, or when the environment must run inside your own cloud.

Path 2: a denv sandbox inside a verifiers environment

For a ToolEnv or SandboxEnv whose tools execute commands, denv provides the sandbox the tools run in.

import verifiers as vf
from denv import Client

class OpsEnv(vf.StatefulToolEnv):
    def setup_state(self, state, **kwargs):
        c = Client()
        sbx = c.sandbox(from_version=self.version)     # a fork of the world
        state["denv"] = sbx.id
        return state

    async def bash(self, cmd: str, state) -> str:
        """Run a shell command in the environment."""
        r = Client().exec(state["denv"], "opsbox", ["bash", "-lc", cmd], timeout_sec=120)
        return r.stdout + r.stderr

    async def cleanup(self, state):
        Client().destroy(state["denv"])

def load_environment(version: str = "ver_01…", **kwargs):
    env = OpsEnv(dataset=load_dataset("you/ops-prompts"), rubric=OpsRubric(), **kwargs)
    env.version = version
    env.add_tool(env.bash, args_to_skip=["state"])
    return env

verifiers' SandboxEnv ships with Prime's sandbox client. denv.verifiers.DenvSandboxClient matches that client's methods, create, exec, upload, download, destroy, so a SandboxEnv can switch sandbox with one constructor argument rather than the subclass above:

env = vf.SandboxEnv(sandbox_client=DenvSandboxClient(from_version="ver_01…"), ...)

Rewards with a separate grader

Fig. 2 denv verify. Grading happens on a fork, as a separate principal, after the agent is stopped.

A verifiers rubric is Python in the trainer's process and may call back into the sandbox. For a grader that must not share a process tree with the agent, add a reward function that calls Client().verify(env_id). denv stops the agent in a fork, collects the declared paths to a root-owned location, refuses special files, runs the x-denv.verifier image, and returns the reward. The rubric adds it like any other reward function, weighted as you choose. The agent's own fork stays as it was for inspection.

Rollouts at training scale

prime-rl runs many rollouts of the same prompt concurrently. With a denv version as the root, each is a fork, so the cost of n=16 is sixteen clones rather than sixteen builds or sixteen image pulls. Fork time on ZFS is roughly constant with data size; on a hosted sandbox target it is the provider's snapshot-restore time, shown in the console before training starts.

Rollout sandboxes have a TTL (default 2 hours) and are destroyed when cleanup runs or the TTL passes, whichever is first, so a crashed trainer does not leave a thousand environments running in your account.

Token capture

verifiers' interception server records the agent's tokens and logprobs from the model endpoint; denv does not take part in that. The environment and the model are on different sides of the trainer, as they should be.

Conformance

The committed conformance run installs verifiers and prime-rl in the suite's virtualenv, runs vf-eval on the Harbor taskset pointed at the hello fixture task with -e denv.harbor:DenvEnvironment, and asserts a reward of 1 from the oracle; then runs a SandboxEnv with DenvSandboxClient through one exec.

Status

Ships today. Path 1 works with any released verifiers that has the Harbor taskset, since the denv side is the Harbor adapter, which is shipped. The raw denv.Client calls in Path 2 work.

Ships today (2026-10-11). Client().verify(): agent frozen, submission collected to a root-owned copy with special files refused, graded on a fork.

Committed by this post. denv.verifiers.DenvSandboxClient matching Prime's sandbox client surface; rollout TTLs; vf-eval and SandboxEnv in the conformance suite; a published vf-denv-ops example environment on the Environments Hub.