How it's used
Four ways to use TIER’s yield and spending measures.
TIER runs on your own systems: a command-line tool, server and dashboard for one organisation. Its yield is accepted outcome points per $1,000 of recorded AI cost. A point is a change’s size multiplied by its recorded quality; it has no dollar value. The scoring rules explain which work counts and how it is weighted.
Cost per point is dollars spent per outcome point. Yield includes all captured cost, including unfinished and unlinked work. Finance’s separate measure, Spend Leverage, compares recorded usage with paid spend. 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.
Choose the reporting mode
Coach the practice, not the person.
Choose team or division reporting for real-data coaching of the practice. 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. Every mode stores individual records. v0.6.1 has four credentials: an admin token with full access, a read-only viewer token, a monitoring-only metrics token, and an upload-only ingest token for laptops. Anyone holding the admin token can read every developer’s stored records in any reporting mode. The ingest token cannot read anything, but it is not tied to a person, so its holder can upload usage under another name.
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.
The synthetic demo’s viewer sees invented developer figures. On real data, developer-mode startup is refused in v0.6.1 (#826). Per-viewer access and automatic age deletion await those controls. Cost, outcome and quality records stay until erased. The access, storage and erasure reference explains the limits. Look at the work together, as the carpenters do here.
Inspect your local AI costs.
Install tierd v0.6.1, TIER’s executable, then run tierd score --repo . in your git checkout. It reads Claude Code session logs and local git history, uses bundled prices and makes no network calls. It prints costs by developer and issue, without outcomes or a yield score; no authentication credential is needed. This local cost table stays on your laptop and is separate from the server’s per-issue report, which is unavailable on real data in v0.6.1 (#826). The quickstart covers installation and the server setup for a full score.
To link spend, put your tracker’s issue number in the branch and start the session in that checkout or worktree. Local costs use your OS username; PR outcomes use the GitHub author’s login, joined by an identity alias. Pairing credit stays with the recorded author.
Test a change in practice.
The synthetic demo illustrates cache-read share (input-side tokens reused from earlier context), premium-model spend share (cost on models at or above TIER’s base input-price cutoff), and cost per point for one kind of accepted work. These breakdowns exist only in developer mode, without an anonymity floor. Per-developer views and the per-issue report are not available on real data in v0.6.1 (#826). Team and division reports omit these breakdowns. For a real-data pilot, agree on one practice and review the team’s sealed calendar-month reports together.
Compare two sealed full calendar months in team mode, using the viewer token. Record differences in repository scope, membership, work mix, capture, prices and scoring rules. Group scores carry no interval, and a comparison API group’s false significance flag means no test was computed. The manager pilot explains the k contributor floor, loading retained history and waiting for the full month and grace period. Check the source records and repeat the observation before attributing a change to the practice.
Read group spend and yield.
Team and division reports use sealed calendar months, computed once after close and kept unchanged. A group appears only when each reported measure has enough contributors; small groups fold into “other”, and an insufficient residual withholds the whole report. The group-report reference covers the contributor floor and loading history before arming sealing.
Group reports exclude spend recorded under no person’s identity. Read Spend Leverage below alongside the group’s cost per point. The synthetic demo’s developer reports separate spend with no linked issue from linked spend with no outcome for that developer in the period. Both remain in yield’s cost. Unlinked spend can still support useful work.
Read the same report together.
Read the same group report together and compare it with that group’s history. Use completed periods within the captured cost history: spend lands when incurred, while outcomes land when recorded as merged.
Check work mix and labels against PRs, capture against source-tool usage, and merge timing before interpreting a rise. Group reports omit those breakdowns, so bring the source records and check another completed period. The comparison rules cover windows, price versions and scoring versions.
The CFO number
Spend Leverage compares your usage with your bill.
Spend Leverage is server-only: the list-price value of captured usage divided by paid spend. Above 1×, recorded usage was worth more at list rates than the amount paid; below 1×, less. Pay-as-you-go approaches 1× when capture, billed scope and list rates match. Discounts and capture gaps can move it.
$10,000 of usage at list price on a $4,000 invoice = 2.5×
Paid spend comes from the operator’s API posts to TIER using amounts supplied by finance, from provider billing pollers, or from configured subscription fees. The admin token used for posting stays with the operator; report readers use the viewer token. Record each bill through one path to avoid counting it twice. Finance must reconcile the amounts with bills, choose the accounting treatment, and match complete calendar months, people and tools. The billing reference covers posting, credits, corrections and seat allocation.
Use leverage to examine a pricing plan; savings and work value need separate evidence. Check the provider’s usage reports before changing a plan: incomplete capture lowers leverage, and Claude Code log accuracy remains unresolved. Capture also supports opt-in Codex, Opencode on Z.ai and Muse, routed proxy calls, Anthropic/OpenAI API usage and manual costs; check that every tool you use is covered.
Coaching
Read the figures in context.
A manager can discuss the team’s cost per point against that team’s own sealed calendar-month history to choose a practice to try, subject to the k contributor floor. 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 conversation assesses the work and its context; a row is not a grade of a person. A dedicated habits view is planned. 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.
| Unsupported interpretation | Coaching practice |
|---|---|
| Rank teammates by yield | Compare a group with its own earlier reports |
| Treat a developer’s row as a grade | Discuss one practice with the team |
| Read a period’s rise as proof of an effect | Check the source records and repeat the observation |
| Compare different kinds of work | Check similar work in source records; group reports omit work-type panels |
| Read recent spend as completed work | Allow for outcomes arriving after spending |
Record the practice to try and the period when you’ll check it.
Peer-learning and coaching playbook → · History of software measurement and individual incentives →