It runs beside the AI agents you already use, checks each task against independent evidence, and keeps a receipt of what passed.
Free to run. Yours to keep.
curl -fsSL https://excellent.so/install.sh | shmacOS today. Windows and Linux are not supported yet. Needs Node.js 22.3 or newer.
Pay invoice INV-20931
Every check held. The receipt binds the task, the checks, the evidence and the verdict, and stays on this machine.
amount-matches-invoice$4,820.00payee-on-approved-listPasswithin-approval-limitPassno-duplicate-paymentNone found03Works with
The installer writes one MCP entry into each agent's own config. Each of these 28 has a prompt you can paste into it, the exact entry and the undo.
Names and marks belong to their owners. Shown to say Excellent works with these agents, with no endorsement implied.
AI agents can produce more work than people can carefully review. Asking another model whether the first one did a good job does not close that gap.
So Excellent treats every “done” as a claim and goes to look. The repo, the tests, the build and the browser can each tell us something real about the result. What holds up leaves a receipt. What does not goes back to the agent with the reason. Software comes first because it leaves unusually good evidence.
01Run
Excellent starts the agent in an isolated worktree and records the exact agent version, model, instructions, tools, repo state and task. Every attempt is bound to the setup that produced it, so a result always belongs to one configuration.
The agent runs in an isolated worktree. A free-text objective is refused: file it as a task first.
Learn more about starting an attempt
Agent version, model, instructions, tools and repo state are bound to the attempt.
Learn more about agents and versions
A retry is a new attempt that links back to the last one. The earlier attempt is never rewritten.
Learn more about work and attempts02Check
When the agent says it is finished, Excellent freezes the resulting tree and gathers evidence from the repo and the tools connected to the task. When a check cannot run, Excellent says so instead of implying a pass.
Git and test evidence are the most settled. Browser, CI and deployment observers are newer.
A model can lower a verdict or send it to a person. It can never carry a pass. Only a check that ran, or a person, can.
How checks decide03Return
A returned attempt carries the unmet check, the observed result, the expected result, the supporting evidence and the next action. The next attempt starts from that evidence instead of a fresh prompt.
Claude Code1 of 6 checks failed
The export ignored the active invoice filter. Expected 12 rows, found 47.
Claude Code6 checks
Second attempt passed all six checks, including the browser check on the filtered view.
The checks held. A receipt is written.
Sent back with the failure in it.
A check could not run. It stays in the count and is never counted as a pass.
04Receipt
Each accepted result leaves a receipt you can open later, cite during review, or use to compare agent setups. It binds the input, the checks, the evidence, the decision and the software version, then signs the hash with Ed25519.
Claude Code8 checks
StartedThe agent runs in an isolated worktree.
01Evidence gatheredThe resulting tree is frozen.
02Checked8 checks against the repo and its tools.
03VerifiedMigration applied cleanly and the rollback path was exercised before accept.
04ReceiptSigned and kept on this machine.
05Real receipt from the Excellent docs. Synthetic release evidence, genuine signature. Its verdict is FAIL: a valid signature proves the receipt was not altered, whatever the verdict says.
Ed25519 over a canonical hash. Change one character and the check fails.
A re-run is a new receipt. Nothing edits history.
Kept in ~/.excellent. We run no cloud that holds a copy.
Your repository, attempts, evidence and receipts stay in a local database on your machine. None of it reaches us. Model calls go from your machine to the provider you chose, on your account.
Receipts stay on the machine that made them. They do not sync between teammates yet.
05Agents
The installer finds the agents on your machine and writes one excellent entry into each one's own config: 28 agents, 9 shapes of entry. A second run changes nothing.
excellent install-agent-mcpsNo agent by that name is configured by the installer. The agents page lists the ones it detects and leaves alone.
Restart each agent afterwards, or it will not see the new server.
Set up Excellent (excellent.so) in Claude Code for me. First run: curl -fsSL https://excellent.so/install.sh | sh
If its output has a line starting "Claude Code: linked" or "Claude Code: already-linked", skip to the last step.
Otherwise open ~/.claude.json (create it as {} if it is missing) and add this under the top-level "mcpServers" object, creating that object if needed and keeping everything else in the file unchanged:
"excellent": {"type":"stdio","command":"/absolute/path/to/node","args":["/absolute/path/to/@excellent-so/cli/dist/server.js"],"cwd":"/absolute/path/to/@excellent-so/cli/dist","env":{}}
Replace /absolute/path/to/node with the output of `node -p process.execPath`, and /absolute/path/to/@excellent-so/cli/dist with the output of `echo "$(npm root -g)/@excellent-so/cli/dist"`.
Last step: tell me to restart Claude Code, because it only sees the new server after a restart.Paste it into Claude Code. It runs the installer and looks for Claude Code: linked, or adds the entry by hand.
~/.claude.jsonmcpServerscurl -fsSL https://excellent.so/install.sh | shIt runs excellent install-agent-mcps, which writes the entry and prints Claude Code: linked.Paths, entries and undo lines are the installer's own, read from its source. Names and marks belong to their owners. Shown to say Excellent works with these agents, with no endorsement implied. Every agent and its config file
Compare and promote · Team, early access
Once Excellent has enough representative work, it sets a baseline and tests candidate setups against work the candidate never saw. A higher average score is not enough.
Work the candidate never saw while it was tuned.
The exact diff is shown before anything changes.
What a candidate can change
The rule
If a candidate sees the held-out tasks or lacks required evidence, it is invalid.
We have not published a verified improvement yet. When we do, it will be our results on our repository.
Open a receipt
This is the sample receipt from the Excellent docs: genuine output of the receipt pipeline, with a genuine signature, made from synthetic release evidence. Its verdict is FAIL. Point at any line to see what it binds.
What it binds
One of the six verification states (PASS, MISMATCH, FAIL, UNKNOWN, NOT_RUN, PENDING). Here: FAIL.
Value
"FAIL"
What it binds is the docs’ own text, from “What each part is for”. A field the docs do not explain says so.
Point at a line, tap it, or tab to the receipt and use ↑ ↓.
Real receipt from the Excellent docs. Synthetic release evidence, genuine signature. Verdict: FAIL. A valid signature proves the receipt was not altered. It does not make the verdict good. Source
Fifteen checks: ten pass, three failing, one running, one blocked outside the run. One unresolved check sinks the set, so the receipt says FAIL.
What it binds
Value
"FAIL"See also
What it binds is the docs’ own text, from “What each part is for”. A field the docs do not explain says so.
Point at a line, tap it, or tab to the receipt and use ↑ ↓. Enter opens a folded line.
Runs on a machine that has never had Excellent on it. Node 18+, no dependencies. The example pack is synthetic: the work it describes is invented, the envelope, hash, signing and anchor are the real pipeline.
These commands need an Excellent monorepo checkout (<repo>), which is not public. For a check any visitor can run, use the commands under Check one yourself.
A valid signature means the receipt has not been altered since the holder of that key signed it. That is tamper-evidence, and it is real.
It does not establish that the key is the tenant's key. If you obtained the key from the same system that issued the verdict, a forged receipt re-signed under an attacker's key verifies exactly as cleanly as a genuine one. Confirm the key's fingerprint through a channel this system does not control, then pin it.
A receipt does not prove every external source was truthful. It proves which records were bound and signed together.
To fetch a tenant’s published trust material:
excellent-mcp verification universal-trust-root --jsonThe CLI on npm today, 0.1.0 (checked October 23, 2026), predates excellent-mcp verification, so this command answers unknown command until the next release.
Pricing
Run Excellent locally for free. Teams can join early access, or work directly with Excellent engineers on a deployment.
Free for developers
Run Excellent locally.
Install ExcellentNo credit card, ever.
Contact us
CI, baselines, experiments, policy.
Contact usSelf-hosted team sync is in beta today.
Custom
Work directly with Excellent engineers.
Book a callEngagements start at $10,000/month. No minimum term.
Every tier includes the same verification loop, local receipts, and agent integration. You bring your own model key.
Compare plansExcellent Deployment
We work directly with teams to find the workflows where agents can create meaningful leverage, build them into your existing systems, and establish the verification required to let them act.
Six phases, each with a result you can check. They repeat as new workflows come into scope.
Two commitments
We don’t deliver AI strategy decks; we ship working systems.
Every deployment is built to become less dependent on us over time.
FAQ
A verification system for agentic tasks. It runs beside the agent you already use, checks the work with independent evidence, and leaves a receipt you can inspect later.
No. Your agent does the work. Excellent starts the attempt, records what happened, checks the result against your repo and tools, and compares different ways of running it.
The one you already use: Claude Code, Codex, Cursor, Copilot, Cline, Gemini, OpenCode, or any other agent that does work you can check. Excellent observes the run instead of replacing it.
Whatever can prove the task: the git tree, tests, lint, the build, browser behavior, API responses, CI, and the deployment. Git and test evidence are the most settled; browser, CI, and deployment observers are newer. When a check cannot run, Excellent says so instead of implying a pass.
The attempt is returned with the exact failure, expected behavior and observed behavior, and sent back to the agent. The original context and the retry history are kept on the receipt.
None of it reaches us. Excellent keeps your repository, attempts, evidence, and receipts in a local database on your machine, and sends none of it to Excellent. Model calls are the exception worth naming: they go from your machine to the provider you chose, on your own account, the same traffic your agent already makes. The security page has both paths in full.
Yes, for individuals. You install it and run it on your own machine, with no seats to buy and nothing metered for local verification. Team features are in early access; contact us to join.
We are building Excellent with Excellent, and we have not published a verified improvement yet. The results page says so plainly and will carry the numbers when one exists. Whatever we publish will be our results on our repository, not a promise about yours.
Install
curl -fsSL https://excellent.so/install.sh | shFree to run. Yours to keep. macOS, Node.js 22.3 or newer.
Read the quickstartThe CLI moves from the beta channel to latest on npm. This is the build the installer gives you today.
Read the changelog