Field notes / tooling
The dashboard accused itself
Our own cost dashboard flagged the day it was born as a 26.5x overspend. The transcript said otherwise. Making sure it never happened to anyone else took a bug report, and three days later the fix shipped.
We build a lot of small internal dashboards. One of them tracks Claude Code token spend across the projects on this machine. It leans on an open-source engine called CodeBurn: free, local-only, reads session logs and estimates what each session would have cost on pay-as-you-go pricing. CodeBurn has a panel called optimize, and the panel's job is to flag waste. Sessions that cost far more than a project's own average, with no obvious reason why.
One day the panel flagged something inside its own house. The dashboard's build session, the day it came into existence, sat there marked as a 26.5x cost outlier. Twenty-six and a half times the project's own average. That is the kind of number designed to make you flinch.
We didn't flinch. We pulled the raw transcript.
1,070 eventsWhat was actually in there
It ran to 1,070 events. A brainstorm, a plan, twenty-four build agents dispatched, and a final commit that promoted the dashboard to its first real version. That was the founding session, and founding sessions are expensive.
The day a project goes from nothing to something costs more than any day after it. A house's foundation costs more than repainting one room, and nobody files that under waste. The panel had measured the founding day against the quiet maintenance days that followed and called the ratio waste. That's a category error rather than a measurement problem. The comparison was never apples to apples, and no cost threshold repairs a comparison that was wrong before the arithmetic started.
So the panel was right to ask the question. It was wrong about the answer.
silence it or file itThe two easy exits
We could have ignored the flag. We could have silenced it locally and moved on, which would have worked fine, for us. It would also have left the bug sitting there for everyone else running CodeBurn against a young project, which is every project at some point.
So we read CodeBurn's source instead. The comparison lives in a function called detectSessionOutliers, in src/optimize.ts. Reading it turned up the useful part: the codebase already had the mechanism a fix would need. A wee exclusion list called outlierExclusions, already doing this exact kind of job elsewhere in the panel, sitting right there.
That gave us something better to file than a complaint. Issue #664: what happens, why it's wrong, and the specific lines to change.
six costed sessionsThe maintainer's fix was better than ours
CodeBurn has an active maintainer, and the pull request was open by the next morning.
Our sketch excluded every project's founding session, permanently. The maintainer's version was sharper. It excludes the founding session only while a project is young, and it measures young by how many costed sessions the project has behind it rather than by wall-clock age.
That distinction is the whole fix. Under our version, a genuinely wasteful founding session would have hidden behind the exemption forever. Under the maintainer's, the benefit of the doubt expires after six costed sessions. A founding session in a two-week-old project gets it. The same session in a mature project with months of history does not. Wall-clock age would have missed that, because a project can be old and barely used, and it's the use that makes the average mean anything.
Three new tests. The 86-test suite green.
The whole arc took three days. Report on the 14th, the maintainer's pull request open by the 15th, merged on the 16th, and out in v0.9.16 on the 17th — where the release notes say, in plain words, that a young project's founding session is no longer flagged as a cost outlier. If you run CodeBurn, update it and the bug is gone.
- 14 Jul us Issue #664 filed, with the lines to change.
- 15 Jul maintainer Pull request open by the next morning.
- 16 Jul maintainer Merged. Three new tests, suite green.
- 17 Jul upstream Out in v0.9.16, for everyone.
not luckWhat it took
None of this needed luck. It needed not trusting a scary number at face value, then reading the data underneath it. The rest was writing the bug report the way you would want one written to you: the exact code path, the root cause instead of the symptom, and a fix that was ready to review.
The tool was wrong, and it was wrong in a way worth the time it took to explain properly. Silencing the flag locally would have fixed our dashboard. It would have left the bug exactly where it was.