When the liveModelSwitchPending flag is set but the current model already
matches the persisted selection (e.g. the switch was applied as an override
and the current attempt is already using the new model), the flag is now
consumed eagerly via a fire-and-forget clearLiveModelSwitchPending() call.
Without this, the stale flag could persist across fallback iterations and
later cause a spurious LiveSessionModelSwitchError when the model rotates
to a fallback candidate that differs from the persisted selection.
Also expands JSDoc on shouldSwitchToLiveModel to document the stale-flag
clearing and deferral semantics.
Replace the ambiguous comparison-based approach (hasDifferentLiveSessionModelSelection
+ in-memory map EMBEDDED_RUN_MODEL_SWITCH_REQUESTS) with a persisted
`liveModelSwitchPending` flag on SessionEntry.
The root cause: the in-memory map was never populated in production because
requestLiveSessionModelSwitch() was removed in commit 622b91d04e and replaced
with refreshQueuedFollowupSession(). This left the comparison-based detection
as the only path, which could not distinguish user-initiated model switches
(via /model command) from system-initiated fallback rotations.
The fix:
- Add `liveModelSwitchPending?: boolean` to SessionEntry (persisted)
- Set the flag to true ONLY when /model command applies a model override
- New `shouldSwitchToLiveModel()` checks the flag + model mismatch together
- New `clearLiveModelSwitchPending()` resets the flag after consumption
- Replace throw-site logic in run.ts to use the new flag-based functions
- Remove orphaned resolveCurrentLiveSelection helper
Only the /model command sets this flag, so system-initiated fallback rotations
are never mistaken for user-initiated model switches. This restores the
live-switch-during-active-run feature that was accidentally broken.
Fixes#57857, #57760, #58137
When auth choice explicitly sets a preferred provider (e.g., volcengine-api-key or byteplus-api-key), the model picker should always filter by that provider. Previously, it relied on providerIds.includes(preferredProvider), which could be false if the catalog hadn't loaded that provider's models yet due to a race condition between auth choice setup and catalog loading.
This ensures that selecting a provider via auth choice consistently filters the model list to only that provider's models, rather than showing all providers.
MiniMax's usage_percent / usagePercent fields report the *remaining* quota
as a percentage, not the consumed quota. When count fields (prompt_limit /
prompt_remain) are also present, fromCounts already computed the correct
usedPercent and the inverted value was silently ignored. But when only
usage_percent is returned (no count fields), the code treated it as a
used-percent and passed it through unchanged, causing the menu bar to show
"2% left" instead of "98% left".
Move usage_percent and usagePercent from PERCENT_KEYS to a new
REMAINING_PERCENT_KEYS array. deriveUsedPercent now inverts remaining-percent
values to obtain usedPercent, matching the behaviour already validated by the
existing "prefers count-based usage when percent looks inverted" test. Count-
based fromCounts still takes priority over both key groups.
Fixes#60193
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When using custom providers like LM Studio, Ollama, or DashScope,
token counts in /status show as 0 because the agent meta store
does not always have usage data populated for these providers.
Fix: set includeTranscriptUsage: true in both /status command and
the session_status tool. This enables the existing fallback path
that reads usage from the session transcript JSONL file when the
meta store has zero/missing token counts.
The merge logic already guards against overwriting valid data:
- totalTokens: only updated when zero or transcript value is larger
- inputTokens/outputTokens: only filled when zero/missing
- model/contextTokens: only filled when missing
Fixes#54995
