Release cadence: 99 PRs / 146 commits on main since v0.9.19 (20 days) — is a cut planned?

[therickfactr]

Hi — question about release cadence rather than a bug report.

main has moved a long way past the last published version, and I wanted to check whether a cut is planned or whether something is blocking one.

Where things stand (measured against tag v0.9.19, af291ae6, published 2026-07-20):

npm latest	0.9.19 (published 2026-07-20)
Commits on main since the tag	146
Merged PRs since the tag	99
package.json on main	still 0.9.19

That is 20 days, which is longer than any gap in the recent tag history (v0.9.15 → v0.9.16 → v0.9.19 ran 3–15 days apart).

Why it's noticeable from the outside: a good number of the unreleased commits change numbers users actually read, not just internals. A few examples:

• fix(context-budget): stop double-counting home skills and CLAUDE.md (99bf246)
• fix(kiro): estimate input tokens from the full prompt, not a 500-char slice (6c4645a)
• fix(models): price codex Kimi rollouts recorded as kimi/k3[1m] (a8a954f)
• fix(parser): fold SQLite -wal siblings into source fingerprints (b7235ad)
• feat(providers): add cline-cli provider for Cline CLI sessions (448d470)
• feat(dash): dark mode with pre-paint bootstrap and themed charts (6fca845)
• fix(copilot): classify CLI sessions by source provenance, not producer (fix(copilot): classify CLI sessions by source provenance, not producer #945)

Anyone on 0.9.19 is still seeing the pre-fix cost figures for those paths. The practical workaround today is running a source build off main, which is what I've been doing — but that isn't something most users will do.

To be clear about one thing: the Homebrew formula is not the problem here — brew info codeburn reports stable 0.9.19, so it is tracking the npm release correctly. The npm release itself is just the older artifact now.

So: is a 0.9.20 (or 0.10.0) cut on the roadmap, and is there anything holding it up? If it's a matter of someone needing to sanity-check a release candidate, or triage which of the 99 belong in the notes, I'm happy to help with that — just say what would be useful.

Thanks for the project, and for the quick reviews on the PRs I've sent.

[iamtoruk]

Thanks for the precise write-up, and yes, a cut is planned in the next few days.

The gap is not a process stall, it is validation load. You identified the reason yourself in your examples: an unusually large share of these 99 PRs change the numbers users read, not internals. Cost attribution, token accounting, cache fingerprinting, provider parsing. Every change in that class gets validated against real session data on main before it ships, because a wrong number that reaches npm is worse than a late one. With this many accounting changes landing in one window, that validation pass simply takes longer than the 3 to 15 day gaps you measured, which covered much smaller batches.

Where that leaves the release: validation is ongoing now, and the target is a cut within days, not weeks. Version and notes will be settled as part of that pass.

Appreciate the offer to help with notes triage, that may well be useful once the validation pass settles which changes make the cut. Will follow up here either way, and this issue stays open until the release is tagged.