fix(nvidia): explicitly hide new max thinking level for Mistral #19

Merged
alex merged 1 commit from pi/issue18-1784362067678 into master 2026-07-18 08:19:17 +00:00
Contributor

Summary

Validates the nvidia extension against pi v0.80.10 (the version @earendil-works/pi-coding-agent was 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.10 range for anything touching "models management via extension". The relevant items:

  • 0.80.6 — added the opt-in max thinking level (above xhigh), surfaced across CLI/SDK/RPC/model selection. ThinkingLevel is now "off" | "minimal" | "low" | "medium" | "high" | "xhigh" | "max".
  • 0.80.6 — added request-wide input-token pricing tiers to custom model costs in models.json/modelOverrides/extension providers (additive, optional).
  • 0.80.8 — added the optional provider refreshModels(context) hook for dynamic model discovery (additive, optional). Also made ModelRegistry.refresh() async — only affects extensions that call it directly.

Findings for extensions/nvidia.ts

  1. No breaking changes affect this extension. It only calls pi.registerProvider(...) with a static model list and never touches ModelRegistry.refresh(). The new refreshModels/tiers features are optional.
  2. It type-checks cleanly against the installed 0.80.10 types (tsc --noEmit --strict → exit 0). thinkingLevelMap is Partial<Record<ModelThinkingLevel, string | null>>, so omitting max is type-safe, and the cost/compat shapes are unchanged.
  3. The new max level already behaves correctly at runtime. pi's getSupportedThinkingLevels() treats an unset thinkingLevelMap.max entry as unsupported (mapped !== undefined → false), so max is 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 max level was implicitly absent rather than explicit. This PR adds max: null (and clarifies the comment) to keep that invariant — it's the same runtime result, but:

  • documents intent (max is unsupported by Mistral via NVIDIA, which only accepts none/high), and
  • guards against any future change to how pi resolves an unset thinkingLevelMap entry.

No change to MiniMax (non-reasoning model → only off is exposed regardless).

## Summary Validates the `nvidia` extension against pi **v0.80.10** (the version `@earendil-works/pi-coding-agent` was 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.10` range for anything touching "models management via extension". The relevant items: - **0.80.6** — added the opt-in **`max`** thinking level (above `xhigh`), surfaced across CLI/SDK/RPC/model selection. `ThinkingLevel` is now `"off" | "minimal" | "low" | "medium" | "high" | "xhigh" | "max"`. - **0.80.6** — added request-wide input-token pricing **`tiers`** to custom model costs in `models.json`/`modelOverrides`/extension providers (additive, optional). - **0.80.8** — added the optional provider `refreshModels(context)` hook for dynamic model discovery (additive, optional). Also made `ModelRegistry.refresh()` async — only affects extensions that call it directly. ### Findings for `extensions/nvidia.ts` 1. **No breaking changes affect this extension.** It only calls `pi.registerProvider(...)` with a static model list and never touches `ModelRegistry.refresh()`. The new `refreshModels`/`tiers` features are optional. 2. **It type-checks cleanly** against the installed `0.80.10` types (`tsc --noEmit --strict` → exit 0). `thinkingLevelMap` is `Partial<Record<ModelThinkingLevel, string | null>>`, so omitting `max` is type-safe, and the `cost`/`compat` shapes are unchanged. 3. **The new `max` level already behaves correctly at runtime.** pi's `getSupportedThinkingLevels()` treats an *unset* `thinkingLevelMap.max` entry as unsupported (`mapped !== undefined` → false), so `max` is 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 `max` level was implicitly absent rather than explicit. This PR adds `max: null` (and clarifies the comment) to keep that invariant — it's the same runtime result, but: - documents intent (`max` is unsupported by Mistral via NVIDIA, which only accepts `none`/`high`), and - guards against any future change to how pi resolves an unset `thinkingLevelMap` entry. No change to MiniMax (non-reasoning model → only `off` is exposed regardless).
alex merged commit 7fae87c6ec into master 2026-07-18 08:19:17 +00:00
alex deleted branch pi/issue18-1784362067678 2026-07-18 08:19:17 +00:00
Sign in to join this conversation.
No reviewers
No labels
dependencies
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
alex/pi-shared!19
No description provided.