Register custom LLM variants in Pi agent configuration

Fixes a Pi agent bug where a saved default model silently falls back to the built-in per-provider default (for OpenRouter, moonshotai/kimi-k2.6) instead of loading the intended one - because Pi's saved default only loads if the exact provider/id exists in its model registry, and Pi ships a static bundled list per provider that does not include OpenRouter routing-shortcut variants (:nitro for throughput, :floor for cheapest, :exacto for quality tool-use) or any brand-new model slug. The fix is registering the slug as a custom model so find(provider, id) actually matches it.

The symptom to watch for is a model that appears to have reset itself with zero warning text anywhere - that silence is the diagnostic tell, since Pi never prints an error for this class of failure, it just quietly shows something else in the footer. Before registering anything, confirm two things first: that the model or variant id is spelled and typed correctly (a typo'd id fails exactly the same silent way as a genuinely missing one), and that the provider actually has a working auth key configured, since a model can be fully registered and still fall back if its provider has no credentials at all.

Three global files are involved: ~/.pi/agent/settings.json holds defaultProvider, defaultModel, and defaultThinkingLevel; ~/.pi/agent/models.json holds custom models keyed by provider; and ~/.pi/agent/auth.json holds provider credentials. Add the model under providers.<provider>.models in models.json - for a built-in provider like OpenRouter or Anthropic, only metadata is needed, since api, baseUrl, and auth are inherited from the bundled defaults:

{
  "providers": {
    "openrouter": {
      "models": [
        {
          "id": "z-ai/glm-5.2:nitro",
          "name": "Z.ai: GLM 5.2 (nitro)",
          "reasoning": true,
          "thinkingLevelMap": { "xhigh": "xhigh" },
          "input": ["text"],
          "cost": { "input": 0.95, "output": 3, "cacheRead": 0.18, "cacheWrite": 0 },
          "contextWindow": 1048576,
          "maxTokens": 32768,
          "compat": { "supportsDeveloperRole": false, "thinkingFormat": "openrouter" }
        }
      ]
    }
  }
}

Copy cost, contextWindow, and compat from the base model rather than hardcoding a generic context or token size, since the variant shares them - the bundled entry can be found in <pi-pkg>/node_modules/@earendil-works/pi-ai/dist/providers/<provider>.models.js. Then set defaultProvider and defaultModel in settings.json to the exact id, leaving defaultThinkingLevel as the user already had it. Verify with pi --list-models | grep <id> and confirm the JSON parses, optionally smoke-testing with pi --provider <p> --model "<id>" "which model are you?".

Several quirks matter: the saved-default lookup in find() requires an exact provider+id match, with no fuzzy matching or colon-stripping, so the slug must be byte-identical between settings.json and models.json; editing settings.json alone does nothing if the slug isn't also registered in models.json; the optional enabledModels field pins the model picker so Ctrl+P cycling can't drift back, formatted as "enabledModels": ["<provider>/<id>:<thinking>"]; a repo's local .pi/settings.json overrides the global one, so a default that only reverts inside one project should be checked there first; and Pi must be fully restarted, since the model registry loads at startup.

Anyone debugging why Pi's model picker won't hold the choice they just made - the fix is a config edit rather than a Pi bug report, and once the right file carries the registration, the chosen model behaves like any other bundled one from then on.