@evandu/super-pi 0.1.103 → 0.1.104

package/dist/client/.super-pi-client-sources.json

@@ -24,5 +24,5 @@
     "src/client/types.ts": "c2d8b16e056173a3951d87f3e7b63dcc53dc9178a5e73fa3e48b2d1ffd4e93c7",
     "src/client/vite-env.d.ts": "65996936fbb042915f7b74a200fcdde7e410f32a669b1ab9597cfaa4b0faddb5"
   },
-  "recordedAt": "2026-10-21T13:33:05.700Z"
+  "recordedAt": "2026-10-21T15:04:31.114Z"
 }

package/dist/server/application/conversation-service.d.ts

@@ -1,6 +1,7 @@
 import { type Store } from "../store.js";
 import type { AgentRuntime } from "../runtime.js";
 import type { SubagentRunRecorder } from "../subagent-runs.js";
+import type { ModelSelection } from "../types.js";
 import type { EventBroadcaster } from "../server-context.js";
 import type { CatalogService } from "./catalog-service.js";
 import type { RunService } from "./run-service.js";
@@ -45,6 +46,14 @@ export declare class ConversationService {
      * a log and in a retry.
      */
     autoRenameConversation(conversationId: string): Promise<string>;
+    /**
+     * The model a conversation has selected, or undefined when it follows Pi's default.
+     *
+     * THIS IS WHAT THE CATALOG'S THINKING LEVELS DEPEND ON. Pi computes the levels from the model
+     * itself, so the levels of the model in force are the levels that conversation gets. A catalog read
+     * without this is a catalog of whatever Pi would default to.
+     */
+    modelSelectionFor(conversationId: string | undefined): ModelSelection | undefined;
     /**
      * Selects a conversation and broadcasts the catalog for that conversation's model.
      */

package/dist/server/application/conversation-service.js

@@ -107,6 +107,19 @@ export class ConversationService {
             throw new Error("当前没有可用的 Pi 进程，无法生成标题");
         return this.runtime.summarizeConversation(conversation, workspace.path);
     }
+    /**
+     * The model a conversation has selected, or undefined when it follows Pi's default.
+     *
+     * THIS IS WHAT THE CATALOG'S THINKING LEVELS DEPEND ON. Pi computes the levels from the model
+     * itself, so the levels of the model in force are the levels that conversation gets. A catalog read
+     * without this is a catalog of whatever Pi would default to.
+     */
+    modelSelectionFor(conversationId) {
+        if (!conversationId)
+            return undefined;
+        const conversation = this.store.snapshot().conversations.find((item) => item.id === conversationId);
+        return conversation?.model;
+    }
     /**
      * Selects a conversation and broadcasts the catalog for that conversation's model.
      */

package/dist/server/command-handler.js

@@ -237,10 +237,21 @@ export class CommandHandler {
             return;
         }
         if (command.type === "catalog.fetch") {
+            // THE CATALOG OF THE CONVERSATION BEING SHOWN, not of whatever Pi would default to.
+            //
+            // The THINKING LEVELS belong to the model in force: Pi computes them from the model itself, and a
+            // model that cannot reason offers only "off". This command used to ask for the catalog with NO
+            // selection, so the levels were always the DEFAULT model's - which means the picker offered the
+            // levels of a model the person was not using, and hid the ones they were. The model list is the
+            // same either way, so only the levels were wrong; the levels are the part a person reads.
+            //
+            // `conversation.select` already asked for it this way; this is the same answer, for the other
+            // way a client asks for it.
+            const selection = this.conversationService.modelSelectionFor(command.conversationId);
             if (sendToSocket)
-                sendToSocket({ type: "model.catalog", conversationId: command.conversationId, catalog: await this.catalogService.getCatalog(undefined, command.conversationId) });
+                sendToSocket({ type: "model.catalog", conversationId: command.conversationId, catalog: await this.catalogService.getCatalog(selection, command.conversationId) });
             else
-                await this.catalogService.broadcastCatalog(undefined, command.conversationId);
+                await this.catalogService.broadcastCatalog(selection, command.conversationId);
             return;
         }
         // The unfiltered catalog, for the settings window's model panel. Sent to the ASKING socket only:

package/dist/server/pi-session-events.d.ts

@@ -73,6 +73,37 @@ export interface TurnEventHandlers {
         followUp: string[];
     }): void;
 }
+/**
+ * The failure Pi reported in the message that ended the turn, if it reported one.
+ *
+ * WHY IT IS HELD AND NOT THROWN ON THE SPOT. Pi retries on its own: an assistant message that ends
+ * with `stopReason: "error"` may be followed by another assistant message, and only the LAST one
+ * decides whether the turn failed. So the failure is remembered when it arrives and raised when Pi
+ * SETTLES - which is the moment Pi has stopped working on its own and the answer is final. A failure
+ * raised at the moment it arrives would abort a turn Pi was about to retry, and the retry would then
+ * look like the user's problem.
+ *
+ * THE SAME RULES AS THE ONE-SHOT PATH, which already got this right (`runtime.ts`: the RPC drain loop
+ * reads the terminal outcome off `agent_end` and throws at `agent_settled`). A provider failure is a
+ * failure; a response that hit the length limit is an INCOMPLETE answer and is one too. An `"aborted"`
+ * is NOT a failure here: the person stopped the turn, and a stopped turn is a turn that ended - the
+ * one-shot path can tell the difference because it knows whether the signal was aborted, and the
+ * session path does not need to: an abort is the user's own action and the run service already
+ * records it as stopped.
+ */
+export interface TurnFailure {
+    /** The message Pi reported, in its own words. */
+    message: string;
+    /** The raw reason, kept so a caller can tell a provider failure from anything else. */
+    stopReason: string;
+}
+/**
+ * Reads the failure out of a `message_end` record, or undefined when it is not a failed one.
+ *
+ * ONLY THE ASSISTANT'S MESSAGE COUNTS. `message_end` also fires for user messages, tool results and
+ * custom messages, and none of those is a turn failing.
+ */
+export declare function describeMessageFailure(record: unknown): TurnFailure | undefined;
 /**
  * A queue of turn items, with the waiters that are blocked on it.
  *
@@ -108,4 +139,6 @@ export declare class TurnQueue {
  * then counted - the same policy the RPC loop applied, and for the same reason: an event type nobody
  * understands is worth saying out loud exactly once.
  */
-export declare function handleSessionEvent(event: unknown, queue: TurnQueue, handlers: TurnEventHandlers, report: (key: string) => void): boolean;
+export declare function handleSessionEvent(event: unknown, queue: TurnQueue, handlers: TurnEventHandlers, report: (key: string) => void, failure?: {
+    current: TurnFailure | undefined;
+}): boolean;

package/dist/server/pi-session-events.js

@@ -62,6 +62,31 @@ export function describeDeliveredUserMessage(record) {
         .filter((part) => part !== undefined);
     return parts.length ? parts.join("\n") : undefined;
 }
+/**
+ * Reads the failure out of a `message_end` record, or undefined when it is not a failed one.
+ *
+ * ONLY THE ASSISTANT'S MESSAGE COUNTS. `message_end` also fires for user messages, tool results and
+ * custom messages, and none of those is a turn failing.
+ */
+export function describeMessageFailure(record) {
+    const event = record;
+    if (event?.type !== "message_end")
+        return undefined;
+    const message = event.message;
+    if (!message || typeof message !== "object" || message.role !== "assistant")
+        return undefined;
+    const text = typeof message.errorMessage === "string" ? message.errorMessage.trim() : "";
+    if (message.stopReason === "error") {
+        return { message: text || "Pi 报告模型或服务提供方错误。", stopReason: "error" };
+    }
+    if (message.stopReason === "length") {
+        // A response that hit the length limit is an INCOMPLETE answer. Pi compacts and continues after a
+        // recoverable one, so a turn that SETTLES with this reason is one whose answer is missing its
+        // end - and saying so is better than a turn that looks finished.
+        return { message: text || "模型输出达到本轮长度上限，回答未完成。", stopReason: "length" };
+    }
+    return undefined;
+}
 /**
  * A queue of turn items, with the waiters that are blocked on it.
  *
@@ -149,11 +174,53 @@ export class TurnQueue {
  * then counted - the same policy the RPC loop applied, and for the same reason: an event type nobody
  * understands is worth saying out loud exactly once.
  */
-export function handleSessionEvent(event, queue, handlers, report) {
+export function handleSessionEvent(event, queue, handlers, report, failure) {
     const record = event;
     if (!record || typeof record.type !== "string")
         return false;
     switch (record.type) {
+        case "message_end": {
+            // THE AUTHORITATIVE END OF AN ASSISTANT MESSAGE. `message_end` is the completed message, and its
+            // `stopReason` is the only place Pi says whether the model actually answered. The bridge used to
+            // ignore this event, which meant a provider that failed was indistinguishable from one that
+            // finished: the turn settled, the status became "completed", and the reader saw a turn that
+            // looked fine and had no answer in it.
+            //
+            // A failure is HELD, not thrown, because Pi retries on its own - the message that failed may be
+            // followed by another one. The retry starts a new assistant message, and THAT clears the held
+            // failure, so only the last message of the turn decides.
+            const reported = describeMessageFailure(record);
+            if (reported && failure)
+                failure.current = reported;
+            return true;
+        }
+        case "message_start": {
+            // A NEW ASSISTANT MESSAGE MEANS A NEW ATTEMPT. Pi's retry starts one, and the failure of the
+            // attempt before it is no longer the failure of this turn.
+            if (record.message?.role === "assistant" && failure)
+                failure.current = undefined;
+            // A STEER THIS TURN DELIVERED. Pi announces the moment a queued message stops waiting and starts
+            // being answered by emitting `message_start` with the user message it picked up, immediately after
+            // the `queue_update` above that shows the entry gone. The host uses it to split the turn so the
+            // answer lands under the message it answers.
+            //
+            // A NON-user `message_start` is not a delivery: it gets the same once-per-type report every other
+            // unrouted event gets, which is the same policy the RPC drain loop applies.
+            const delivered = describeDeliveredUserMessage(record);
+            if (delivered === undefined) {
+                if (record.message?.role === "assistant")
+                    return true;
+                report(`type ${JSON.stringify(record.type)}`);
+                return true;
+            }
+            try {
+                handlers.onSteerDelivered?.(delivered);
+            }
+            catch (error) {
+                console.warn(`PiRpcRuntime: the steer delivery handler threw: ${error instanceof Error ? error.message : "unknown error"}`);
+            }
+            return true;
+        }
         case "message_update": {
             const assistant = record.assistantMessageEvent;
             if (!assistant)
@@ -240,28 +307,19 @@ export function handleSessionEvent(event, queue, handlers, report) {
             }
             return true;
         }
-        case "message_start": {
-            // A STEER THIS TURN DELIVERED. Pi announces the moment a queued message stops waiting and starts
-            // being answered by emitting `message_start` with the user message it picked up, immediately after
-            // the `queue_update` above that shows the entry gone. The host uses it to split the turn so the
-            // answer lands under the message it answers.
+        case "agent_settled": {
+            // THE TURN IS OVER, AND IT MAY HAVE FAILED. Pi settling is the end of the turn, and a turn that
+            // ended because the provider failed has to say so: a failure that is not raised is a failed turn
+            // that the reader sees as a completed one, with no answer in it and no banner above it.
             //
-            // A NON-user `message_start` is not a delivery: it gets the same once-per-type report every other
-            // unrouted event gets, which is the same policy the RPC drain loop applies.
-            const delivered = describeDeliveredUserMessage(record);
-            if (delivered === undefined) {
-                report(`type ${JSON.stringify(record.type)}`);
+            // The failure is raised HERE and not when it arrived, because Pi retries on its own - a message
+            // that failed may be followed by another one, and only the last one decides.
+            const held = failure?.current;
+            if (held) {
+                failure.current = undefined;
+                queue.push({ kind: "error", error: new Error(held.message) });
                 return true;
             }
-            try {
-                handlers.onSteerDelivered?.(delivered);
-            }
-            catch (error) {
-                console.warn(`PiRpcRuntime: the steer delivery handler threw: ${error instanceof Error ? error.message : "unknown error"}`);
-            }
-            return true;
-        }
-        case "agent_settled": {
             queue.push({ kind: "end" });
             return true;
         }

package/dist/server/pi-session-pool.js

@@ -188,9 +188,19 @@ export class PiSessionPool {
             const same = running?.provider === wanted.provider && (running?.id ?? running?.id) === wanted.modelId;
             if (!same) {
                 try {
-                    await session.setModel({ provider: wanted.provider, id: wanted.modelId });
+                    // THE WHOLE MODEL, NOT THE PAIR. Pi's `setModel` puts what it is given straight into the
+                    // agent's state, so a `{provider, id}` pair would not be a shorthand for a model - it would BE
+                    // the model the agent runs on, with no `api` and no `contextWindow`. Measured: with the whole
+                    // model the session reports `api=bedrock-converse-stream`, `contextWindow=1000000` and the
+                    // thinking levels `[off, minimal, low, medium, high]`; with the pair the api and the context
+                    // window are null and the levels collapse to `[off]`, which is what the picker shows.
+                    //
+                    // The pair is still the fallback, because a session that cannot resolve a model should still
+                    // be able to run the one it has.
+                    const whole = session.resolveModel?.(wanted.provider, wanted.modelId);
+                    await session.setModel(whole ?? { provider: wanted.provider, id: wanted.modelId });
                     if (process.env.SUPER_PI_TRACE_LATENCY === "1")
-                        console.warn(`[super-pi latency] conversation=${request.conversationId} phase=session.model-applied model=${wanted.provider}/${wanted.modelId}`);
+                        console.warn(`[super-pi latency] conversation=${request.conversationId} phase=session.model-applied model=${wanted.provider}/${wanted.modelId} whole=${whole ? "yes" : "no"}`);
                 }
                 catch (error) {
                     console.warn(`PiSessionPool: conversation ${request.conversationId} asked for ${wanted.provider}/${wanted.modelId} and Pi declined: ${error instanceof Error ? error.message : String(error)}. The turn will run on the model already loaded.`);

package/dist/server/pi-session.d.ts

@@ -68,11 +68,15 @@ export interface SdkCatalog {
      *
      * Separate from the models because it is the expensive half: it needs a session, so a caller that
      * only wants the list does not pay for it.
+     *
+     * UNDEFINED MEANS "THIS RUNTIME DOES NOT KNOW THAT MODEL", and it is not the same answer as "that
+     * model has no levels but off". A caller that gets undefined asks whoever does know the model; a
+     * caller that got a list would be showing another model's levels.
      */
     thinkingLevelsFor(model: {
         provider: string;
         modelId: string;
-    }): Promise<string[]>;
+    }): Promise<string[] | undefined>;
 }
 /**
  * Builds a zero-process catalog reader.
@@ -235,11 +239,35 @@ export interface PiSessionLike {
      * running session, so a model change does not need a new session - and making one would cost a
      * transcript replay, which is the most expensive thing this runtime does. A user who picks a different
      * model in the picker would otherwise pay for the whole conversation's history to be re-read.
+     *
+     * THE ARGUMENT MUST BE A WHOLE MODEL. Pi's `setModel` puts it straight into the agent's state
+     * (`agent-session.ts:2514`), so a `{provider, id}` pair is not a shorthand for a model - it IS the
+     * model the agent will use, and it has no `api`, no `contextWindow` and no `maxTokens`. Measured:
+     * with a whole model the session reports `api=bedrock-converse-stream`,
+     * `contextWindow=1000000` and the thinking levels `[off, minimal, low, medium, high]`; with a pair
+     * the api and the context window are null and the levels collapse to `[off]`. `resolveModel` is how
+     * the whole model is obtained.
      */
     setModel?(model: {
         provider: string;
         id: string;
+        [key: string]: unknown;
     }): Promise<void>;
+    /**
+     * The WHOLE model for a provider/id pair, the way Pi's own `set_model` gets it.
+     *
+     * Pi's RPC mode looks the pair up in the model runtime's snapshot and hands the FOUND MODEL to
+     * `session.setModel` (`rpc-mode.ts:470-477`); the pair alone is never what Pi takes. This is the same
+     * lookup, exposed so the caller does not have to own a second model runtime.
+     *
+     * Optional because a test double has no models; its absence means "this session cannot resolve a
+     * model", and the caller then falls back to the pair it has.
+     */
+    resolveModel?(provider: string, modelId: string): {
+        provider: string;
+        id: string;
+        [key: string]: unknown;
+    } | undefined;
     /** The thinking levels the session's current model supports. Pi's own answer, not a derivation. */
     getAvailableThinkingLevels?(): string[];
     setThinkingLevel?(level: string): void;

package/dist/server/pi-session.js

@@ -103,6 +103,14 @@ export async function createSdkCatalog(cwd) {
             const cached = levelsByModel.get(key);
             if (cached)
                 return cached;
+            // THE MODEL HAS TO BE FOUND FIRST, and the reason it has to be found is that a session created
+            // WITHOUT one runs on Pi's DEFAULT model - and then it answers with the DEFAULT MODEL'S LEVELS.
+            // That is a silent wrong answer: the picker would offer the levels of a model the person is not
+            // using, and hide the ones they are. A model this runtime does not know is not a model with no
+            // levels; it is a model whose levels have to be asked of whoever does know it.
+            const whole = modelRuntime.getModel?.(model.provider, model.modelId);
+            if (!whole)
+                return undefined;
             // A model that is not running has no levels of its own, so a short-lived in-memory session is
             // built to ask Pi. It costs a session - measured at ~30ms warm, and no process at all - and it is
             // paid once per model rather than once per picker open.
@@ -112,7 +120,7 @@ export async function createSdkCatalog(cwd) {
                 modelRuntime,
                 settingsManager,
                 sessionManager: sdk.SessionManager.inMemory(cwd, { id: "catalog-levels" }),
-                model: modelRuntime.getModel?.(model.provider, model.modelId),
+                model: whole,
             });
             try {
                 const levels = sessionLevels(session);
@@ -269,7 +277,23 @@ export async function createPiSession(creation) {
         };
         const { session } = await sdk.createAgentSession(options);
         traceSession(creation.sessionId, "sdk.session.created", startedAt);
-        return session;
+        const live = session;
+        // THE WHOLE MODEL, LOOKED UP THE WAY PI LOOKS IT UP. Pi's `setModel` puts the model it is given
+        // straight into the agent's state, so what it needs is the WHOLE model - the one with an `api`, a
+        // `contextWindow` and a `maxTokens` - and not the `{provider, id}` pair the picker holds. The only
+        // thing that has a whole model is the model runtime this session was built with, and Pi's own RPC
+        // `set_model` does exactly this lookup before it calls `setModel` (`rpc-mode.ts:470-477`).
+        //
+        // It is attached to the session rather than kept beside it because the session is what outlives a
+        // turn: a model change applies to a LIVE session, and the live session is the thing that has to be
+        // able to answer "give me this model whole".
+        live.resolveModel = (provider, modelId) => {
+            const found = modelRuntime.getModel?.(provider, modelId);
+            if (!found || typeof found !== "object")
+                return undefined;
+            return found;
+        };
+        return live;
     });
 }
 function transcriptBytes(sessionManager) {

package/dist/server/runtime.d.ts

@@ -431,14 +431,27 @@ export declare function describeSteerDisposition(data: unknown): SteerDispositio
 /**
  * Keys Pi's model answers by. Exported so the store and the tests agree with the runtime.
  *
- * THE MODEL IS NOT PART OF THE KEY, and that is the second half of why the picker no longer starts a
- * process. The MODEL LIST is the same answer whichever model a conversation has selected - it is the
- * list of models Pi offers, not the ones one conversation may use. The only thing that varies with the
- * selection is the THINKING LEVELS, which belong to the model in use.
+ * THE MODEL LIST IS SHARED. The list of models Pi offers is the same answer whichever model a
+ * conversation has selected - it is not the list of models one conversation may use. So the list has
+ * ONE key, and every conversation shares it.
  *
- * So the key records just whether levels were asked for. Keying on the model (as this used to) meant a
- * cache miss for every model a person ever picked, and every miss was a process start - so the picker
- * went grey again after every model change, which is exactly when a person is moving between models.
+ * THE THINKING LEVELS BELONG TO THE MODEL IN USE, so they get a key PER MODEL. This used to be one
+ * "levels" key for every model, on the assumption that the level list is the same whichever model is
+ * selected - and that assumption is wrong: Pi computes the levels from the model itself
+ * (`getSupportedThinkingLevels`: a model that cannot reason offers only "off", and a model whose
+ * thinking map says so offers fewer). Measured with one key: after reading the levels for a reasoning
+ * model, a NON-reasoning model was offered the reasoning model's levels, and the other way round - so
+ * the picker offered levels the model in force does not have, and hid the ones it does. Super Pi
+ * cannot compute the levels itself instead: Pi's rule is not exported, and a second implementation of
+ * it would drift from Pi's.
+ *
+ * THE COST OF A KEY PER MODEL, and why it is not what it used to be. An earlier version of this
+ * comment said that keying on the model "meant a cache miss for every model a person ever picked, and
+ * every miss was a process start - so the picker went grey again after every model change". That was
+ * true when the catalog ALWAYS answered by spawning a Pi, which is no longer how the ordinary path
+ * works: the SDK path reads the levels out of a session (measured ~30ms, no process at all) and caches
+ * them per model. The one-shot path - a Pi the person named explicitly - does pay a spawn for a model
+ * it has not read yet, and that is the price of asking Pi rather than guessing at its rule.
  */
 export declare const catalogKey: (selection?: ModelSelection) => string;
 /**

package/dist/server/runtime.js

@@ -196,16 +196,29 @@ const CATALOG_COMMAND_TIMEOUT_MS = 15_000;
 /**
  * Keys Pi's model answers by. Exported so the store and the tests agree with the runtime.
  *
- * THE MODEL IS NOT PART OF THE KEY, and that is the second half of why the picker no longer starts a
- * process. The MODEL LIST is the same answer whichever model a conversation has selected - it is the
- * list of models Pi offers, not the ones one conversation may use. The only thing that varies with the
- * selection is the THINKING LEVELS, which belong to the model in use.
+ * THE MODEL LIST IS SHARED. The list of models Pi offers is the same answer whichever model a
+ * conversation has selected - it is not the list of models one conversation may use. So the list has
+ * ONE key, and every conversation shares it.
  *
- * So the key records just whether levels were asked for. Keying on the model (as this used to) meant a
- * cache miss for every model a person ever picked, and every miss was a process start - so the picker
- * went grey again after every model change, which is exactly when a person is moving between models.
+ * THE THINKING LEVELS BELONG TO THE MODEL IN USE, so they get a key PER MODEL. This used to be one
+ * "levels" key for every model, on the assumption that the level list is the same whichever model is
+ * selected - and that assumption is wrong: Pi computes the levels from the model itself
+ * (`getSupportedThinkingLevels`: a model that cannot reason offers only "off", and a model whose
+ * thinking map says so offers fewer). Measured with one key: after reading the levels for a reasoning
+ * model, a NON-reasoning model was offered the reasoning model's levels, and the other way round - so
+ * the picker offered levels the model in force does not have, and hid the ones it does. Super Pi
+ * cannot compute the levels itself instead: Pi's rule is not exported, and a second implementation of
+ * it would drift from Pi's.
+ *
+ * THE COST OF A KEY PER MODEL, and why it is not what it used to be. An earlier version of this
+ * comment said that keying on the model "meant a cache miss for every model a person ever picked, and
+ * every miss was a process start - so the picker went grey again after every model change". That was
+ * true when the catalog ALWAYS answered by spawning a Pi, which is no longer how the ordinary path
+ * works: the SDK path reads the levels out of a session (measured ~30ms, no process at all) and caches
+ * them per model. The one-shot path - a Pi the person named explicitly - does pay a spawn for a model
+ * it has not read yet, and that is the price of asking Pi rather than guessing at its rule.
  */
-export const catalogKey = (selection) => (selection?.provider && selection.modelId ? "levels" : "list");
+export const catalogKey = (selection) => (selection?.provider && selection.modelId ? `levels:${selection.provider}/${selection.modelId}` : "list");
 /**
  * Where the `task` extension lives, as an ABSOLUTE path.
  *
@@ -721,9 +734,14 @@ export class PiRpcRuntime {
             announced.add(key);
             console.warn(`PiRpcRuntime: unhandled Pi session event ${key} - consumed without action.`);
         };
+        // THE FAILURE THE TURN ENDED ON, if it ended on one. Held here rather than thrown on the spot,
+        // because Pi retries on its own and only the LAST assistant message of a turn decides whether the
+        // turn failed. The bridge clears it when a new assistant message starts, and raises it when Pi
+        // settles.
+        const failure = { current: undefined };
         const unsubscribe = session.subscribe((event) => {
             try {
-                handleSessionEvent(event, queue, handlers, report);
+                handleSessionEvent(event, queue, handlers, report, failure);
             }
             catch (error) {
                 console.warn(`PiRpcRuntime: the session event handler threw: ${error instanceof Error ? error.message : "unknown error"}`);
@@ -2346,14 +2364,22 @@ export class PiRpcRuntime {
             const pick = (model) => (model ? { provider: model.provider, modelId: model.modelId, label: model.label } : undefined);
             // The levels belong to the SELECTED model, so they are asked of the model in question rather
             // than of whatever Pi would have defaulted to.
+            //
+            // AND WHEN THE SDK DOES NOT KNOW THAT MODEL, THE WHOLE READ IS HANDED OVER rather than answered
+            // with another model's levels. The model in force may belong to a Pi the SDK is not (a Pi the
+            // person named explicitly), and a list of levels for a DIFFERENT model is worse than no answer:
+            // the picker would offer levels the model in force does not have.
             const forModel = selection ?? reader.defaultModel;
-            const levels = forModel ? await reader.thinkingLevelsFor(forModel) : [];
+            const levels = forModel ? await reader.thinkingLevelsFor(forModel) : undefined;
+            if (forModel && !levels)
+                return undefined;
+            const levelNames = levels ?? [];
             const value = {
                 source: "pi",
                 models,
-                levels,
+                levels: levelNames,
                 defaultModel: pick(reader.defaultModel ? describeModel({ provider: reader.defaultModel.provider, id: reader.defaultModel.modelId, name: reader.defaultModel.modelId }) : undefined),
-                defaultThinkingLevel: reader.defaultThinkingLevel ?? levels[0],
+                defaultThinkingLevel: reader.defaultThinkingLevel ?? levelNames[0],
                 fetchedAt: new Date().toISOString(),
             };
             return value;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evandu/super-pi",
-  "version": "0.1.103",
+  "version": "0.1.104",
   "description": "Web control plane and companion for Pi",
   "license": "MIT",
   "type": "module",
@@ -43,6 +43,8 @@
     "scripts/stream-checkpoint.test.mjs",
     "scripts/stream-transport.test.mjs",
     "scripts/pi-session.test.mjs",
+    "scripts/pi-model-switch.test.mjs",
+    "scripts/pi-thinking-levels.test.mjs",
     "scripts/diagnose-cli.test.mjs",
     "scripts/lan-access.test.mjs",
     "scripts/terminal-pty.test.mjs",