← MyStatus

Cost breakdown of 3 deliverables

Measured . These are three deliverables, not all of them.

Somebody asked how you would know what your AI spend actually buys you.

How to read these numbers →

Receipt #1

Costs for building a report

Charged to Engineering

Shipped Aug-30-26
1.7
Person hours

Time the public work log was open while this was being built.

$255
At $150 an hour

The rate stated 2026-08-26. Nobody was billed this; it is what the same hours would have cost at consulting rates.

5,670,896
Tokens, cost-weighted

Input once, cached reading a tenth, cached writing double, output five times.

$26.43
Tokens, at list rates

Published rates on the day each turn ran. Nobody was billed this; the work runs on a flat monthly plan.

The hours are a floor — they count time the public log was open, and a machine's log cannot see the minutes a person spent reading and deciding. Both dollar figures are stated, not measured: a price list, not a bill, and nobody was billed either. The tokens are a floor too: they count from the branch's first commit, while the closing row this receipt links to counts from when the branch was cut, and the difference is the reading and planning done before anything was written.

View the report we made →

The billing report. A tool that reads our public work log and turns it into the document a client would actually be sent: every deliverable that shipped in a period, how long each one was worked, and what that comes to at an agreed rate. Its first real run billed 45.3 hours of 47.9 measured — and it found a rounding rule that had quietly dropped $390, because sixty-six lines each rounded down on their own. This receipt prices the thing that prices things, which is either the most useful entry on the page or the most circular, depending on your mood.

Where these figures come from

The token bill, in parts

Written
161,278
The work itself
Standing context
13,604,340
105,460 per turn, 129 turns
Re-reading itself
24,749,855
The conversation so far, every turn
Model
claude-opus-5
Cost per token differs by model

Never one total. Adding these together gives a number several times larger than the work, because the standing instructions are re-read on every single turn — so the big figure is real, is quoted by usage dashboards, and overstates what was built. Both halves are here so nobody has to take our word for either.

Where the hours came from

1 of 1 stretch ended on a posted entry you can open.

Receipt #2

Costs for building usage insight

Charged to Engineering

Shipped Aug-31-26
2.6
Person hours

Time the public work log was open while this was being built.

$390
At $150 an hour

The rate stated 2026-08-26. Nobody was billed this; it is what the same hours would have cost at consulting rates.

1,874,057
Tokens, cost-weighted

Input once, cached reading a tenth, cached writing double, output five times.

$8.23
Tokens, at list rates

Published rates on the day each turn ran. Nobody was billed this; the work runs on a flat monthly plan.

The hours are a floor — they count time the public log was open, and a machine's log cannot see the minutes a person spent reading and deciding. Both dollar figures are stated, not measured: a price list, not a bill, and nobody was billed either. The tokens are a floor too: they count from the branch's first commit, while the closing row this receipt links to counts from when the branch was cut, and the difference is the reading and planning done before anything was written.

The curve it produced, on the stats page →

The aging curve. A measurement of when a working session stops being worth continuing. Every exchange in a long session costs more than the one before it, because the whole conversation so far gets re-read each time — and nobody here knew by how much. Across the 144 sessions we had measured then, it turned out to be nearly three times, once a session passes its 141st exchange; the curve has been retaken twice since, and /stats carries what it says today rather than this card. The uncomfortable part is what it caught: our own habit of batching several jobs into one long session, adopted weeks earlier for an unrelated reason, was the most expensive thing in the table.

Where these figures come from

The token bill, in parts

Written
46,180
The work itself
Standing context
4,666,904
106,066 per turn, 44 turns
Re-reading itself
5,658,187
The conversation so far, every turn
Model
claude-opus-5
Cost per token differs by model

Never one total. Adding these together gives a number several times larger than the work, because the standing instructions are re-read on every single turn — so the big figure is real, is quoted by usage dashboards, and overstates what was built. Both halves are here so nobody has to take our word for either.

Where the hours came from

1 of 1 stretch ended on a posted entry you can open.

Receipt #3

Costs for re-laying this page

Charged to Marketing

Shipped Sep-22-26
5.5
Person hours

Time the public work log was open while this was being built.

$825
At $150 an hour

The rate stated 2026-08-26. Nobody was billed this; it is what the same hours would have cost at consulting rates.

4,204,671
Tokens, cost-weighted

Input once, cached reading a tenth, cached writing double, output five times.

$19.12
Tokens, at list rates

Published rates on the day each turn ran. Nobody was billed this; the work runs on a flat monthly plan.

The hours are a floor — they count time the public log was open, and a machine's log cannot see the minutes a person spent reading and deciding. Both dollar figures are stated, not measured: a price list, not a bill, and nobody was billed either. The tokens are a floor too: they count from the branch's first commit, while the closing row this receipt links to counts from when the branch was cut, and the difference is the reading and planning done before anything was written. On this receipt that was 44% of the tokens, measured by hand on 22 September.

The row that closed it, on the work log →

This page, re-laid as receipts. The re-layout of the page you are reading. It used to open with three paragraphs explaining the numbers, and on a phone you could read the whole first screen without meeting one. Now it opens with the receipts, each saying what the money was for before it says anything else. It added no feature and no capability — nothing on this page can do anything it could not do the day before. It is the work of making a page say what it is to the person it is sent to, which is why this is the one receipt here charged to Marketing rather than Engineering, even though every minute of it was spent in a code editor.

Where these figures come from

The token bill, in parts

Written
40,246
The work itself
Standing context
11,280,600
150,408 per turn, 75 turns
Re-reading itself
18,595,750
The conversation so far, every turn
Model
claude-opus-5
Cost per token differs by model

Never one total. Adding these together gives a number several times larger than the work, because the standing instructions are re-read on every single turn — so the big figure is real, is quoted by usage dashboards, and overstates what was built. Both halves are here so nobody has to take our word for either.

Where the hours came from

1 of 1 stretch ended on a posted entry you can open.

The department on each receipt is stated by hand on this page. Nothing on the row says it yet; that is the next thing the record learns to carry.

How to read these numbers →

What this page is

It is a fair question and it usually gets an unfair answer — a token count, which measures how much was read, not how much was built. Above are three things we shipped, each with the hours it took, the tokens it cost, and a link to the public record every figure was read from.

Nothing on this page was measured for this page. The work log has been public since the day it started: an entry when a piece of work opens, entries while it runs, an entry when it merges. The hours are the time between those entries. The tokens are the receipt each finished piece of work already carried. All this page does is put them side by side and show you the rows.

How much of this was doing it twice

Rework here means work we did to fix or finish something we had already called done. It has always been a separate piece of work with its own record, so it can be counted rather than estimated. Since the work log opened on August 23, 255 pieces of work merged. 115 of them were rework. That is 45 percent, and the number is uncomfortable until you read the split.

Fixed a defect
10
Something shipped wrong
The task implied it
59
A second pass the work asked for
The record catching up
42
Merge hashes, notes, the queue
Proof after the fact
4
Checks that needed a live deploy

Most of it is not poor quality, and one column of it is. 10 of those merges went back to fix something that shipped wrong. That is 3 percent of everything that merged in the window. A retired bank CIO put the arithmetic to us on a call this month: fifty cents to do a thing, four dollars to fix it when it was done badly. He is right about where the money goes, which is exactly why those 10 are broken out here instead of resting inside the 115.

Both halves of this fraction were re-read on September 19, and the share went down. The count before that was taken on September 10 and read 101 of 211 — 47 percent. Refreshing only the bottom half would have printed us a better number for no reason except which half somebody touched, so both moved together: the 44 pieces of work that merged in between were read one at a time, 14 of them were rework, and that lower rate is what drags the share from 47 percent to 45. Not one of the 14 was a second pass — they are the record catching up, and fixes. The column that means poor quality moved the other way, 2 percent to 3.

Everything above was read by a person, and it stops on September 19. From September 22 the same count is read from the record instead: a second pass now closes with a card pointing at the task it follows up, labelled with one of four words, and a script counts the cards. Since then 34 of 91 pieces of work were rework — 37 percent, with 13 of them fixing a defect, and 2 merges carry no closing row, so this half is a floor too. Counted at ab446b4 on October 12. The two are printed apart and never added together, because they were drawn by different instruments: a person reading a row can tell a parent task from the followup that looks exactly like it, and a script reading a card cannot. 23 merges fall between the two halves, and they are counted in neither — the mechanism that makes a closing row readable is the same change that opened this seam, so nothing before it has a line to read. Re-reading them by hand is the work this change exists to end, and doing it for the newest days only is the error the paragraph above describes.

Three things this figure cannot see. 15 merges in the window never got a closing entry, so if any of them were rework the count above is a floor — and four of those, by their own merge messages, plainly were. A defect fixed under its own numbered prompt rather than on a followup branch is not reached at all: three in this window are that shape, and counting them would put the poor-quality column at 5 percent rather than 3. And the token cost of rework is not here at all: tokens on this page are measured per feature, and none of the three receipts above is one of these. Counted from 2026-08-23 on 2026-09-19, by hand, against the rows linked throughout this page.

Hours derived from the public work log. Tokens measured from session transcripts at the time of the run above. The same machinery produces the running totals on the stats page.