drexthealpha/Knos

Pay AI agents only when your checks pass.
For teams that pay AI coding agents on GitHub: a program holds the pay until your checks pass.
Of 241 merged agent pull requests claiming passing tests, 9 failed a test, build, lint or type check.
Check a pull request · Check every claim yourself
How it works
*You set the rules first. The money moves only when the work passes them.*
1. One comment on an issue (a task's page on GitHub) posts the task, your checks and the pay: /knos fund 20 checks: test.
2. An AI agent or a person sends the work as a pull request.
3. When the checks pass and you merge the work, a program pays the worker.
**Ready to try it on your own repository?** Get started in five minutes.
Try it in ten seconds
Open the check in your browser. Paste the link to an AI agent's pull request. It tells you whether the agent's checks really passed.
No pull request at hand? On the front page, press **Try a sample invoice**. It checks a made-up bill from an AI agent.
There is nothing to install, no sign-up, and nothing is sent to Knos.
Why nobody can fudge the count
GitHub (where your code lives) signs a token for each run of your checks. The token proves which workflow ran, on which commit. Nobody else can make it.
A workflow is the script that runs your checks. A commit is one saved version of the code.
*GitHub signs which workflow ran, on which commit. Both sides rebuild the same bill, and a program pays.*
You and the other side each keep a copy of those signed runs. Each side rebuilds the bill from its own copy (the command is knos meter reconcile).
**The two bills match line for line, so neither side can change the count alone.**
The money waits in a program on Solana, not with Knos. That program checks GitHub's signature before it pays. Today one person can still change that program, after a public wait (who holds the keys).
Today Knos earns its fee only when work is accepted. When you get a refund, the fee goes back to you. So Knos gains when work passes, and the meter is not yet fully neutral (the plan to fix it).
Why Solana: Money is released with no custodian, and neither buyer nor supplier can change the count. One person holds every upgrade key today; a program change waits 8 days in public. A custodian is a company that holds your money for you.
Is it real?
It runs on test money only: test USDC on Solana's practice network, devnet.
There are no customers yet. Nobody has bought anything (what is not real yet).
One person holds every key today. Any change to the programs waits in public for 8 days first (who holds the keys).
| What | Today | Read from |
|---|---|---|
| This copy | Release 0.3.28, October 2026. A copy naming an older release, or another product, is out of date | CHANGELOG.md; the newest: PyPI |
| Reproduced by someone else | 0 of 270 | docs/reference/CAPABILITIES.md, the rows "reproduced by someone else" |
| Exercised at the public devnet program ids | 26 of 270: GitHub token verification, funding by one comment, funding from a wallet, pay on merge, refund at the deadline, pause, work orders, an order paying up to four payees, orders judged by the buyer's black-box tests, auto-accepted orders, a holdback released after its warranty, top-ups, single-use tokens, one counted evaluation, a counted batch of evaluations, the seller's own count, a payee's passkey wallet, a passkey funder, the passkey relay, the site's Buy page, an x402 order, the upgrade gate, strict JSON in the verifier, an outcome that is not code, ES256 tokens in one transaction, the presentation grace | docs/reference/CAPABILITIES.md, the rows "exercised on devnet" |
| Deployed at the public devnet program ids, no transaction recorded | 3 of 270: GitLab token verification, the key guardian, holding pay for a payee with no wallet | docs/reference/CAPABILITIES.md, the rows "deployed on devnet" |