coverage
Supported products
Every tool OVM installs, switches, and launches — and, next to each one, exactly how far we have verified it. The second half matters as much as the first: coverage differs by product, and a blank space is not a score.
1What OVM manages
| Product | What it is | Source | Install | Versions | Latest | Coverage |
|---|---|---|---|---|---|---|
| Claude Code | Anthropic's agentic coding CLI | npm + native | ovm install claude | — | — | benchmarked |
| Codex | OpenAI's agentic coding CLI | GitHub Releases | ovm install codex | — | — | benchmarked |
| Pi | Earendil's coding agent | GitHub Releases | ovm install pi | — | — | install verified |
| QM | Y Combinator's multiplayer agent harness — a control-plane CLI, not a coding agent | npm | ovm install qm | — | — | install verified |
Version counts and latest versions are read live from /api/registry.json. A dash means the registry has not been reached, not that the product has no versions.
2What the coverage tiers mean
Benchmarked. Everything below, plus timed performance runs: a real authenticated session on dedicated hardware, driven to a real model response, recorded per version and per platform. These are the numbers on the benchmarks page.
Install verified. Every published version is tracked in the registry, and each new release is installed on real hardware and made to report its own version through the OVM launcher before it is admitted. A release that fails is withheld from the registry rather than offered to you.
Install verification proves the artifact downloads, unpacks with all its required parts, and starts. It does not prove every subcommand works. We label it as what it is rather than rounding it up to "verified".
An empty benchmark cell means not measured — never measured and slow. Absence of a number is absence of a test, and the two should never be confused when the missing number would flatter or damage a product.
3Why Pi and QM carry no benchmark numbers
Benchmarking a coding agent honestly needs two things we do not have for every product: a subscription-authenticated session for that specific tool on the benchmark machine, and a prompt harness comparable enough that the resulting numbers can sit in the same table. Pi has neither yet. Adding a column of numbers gathered a different way would make the comparison worse, not better.
QM is a different case, and a permanent one. It is a control-plane CLI — it provisions and deploys a fleet of agents to Docker, Fly, or AWS. It has no agent loop of its own to time, so "time to first model response" is not a slow measurement for QM, it is a meaningless one. QM is tracked and install-verified; it will not appear in the performance tables, and that is a statement about the tool's shape rather than its quality.
4How a version reaches you
Every product above shares the same pipeline: upstream publishes, we
discover it, verify it on real hardware at that product's coverage tier,
and only then admit it to the registry that ovm install
reads. Methodology describes the
verification in detail, how it works
covers the client side, and releases is the
live registry itself.