Yield per $1,000 of AI spend

What did your AI spend get merged?

TIER compares work accepted into your codebase with recorded AI usage at list price. With GitHub’s webhook connected, it adjusts size-weighted merged changes for detected CI failures and reverts. The unit is outcome points per $1,000 of captured AI usage, priced at list rates: an observational ratio, not a causal estimate. Acceptance into the codebase does not establish deployment, business value or how much of the work AI did.

TIER reports captured spending by model; it does not assign merged outcomes to individual models or determine which model caused a result. Same-task comparisons appear in the separate Model Report, which measures model-and-tool combinations on declared tasks. Its benchmark points are not repository TIER.

TIER = Σ(size weight × quality multiplier) ÷ (AI cost in $ / $1,000)
= size-weighted points, adjusted by caller-supplied quality or supported recorded signals, per $1,000 of captured spend
Read the source → See how it works

TL;DR: TIER in one read →

Illustration · August 2026 · teams
96
Org TIER
points per $1,000
of list-price AI usage
TeamPointsCostTIERTrend
Growth95$2,88033▼ 14%
Payments319$1,940164▲ 11%
Platform205$1,610127▲ 6%
Invented example: a sealed August 2026 report, USD list-price cost. Org TIER 96 = 619 points ÷ ($6,430 / $1,000). Trend compares each team with its prior sealed month; teams appear alphabetically.

TL;DR

What does the number tell you?

Think of miles per gallon: AI usage is the fuel, and merged changes are the distance. TIER includes qualifying work done without AI. It 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. There is no absolute good score or grade band; compare a team with its own history under consistent rules and a similar mix of work. Use it to decide what to change in how you spend.

A driver points at a green TIER gauge, “points per $1,000”, between an “AI usage (at list price)” gauge and a “Work merged” odometer. The plaque reads “Grades the work, not the worker”. Caption: “Not how much fuel you burned. How far it got you.”
The plaque states the project's coaching policy; TIER cannot enforce how readers use developer records. 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.

Three ways to use it. Pick one.

A. Look at your own AI usage, on your computer

For one developer who wants to see where the money went.

Advantages: the report runs locally without a server or network calls. Install on macOS or Linux with Go 1.27.2 or newer, or use a release archive. Windows is untested and unsupported; the guide covers installation and PATH setup.

Limits: score reports cost only from local Claude Code logs. Run the command below inside the Git checkout used for those sessions; without local history, there is no usage to report.

tier_bin=$(go env GOBIN) && tier_gopath=$(go env GOPATH) && tier_bin=${tier_bin:-${tier_gopath%%:*}/bin} && go install github.com/tiermetric/tier/cmd/tierd@v0.6.1 && "$tier_bin/tierd" score --repo .
Step-by-step guide →

B. Preview the dashboard with invented data

For someone deciding whether to pilot TIER with a trusted team.

What runs: tierd demo shows a synthetic dashboard. It generates its own invented data in a private temporary database and cannot load yours. Per-developer views and the per-issue report are not available on real data in v0.6.1 (#826).

Requirements and limits: install TIER, then run the demo locally. For a real-data pilot, use Path C’s team mode, the contributor floor and a sealed full calendar month. Missing usage can inflate the ratio; report warnings help you check the data, but cannot prove capture is complete.

Step-by-step guide →

C. A shared board for your team

For a team lead, with someone who can look after a server.

What runs: an operator hosts the server, imports the roster, joins laptop usernames to GitHub logins and chooses team or division reporting. These modes serve only closed calendar months whose records the operator has frozen (“sealed”); later uploads leave those reports unchanged. Spend without a developer identity is excluded.

Who can read: 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.

Team reports omit developer identifiers and use k-anonymity to withhold groups with too few contributors, sometimes including the whole report. This limits what viewers see; it does not limit holders of the admin token. Every teammate must upload from every AI-work machine. Missed uploads leave gaps; the operator owns hosting, updates and backups, with no published setup-time or cost estimate.

The security and deployment guide covers credentials, the public HTTPS webhook and access controls. The dashboard can stay private.

Step-by-step guide →

The longer explanation →

What TIER measures

TIER — Token Impact & Efficiency Ratio

Tokens are the units AI models consume and vendors price. TIER converts recorded token counts to dollars. Impact here means merged changes, weighted by size and quality. TIER does not price what a change is worth to the business. The result is a continuous ratio.

T·I·E·R = Outcome points (size × quality) ÷ Cost (dollars of AI spend / $1,000)

The problem, and the meter

AI usage totals do not explain merged work.

Usage totals tell you what a model processed. A cost report tells you what that usage costs at list price. Neither tells you which work your team accepted. TIER puts the work record beside the cost.

01

A usage chart leaves the work out

The same spending total can cover merged work, useful exploration or abandoned attempts. A total alone cannot tell you which.

02

Size leaves value out

Change size measures the amount of code changed. A small fix can matter more than a large feature; TIER’s weights cannot settle that question.

03

Recorded cost differs from the invoice

Subscriptions, discounts and credits can change what you pay. Keep list-price usage and payments separate when deciding whether a plan fits.

04

Missing usage can make the score look better

Tools and machines outside supported capture paths leave cost out of the calculation. An attribution warning cannot reveal usage TIER never received.

0.5–8 points

The default size scale weights accepted changes.

Size-weighted merged work
List-price USD

Reference rates put recorded usage on a consistent cost basis.

Recorded AI cost
0.7 × size

Credit after a detected CI failure with GitHub’s webhook connected, unless a qualifying flaky rerun clears it.

Detected quality signals

Lines of code, function points, story points and velocity each describe part of the work. The museum illustrates the limits of using counts as progress. TIER adds AI cost to the comparison; splitting PRs or inflating size labels can still increase points. Read the history and limits of these measures →

Pencil drawing of “The Museum of Mistaken Progress.” Display cases illustrate measures of developer work: Lines of Code (“Rewarded verbosity”), Story Points (“Measured effort, not value”), Pull Requests, and Tokens Spent, a counter at 48,210,337 (“Measured the bill, not the result”). In the New Wing, a curator shows two visitors TIER, whose gauge points from Burn toward Yield. Caption: “Our newest exhibit — and the first one still running.”
Counting PRs reports merge volume. TIER weights accepted changes by size and detected quality, then divides by recorded AI cost.

How it works

Three steps to a deterministic score.

TIER computes the score without asking an AI model to judge the work. What it counts can still come from AI: agents write code, tests, reviews and size labels, and your review rules decide what merges, so changing those rules moves the number. The three steps below describe v0.6.1.

Step 01 — cost

Read the spend

TIER reads Claude Code logs, with optional readers for Codex CLI, Opencode’s Z.ai coding plan and Muse Code. Other tools can use its proxy. OpenAI, xAI, DeepSeek and Gemini proxy routes, and organization pollers, remain unverified against live traffic; Copilot, Cursor and other Opencode providers are outside the local readers’ coverage.

Supported token counts are priced at capture using a versioned table. Unknown models use a warned estimate; old costs retain their price provenance. The capture and calculation method covers coverage, deduplication, partial-message reader limits, rounding and prices.

Step 02 — work

Join the outcomes

A merged PR needs an issue reference in its branch or body to count. The branch reference wins; each PR earns one outcome even if it closes several issues. A size label supplies its weight; otherwise changed lines and files determine it, including generated and vendored changes. The scoring rubric gives the sizing rules.

Points are the project's size conventions, derived from labels or changed lines and files. They are not validated measures of difficulty, maintainability, customer value, engineering time or the contribution made by AI.

A merged PR contributes points only when TIER derives an issue reference from its branch or description. A merge without one records no outcome. Any AI cost captured for the work still counts. Holding captured spend and all other outcomes fixed, omitting an otherwise eligible PR cannot increase the numeric ratio; it can reduce it.

An otherwise eligible merged PR can earn points regardless of its file paths, including documentation, handover and agent-memory changes. A point does not establish that the change improved deployed software. Bot- and agent-produced changes can earn points even when their AI usage is not captured. Account type does not establish whether a change used AI, and missing usage can make the ratio read high.

Backfill reconstructs merged outcomes, not their historical CI or revert signals. Those outcomes start at multiplier 1.0, which means no degrading signal was recorded. With the webhook, matched CI failures and recognized reverts can lower it. A default-branch commit whose subject starts with “Revert” followed by whitespace and nonempty text, matched to the original merge SHA or issue within 60 days, receives a revert penalty. Matching partial reverts receive the same penalty as full reverts; reversals outside the supported syntax can remain unmatched. Footer matching identifies recorded merge or squash SHAs, not constituent-commit ancestry. Incidents are not ingested as quality events. Commit-message keywords choose the penalty; missing or mixed keywords select 0.1 without establishing a defect. The floors are uncalibrated scoring conventions; the lowest applicable multiplier wins. v0.5.2 could award an eligible revert PR separate positive credit; v0.6.1 excludes recognised revert PRs. Undoing a revert does not restore the original’s credit. Matched events do not establish continuous webhook coverage.

In v0.6.1, by default an eligible follow-up PR that fixes earlier work earns its own points, and the original keeps its points unless the follow-up is a recognised revert of it. With corrective-work accounting turned on, a declared correction can lower the original’s points within 14 days of the original’s merge.

Optional direct-commit capture and outcomes-API integrations also supply outcomes. An outcomes-API integration, such as a CI job, holds the admin token wherever it runs and is therefore an operator-trusted credential holder. The admin token stays with the operator; laptop shippers use the ingest token and report readers use the viewer token. Their records still depend on the caller’s accuracy. Integration rules and validation.

Step 03 — ratio

Divide the totals

Add the eligible points and recorded list-price costs in the reporting window, then divide. Developer reports include captured spend that lacks an issue match. Usage is dated when it happened; points are dated at merge, so work crossing a window boundary can move the ratio.

The unit is outcome points per $1,000 of spend. Merge changes worth 100 weighted points on $1,000 and you score 100. Spend $10,000 for the same work and you score 10. Do the same work for $250 and you score 400.

Zero cost has no meaningful ratio. Sparse evidence produces warnings, while flagged outcomes retain their points. Linking already-counted usage to an issue explains the total without raising its score.

Joining spend and work requires matching developer, repository and issue identities. Attribution conventions explain aliases, team moves and author credit.

AI-session field summary
✕Prompts & replies
✕Source code & file changes
✕Keystrokes & screenshots
✓Token counts & model names
✓Timestamps, message & session IDs
✓Developer, repository & issue identifiers; priced costs

Session readers discard conversation text; the proxy forwards it in transit. SQLite records and reader checkpoints can identify people, repositories and working directories. Raw GitHub webhook bodies can contain sensitive text and have bounded retention; derived developer records have no automatic retention ceiling. The stored-field, retention and erasure rules cover the full schema and optional path attribution.

The full method: how the score is computed →

Historical self-measurement

We point the meter at ourselves.

We run TIER on TIER's own development every day, and we use what it shows us to decide how we work with AI tools and where the money goes.

This is the maintainer's reported historical reading from TIER's own development repository. It illustrates the dashboard; it is not independent validation of the metric or its rubric. The maintainer has exercised TIER's CI and revert rules in manual test runs; the project's automated webhook tests exercise the same rules. The inspected historical 221 figure has no recorded quality-event receipt. Read it as size-weighted history, not demonstrated quality-adjusted output. The 30 days through 21 July 2026; published 22 July UTC.

Historical 221: computed from backfilled history; no quality events were recorded for it, so it is size-weighted only. Original inputs and run settings are not publicly reproducible. This is an observational ratio, not a causal estimate or independent validation.

Claude costs came from deduplicated Claude Code usage logs; completeness against independent provider accounting remains unvalidated, including for the subscription routes used here. If those logs undercount, costs are understated and TIER scores read high. If Claude's logs undercount more than Codex's, Claude looks relatively cheaper in cross-vendor comparisons.

221
Historical size-weighted points per $1,000 of captured spend
$3,268
of AI usage at list price, building TIER
152
merged PRs, worth 723 weighted points
$4.52
cost per outcome point

723 points ÷ ($3,268 / $1,000) rounds to 221. The published rounded totals decompose to about 4.76 points per recorded PR and 46.5 recorded PRs per $1,000. The underlying historical inputs remain unverified. This predates v0.5.2; the private inputs, exact totals and run settings were not preserved in a public dataset, so this page cannot independently establish them.

Synthetic TIER dashboard with invented outcomes and spend: aggregate TIER 138.7, $364.10 recorded cost, no billed spend recorded, and model/cache cost breakdowns.
Synthetic dashboard illustration from invented demo data, 25 September–14 October 2026: aggregate TIER 138.7 and $364.10 recorded cost. No billed spend is recorded for this window, so Spend Leverage is unavailable. Capture Fidelity describes the request-level share of captured spend; it does not establish complete capture. This capture shows the synthetic developer-mode dashboard.

72.1% of recorded spend lacked an issue match; 28% matched is rounded. All captured spend counts here. Unattributed usage can be useful; the gap measures linkage, not waste. Starting a session outside the worktree is one possible cause, but this run does not establish its cause or the amount of uncaptured usage.

A mechanic reads a green TIER gauge fitted to his own truck; a clipboard on the bench says “Our own number”. Caption: “We run it on ourselves first, and publish what it says.”

Who it's for

Finance, engineering leads and engineers.

A finance chief, a manager and a developer point at one green TIER gauge, asking “Yield per dollar”, “Team trends” and “Audit the math”. Caption: “Three questions. One number they can all check.”
CFO / Finance

Compare usage with the plan you paid for

Spend Leverage is list-price cost divided by what you actually paid. Finance supplies monthly invoice totals; TIER cannot infer payments or reconcile invoice scope. Missing usage understates leverage, and without a positive paid total it is unavailable. It compares usage with a plan price, not savings or financial return. Invoice inputs and allocation.

List-price cost and actual-paid spend are separate · finance supplies invoice totals
VP of Engineering

Compare each team with its own past

Use comparable monthly reports to review spending. Keep pricing, sizing and capture consistent, and account for changes in work mix and cache use. Team/division reports show aggregate rows; useful research can still lower the ratio.

Sums before dividing · sealed months · compare within the same work context
Staff Engineer

Inspect the capture and scoring code

One Go program stores server data in SQLite. v0.6.1’s go.mod lists three direct dependencies. Inspect the readers, price table and outcome rules before relying on a report.

Apache-2.0 · source available · self-hosted

See how each team uses TIER →

Get better

Coach the practice, not the person.

Review model choice, cache use and usage without a clear task. Choose a change in working practice and compare it with your own earlier, comparable work. TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual.

Every developer

Start with your local cost report

Start with Path A’s local cost report. An issue-bearing branch and a session started in the worktree doing the work help explain where spend went. Reduce avoidable usage after checking what the work needed.

Managers & leads

Preview named developer mode with invented data

In the synthetic demo’s developer mode, viewers see invented developer identifiers and 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, is the only preview of these views. Per-viewer row restrictions remain unbuilt. Reports include earlier-period comparisons and an uncertainty range based on recorded history; missing capture and business value lie outside that range. Model/cache breakdowns are available here; per-developer coaching levers remain planned. Guidance for named measurement.

A debugging period and a feature-building period need different context. Nothing in the software stops an admin from misusing identifiers or exports. TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual. Read the coaching guidance.

What you can verify

The source and scoring rules are public.

Read the implementation and compare it with your records. Preserve the input rows, reporting window, prices and scoring settings when publishing a result; late records can change a live report.

Two people hold identical “TIER: 250” receipts from a glass machine with “Spend”, “Outcomes” and “Divide” hoppers. A sign reads “Same inputs, same number”. Caption: “Nothing hidden. Run it twice, get the same answer.”

Deterministic

Deterministic: the same stored inputs and scoring rules give the same score. Verification and report manifests explain how to preserve and check a run.

Inspect what is stored

The field summary above distinguishes AI-session metadata from raw GitHub bodies. Review it before choosing what to collect and who receives access.

Self-hosted, single binary

You control where the data lives: one program and one SQLite database file. Backfill queries GitHub, uploads reach your server, and configured proxies and pollers contact their providers.

Read the documented failure modes

The 28-scenario adversarial analysis covers gaming and misuse. It distinguishes implemented protections, proposals and accepted limits, and explains how its historical token examples differ from today’s dollar calculation.

Test spending changes against your own consistently captured records and comparable work. The project offers documentation, issues and releases in the public repository; no support SLA is promised.

Try the local cost report

Inspect your recorded AI usage.

Free Apache-2.0 software. Start with Path A’s local cost report, then add merged history or a shared server when you need them.

github.com/tiermetric/tier ↗ Getting started
$tier_bin=$(go env GOBIN) && tier_gopath=$(go env GOPATH) && tier_bin=${tier_bin:-${tier_gopath%%:*}/bin} && go install github.com/tiermetric/tier/cmd/tierd@v0.6.1 && "$tier_bin/tierd" score --repo .