Most code lives in Swift Rewrite
That one brief accounts for 27,392 of the 46,599 final application SLOC across all nine builds.
Three AI builders · same three briefs · one receipt
Three apps, each built from scratch by Fable 5, GPT-5.5, and GPT-5.6-Sol. Same briefs, different engines. Fable finished in half the time, sent half the messages - and still charged double. Here is the receipt, line by line - and, in Q1-Q6, the code-quality audit of what the premium bought.
Same three builds each. The cheapest run and the priciest are separated by more than 2x.
Recorded workflow time only. Overnight pauses and gaps between manual resumptions are excluded.
Divide each bill by the hours the build was actually running and the models price themselves like contractors. One of them bills like a senior partner.
Total cost ÷ active workflow time
Per-build burn rate, priciest hour first
Speed is the saving grace. Fable burns $108.8 per active hour - 4.4x either GPT rate, peaking at $163.7/h on the Swift rewrite. But it also finished all three apps in 9h 09m of active work, less than half GPT-5.6's 22h 15m. That pace is why the total bill lands at 2.2x instead of 4.4x.
Same timing caveat as the section above. Active hours mix two measurement systems - the Codex goal ledger and Claude root-session turn durations - so read cross-model rates as close estimates, not lab-grade numbers.
Final application source at the clean benchmark snapshot. Bars separate code attributable after exact starter-copy removal from unchanged starter residue.
That one brief accounts for 27,392 of the 46,599 final application SLOC across all nine builds.
GPT-5.5 retained 1,503 exact starter SLOC, GPT-5.6 retained 1,350, and Fable retained just one.
About 1.9x GPT-5.6's rate. This measures source volume per active hour, not quality or maintainability.
Counting method. cloc 2.06 --skip-uniqueness at benchmark commit e74a40b, counting nonblank, noncomment TS, TSX, JS, JSX, and CSS in src/, app/, and widgets/. Tests are separate. Dependencies, native prebuild output, assets, build output, configuration, agent files, and explicit spike implementations are excluded. Starter-adjusted SLOC removes only SHA-256-identical starter files, so modified starter-derived files remain counted. Reproduce with bun run measure_code_lines.ts.
Starter-adjusted application SLOC across the bottom, dollars up the side. The dashed guides mark constant price-per-line rates - a build above a guide paid more per line than it marks. Every Fable run sits near or above the $80 guide; the cheapest GPT runs sit under $30.
Read with care. This prices volume, not quality - a cheaper line is not automatically a better one. Rates divide cost by starter-adjusted SLOC, so exact starter copies are removed before dividing.
The cost-heavy token classes only - input, output, and cache writes. Cache reads are cheap and huge, so they are pulled out to the side. This is the chart that explains the bill.
Fable pays to remember. It sends almost no fresh input but writes 23.0M cache tokens - the priciest class there is. Both GPT models write zero cache and instead push 21-26M input tokens. Different strategy, very different bill. Cache reads (cheap): Fable 656M, GPT-5.5 579M, GPT-5.6 716M.
Fable sent the fewest messages of any model, yet charged the most. Normalize by effort and the gap gets sharper.
Total cost ÷ messages sent
Total cost ÷ tokens processed
The premium is real. Fable 5 costs about 4.4x more per message than either GPT model and 2.2x the total for the same three apps - almost entirely from those cache writes.
Fable sent half the messages of either GPT model yet still charged the most. This is why: every one of its turns writes about twice the output and hauls about twice the cached context.
Output tokens ÷ messages sent
Cache reads ÷ messages sent
Half the messages, double the payload. Fable averages 643 output tokens per message against about 300 for both GPT models, and re-reads 294k cached tokens per turn against about 133k. Fewer, denser turns - the mechanism behind the per-message premium in the section above.
The Swift rewrite on Fable 5 is the single most expensive run in the whole set.
Every build plotted: tokens processed on the bottom, dollars up the side, bubble size is messages sent. Points that sit high for how far right they are cost more per token. Fable's runs float to the top.
Starter-adjusted application SLOC across the bottom, active workflow hours up the side. The second trend line removes the single 13h 34m run to expose how sensitive the relationship is.
The full regression adds about 45 active minutes for each additional 1,000 starter-adjusted source lines.
Removing Swift Rewrite on GPT-5.6 makes the estimated slope much shallower.
App scope, model behavior, debugging, testing, and tool latency can all affect time independently of code volume.
Interpretation. The sample has a moderate-to-strong positive association, but it does not establish causation. Pearson r measures the linear relationship; Spearman ρ checks whether larger builds generally rank as longer. The longest run has substantial leverage, so both fits are shown.
Nine builds with every token class, code-volume measure, duration, and cost broken out.
| App | Model | Messages | Tokens in | Tokens out | Cache read | Cache write | Total tokens | Final app SLOC | Test SLOC | Active time | Cost |
|---|
A second dataset. Nine independent review agents - one per build - read every source file and scored it on a CAST-derived rubric: Resiliency (will it break?), Agility (can a new dev change it safely?), Elegance (is it lean?). Health is the average of the three. The green band starts above 75.
Every build lands in the green band - but not equally. Fable posts the top score on all three apps. Most GPT builds cluster near the 75-point band line; only GPT-5.6's Swift rewrite breaks away from the pack.
Split health into its three dimensions and the story sharpens: robustness is close to a three-way tie. The separation is in changeability and leanness - dead code, duplication, naming, silent error handling.
Each audit converted its findings into an effort-to-fix estimate. The soft band is the range, the notch the midpoint. GPT-5.5's Swift rewrite alone carries more estimated debt than all three Fable builds combined.
Five of six GPT builds ship unchanged Expo starter template as dead code - up to ~730 LOC (20% of src) in one build - plus two competing theme systems. Fable ships none.
Bare catch blocks or uncaught promise chains with no logging appear in five of the six GPT builds. Failures surface as generic UI states that are hard to diagnose in production.
Model averages sit within about six points on error handling and defensive coding. The ranking is decided by cleanliness, not robustness.
Estimate fidelity. Debt is a bottom-up effort-to-fix estimate from counted violations, quoted at ±50%. Debt density divides each model's midpoint total by the lines its auditors read, so it is comparable across models but still an estimate, not a measurement.
Build cost across the bottom, health score up the side. At the model level the answer is yes: the spend ranking and the quality ranking are identical. Build by build it is noisier - GPT-5.6's Swift rewrite reaches 86 at less than half Fable's price.
Read with care. Nine builds is a small sample, and health scores are rubric-guided expert judgments (LLM auditors with file:line evidence), not deterministic static analysis. Directionally solid; not lab-grade.
All nine audits: every dimension score, the audit's own source-line count, the debt estimate, and the single biggest issue found.
| App | Model | Health | Band | Resiliency | Agility | Elegance | Audit LOC | Est. debt | Biggest issue |
|---|
Method. Scored with the code-quality-scoring framework (derived from CAST Highlight's Software Health indicators). One independent agent per build read all source files (dependencies, lockfiles, and generated files excluded), scored each dimension 0-100 with file:line evidence, and estimated remediation effort. Health = avg(Resiliency, Agility, Elegance); bands: green >75, orange ~53-75, red <53. Audit LOC is the auditor's source count and differs slightly from the cloc-based SLOC in section 05 (different exclusion rules). Full findings with file references: code-quality-report.md.
A separate seven-day diagnostic from Claude Code's /usage command. These signals describe local usage patterns, not the nine benchmark builds above.
Long sessions remain expensive even when their context is cached. Context length is the clearest usage-pressure signal in this snapshot.
This often points to background or loop sessions. Continuous activity can accumulate quickly, so it is worth confirming that every long run is intentional.
Every subagent makes its own requests. Delegation is useful, but model choice and prompt scope materially affect its usage footprint.
Share of usage associated with each skill
Usage associated with named subagent types
Usage associated with connected tool servers
Use /compact during a long task and /clear when switching to unrelated work.
Check that background and loop activity lasting eight hours or more is expected and still productive.
Use cheaper models for simpler subagents, especially general-purpose, and tighten prompts before spawning them.
MCP results remain in session context. Disable servers that are not needed, compact after large results, and scope heavy skills down or assign them a cheaper model in frontmatter.
Source and limits. Claude Code /usage, last seven days, approximate from sessions stored on this machine. Activity from other devices and claude.ai is excluded. The truncated skill name is preserved exactly as displayed by the command.