Vet: an AGPL-3.0 verification pass for code changes and agent transcripts

The gap Vet targets: agents that finish without being right

A coding agent can close a task, write a plausible summary, and still leave the repository in a state that does not match what was asked. The README frames Vet around exactly that split: it checks agent conversations for goal adherence and code changes for correctness. Those are two different failure modes. The first is a mismatch between the user's request and what the agent actually did. The second is ordinary defects in the resulting diff. Most linters and type checkers only see the second, and only within the rules they encode. Vet's pitch is that an LLM pass over both the diff and the transcript catches the first category, which no static tool inspects at all. The intended user is someone who already delegates edits to an agent and wants a checkpoint between the agent's claim of completion and a merge. It is not a replacement for tests. Nothing in the README suggests Vet executes the code it reviews.

What the pipeline actually does with your repository

The mechanism is described in one line of the README: Vet snapshots the repo and diff, optionally adds a goal and agent conversation, runs LLM checks, then filters and deduplicates findings into a final list of issues. Each stage matters for cost and for trust. The snapshot plus diff is the base input, which is why --base-commit exists: comparing against a ref scopes the review to the change rather than the whole tree. The goal is the free-text string you pass as the first positional argument, for example vet "Implement X without breaking Y". The conversation is the agent transcript, loaded through the skill scripts or through the --history-loader command. The checks are LLM calls, and the filter and deduplicate stage implies the raw model output is noisier than what you finally see, which is a reasonable design given that LLM review passes tend to repeat the same complaint across chunks. Whether the filtering is rule-based or another model call is not stated in the README. That is a real gap if you are trying to reason about why a finding disappeared.

Install paths and the commands you will actually type

Three install routes are documented: pip install verify-everything, pipx install verify-everything, and uv tool install verify-everything. The package name differs from the project name, which is worth noting when you search a package index. Basic use is vet "Implement X without breaking Y" from inside the repo, and vet "Refactor storage layer" --base-commit main to compare against a ref. The --agentic flag with --agent-harness claude, codex or opencode routes the work through an existing subscription instead of a raw API key, which is the documented way to avoid separate API billing. Output formats are text, json and github, and the exit codes are 0 for no issues, 1 for an unexpected runtime error, 2 for invalid usage or configuration, and 10 for issues found. Exit code 10 is the one to wire into a pipeline, because it separates a clean run from a failed run from a run that found something. For GitHub, the README gives a workflow file that checks out the pull request head SHA with fetch-depth 0 and calls imbue-ai/vet@main, with agentic: false and ANTHROPIC_API_KEY supplied as a repository secret. The action handles Python setup, installation, merge base computation and posting the review.

Model configuration is a JSON file, not a flag soup

Vet looks for model definitions in $XDG_CONFIG_HOME/vet/models.json (or ~/.config/vet/models.json) and in .vet/models.json at the repo root. The schema is OpenAI-compatible: a providers object keyed by provider name, each with api_type, base_url, api_key_env, and a models map whose entries carry model_id, context_window, max_output_tokens and supports_temperature. The README's example defines an OpenRouter provider with gpt-5.2 and kimi-k2 entries, then invokes vet "Harden error handling" --model gpt-5.2. Two details are easy to miss. The api_key_env field means the key is read from an environment variable rather than stored in the file, which keeps credentials out of the repository. The context_window and max_output_tokens fields are declared by you, not probed, so a wrong value produces failures that look like model misbehaviour. There is also a remote registry: vet --update-models downloads community-contributed definitions and caches them at ~/.cache/vet/remote_models.json, after which they appear in vet --list-models. That gives you a way to pick up new model definitions without upgrading the package, at the cost of trusting definitions you did not write.

The --history-loader option runs shell commands as you

The README carries a security note that deserves more weight than its placement suggests: the --history-loader option executes the specified shell command as the current user to load conversation history, and the note tells you to review history loader commands and shared config presets before use. Read that as a design property rather than a warning label. Any preset or configuration file that can set a history loader can therefore cause arbitrary command execution under your account, and the models.json search path includes .vet/models.json at the repo root, which is a file that arrives with a checkout. Whether the loader can be set from that same file is not stated in the supplied material, so treat the question as open and inspect any .vet directory in a repository before running Vet inside it. This is the kind of thing that matters more in CI than on a laptop, because CI usually has credentials attached.

Where the approach is the wrong tool

Vet's findings come from LLM calls, so the output is not reproducible in the way a compiler diagnostic is. Two runs over the same diff can differ, and the filter and deduplicate stage is not documented in enough detail to predict what survives. That makes it a poor fit for a required status check on a high-traffic repository unless you are prepared to tune it, because a nondeterministic gate teaches people to rerun until it passes. It is also the wrong tool when the code cannot leave your network: the README states that requests go directly to your inference provider, which is a privacy property in Vet's favour relative to a hosted review service, but it still means repository contents and, with the skill installed, agent transcripts are sent to that provider. Cost scales with diff size and with the number of checks, and nothing in the README describes a budget cap or a way to bound spend per run. Finally, Vet reviews changes. It has nothing to say about a repository with no diff, so it will not help you audit an existing codebase.

How it differs from a hosted AI reviewer and from plain linting

The obvious comparison is a hosted AI code review service. The difference is not the model, it is where the data and the configuration live. A hosted reviewer requires an account and receives your code on its own infrastructure. Vet runs as a local CLI or a GitHub Action, reads model definitions from files you control, and sends requests straight to the provider whose key you supplied. The README states there is no account, no fees and no data collection. The second comparison is to conventional static analysis. A linter encodes rules that someone wrote in advance and produces the same output every time; Vet reads the diff and the stated goal and produces a judgement. Those are complementary, not competing. The interesting part of Vet is the transcript input, because a linter has no access to what the agent was asked to do, and goal adherence is where agent workflows actually break. The cost of that capability is that you are now debugging a model's opinion, not a rule.

Licence, releases and what maintenance looks like

Vet is licensed AGPL-3.0. For a CLI that developers run locally, that is usually unremarkable. If you modify Vet and expose it to users over a network, the AGPL's source-availability condition is the part to read carefully, and if you intend to embed it in a product, that is a question for your own counsel rather than for this article. The repository is not archived, the default branch is main, and the release cadence visible in the supplied material is three versions in roughly two weeks (v0.2.13 on 2026-05-26, v0.2.14 on 2026-05-28, v0.2.15 on 2026-06-10), with the last push timestamp matching the newest release. A 0.2.x version line with frequent point releases means interfaces can still move, so pinning a version in CI is the safer default than tracking main. Note that the documented GitHub Action example uses imbue-ai/vet@main, which tracks the branch rather than a tag. The upgrade cost itself is low: pipx or uv tool upgrades replace a binary, and vet --update-models refreshes model definitions without touching the installed package. The real recurring cost is the inference bill and the time spent reading findings that turn out not to matter.

Editorial conclusion

Adopt Vet if your team already runs Claude Code, Codex or OpenCode on real repositories and you want a diff-scoped second pass that can also read the agent's own conversation, with exit code 10 wired into CI. Do not adopt it if you need deterministic, offline verification, if you cannot send repository contents to an external inference provider, or if you are not prepared to read the shell commands that --history-loader will execute. Before trusting it, run vet --list-models, confirm which provider your key belongs to, and run the CLI once against a small branch with --base-commit to see the actual finding format and exit code on your own code.

Official sources

1. imbue-ai/vet on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases