What one seat returns

The four numbers

One engineer, one flat-rate seat, 10.4 measured weeks.

$7,367

metered-equivalent consumption, at list API rates

5.9×

what the same work would cost without caching discipline

model calls, across five model tiers

production components shipped and operated

To be precise about what the first figure is and is not: it is not an invoice, and not a saving. The work ran on a flat-rate plan. It is what the same token volume would bill if metered at published API rates — the honest way to express what a single seat carried.

Two windows, kept separate	Span	Commits
Project life	21 Apr → 9 Aug · 15.7 weeks	1,851
Measured token window	28 May → 9 Aug · 10.4 weeks	1,461

The consumption figure covers 66% of the project's life and cloud sessions only — records from earlier and from local machines are not in it. So it bought 1,461 of the 1,851 commits, not all of them, and the true figure is higher than what is printed here. Every number on this page is a floor, and where two spans could be conflated to make something look better, they are listed separately instead.

Is the spend controlled?

This is the question worth answering first, and it has a number.

Of 7.16 billion tokens consumed, 96.3% were cache reads — billed at a tenth of the standard input rate because the work was deliberately structured around a stable, reusable context. Price the identical token volume with no caching discipline and it comes to $43,544.

Same work, priced two ways	Cost
As actually run	$7,367	structured for cache reuse
With no caching discipline	$43,544	every token billed fresh
Difference	$36,178	the cost of not knowing this

That gap is the entire argument about predictability. Unmanaged, this consumption pattern produces the runaway bill people are right to fear. Managed, it is a sixth of that — and the management is not a heroic effort, it is a handful of practices applied consistently (the working method documents them). The figure is reproducible on any machine's usage records, not a claim.

The demand signal

The tier was outgrown twice, on personal money, before anyone was asked to fund anything.

Stage	What happened
Entry individual tier	Where the project started, in April
Upgraded to the top individual tier	Self-funded, because the work had outgrown the first one
Exceeded that tier twice	Two overages paid on top — demand kept climbing past the ceiling

This is the part a forecast cannot give you. Projected demand is an argument; a tier upgrade and two overages paid out of pocket are revealed preference. The usage did not have to be talked into existing, and the ceiling was not theoretical — it was hit, twice, by one person on one project.

The honest read of that: the individual tiers are correctly sized for individual use, and this stopped being individual use somewhere around the third component. The ask is not for more capacity in the abstract — it is for the tier that matches a workload which has already demonstrated its own size.

Cheap models on cheap work

Routing by difficulty, visible in the billing shape.

Tier	Calls	Cost	What it was used for
Frontier	3,159	$2,398	the hardest reasoning and long-horizon runs
High	24,217	$4,919	the working majority — code, review, analysis
Mid	671	$34	well-specified mid-difficulty tasks
Small	1,210	$12	documentation retrieval, cited and verified

1,210 retrieval calls cost twelve dollars because retrieval does not need a frontier model. That is a design decision, made once and applied automatically — the kind of thing that separates a tool being used well from a tool being used.

What came out

Not a prototype — production systems with users on a schedule.

Four components, four release targets

An ingest and orchestration service, a zero-dependency telemetry agent running on machines I cannot access, an auto-updating desktop client with three release channels, and a web application. Each independently versioned, each with its own rollback story.

~58k lines · 1,851 commits · 596 automated releases

Operated, not just built

Deploy freezes during live windows enforced in CI, load-shedding and per-client budgets as configuration rather than deploys, circuit breakers, crash-loop auto-rollback, and a durable client queue so an outage costs latency rather than data.

86 test suites · CI on every shipping branch

Data platform

192 schema migrations, row-level security, reporting functions, and a reconciliation layer that merges overlapping records from many independent clients into one authoritative row without double-counting.

77 application routes

Audits that found real defects

A join silently matching 2.6% of the time, 37 enabled-but-dead user rules, a category of records 44% of which were false, and 79,199 lines of branch drift — each found by asking a question nobody had asked, and each cheap to run.

every one looked healthy from outside

The exhibit most people miss

The same seat produced the presentation layer, not just the code.

A seat is usually justified on engineering output alone, which undersells it. The same seat, in the same sessions, produced the explanatory and marketing surfaces that would otherwise need a designer, a front-end developer, and a copywriter — including the page you are reading and the two beside it.

Surface	Size	What it involved
Product story page	550 lines	A seven-chapter scroll-through explaining the platform to non-technical readers, written from corrected source facts rather than invention
Animated interface demos	401 lines	Four working recreations of live product overlays — a damage meter with a defensive-cooldown countdown, a healer-status board, a synchronized-callout sequence, and an auction flow — animated from real recorded values
Storyboarded sequence	192 lines	A scroll-driven build-up animation storyboarded shot by shot with the client, contained to a phone viewport after the first version overflowed it
Condensed variant	148 lines	A short version of the same story for readers who will not scroll seven chapters
This site	900 lines	Three pages and a shared stylesheet, self-contained: no external fonts, no CDN, nothing fetched at render time

All of it hand-built rather than templated — scroll-reveal and count-up behavior written directly against the browser's intersection observer, reduced-motion honored, light and dark both handled. The point is not that the pages are elaborate. It is that explanatory and design work landed inside the same seat, on the same day, as the database migration and the release — which is where a lot of the real return sits, and where a code-only accounting misses it entirely.

The objections, answered

In the order they usually arrive.

“Costs are unpredictable”: A flat seat is a fixed line item by definition. The consumption behind it is also measurable and, here, managed — 96.3% cache reads, and a 5.9× gap against the undisciplined version of the same work.
“Output quality is unverifiable”: 86 test suites, golden-file regression over recorded production input, and CI on every branch that reaches a user. The audits above found defects that had passed green tests for months — the verification is real enough to catch things people missed.
“It only helps with boilerplate”: The listed findings are not boilerplate: a silent join failure, a clock-skew measurement across real machines, a pattern compiler eating its own input. The gains were largest on the ambiguous work.
“One person got lucky”: Possibly — which is why every figure here is reproducible: counted from the repository, the production database, or the usage records, with the method written down so it transfers.
“What does it replace?”: Nothing, in this case — it is work that would not otherwise exist at this scope. That is the honest answer, and a better one than a fabricated headcount equivalence.

In one line

One seat carried $7,367 of metered-equivalent work in 10.4 measured weeks, at a sixth of what the same tokens cost undisciplined, and shipped four production components and their presentation layer.

Every number on this page is counted, and every one of them is a floor.

← Profile · Working method →