Skip to content

feat: composer context chip recalculates live — task selector and model switches - #319

Merged
plombeer31 merged 1 commit into
mainfrom
feat/live-context-chip
Sep 3, 2026
Merged

feat: composer context chip recalculates live — task selector and model switches#319
plombeer31 merged 1 commit into
mainfrom
feat/live-context-chip

Conversation

@plombeer31

Copy link
Copy Markdown
Collaborator

What

The composer's context chip (the minibar readout) now re-renders instantly when anything that changes the context math happens, instead of waiting for the next prompt build:

  1. Task selector. The context panel's selector already reprojected every figure inside the panel, but the chip under it kept showing the last built prompt — so the one readout that survives closing the panel never reflected the number just chosen. The chip now renders the same projection the panel uses (usageAtPairs, via a new selectComposerContextUsage selector): every step of the dial immediately moves the chip's gauge, the N/M tasks figure, and the token pair. The draft keeps driving the chip until a prompt is actually built against it (prompt_built already retires the draft on that match), so the chip and panel tell one story.

  2. Model / provider switch. resolveWindow prefers the window the last prompt was built against over every live source, so after switching the active chat model the chip kept gauging against the previous model's window until the next message. A providers_refresh that changes the active text route (provider id or chat model) now drops the stale prompt-derived window, letting the chip fall through to the health poller / catalogue and re-gauge for the new model on the very render that shows the switch. Ordinary refreshes and the first population of the rows keep the measured window.

Tests

  • selectComposerContextUsage: no draft → measured view; draft above the session's real task count → projection clamps to the tasks that exist; draft below → oldest task priced out; draft equal to the cap → measured view (no estimate swap on a no-op).
  • providers_refresh: model change and provider handover drop the window (measured token count untouched); same-route refresh and first population keep it.
  • tsc --noEmit clean; context-chip, context-panel, tui-app, reducer suites pass.

Related: #318 fixes the measurement itself (KV-cached prompt tokens were dropped from the readout); this PR makes the surfaces react. The two are independent.

Two gaps between the context panel and the chip under it:

- Working the panel's task selector reprojected every figure inside the
  panel and left the composer chip on the last built prompt, so the one
  readout that survives closing the panel never showed the number just
  chosen. The chip now renders the same projection the panel does
  (selectComposerContextUsage): stepping the dial moves the minibar
  gauge, token pair and task count on the same render, and the draft
  keeps driving the chip until a prompt is actually built against it.

- Switching the active chat model (or provider) left the chip gauging
  against the window the *previous* model's prompt was built with,
  because resolveWindow prefers the prompt-derived window over every
  live source. A providers_refresh that changes the active text route
  now drops that stale window, so the chip re-gauges from the health
  poller / catalogue for the newly chosen model immediately instead of
  one prompt build later.
@plombeer31
plombeer31 merged commit 9f7495d into main Sep 3, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant