# PrimeIntellect-ai/verifiers: Environments for LLM Reinforcement Learning > verifiers is a Python library for building RL environments and evaluation harnesses for LLMs, tied to the Prime Intellect Environments Hub and prime-rl. Here is what the repository actually documents, what it leaves open, and who should adopt it. **PrimeIntellect-ai/verifiers** — Our library for RL environments + evals - Repository: https://github.com/PrimeIntellect-ai/verifiers - Stars: 4,655 · Forks: 686 - Language: Python - License: MIT - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/primeintellect-ai-verifiers ## What verifiers is, and the problem it addresses Training a language model with reinforcement learning needs more than a dataset. It needs an environment: a task distribution, a way to run a model against each task, and a scoring function that turns the model's output into a reward signal. Most teams end up writing that scaffolding themselves, once per task family, and the scaffolding is where the bugs live. verifiers is Prime Intellect's library for that layer. The README describes it as "our library for creating environments to train and evaluate LLMs." The pyproject.toml description is more specific: "Verifiers: Environments for LLM Reinforcement Learning." The keyword list in the same file names the intended shape of the work: reinforcement-learning, grpo, environments, multi-turn, agents, agentic-rl, tool-use, train, eval, harness. The audience is narrow and identifiable. This is for engineers and researchers who are already doing RL post-training or agentic evaluation and who want to package a task as a reusable environment rather than a one-off script. The README states that the library is tightly integrated with the Environments Hub, the prime-rl training framework, and the Hosted Training platform. That sentence is the honest summary of the project's centre of gravity. ## How the library is structured: environments, scoring, and the Prime stack The repository layout tells you more than the README does. At the top level there are environments/, examples/, configs/, docs/, skills/, scripts/, and the verifiers/ package itself. The presence of a dedicated environments/ directory alongside the library package suggests environments are treated as first-class artifacts that live outside the core code, which is consistent with a hub model where environments are published and shared. The README points at docs/ for "short, human-written guides and overviews about the architecture" and at AGENTS.md plus skills/ for coding agents, which it says "go into more details." That is an unusual documentation split: the human-facing architecture notes are deliberately short, and the deeper material is written for agent consumption. If you want to understand the internal data flow before writing code, the README directs you to docs/ rather than explaining the flow inline. The README does not document the reward-scoring interface, the rollout loop, or how a multi-turn episode terminates. The dependency list in pyproject.toml is the clearest statement of architecture. It includes anthropic and openai for model access, pydantic and prime-pydantic-config for typed configuration, pyzmq and msgpack for message passing, uvicorn and httpx for serving and HTTP, prime-tunnel, prime-sandboxes and prime-runs for Prime Intellect's execution and run infrastructure, and mcp pinned exactly at 2.0.0 for tool use. renderers[multimodal] handles output rendering. The picture is a library that expects to talk to remote model endpoints, to sandboxed execution, and to a training process, over typed configs and a message bus. That is a heavier architecture than a single-process eval script, and it is a deliberate one. ## Installing verifiers and running a first environment The README recommends installing the Prime CLI to interact with environments, and gives the install path for uv first. This is the only installation procedure the README documents. ```bash # install uv curl -LsSf https://astral.sh/uv/install.sh | sh # install the prime CLI uv tool install prime ``` After that, the prime CLI is on your PATH as a uv tool. The README does not show a pip install of the verifiers package itself, and it does not print a version-check command, so the next step is to read docs/ for the environment authoring guide rather than to guess a subcommand. The repository does contain examples/agent.py, which is the concrete starting point the layout offers for an agent-shaped environment. Two constraints from pyproject.toml matter before you start. The package requires Python >=3.11 and <3.15, and mcp is pinned to exactly 2.0.0. If your project already depends on a different MCP client version, that pin is the first conflict you will hit. The README does not document a workaround. ## Where verifiers is the wrong tool The integration story cuts both ways. The README says verifiers is "tightly integrated" with the Environments Hub, prime-rl, and Hosted Training. Nothing in the README claims the environments are portable to other training frameworks. If your RL stack is not prime-rl, you are reading the docs to find out whether the environment abstraction is separable, and the README does not answer that question. The dependency list reinforces the concern. prime-tunnel, prime-sandboxes and prime-runs are direct dependencies, not optional extras. A team that wants a lightweight scorer for a single-turn math task is pulling in ZMQ, msgpack, uvicorn, a sandbox client and an MCP client to get it. For that use case a few hundred lines of your own code plus math-verify (which verifiers also depends on) is a smaller commitment. The project also labels itself honestly: the classifier in pyproject.toml reads "Development Status :: 4 - Beta." Beta status plus a release cadence that moved from v0.2.1 in July 2026 to v0.3.1 in August 2026 means the environment API is still moving. The README does not document a deprecation policy or a compatibility guarantee between minor versions. Treat environment code as something you will maintain against upstream changes, not something you write once. ## Alternatives and how the approach differs The obvious comparison is a general-purpose evaluation harness such as lm-evaluation-harness. The difference is in what the two projects consider the unit of work. lm-evaluation-harness is built around static benchmarks: you add a task, you run the model over a fixed set of prompts, you get a score. verifiers is built around environments that produce rollouts for training, with multi-turn episodes, tool use and sandboxed execution in the dependency list. A benchmark harness answers "how good is this model right now." An environment library answers "what signal do I feed the trainer." Those are different artifacts, and a team that only needs the first will find verifiers heavier than necessary. A second comparison is writing your own rollout loop against your trainer's API. That is what most teams do first, and it is not unreasonable: you control the reward function and there is no dependency surface. What you give up is the packaging. The hub model in verifiers, where an environment is a named artifact other people can install and run, only pays off if you actually publish or reuse environments. If every task you will ever train on is bespoke and internal, the packaging layer is overhead. A third option worth naming is a sandboxing or agent-runtime library on its own, without the RL framing. The README does not discuss this, but the dependency split makes the distinction visible: prime-sandboxes handles execution, and verifiers is the layer that turns execution plus scoring into a training signal. ## Maintenance, releases and licence The repository is not archived, and the last push was on 2026-09-20, three days before this review. Releases are tagged and recent: v0.3.1 on 2026-08-24, v0.3.0 on 2026-08-07, and v0.2.1 on 2026-07-20. Version numbers are derived from git tags via hatch-vcs, which the pyproject.toml build-system section makes explicit, so the version you install is a function of the tag you build from rather than a hand-edited string. That is a small but real operational detail: a source install without tags will not produce the version you expect. The licence is MIT, declared in both pyproject.toml (license = "MIT") and the LICENSE file at the repository root. MIT is permissive: it allows commercial and closed-source use, modification and redistribution, provided the copyright notice and permission notice are retained. That is the general shape of the licence, not advice about your situation; if you are redistributing environments built on this library, read the LICENSE file and the licences of the dependencies, several of which come from Prime Intellect itself and may carry their own terms. The upgrade cost is the part the README does not address. There is no documented migration guide between v0.2 and v0.3, and no stated support window. With a beta classifier and a monthly-ish release rhythm, the practical approach is to pin the version in your own lockfile and read the release notes before moving, rather than tracking main. ## Conclusion Adopt verifiers if you are already inside the Prime Intellect stack (prime-rl, the Environments Hub, Hosted Training) or you want a Python-first way to express multi-turn, tool-using tasks as RL environments. Do not adopt it if you need a provider-neutral harness that runs the same environment against arbitrary training backends; the README names only Prime Intellect's own training framework and hub, and the dependency list is pulled toward that ecosystem. Before committing, verify two things in the repository itself: whether the docs/ directory covers the environment API you need, and whether the pinned dependencies (mcp==2.0.0, renderers[multimodal]>=0.1.12.dev2) resolve cleanly on your Python version, since pyproject.toml requires >=3.11,<3.15. ## FAQ ### What are verifiers? In this project, verifiers is Prime Intellect's Python library for creating environments to train and evaluate LLMs, described in pyproject.toml as "Verifiers: Environments for LLM Reinforcement Learning." It is integrated with the Prime Intellect Environments Hub, the prime-rl training framework and the Hosted Training platform. ### What is the role of a verifier in this library? The library is built around environments that train and evaluate LLMs, and its keyword list includes reinforcement-learning, grpo, multi-turn, tool-use, train, eval and harness. The README does not separately document a component called a verifier, so the term in the project name refers to the library as a whole rather than to a named class. ### How do you install verifiers? The README recommends installing uv first, then the Prime CLI with uv tool install prime, and using that CLI to interact with environments. The README does not show a direct pip install of the verifiers package; it points to the docs/ directory for architecture guides. ## Sources - [Issues](https://github.com/PrimeIntellect-ai/verifiers/issues) - [License: MIT](https://github.com/PrimeIntellect-ai/verifiers/blob/main/LICENSE) - [PrimeIntellect-ai/verifiers on GitHub](https://github.com/PrimeIntellect-ai/verifiers) - [README](https://github.com/PrimeIntellect-ai/verifiers/blob/main/README.md) - [Releases](https://github.com/PrimeIntellect-ai/verifiers/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/primeintellect-ai-verifiers