Fix 1 — clamp, never reject (owner ruling, interlude 2026-09-22): a
model swap with a pinned thinking level must JUST WORK. The owner hit
the write-side 400 live (Claude Fable 5.1/xhigh → GLM 5.3 flash:
"z-ai/glm-5.3-flash does not support thinking level xhigh"). The
supported-level verdicts in validateChatSettings and
validateModelsSettings are DEAD — the WRITE clamps the pin to the new
model's nearest supported level (pi's clampThinkingLevel, the same
translation piEngineForSpec applies at runtime) and stores the clamped
result; the server is the truth — the record shows the clamped level
after write.
New pure helpers in model-catalog.ts, applied by ALL THREE write
routes (section, defaults, per-chat — one verdict seam, so every
surface that used the old 400 gets the clamp uniformly):
- clampModelsLevels: every slot's level clamps against the SLOT'S OWN
model (the parser already requires a model on each slot write).
- clampChatLevel: the body's own model, else the record's resolved
strong slot (the chain's fallback); no model anywhere → rides
unchecked (runtime clamps at engine build; the turn gate refuses
the model-less chat anyway).
Fix 2 — DEFAULT_THINKING_ORDER moves from config.ts to core/settings
(core barrel, AUTH_KEYS precedent — one source of truth, no drift).
The UI imports it to auto-populate a thinking level on FRESH model
picks; the ordering has no other client role. Legacy unset records
keep the runtime defaultThinkingLevel fallback at engine build
untouched. Import sites updated: agent/models.ts, tests.
Verified live on 3004: the owner's exact case stores max (not 400);
a bare chat-level write clamps to low against the strong slot's glm;
unknown provider/model still 400s with the provider list.
Tests: the level-verdict suites became clamp suites (the owner's case
pinned verbatim: xhigh→max, minimal→low, off→low, supported
pass-through, level-less slots ride); the machine-aware
expectBareLevelVerdict chain is retired — clampChatLevel takes the
strong slot as an explicit param, so the tests are pure again.
Gates: typecheck, lint, 839/839, build.
Model slots wave (2026-09-20), chunk B:
- settings: new `models` section {strong, cheap, vision} slots (each
field independent, same shape as a role override); ROLE_SLOT maps all
nine roles to tiers (strong=prober+teacher, cheap=researcher/
demoBuilder/extractor/auditor/labeler, vision=visualMaker+pdfReader);
resolution chain per role: override → slot → factory pin.
- config: ModelSpec gains provider (all pins openrouter, the BYOK
default); MODEL_PINS in stores.ts now spans all nine roles (the strong
slot's factory rep IS the prober pin).
- engine: piModels() registers EVERY builtin provider catalog;
piEngineForSpec(resolved spec) is the new engine factory (pi-ai
resolves per-provider keys from env itself); piEngineFor stays as the
config-pin fallback. chat-handler resolves the conversation chain
(chat override → strong slot → pin) and injects engineFor into the job
runner, closing the old gap where per-role overrides never reached
job engines.
- /api/models: models federate ONLY keyed providers (providers surface
with keyPresent, env-wins, fresh per call); slots (resolved tier pins)
join rolePins; catalogDefaultsFor inherits the strong slot; the models
settings section gets the same catalog gate as chat.
- pricing: PRICES/CONTEXT_LIMITS uniformly keyed provider:id
(regenerated from ALL pi-ai catalogs, 1354 keys); usage stamps
(TurnUsage, JobUsage, extraction stages) switch to provider:id —
owner decision: no legacy compat, old stamps render unpriced.
amosblomqvist