Xerify
Ask another provider. Get a clear second opinion. A shell-first, open-source tool for cross-provider verification.
Problem
Asking the model that wrote the code to check its own work is a closed loop. A model cannot see its own blind spot: the same training data produces the flawed assumption and then confirms it. If the answer to "is this change safe?" comes back through the same channel that asked, it is an echo, not a verification.
In practice teams solve this by hand — copy the output, paste it into a different chat window. That is not repeatable, not scriptable, and cannot be wired to an exit code in CI. The decision is never recorded, the evidence boundary is undefined, and the result never gets past "looked fine to me".
Approach
Xerify moves the second opinion into the terminal. Evidence is piped in, the claim is stated explicitly with `--claim`, and the verifying side is chosen with `--to`. Output is either human-readable or one stable JSON envelope, so the same call works by hand and as a CI step.
One rule sits at the center: the verifier must be a different invocation provider than the author. A same-provider `verify` is rejected before any model call. This measures channel diversity — it does not claim that two models have independent weights or blind spots, and the documentation says so plainly.
The same core powers four surfaces: the CLI, a JavaScript/TypeScript library, a local STDIO MCP server, and a Streamable HTTP MCP server. A coding agent can call exactly the verification a human runs in the shell.
Technical Decisions
Provider identity follows the channel, not the model
`--from` and `--to` name the control and billing service performing the call. A model picked through Cursor is `cursor` even when its ID says GPT or Claude; direct Codex is `openai`, direct Claude is `anthropic`. Deriving identity from the model name would hide cases where two supposedly different channels are the same one.
Uncertainty is never rounded up to success
Three outcomes: `confirmed` (0), `refuted` (10), `unclear` (11). Timeout, provider failure, invalid schema, and truncation stay fail-closed with their own non-zero codes. `unclear` is never collapsed into 0 — the caller can tell "I could not tell" from "I confirmed it" by exit code alone.
Provider output is untrusted data
Returned text is never evaluated as a command, source file, MCP instruction, or configuration. Prompt and context never enter shell arguments, adapters invoke a single executable with `shell: false`, and output is read byte-bounded. Official CLI adapters run from restrictive temporary workspaces rather than the user's repository.
The audit trail is metadata only
The JSONL log and run history under `.xerify/` record metadata only; prompt, context, answer, findings, raw response, and secret values are excluded. Runs take monotonic identities through one atomic `HEAD.json`, and a compact archive index lets humans and agents search thousands of records without opening every file.
Setup checks cost nothing
`health`, `doctor`, `providers list`, `providers probe`, and `config validate` make no model calls. Only live `ask` and `verify` can consume quota or incur charges — a line kept explicit in both the docs and the command surface.
Outcome
Open source under MIT as a 0.1.0 release candidate. Public CI is green on Ubuntu, macOS, and Windows with Node 20 and 24, including external install and MCP Inspector smoke tests. The same checks pass on the WSL2 / Node 24 lane.
Documented in six languages (English canonical, plus Turkish, German, Chinese, Spanish, and French). Worked verification examples cover research, game production, website, analytics, and outbound-data cases — each showing the bounded evidence, the exact command, and the observed result.
Verhex runs it on its own work: this site's repository has `xverify-cli` installed as a dev dependency and wired up as an MCP server.