…110)

The fixture timestamps are fixed at 2026-08-21 while the test asks for a
30-day window against the real clock, so on 2026-09-20 the corpus aged out
of that window and the warm update read a second body. The assertion was
about incremental body reads, not about the window, and it expired by date
on every branch. Pinning Date.now the way the neighbouring content tests
already do keeps it meaningful.

Day, month and hour keys are derived once per ingested record, and each call
built a new Intl.DateTimeFormat - twice, because resolveTimeZone constructed
one of its own. Formatter construction dominates that path: a CPU profile of a
pegged extension host attributed 57% of samples to resolveTimeZone and
partsInZone alone.

Memoise the resolved zone and both formatters per zone. Keys are unchanged,
including the empty-zone and invalid-zone fallbacks; the cache holds one entry
per configured zone. Measured on a 1.4 GB local history: 1,059 -> 167,982
records/second (158x), 0 key mismatches over the comparison set.

Co-authored-by: Jiaming WANG (Carl) <74130028+Carl723000@users.noreply.github.com>

The content analysis fast path required exactly one changed file
(sourcePlans.length === 1 && plans.length === 1). A machine running several
agents appends to several transcripts between two refreshes, so that gate never
held: every refresh fell back to replaceWithFullAnalysisPlans() and re-read
every file. The diagnostics show the shape of it - changed=3 reused=641
alongside bodies=644 and bytes=1.4 GB.

The application side already loops over plans, so the gate is what limited it.
Allow any number of pure tail appends, and make two ordering guarantees the
single-file case never needed:

- parse appends in full-scan order, so the first file to carry a UUID owns it
  exactly as in the full loader (the comparator returned 0 for two appends,
  leaving discovery order to decide);
- attribute each new UUID to the appended file that actually carries it,
  earliest first, instead of to parsedPlans[0].

The per-file UUID ownership check that forces a rebuild now runs for every
appended file rather than only a lone one.

Measured on 15 real transcripts (34 MB), three files appended: 15 body reads
and 8680 ms became 3 body reads and 586 ms.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Jiaming WANG (Carl) <74130028+Carl723000@users.noreply.github.com>
Co-authored-by: OpenAI Codex <215057067+openai-codex[bot]@users.noreply.github.com>

* perf: keep multi-file appends on the incremental path (#99)

The content analysis fast path required exactly one changed file
(sourcePlans.length === 1 && plans.length === 1). A machine running several
agents appends to several transcripts between two refreshes, so that gate never
held: every refresh fell back to replaceWithFullAnalysisPlans() and re-read
every file. The diagnostics show the shape of it - changed=3 reused=641
alongside bodies=644 and bytes=1.4 GB.

The application side already loops over plans, so the gate is what limited it.
Allow any number of pure tail appends, and make two ordering guarantees the
single-file case never needed:

- parse appends in full-scan order, so the first file to carry a UUID owns it
  exactly as in the full loader (the comparator returned 0 for two appends,
  leaving discovery order to decide);
- attribute each new UUID to the appended file that actually carries it,
  earliest first, instead of to parsedPlans[0].

The per-file UUID ownership check that forces a rebuild now runs for every
appended file rather than only a lone one.

Measured on 15 real transcripts (34 MB), three files appended: 15 body reads
and 8680 ms became 3 body reads and 586 ms.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* perf: a new transcript no longer rebuilds the corpus (#99)

A file that had just appeared was classified as an unsafe source mutation, so
plans were replaced with a full rebuild of every file. Every new session starts
its own transcript, so on a machine running agents this happened many times a
day - and it is why the multi-file append fast path rarely helped in practice.

A new file is as safe as a tail append: its own body is read in full and the
established contributions are untouched. Let such plans through the gate, add
the new file's whole analysis as its delta, and recompute ordering state from
metadata only when files were actually added, so pure appends still never touch
historical files.

Ownership is guarded: a new file carrying a UUID somebody already owns falls
back to the full rebuild, because the full loader resolves that by scan order.

Measured on 15 real transcripts, two appends plus one new file: 16 body reads
and 3042 ms became 3 body reads and 567 ms.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Carl <74130028+Carl723000@users.noreply.github.com>
Co-authored-by: OpenAI Codex <215057067+openai-codex[bot]@users.noreply.github.com>

* feat: optional status-bar quota format template

Adds statusBarQuotaFormat (default empty, which keeps the built-in
layout). A template names the quota windows itself:
{5h|wk|7d|model:NAME}.{pct|reset|label}, e.g.
"{5h.pct} | {7d.pct} · {model:Fable.pct}".

Separators come out as typed. A segment whose windows the account does
not report is dropped together with its separator, so one template
works across plans. The warning colour follows the windows the
template shows.

* test: cover the quota format status-bar wiring

Drives setVisibility/updateQuota against the vscode stub so the path from
the setting to the bar text and its warning colour is pinned, not only
the pure formatter.

* fix: keep typed spacing and unknown tokens in a quota format

Literal text kept its own whitespace collapsed, and a segment naming only
windows the account lacks took any typo in it down as well, which
contradicted the rule that an unrecognised token stays visible. A missing
window now leaves a marker that closes just its own gap.

Also documents the setting in the two README editions that carry
settings detail.

* feat: let a reset token name its own countdown style

resetCountdownFormat is one setting for the whole bar, so a template could not
put a countdown for the 5h window beside a wall clock for the week. A reset
token now takes an optional style - {5h.reset:units}, :decimal, :clock or :at -
and falls back to the global format without one. A reset the API left blank
closes its gap the way a missing window does.

* ux: keep quota format presets compact across locales

* docs: place quota format in current configuration guidance

* docs: separate published v2.3.3 from unreleased changes

---------

Co-authored-by: Carl <74130028+Carl723000@users.noreply.github.com>

On a long history the rolling window is always drifting past something: some
file's oldest event has just left it, so the file arrives as a 'cutoff'
rebuild, or its stored aggregate is rebased in place. The analysis fast path
demanded "appends and nothing else", so either case rejected it and every
refresh re-read the whole corpus.

Measured on a 650-file, 1.4 GB history with several agents running: 136 of 140
refreshes re-read every body to serve one appended file — around 60 s of parse
time per refresh, roughly once a minute, which is what pegged the extension
host.

Neither case invalidates the other files. A 'cutoff' rebuild is assigned only
when the body on disk is unchanged, so the file owns exactly the UUIDs it
owned before and cannot preempt a later owner; a rebase only narrows an
aggregate that is already stored, and the UUIDs it drops are handed to the
ownership pass, which re-plans precisely those files that could claim them.

What does invalidate every stored contribution is a changed analysis context —
no prior runtime, a different time zone, a different window length — and that
still forces the rebuild, as do deletions, moves and a cutoff moving backward.

The guards that matter keep their tests: a rebuilt earlier file preempting a
later UUID owner, and an append that gives a zero-timestamp file its first
timestamp, both still fall back to the full rebuild.

formatUsageDate called toLocaleDateString once per table row and chart
point, constructing a fresh Intl.DateTimeFormat each time. That is the
same per-call cost #109 removed from dateKeys, and it showed up at 3-8%
self time in extension-host profiles captured while the dashboard was
rendering.

Formatters are now cached per locale and options. When no date field is
requested, the numeric year/month/day default that toLocaleDateString
applies is added explicitly, so output stays identical. A new test
compares the result against toLocaleDateString for all eight UI locales
across several option shapes, including the cached second call.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

* perf: an appended file leaving the window stays incremental (#99)

Follow-up to the previous window-drift fix, from the same measurement: full
rebuilds became rare but did not stop, and the remaining ones each cost 50-120 s
of parse time.

The remaining cause is the file that is appended to in the very refresh where
one of its own events leaves the window. Its stored aggregate still counts the
expired event, so a tail read cannot serve it and the file has to be re-read in
full. Until now that made it indistinguishable from a mid-file edit — it was
planned as 'source', which rejects the analysis fast path and re-reads every
body. On a machine with several agents the pairing is routine: sessions append
constantly, and on a long history the window is always drifting past something.

Such a file only grew. It keeps every UUID it owned and can gain only new ones,
which is exactly the shape of a plain append, so it is planned as 'window' and
allowed on the fast path — and, like an append, it is put through the ownership
probe after parsing: if one of its lines carries a UUID owned by a later file,
the full rebuild still happens. A genuine mid-file edit remains 'source', since
the append prefix and boundary checks are what tell the two apart.

The same reason covers the second shape of the pairing, where the cheap rebase
succeeds but changes the payload: that append was already being downgraded to a
rebuild, and it is a window rebuild too, not a source edit.

Test: `a file that is appended to while losing an event to the window stays
incremental` — it fails on the parent commit with "re-read the whole corpus:
8 bodies" and asserts the result equals what the full loader produces.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix: preserve UUID ownership across mixed window updates

Parse changed Claude files in canonical order when an append and a window rebuild happen together. The new regression fails before this fix and matches the full loader afterward.

Co-authored-by: OpenAI Codex <215057067+openai-codex[bot]@users.noreply.github.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Carl <74130028+Carl723000@users.noreply.github.com>
Co-authored-by: OpenAI Codex <215057067+openai-codex[bot]@users.noreply.github.com>

Unify sharing previews, finish provider interaction and localization parity, preserve legacy commands, and keep large histories and live scrolling bounded.

Co-authored-by: OpenAI Codex <215057067+openai-codex[bot]@users.noreply.github.com>