The story

The AI bill, set beside the work that merged.

An AI usage chart shows consumption. TIER puts accepted software changes beside the recorded cost, so an engineering lead and a finance team can follow the same ratio over time. A token is a unit of text processed by a model, roughly a fragment of a word. TIER normally converts token counts to US dollars at the model's reference rates, then reports weighted outcome points per $1,000 of recorded usage.

TIER is open source (Apache-2.0) and runs on your own systems. This page describes v0.6.1, a working, pre-v1 tool. The project tested the approach on its own repository; that self-measurement is the evidence offered here.

The problem

A bill and a work record answer different questions.

An invoice establishes what was charged. A usage report shows consumption. TIER sets that record beside accepted changes. Treat it as one input to a budget discussion. The ratio counts AI usage cost only, so it is not an ROI figure: points have no dollar value, and revenue, hours saved, labor and infrastructure costs sit outside it.

Cost

Recorded usage has a price

By default TIER reads Claude Code's local usage logs. Optional collectors read Codex, Opencode's Z.ai coding-plan usage and Muse Code; a forwarding proxy records calls sent through it to AI providers, and periodic Anthropic and OpenAI usage collectors can add daily totals. Captured tokens use a versioned reference price table; manually posted costs use the caller's dollar amount. Uncaptured usage, including Cursor and GitHub Copilot, looks free and can inflate the ratio.

Work

Accepted changes are a limited proxy

A pull request (PR) proposes a code change; merging accepts it into a repository branch. Deployment and use remain unverified. Research, reviews or debugging that produce no accepted outcome earn no points, while their captured AI cost remains. A low ratio alone is insufficient evidence of waste.

Billing

A flat fee stays separate

TIER prices captured usage at reference list rates even on a subscription. Finance supplies actual paid amounts in US dollars per calendar month. Spend Leverage divides list-price cost by that payment; TIER stays unchanged. Compare full calendar months and the provider's usage reports before judging a plan. Discounts and credits affect paid spend; leverage describes usage relative to payment, not savings or a metered-bill forecast.

Attribution

The two records need the same identity

Recorded cost uses the identity supplied when usage is shipped, normally the computer's login name; a PR belongs to its author's GitHub login. The administrator joins differing identifiers with an alias map and loads a team roster. Team membership is dated: cost follows membership when incurred, work when merged. Shared-account usage stays under the supplied identity; TIER does not apportion reviewer effort.

The precedent

Adoption comes before the reckoning.

Cloud cost management offers a useful comparison: once workloads move to the cloud, teams have a bill to examine. AI coding tools bring the same need. Counting tokens tells you how much was used. Counting accepted changes beside that cost adds an output measure; causation and business value still need separate evidence.

Usage: what was consumed
TIER: accepted outcome points per $1,000 of recorded usage

The reframe

Count accepted changes beside their recorded cost.

A PR count treats a typo fix and a subsystem as equal. TIER uses size weights to distinguish them, then reduces credit for the failure signals it can observe. These weights and time limits are the project's conventions, not scientifically validated measures of value.

A merged PR counts only when its branch name or description references an issue in that repository. Usage logs supply the branch reference for cost attribution. A developer's ratio includes all cost recorded under that identity, even when no issue can be found, and all qualifying outcomes, including work written without AI. Identifying AI-authored code needs separate evidence.

The usage record
Model, token counts and time of use
Repository, branch and shipping identity when available
Recorded cost at reference rates, including abandoned and unfinished work
A versioned price table, with warned estimates for unknown models; stored prices change only when the administrator explicitly reprices events
The outcome record
One outcome per qualifying merged PR. Optional direct-commit capture also requires an issue reference in the commit subject and targets the default branch. Other code platforms can submit records through the API, with caller-supplied data and quality.
Size labels set each PR's weight; a fallback based on changed lines and files still rewards larger diffs, including generated churn.
Connected GitHub event notifications (a webhook) can lower quality after failed automated tests or builds; a timely passing rerun clears that failure.
A supported, matched revert lowers quality according to message keywords, not verified cause. A matched partial reversal receives the same 0.1 or 0.8 floor; TIER does not measure the fraction reversed. The lowest applicable multiplier wins.

The same points at lower recorded cost give a higher ratio. Automatic quality reductions depend on delivered, matched webhook signals; imported PRs lack reconstructed failure history. An unchanged multiplier means no observed failure signal. Other partial reversals can remain unobserved. Hotfix branch names, issue reopening and incidents do not themselves change scoring. Corrective declarations can change scoring only with the operator’s opt-in policy. The floor values are uncalibrated conventions. v0.5.2 could give an eligible revert PR separate positive credit; a separately recognised revert push can reduce the matched original outcome within the supported window. v0.6.1 excludes recognised revert PRs. Undoing a revert does not restore the original’s credit.

Cost counts when incurred; outcomes count when accepted. Live developer calculations can revise the original merge's window as quality signals arrive; these views are available only with invented synthetic demo data in v0.6.1 (#826). Team and division reports use closed calendar months, sealed by the administrator against late changes. Choose periods inside the capture history that include work started and accepted. A window that has already ended won't pick up PRs merged later.

Compare your own history with the same people, work mix, size-label calibration, TIER release, rubric and recorded prices. Check capture gaps and window edges first. Staffing, task complexity or a different model can move the ratio without a practice causing the change. The evidence floor guards against thin data; causation and trial duration still need judgment.

The technical reference gives the issue-reference syntax, weights, quality clocks, evidence thresholds, pricing arithmetic, capture limits, access rules and setup steps.

What the name means

TIER — Token Impact & Efficiency Ratio

“Token” names the usage input; dollars account for different model prices. “Impact” here means accepted outcome points, not business impact. TIER is a ratio, with no grade thresholds or universal good or bad value. A team's figure divides its summed points by its summed cost, rather than averaging its members' ratios.

T·I·E·R = Σ(size weight × quality multiplier) ÷ (recorded cost in US dollars / 1,000)

The unit is outcome points per $1,000; the thousand-dollar scale only makes the ratio easier to read. With no recorded cost, TIER reports 0, indicating missing cost evidence. Dollars per point is the inverse view, cost divided by points; with no points it is undefined.

Where this sits in history

Earlier metrics show why incentives matter.

Lines of code count code volume; function points size delivered functionality; velocity tracks completed estimates. DORA measures delivery speed and stability. TIER adds recorded AI cost as a denominator and points for accepted changes as a numerator; it belongs beside delivery and developer experience measures. TIER grades the work, not the worker. TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual.

Launch scope. Use TIER alone, or with people you fully trust. Alone, you get the local tierd score cost table; a real-data score needs a team meeting the k contributor floor (minimum three counted people, default five). Everyone with a read, upload or administrator credential, or control of the database, must be trusted with all retained developer data and to report usage honestly. Use name-free team/division reports for shared use. Promotion of non-synthetic developer mode awaits controls for who can see named records, a viewing audit log and retention limits (#826). v0.6.1 refuses tierd serve --aggregation developer on real data, including loopback and read-only operation (#1253). Per-developer views and the per-issue report are not available on real data in v0.6.1 (#826). The synthetic demo (tierd demo), which generates its own invented data in a private temporary database and cannot load yours, shows these views read-only with capture and write routes absent. Upload credentials are not yet tied to a contributor's identity: a holder can submit usage as someone else, add fabricated contributors to the team list to meet k (the minimum number of contributors a report needs), or claim another uploader's event key first. That minimum does not authenticate contributors. These trust requirements are not enforced access controls. In v0.6.1, an ingest token permits only event uploads; admin credentials retain broader access. Corrective-work accounting (Event 3) is off by default and requires operator opt-in in v0.6.1. When enabled, only declared Corrects: #N relations count: eligible same-author pairs count provisionally before operator review; cross-author pairs require confirmation. A declared correction can lower the original’s points; undeclared repairs are not detected.

Size labels can be inflated, PRs split to earn more points, and AI usage moved to tools TIER cannot see. Necessary experiments can also lower the score. Business judgment remains with the people using it. The published failure-mode analysis describes these risks; some mitigations remain proposals. Use it to decide how you spend and what you coach. Use the number to investigate practices. TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual. TIER cannot enforce how readers use developer records.

In the synthetic demo, developer mode shows named invented rows. Per-developer views and the per-issue report are not available on real data in v0.6.1 (#826). The synthetic demo (tierd demo), which generates its own invented data in a private temporary database and cannot load yours, shows these views read-only with capture and write routes absent. The operator chooses team or division reporting for real data. These reports hide names from viewers and require a minimum group size, called k-anonymity. Contributors include rostered, non-bot people with usage from a log reader, collector or proxy, or a merged PR, after aliases are joined. Small groups fold into “other”; an undersized residual withholds the whole report. Spend with no person attached is excluded.

v0.6.1 has an admin token for reads, writes, exports, erasure and provider proxies, a read-only viewer token, a scrape-only metrics token, and an ingest token accepted only on POST /api/v1/events. Use the ingest token for laptop shippers; it grants no reads, outcomes, exports, erasure or proxy access. It is not bound to a developer identity: its holder can post usage under another name or pad a contributor group. Admin token holders can read every developer’s identifying records in any reporting mode and post or erase records. k-anonymity limits what viewers of team and division reports see; it does not restrict admin token holders. Treat admin and metrics credentials as operator-only. Without a configured admin token, the server is loopback-only and unauthenticated; other tokens alone do not enable authentication.

Usage, cost, accepted outcomes and quality events are checkable against the public calculation code. Log readers keep metadata and token counts; prompt and response text stay outside stored records. The proxy forwards complete requests but stores usage. Raw GitHub webhook deliveries can contain commit messages and author details and have bounded retention; cost and outcome rows have no age-based deletion.

Read the lineage: lines of code, function points, velocity and DORA →

To try it, run one installation for one organization: a binary with a local SQLite database. Download a release binary or build from source. Retained usage logs, matching identities and issue references connect the records; automatic quality signals also need a reachable server and a signed GitHub webhook.