Related units
Every unit software has tried before, what each teaches, and where each fails for agents.
Software has priced work before. Each attempt teaches a constraint the quirq is built against.
| Unit | What it taught | Why it fails for agents |
|---|---|---|
| SLOC | Count something | Counts artifacts; rewards volume; disowned by its own users |
| Function points (Albrecht) | Price specified functionality, not typing | Needs expert human counters; measures spec size, not delivered change |
| Story points | Relative sizing helps teams plan | Deliberately team-local; useless for pricing across organizations |
| DORA / SPACE | Measure the delivery system | Explicitly declines to price a worker's deliverable |
| Execution-gated benchmarks (SWE-bench) | Verify by state, not self-report | Researcher-authored tests, no budget semantics: measures capability, not value |
| Tokens | Meter the machine precisely | The input meter; see two meters |
Against that record, the quirq is: machine-counted (function points needed expert judges), value-denominated and durable (SLOC and tokens price activity), absolute and portable (story points are relative), and attributable to a worker's deliverable (DORA and SPACE abstain, wisely, for humans; agents need the price).
One inheritance to respect rather than escape: the multitask warning (Holmström-Milgrom) applies to any unit of account, including this one. A team paid per quirq will manufacture checks. The mitigations are structural, not hortatory, and they are the subject of gaming.
A side effect worth noting for labor economics: quirq ledgers are task-level automation data at market scale. Which check types agents settle cheaply, and which still route to humans, is the substitution margin, observed rather than surveyed.
That is what the quirq is. Next: what it calculates.