Message-box context indicator shows the previous model's window after switching models in the picker

[Rodrigo48025]

Message-box context indicator stays on the previous model's window after switching models in the picker

Summary

The context-window number rendered inside the message input box (token-meter) keeps showing the previous model's window after the user switches models in the picker. It only updates when the next outgoing request fires a request/context event.

The picker change itself does not refresh the indicator, even though the selected model's contextWindow is already resolved at that point.

Environment

• DeepSeek Harness 0.1.2-alpha.3 (commit dd6322d604)
• Web UI at http://127.0.0.1:3080
• Provider: OpenRouter (via the llm-pi-ai adapter)
• Two affected models: <MODEL_A_ID> (advertised <WINDOW_A>) and <MODEL_B_ID> (advertised <WINDOW_B>) — I left the real IDs out of this template, see the note at the bottom

Reproduction

1. Start a fresh session.
2. Select <MODEL_A_ID> in the model picker. Send a message. The indicator in the message box shows <WINDOW_A>. ✅
3. Without sending another message, switch the picker to <MODEL_B_ID>. The indicator still shows <WINDOW_A>. ❌
4. Send a message. The outgoing request resolves <MODEL_B_ID>, the agent loop appends a new request/context, and only now does the indicator jump to <WINDOW_B>.

Expected

The indicator should reflect the currently selected model's window, not the window of the most recent completed request. Either of these is fine:

• Update the indicator (and any other consumer of the contextPressure projection) when the picker changes, using the already-resolved model.contextWindow from the catalog, or
• Emit a request/context event at resolve-time so the projection's "last-wins" rule picks it up before the next outgoing request.

Where in the code

The projection only updates contextWindow on request/context events:

• packages/llm/token-meter/src/usage-projection.ts:188 — the contextPressure projection's apply only changes state.contextWindow when event.type === 'request/context'.

request/context is only appended per outgoing request, not on model change:

• packages/core/agent-loop/src/agent.ts:531 — the agent loop appends a request/context event just before issuing a request, and only when the resolved provider / model / contextWindow differs from the previous one. The picker change never reaches this path because no request has been issued yet.

The picker change does have the data it needs but does not push it to the session's token-meter projection:

• packages/llm/llm/src/index.ts:774 — LlmResolvedModelInfo.context is computed and validated at resolve time, but the resolved value is not written back to the session until the agent loop runs.

Suggested fix (sketch)

A small, low-risk change would be to append a request/context event from the model-picker's onChange handler (or from the resolve path itself) using the already-known model.contextWindow. Because the projection is "last-wins" and dedupes on equality (agent.ts:528-532), a duplicate that matches the last request is a no-op, so over-emit on the picker side is safe.

Tests

packages/llm/token-meter/tests/token-usage-projection.spec.ts:313 covers the "stays correct across successive requests" case. There is no equivalent test for "picker changed, no new request yet" — adding one would lock the desired behavior in.

Workaround

None on the client. The "stale until next request" behavior is by design but is not documented in the message-box UI.

Note

This report is filed from a DSH checkout where I have redacted the exact model IDs. The two models are both surfaced through OpenRouter, with advertised context windows that differ by a factor of ~4. The bug is the same regardless of which pair of models is used: the indicator follows the last request/context event, not the picker's current value.

[argszero]

Verified all three references against current master (4e84901 = 0.1.2-alpha.4) — the mechanism is unchanged since alpha.3, and the report is accurate. I also found one fact that changes the fix calculus a little, so let me lay out the full picture.

Verification (alpha.4)

1. packages/llm/token-meter/src/usage-projection.ts:189-195 — the contextPressure projection's apply only mutates state.contextWindow on request/context events. Correct.
2. packages/core/agent-loop/src/agent.ts:521-531 — request/context is appended just before issuing a request, and only when provider / model / contextWindow differ from the previous request/context (the equality-dedupe you cite). Correct.
3. packages/llm/llm/src/index.ts:751,774 — the resolved context (validated positive integer, carried as LlmResolvedModelInfo.context.contextWindow) is available at resolve time, and only the agent loop writes it into the session. Correct.

The picker change is not invisible to the session — it just carries no window

The important extra fact: the picker's selection does reach the durable session log immediately, as model/selection — packages/api/session-controller/src/agent.ts:326-328 (selectForNextRequest) appends it synchronously on selection, and the durable modelSelection projection tracks it (model-selection-projection.ts: model/selection → pending, exposed as next = pending ?? lastUsed). So the session already knows the picker changed; the gap is narrower than "no event fires". Two concrete gaps:

• model/selection carries only provider / model / reasoningEffort — no contextWindow — so the durable event the picker does emit has nothing for the token-meter to latch onto.
• The contextPressure projection only listens to request/context, so even a window-bearing model/selection would be ignored until the next request.

Fix refinement

Your sketch (append request/context from the picker's onChange) works, but has an ownership wrinkle worth weighing: request/context is an agent-loop-owned event that carries the resolved request context, and the client picker has no resolved value to emit — the client directory holds the catalog-advertised window, which can differ from the resolve-verified one after compat adjustments. Emitting client-asserted windows into a request-owned event type is where the semantics would get blurry.

A slightly more design-faithful variant, all server-side:

1. Extend the model/selection payload with an optional contextWindow, filled by the server's select path (selectForNextRequest) using the same resolve that already computes LlmResolvedModelInfo.context (llm/src/index.ts:751/:774). Optional field = no migration pain under the current pre-release stance (SESSION_FORMAT_VERSION 0, backends reject old on-disk formats).
2. Teach the contextPressure projection's apply to treat a model/selection carrying contextWindow as a contextWindow source with the same last-wins + equality-dedupe semantics (usage-projection.ts:189-195 already has exactly that shape) — bump stateVersion 4→5.

That keeps event ownership where the window is actually resolved, updates every contextPressure consumer at once (the message-box StatsLine, ui-conversation's context-occupancy, the subagent header lineage) instead of just the meter, and stays ~5 lines per file. The catalog-value fallback you proposed is fine as a best-effort display if a resolve round-trip at selection time is undesirable — just note it may briefly disagree with the next request/context if the adapter adjusts the window.

Test gap confirmed

token-usage-projection.spec.ts has the recordContext helper and the successive-requests case you cite; there is no model/selection-with-window-before-request case. A regression test that appends model/selection (with contextWindow) and asserts contextPressure.contextWindow updates without any request/context would lock the behavior in.

This is a clean, well-scoped report — a PR along these lines would be welcome, and I'd be happy to look at the specific diff if you open one.