Skip to content
unerrunerr

How we measure agent work

Every definition on this page is free to use, quote and build on, under CC BY 4.0. We publish the definitions because a measurement nobody can check is not a measurement.

The seven we compute today

Code survival

The share of lines written by an agent that are still present in the codebase 30 and 90 days later, compared with lines written by a person over the same window.

How it is computed. From git history on your machine, by attributing each surviving line back to the change that introduced it.

What it does not measure. Whether the code was correct, or whether it was good. A line can survive because nobody looked at it.

Durability score

Whether a single change holds. Twenty-four hours after an agent edits one function or file, its content is compared against what the edit left behind: unchanged counts as held, changed counts as reverted, and a change too recent to check yet counts as neither.

How it is computed. By hashing the edited code right after the change and comparing that hash to the same code 24 hours later, on your machine.

What it does not measure. Why a change was reverted. A genuine bug fix, a deliberate rewrite, and a plain style preference all score exactly the same as a failure.

Self-correction patterns

The pattern left when an agent looks up a piece of code, edits it, and looks it up again within 60 seconds — evidence the first edit didn't settle what it was trying to fix. Each pattern is scored for how closely the two look-ups match and kept only above a confidence floor.

How it is computed. From the sequence of look-ups and edits inside one session: a look-up, an edit, then a second look-up of the same code inside a 60-second window.

What it does not measure. Whether the second attempt actually fixed the problem. It counts the retry, not the outcome.

Cache hit rate

The share of a session's input tokens served from cache instead of sent fresh: cache reads divided by cache reads plus fresh input. A stable, reused conversation prefix pushes the rate up; a prefix that keeps changing pushes it down.

How it is computed. From the input and cache-read token counts reported back for every turn in a session, summed and divided, on your machine.

What it does not measure. Whether the cached content was worth keeping. A large, stale cache still hits often.

Re-read amplification

How many times, on average, a token written into the cache gets billed back as a read before the session ends: cache reads divided by cache writes. A token admitted once and read back 35 times costs 35 reads, not one — this is that multiplier.

How it is computed. From the same per-turn cache-read and cache-write token counts as cache hit rate, divided against each other across the session.

What it does not measure. Whether the token needed to be in context at all. A necessary token and a wasted one amplify exactly the same way once they're cached.

Weighted input units

One number for a session's input cost, in units of a plain input token: fresh input counted once, cache reads counted at a tenth, and cache writes counted at twice that — the actual price ratios prompt caching bills at.

How it is computed. By taking a session's input, cache-read and cache-write token counts and weighting each at its billed price relative to one plain input token.

What it does not measure. Output tokens, which bill at a different, higher rate and are tracked separately so the two costs don't hide inside one number.

Delegated share

The share of a session's work handed off to a sub-agent instead of run on the main conversation thread: sub-agent runs divided by sub-agent runs plus main-thread turns, expressed as a percentage of the session's total.

How it is computed. By counting how many turns in a session were sub-agent delegations against how many ran on the main thread, on your machine.

What it does not measure. Whether delegating was the right call. A high share can mean efficient parallel work, or it can mean work that should have stayed on the main thread.