Pay for verified work, not tokens

A token is a strange thing to sell. It is the input, not the result, and for code the two come apart hard. A model can spend a great many tokens producing a change that does not compile, and very few producing one that ships. Priced by the token, the customer pays the same for both, and pays the most for the runs that wasted the most. The incentive points the wrong way.

The honest unit is the outcome: a change that is verified and accepted. That is what a person actually wanted, and it is the only thing worth charging for. But pricing purely on the accepted result has its own trap, because verified work carries a real cost that someone paid, whether or not the result was the one the customer hoped for. Real compute ran. Tests ran. Critics ran. Charging nothing for honest, working effort is neither sustainable nor, in its own way, honest.

So the charge is designed to follow the outcome in two plain layers. If real, checkable work happened, if the change compiled and the tests ran, you pay the cost of that compute, whether or not you keep the result, because the work was real. On top of that, and only if the change passed verification and you accepted it, sits a margin. And there is one ending that costs nothing at all: if the attempt crashed and produced nothing verifiable, the cost is ours, not yours.

What is meant to make that offer possible is the architecture, not a generous mood. A change is authored by one model, then attacked by critics from families that fail in different shapes, and checked against a verifier that is not a model at all but the compiler and the test suite. The point of that machinery is to make one ending, a crash that produced nothing, rare, so honest work should land in the verified, paid range rather than the unpaid one.

There is a longer game underneath. Every one of those decisions, the change, the outcome, the correction, is kept. The point of collecting it is to train models that reach the verified range more often on their own, that find a working answer sooner and waste fewer attempts getting there. The pricing and the data are the same loop seen from two sides: pay for what works, and learn from the difference between what worked and what did not.

We do not publish which models do the authoring or the checking, or the numbers behind the floor and the margin. The rule is simple: you should pay for verified work, never for a crash, and a premium only on a result you chose to keep.