[BUG] Context Limit at Task Header won't Update when Changing Provider during the Task

[sihangchen97]

Problem (one or two sentences)

context limit at task header won't update if I change to a provider with longer context size during the task

Context (who is affected and when)

N/A

Reproduction steps

1. start a task with Provider 1 (such as with 128k context size)
2. stop the task
3. change to Provider 2 (such as with 256k context size) and restore the task
4. no change with the context size bar at the header

Expected result

context size at the header should change

Actual result

context size at the header not changing, and the bar will exceed 100% (wrong ratio)

Variations tried (optional)

No response

App Version

3.70.0

API Provider (optional)

None

Model Used (optional)

No response

Zoo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[taltas]

@zoomote, can you look into why this might be happening? Don't make a PR just yet, just come up with your findings and comment here.

[zoomote]

I'm on it. I started a task for this issue, and I'll keep updates here.

See task

[zoomote]

Investigated this — here's why it happens. (Per the request, no PR; findings only.)

Root cause

The header bar's denominator (context window) is computed from the live global apiConfiguration in the webview, while the numerator (context tokens) comes from the task's persisted messages. On the stop → switch provider → restore flow, restoring the task reverts the provider profile back to the one saved in the task history, so the denominator goes back to the old provider's context window while the numerator stays high — the bar then shows the old limit and can exceed 100%.

Key pieces:

1. Header reads the live profile, not per-task model info. webview-ui/src/components/chat/TaskHeader.tsx:59-65 does useExtensionState() → useSelectedModel(apiConfiguration) → contextWindow = model?.contextWindow. No context-window value is stored per task; whatever the global extension state says is what the bar uses.

2. Context tokens come from persisted history. getApiMetrics / consolidateTokenUsage take the last api_req_started message's tokensIn + tokensOut, so the numerator survives the provider switch.

3. The task's sticky provider profile overwrites your switch on restore. Every task save persists the profile name into HistoryItem.apiConfigName (src/core/task/Task.ts:1110-1121 via taskMetadata). When you restore the task, ClineProvider.createTaskWithHistoryItem (src/core/webview/ClineProvider.ts:1090-1103) unconditionally calls activateProviderProfile({ name: historyItem.apiConfigName }), which writes the old profile's settings back into the context proxy and posts state to the webview. This silently undoes the provider change you made after stopping the task — the resumed task itself also runs the old provider/model, not just the header.

4. The stale profile name is never refreshed on this path. The restore uses persistTaskHistory: false, and the sticky name is only updated when you switch providers while that task is still the current task (persistStickyProviderProfileToCurrentTask, ClineProvider.ts:1669-1695). In the repro (stop → switch → restore), the task is no longer current, so its apiConfigName stays "Provider 1" forever.

Note: switching providers while the task is still running works correctly (updateTaskApiHandlerIfNeeded + postStateToWebview), which is why the bug only shows up on the stop/switch/restore path.

Fix direction

The narrowest fix is in createTaskWithHistoryItem (ClineProvider.ts:1090-1103): when restoring, don't reactivate historyItem.apiConfigName if the user's currently active profile differs (prefer the current profile, and/or update the history item's sticky apiConfigName). The webview needs no change — the bar will follow apiConfiguration automatically once restore stops reverting it.

[taltas]

@zoomote Make a PR based on the fix direction, use the narrowest fix.

[zoomote]

I'm on it. I routed this request into the existing task for this issue so follow-up work stays on one Roomote thread, and I'll keep updates here.

See task

[zoomote]

Fix is up as a paired set of draft PRs (assigned to @taltas):

• Zoo-Code: [Fix] Context limit in task header stays stale when user switches provider mid-task and restores #973 — implements the narrowest fix from the findings: on task restore, if your currently active provider profile differs from the task's stale sticky profile, the restore keeps your current profile instead of reverting it (and corrects the task's sticky name going forward). The header's context bar then picks up the new provider's context window automatically — no webview change needed. Full pnpm test, lint, and typecheck pass; regression coverage added in ClineProvider.sticky-profile.spec.ts.
• Zoo-Code-Docs: [Docs] Update per-task profile persistence resume behavior Zoo-Code-Docs#16 — updates the "Per-Task Profile Persistence" docs, which explicitly documented the old "always restore the original profile" behavior.

I'll do a self-review on GitHub and follow up here with the results.