fix(nvidia): explicitly hide new max thinking level for Mistral #19
No reviewers
Labels
No labels
dependencies
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
alex/pi-shared!19
Loading…
Reference in a new issue
No description provided.
Delete branch "pi/issue18-1784362067678"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Validates the
nvidiaextension against pi v0.80.10 (the version@earendil-works/pi-coding-agentwas bumped to in #17). Closes #18.Analysis of the v0.80.x model-management changes
I read the v0.80.10 changelog and checked every release in the
0.80.4 → 0.80.10range for anything touching "models management via extension". The relevant items:maxthinking level (abovexhigh), surfaced across CLI/SDK/RPC/model selection.ThinkingLevelis now"off" | "minimal" | "low" | "medium" | "high" | "xhigh" | "max".tiersto custom model costs inmodels.json/modelOverrides/extension providers (additive, optional).refreshModels(context)hook for dynamic model discovery (additive, optional). Also madeModelRegistry.refresh()async — only affects extensions that call it directly.Findings for
extensions/nvidia.tspi.registerProvider(...)with a static model list and never touchesModelRegistry.refresh(). The newrefreshModels/tiersfeatures are optional.0.80.10types (tsc --noEmit --strict→ exit 0).thinkingLevelMapisPartial<Record<ModelThinkingLevel, string | null>>, so omittingmaxis type-safe, and thecost/compatshapes are unchanged.maxlevel already behaves correctly at runtime. pi'sgetSupportedThinkingLevels()treats an unsetthinkingLevelMap.maxentry as unsupported (mapped !== undefined→ false), somaxis already hidden for the Mistral model. Verified by simulating the resolver against the current config → supported levels are['minimal', 'high'], as intended.Change made
The extension deliberately enumerates every thinking level with its mapping (null hides the level). The new
maxlevel was implicitly absent rather than explicit. This PR addsmax: null(and clarifies the comment) to keep that invariant — it's the same runtime result, but:maxis unsupported by Mistral via NVIDIA, which only acceptsnone/high), andthinkingLevelMapentry.No change to MiniMax (non-reasoning model → only
offis exposed regardless).maxthinking level for Mistral 7fae87c6ec