@evandu/super-pi 0.1.103 → 0.1.105

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

@@ -78,6 +78,15 @@ export declare class PiSessionPool {
      * knows what one looks like.
      */
     private readonly mintCapability;
+    /**
+     * How many times the set of models Pi knows about has changed.
+     *
+     * Injected rather than imported for the same reason the capability minting is: the pool needs to
+     * know WHEN a session is stale, and the caller knows what changed. A provider added through the
+     * settings window makes every live session unable to reach the new model, and the next turn is
+     * where that gets fixed.
+     */
+    private readonly modelEpoch;
     private readonly sessions;
     constructor(
     /** Where Pi keeps its session files. */
@@ -104,7 +113,16 @@ export declare class PiSessionPool {
      * does not have to know what a capability is - it needs to know WHEN one is needed, and the caller
      * knows what one looks like.
      */
-    mintCapability?: (conversationId: string) => string);
+    mintCapability?: (conversationId: string) => string, 
+    /**
+     * How many times the set of models Pi knows about has changed.
+     *
+     * Injected rather than imported for the same reason the capability minting is: the pool needs to
+     * know WHEN a session is stale, and the caller knows what changed. A provider added through the
+     * settings window makes every live session unable to reach the new model, and the next turn is
+     * where that gets fixed.
+     */
+    modelEpoch?: () => number);
     /**
      * The session for a conversation, built if there is none and REPLACED if the live one is stale.
      *

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

@@ -48,6 +48,7 @@ export class PiSessionPool {
     onSessionDestroyed;
     factory;
     mintCapability;
+    modelEpoch;
     sessions = new Map();
     constructor(
     /** Where Pi keeps its session files. */
@@ -74,13 +75,23 @@ export class PiSessionPool {
      * does not have to know what a capability is - it needs to know WHEN one is needed, and the caller
      * knows what one looks like.
      */
-    mintCapability = () => "") {
+    mintCapability = () => "", 
+    /**
+     * How many times the set of models Pi knows about has changed.
+     *
+     * Injected rather than imported for the same reason the capability minting is: the pool needs to
+     * know WHEN a session is stale, and the caller knows what changed. A provider added through the
+     * settings window makes every live session unable to reach the new model, and the next turn is
+     * where that gets fixed.
+     */
+    modelEpoch = () => 0) {
         this.sessionDir = sessionDir;
         this.repositoryRoot = repositoryRoot;
         this.agentDir = agentDir;
         this.onSessionDestroyed = onSessionDestroyed;
         this.factory = factory;
         this.mintCapability = mintCapability;
+        this.modelEpoch = modelEpoch;
     }
     /**
      * The session for a conversation, built if there is none and REPLACED if the live one is stale.
@@ -188,9 +199,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.`);
@@ -217,6 +238,7 @@ export class PiSessionPool {
             tools: request.tools,
             excludeTools: request.excludeTools,
             extensions: superPiExtensionPaths(this.repositoryRoot),
+            modelEpoch: this.modelEpoch(),
         };
     }
     /**

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.
@@ -125,6 +129,16 @@ export interface SessionFingerprint {
     excludeTools: string[] | undefined;
     /** Which of Super Pi's own extensions were mounted. */
     extensions: string[];
+    /**
+     * How many times the set of models Pi knows about has changed.
+     *
+     * NOT THE MODEL, BUT THE WORLD THE MODEL LIVES IN. A session's `ModelRuntime` is built with it and
+     * does not learn about a provider added afterwards, so a session that keeps running on the old
+     * runtime cannot switch to a model that only exists in the new one - and Pi's refusal to switch is
+     * swallowed into a warning, which would leave the turn running a model the picker does not name.
+     * The counter makes such a session stale, and it is rebuilt at its next turn.
+     */
+    modelEpoch: number;
 }
 /**
  * Fingerprints are compared by VALUE, and this is where that comparison is spelled out.
@@ -235,11 +249,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);
@@ -177,6 +185,8 @@ export function sameFingerprint(a, b) {
         return false;
     if (!sameSet(a.extensions, b.extensions))
         return false;
+    if (a.modelEpoch !== b.modelEpoch)
+        return false;
     return true;
 }
 function sameSet(a, b) {
@@ -269,7 +279,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) {
@@ -319,8 +345,17 @@ async function resolveSessionManager(sdk, creation) {
  * file goes out of its way not to do for a path it can derive. The derivation is Pi's own default:
  * `~/.pi/agent`, with the home directory taken from the environment rather than from `os.homedir()`,
  * because on Windows the two disagree often enough to matter.
+ *
+ * `PI_CODING_AGENT_DIR` WINS, exactly as it wins in Pi (`core/config.ts:getAgentDir`). A person who
+ * set it expects Pi to read its whole configuration from there, and this function used to disagree
+ * with Pi about it: Pi's model runtime read `models.json` from that directory while the session's
+ * resource loader read the skills from `~/.pi/agent`. Two halves of one Pi pointed at two
+ * directories, and only one of them was the one the person had configured.
  */
 function defaultAgentDir() {
+    const configured = process.env.PI_CODING_AGENT_DIR?.trim();
+    if (configured)
+        return configured;
     const home = process.env.HOME ?? process.env.USERPROFILE ?? "";
     return home ? join(home, ".pi", "agent") : join(".pi", "agent");
 }

package/dist/server/providers.d.ts

@@ -0,0 +1,160 @@
+import type { PublicProvider } from "./types.js";
+/**
+ * THE PROVIDERS A PERSON ADDED, and the two files that make Pi know about them.
+ *
+ * WHAT THIS REPLACES. Pi's own answer to "I want to use a model that is not in your list" is a
+ * hand-written `~/.pi/agent/models.json` (the provider and model definitions) plus a key in
+ * `~/.pi/agent/auth.json`. There is no command for it and no UI for it - the files are the interface.
+ * This module is that interface, in a form: the settings window collects the same fields and writes
+ * the same files.
+ *
+ * WHY THE FILES AND NOT A RUNTIME REGISTRATION. Pi's SDK can register a provider in memory
+ * (`ModelRuntime.registerProvider`) and hold a key in memory (`setRuntimeApiKey`), and both are
+ * tempting - they touch nothing of the user's. They do not work here, for two reasons that are
+ * facts about this codebase rather than opinions:
+ *
+ *   1. `ModelRuntime` is created PER SESSION here (`pi-session.ts:498`), so a provider registered on
+ *      one instance is invisible to the next conversation.
+ *   2. A spawned Pi (`pi --mode rpc`, the one-shot mode) has no provider-registration command at all
+ *      - its RPC surface is `set_model` and `get_available_models` and nothing that defines a
+ *      provider. A provider that exists only in this process's memory cannot reach it.
+ *
+ * The files, by contrast, are read by BOTH paths: the SDK's `ModelRuntime.create()` loads
+ * `models.json` and `auth.json` from Pi's agent dir, and a spawned Pi does the same. So writing them
+ * is the only way one setting works everywhere - including in the terminal, where `pi` sees the same
+ * provider the person just added here.
+ *
+ * THE TRUTH SOURCE IS OURS, THE FILES ARE DERIVED. `<dataDir>/providers.json` (0600, holds the key)
+ * says which providers Super Pi manages. Pi's two files are rewritten from it after every change, by
+ * MERGING: only the provider ids we manage are touched, everything else in those files is left alone.
+ * That is what makes "delete the provider I added" safe, and it is why a person who hand-wrote their
+ * own provider keeps it.
+ *
+ * THE KEY NEVER REACHES THE BROWSER. It lives in two files with restrictive permissions - ours and
+ * Pi's `auth.json` - and in neither the state snapshot nor any event. What the browser gets is
+ * `hasKey: true`.
+ */
+/** One model of a provider, as the settings window collects it. */
+export type ProviderModelDefinition = {
+    id: string;
+    name?: string;
+    reasoning?: boolean;
+    imageInput?: boolean;
+    contextWindow?: number;
+    maxTokens?: number;
+    /**
+     * The two compatibility switches an OpenAI-compatible server sometimes needs.
+     *
+     * `supportsDeveloperRole: false` makes Pi send the system prompt as a `system` message instead of
+     * a `developer` one, which is what relays and local servers that predate the `developer` role need.
+     * `supportsReasoningEffort: false` stops Pi from sending `reasoning_effort` to a server that does
+     * not know the field. Both are per-provider in Pi's schema and per-model here, because a server can
+     * be one and not the other.
+     */
+    supportsDeveloperRole?: boolean;
+    supportsReasoningEffort?: boolean;
+};
+/** One provider, as the settings window collects it. */
+export type ProviderDefinition = {
+    id: string;
+    name?: string;
+    baseUrl: string;
+    api: string;
+    /** The API key. Stored, never broadcast. */
+    apiKey?: string;
+    models: ProviderModelDefinition[];
+};
+/** One model, as the browser sees it. No key, no nothing secret - there is nothing secret here. */
+export type { PublicProvider, PublicProviderModel } from "./types.js";
+/**
+ * The API adapters Pi ships, as the ids a provider may name.
+ *
+ * Taken from Pi's own `KnownApi` union (`pi-ai/dist/types.d.ts`) rather than invented: the id ends
+ * up in `models.json` and Pi looks the adapter up by exactly this string, and an unknown one fails
+ * at REQUEST time ("No API provider registered for api: ...") rather than at load time. Offering the
+ * list in the form is the difference between a person finding the right value and guessing.
+ */
+export declare const KNOWN_APIS: readonly ["openai-completions", "anthropic-messages", "openai-responses", "azure-openai-responses", "openai-codex-responses", "mistral-conversations", "google-generative-ai", "google-vertex", "bedrock-converse-stream", "pi-messages"];
+/**
+ * Pi's global configuration directory - where `models.json` and `auth.json` live.
+ *
+ * `PI_CODING_AGENT_DIR` wins, because that is Pi's own rule (`core/config.js:getAgentDir`) and a
+ * person who set it expects Pi to read its config from there. The fallback is Pi's own default,
+ * `~/.pi/agent`, with the home directory taken from the environment rather than from `os.homedir()`
+ * - on Windows the two disagree often enough to matter.
+ */
+export declare function piAgentDir(): string;
+/** Pi's provider and model definitions. */
+export declare function piModelsPath(agentDir?: string): string;
+/** Pi's credential store. */
+export declare function piAuthPath(agentDir?: string): string;
+/**
+ * Strips JSONC comments, the way Pi's own parser does.
+ *
+ * Pi reads `models.json` with comments allowed, so a person may well have written comments in it -
+ * and Super Pi has to be able to READ that file to merge into it. A naive strip would corrupt a
+ * string that contains `//` (a base URL with a path, an api key with a slash), so this walks the
+ * text and tracks whether it is inside a string.
+ */
+export declare function stripJsonComments(text: string): string;
+/**
+ * The providers Super Pi manages, and the writes that make Pi know about them.
+ *
+ * The class owns three files: its own registry, Pi's `models.json` and Pi's `auth.json`. Only the
+ * first is a truth source; the other two are rewritten from it.
+ */
+export declare class ProviderRegistry {
+    private readonly dataDir;
+    private readonly piDir;
+    /**
+     * `piDir` is Pi's own configuration directory, and it is a PARAMETER rather than a lookup at
+     * write time for one reason: a test that forgets to set `PI_CODING_AGENT_DIR` would then write to
+     * the developer's real `~/.pi/agent`. With the directory in hand, a test cannot reach it by
+     * accident - it has to be given one.
+     */
+    constructor(dataDir: string, piDir?: string);
+    /** Super Pi's own registry: the providers it manages, with their keys. */
+    private get registryPath();
+    /**
+     * Reads the registry.
+     *
+     * A missing file is an empty registry, not an error: nobody has added a provider yet. A file that
+     * cannot be parsed IS an error, because reading it as empty would let the next write replace
+     * somebody's keys with nothing.
+     */
+    load(): Promise<ProviderDefinition[]>;
+    /** Writes the registry. The key lives here, so the file is 0600. */
+    save(providers: ProviderDefinition[]): Promise<void>;
+    /**
+     * Makes Pi's files match the registry.
+     *
+     * `previousIds` are the providers Super Pi managed before this change: they are the only ones
+     * whose entries may be REMOVED. An id that is in Pi's `models.json` and not in `previousIds` belongs
+     * to the person who wrote that file, and touching it would be Super Pi editing a provider it does
+     * not own - so the write is refused with a message naming the id.
+     */
+    applyToPi(previous: ProviderDefinition[], next: ProviderDefinition[]): Promise<void>;
+    /**
+     * Writes the keys into Pi's `auth.json`.
+     *
+     * A credential is REMOVED only when it is the one Super Pi wrote: the same provider id and the
+     * same key. A person who replaced our key with their own - or who ran Pi's `/login` and put an
+     * OAuth token there - keeps it. Deleting somebody else's credential because they removed our
+     * provider would be the worst version of this feature.
+     *
+     * TWO CASES, and the second is the one that is easy to miss: the provider can be gone ENTIRELY
+     * (it was removed), or it can still be there with its key GONE (the person asked for the key to be
+     * cleared). Both have to take the credential with them, or "clear the key" would leave a working
+     * key sitting in Pi's auth file.
+     */
+    private applyKeysToPi;
+}
+/** The provider list as the browser sees it: the key becomes a fact. */
+export declare function publicProviders(providers: ProviderDefinition[]): PublicProvider[];
+/**
+ * Checks what the form collected and returns it in the shape the registry stores.
+ *
+ * EVERY RULE HERE SAYS WHY, because a message a person reads is the only validation they get: the
+ * server cannot ask a follow-up question, so a refusal has to name the field and the reason.
+ */
+export declare function validateProvider(input: unknown): ProviderDefinition;