Stats-bar catalog join + dock numerator consistency (context-meter close-out)
Platform's context-meter pair (04e336d, 18cc493) left two client seams in my band; this closes the arc: 1. STATS-BAR CATALOG JOIN: contextWindow's denominator resolves ONLY from pi's live catalog — stats-bar now builds the provider:id -> contextWindow index client-side (catalogLimits in model-picker.tsx, the client twin of the server's catalogContextLimits join) over the picker's existing /api/models fetch/cache (useModelCatalog exported; module-level dedupe, one fetch feeds both ModelControl and the meter). Catalog pending or failed -> undefined index -> limit null -> USAGE-ONLY (Platform's interim render IS the null path; the honest-render precedent, never a fake window). 2. DOCK NUMERATOR CONSISTENCY: toBlobs' context fold was still last-step input+output only — now the same cache-inclusive footprint the session meter uses (all four directions; provider "input" EXCLUDES cacheRead/cacheWrite, so the old fold read wildly low on cache-heavy jobs). Same metric everywhere. Review of Platform's interim edits in this band: verified as-shipped — stats-bar's usage-only render (summary + popover), FeedJob.contextLimit with the line-hides null treatment, and the render-test rewrites all fit. Only fix needed: none beyond the above. Tests: catalogLimits pinned pure (index shape, provider:id keying, missing-model absence); toBlobs pinned on the cache-inclusive numerator (10k+0.5k+120k+30k = 160.5k against a 200k feed limit). 889/889. Live-verified on :3001: seedplan's bar reads "18.7k / 1M" (footprint 18725, catalog 1048576); a nope/unknown-model chat renders "12.8k" usage-only with cost "-"; the popover detail matches; the dock blob's context line renders "946 / 1M" from a server-joined feed (an unintentionally real runner-adopted job — the full chain, live).
This commit is contained in:
@@ -180,7 +180,18 @@ export function toBlobs(feed: ActivityFeed): ActivityBlob[] {
|
||||
// blob shape's call — here the line simply hides).
|
||||
const limit = job.contextLimit;
|
||||
if (usage && lastStep && limit !== null && lastStep.inputTokens !== undefined) {
|
||||
context = { used: lastStep.inputTokens + (lastStep.outputTokens ?? 0), limit };
|
||||
// Same metric as the session meter (prices.ts stepFootprint — the
|
||||
// context-meter audit, owner 2026-09-23): all four directions.
|
||||
// Provider "input" EXCLUDES cacheRead/cacheWrite, so input+output
|
||||
// alone reads wildly low on cache-heavy jobs.
|
||||
context = {
|
||||
used:
|
||||
lastStep.inputTokens +
|
||||
(lastStep.outputTokens ?? 0) +
|
||||
(lastStep.cacheReadTokens ?? 0) +
|
||||
(lastStep.cacheWriteTokens ?? 0),
|
||||
limit,
|
||||
};
|
||||
}
|
||||
return {
|
||||
id: job.id,
|
||||
|
||||
Reference in New Issue
Block a user