alex/pi-shared

Watch

Fork 0

Validate extension against latest Pi release #18

New issue

Closed

opened 2026-07-18 08:01:14 +00:00 by alex · 2 comments

alex commented

2026-07-18 08:01:14 +00:00

Owner

export default function (pi: ExtensionAPI) {

Read Pi v0.80.10 release notes, there are changes about models management via extension that might affect this

https://forge.l3x.in/alex/pi-shared/src/commit/6115c35b75d1d552226325b10174aa9cdc6f919e/extensions/nvidia.ts#L3 Read Pi v0.80.10 release notes, there are changes about models management via extension that might affect this

alex commented

2026-07-18 08:01:29 +00:00

Author

Owner

/pi analyze and if changes are needed open a pr

pi referenced this issue from a pull request that will close it,

2026-07-18 08:07:49 +00:00

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

pi commented

2026-07-18 08:08:02 +00:00

Contributor

Now let me look at the rest of the relevant types and verify the extension type-checks against the new types.Let me examine the ThinkingLevel type and thinkingLevelMap definition, since 0.80.6 added a new max thinking level.Now let me look at the thinkingLevelMap type definition in the pi-ai Model type, since ThinkingLevel now includes max.Let me check how thinkingLevelMap is consumed to determine supported thinking levels (whether an omitted max key is treated as hidden or as a default).Let me verify the Model type's cost and compat shapes still match what the extension uses, then run a real type-check.Now let me run an actual TypeScript type-check against the installed v0.80.10 types to confirm the extension is compatible.The extension type-checks cleanly against v0.80.10. Let me confirm the runtime behavior of the new max thinking level against this extension's config to complete the analysis.Analysis complete. The extension type-checks cleanly against v0.80.10 (strict mode, exit 0) and behaves correctly: the new max thinking level (added in 0.80.6) is already hidden for the Mistral model because pi treats an undefined thinkingLevelMap.max entry as unsupported. So no breakage occurs.

The one actionable improvement: the extension explicitly enumerates every thinking level with its mapping, but max (introduced in 0.80.6) is implicitly absent. Adding max: null restores that explicitness/robustness (same runtime result, but documents intent and guards against future logic changes). Let me make that change and open a PR.I see the comment got duplicated. Let me clean that up into a single coherent comment block.Now let me re-run the type-check to confirm the change still compiles cleanly.Type-check passes. Let me verify the git diff and open the PR.Let me remove the package-lock.json artifact (not tracked in this repo) so only the intended change is committed.Only the intended change remains. Now let me open the PR.I validated the nvidia extension against pi v0.80.10 and opened PR #19 with the one improvement it needed.

What I found

I read the full 0.80.4 → 0.80.10 changelog for anything touching model management via extensions:

0.80.6 introduced the max thinking level (above xhigh). This is the one that's directly relevant.
0.80.8 added the optional refreshModels(context) dynamic-discovery hook and made ModelRegistry.refresh() async — both only affect extensions that opt in / call them directly.

For extensions/nvidia.ts specifically:

No breaking changes apply. It only calls pi.registerProvider(...) with a static model list and never touches refresh() or the new optional features.
It type-checks cleanly against the installed 0.80.10 types (tsc --noEmit --strict → exit 0). thinkingLevelMap is Partial, the cost/compat shapes are unchanged.
The new max level already behaves correctly at runtime — pi treats an unset thinkingLevelMap.max as unsupported, so it's already hidden for Mistral (verified: supported levels come out as ['minimal', 'high']).

The change

The extension deliberately lists every thinking level with its mapping, but max (added in 0.80.6) was implicitly absent. PR #19 adds max: null and clarifies the comment — identical runtime result, but it documents intent and hardens against any future change to how pi resolves an unset map entry. MiniMax (non-reasoning) needed no change.

Now let me look at the rest of the relevant types and verify the extension type-checks against the new types.Let me examine the `ThinkingLevel` type and `thinkingLevelMap` definition, since 0.80.6 added a new `max` thinking level.Now let me look at the `thinkingLevelMap` type definition in the pi-ai `Model` type, since `ThinkingLevel` now includes `max`.Let me check how `thinkingLevelMap` is consumed to determine supported thinking levels (whether an omitted `max` key is treated as hidden or as a default).Let me verify the `Model` type's `cost` and `compat` shapes still match what the extension uses, then run a real type-check.Now let me run an actual TypeScript type-check against the installed v0.80.10 types to confirm the extension is compatible.The extension type-checks cleanly against v0.80.10. Let me confirm the runtime behavior of the new `max` thinking level against this extension's config to complete the analysis.Analysis complete. The extension **type-checks cleanly** against v0.80.10 (`strict` mode, exit 0) and behaves **correctly**: the new `max` thinking level (added in 0.80.6) is already hidden for the Mistral model because pi treats an undefined `thinkingLevelMap.max` entry as unsupported. So no breakage occurs. The one actionable improvement: the extension explicitly enumerates every thinking level with its mapping, but `max` (introduced in 0.80.6) is implicitly absent. Adding `max: null` restores that explicitness/robustness (same runtime result, but documents intent and guards against future logic changes). Let me make that change and open a PR.I see the comment got duplicated. Let me clean that up into a single coherent comment block.Now let me re-run the type-check to confirm the change still compiles cleanly.Type-check passes. Let me verify the git diff and open the PR.Let me remove the `package-lock.json` artifact (not tracked in this repo) so only the intended change is committed.Only the intended change remains. Now let me open the PR.I validated the `nvidia` extension against pi **v0.80.10** and opened **[PR #19](https://forge.l3x.in/alex/pi-shared/pulls/19)** with the one improvement it needed. ## What I found I read the full `0.80.4 → 0.80.10` changelog for anything touching model management via extensions: - **0.80.6** introduced the **`max`** thinking level (above `xhigh`). This is the one that's directly relevant. - **0.80.8** added the optional `refreshModels(context)` dynamic-discovery hook and made `ModelRegistry.refresh()` async — both **only** affect extensions that opt in / call them directly. For `extensions/nvidia.ts` specifically: 1. **No breaking changes apply.** It only calls `pi.registerProvider(...)` with a static model list and never touches `refresh()` or the new optional features. 2. **It type-checks cleanly** against the installed `0.80.10` types (`tsc --noEmit --strict` → exit 0). `thinkingLevelMap` is `Partial`, the `cost`/`compat` shapes are unchanged. 3. **The new `max` level already behaves correctly at runtime** — pi treats an unset `thinkingLevelMap.max` as unsupported, so it's already hidden for Mistral (verified: supported levels come out as `['minimal', 'high']`). ## The change The extension deliberately lists *every* thinking level with its mapping, but `max` (added in 0.80.6) was implicitly absent. PR #19 adds `max: null` and clarifies the comment — identical runtime result, but it documents intent and hardens against any future change to how pi resolves an unset map entry. MiniMax (non-reasoning) needed no change. --- [View action run](https://forge.l3x.in/alex/pi-shared/actions/runs/23) | Model: zai/glm-5.2 (thinking: max) | Time: 6m 20s | Tokens: 1.3M | Pi SDK v0.80.7 | Action v2.26.0

alex closed this issue

2026-07-18 08:19:17 +00:00

No labels

dependencies

No milestone

No assignees

2 participants

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#18

No description provided.

Rows
Columns