All five were real. Fixed in ad5af2c.

Migrating installs lose the active model (P1). Right, and the underlying gap is wider than migration: a model was only recorded once something was edited, so switching away from any never-edited model lost what it was running with. Rather than special-casing hydration, both switch paths now snapshot the model being left. That covers the upgrade case naturally, since the checkpoint restored at startup carries the hydrated global params and gets recorded on the way out.

Whole-map hydration fence (P1). Confirmed. inferenceParams is fenced per key precisely so a pre-hydration edit cannot discard the rest, and my map used one counter for everything, so a single setParams landing before the settings response dropped every other model's entry for the session. Now tracked per model id: locally edited ids win, the rest are merged from the response.

Post-load updates overwrite the memory (P1). Confirmed at both sites. setCheckpoint replays, then setParams({ ...store.params, maxTokens: loadResp.context_length }) runs with the checkpoint unchanged, so replay was skipped, the remembered budget was overwritten and then snapshotted back over the model's entry, including for persist: false background loads. Those two calls now pass fromModelLoad, which forces the replay so remembered values outrank the load defaults, and a non-persisting update no longer rewrites durable memory at all. Pinned by a test that asserts the old behaviour is what the flag prevents.

The cap did not bound anything (P2). Correct, and worse than not capping: _deep_merge_settings does merged = dict(current) and assignment to an existing key keeps its original position, so a model trimmed off the front stayed trimmed, and any later edit to it was silently discarded on the next reload. That model could never retain settings. There is no way to delete keys through the merge endpoint, so a client-side trim cannot be made correct without changing the write semantics and giving up the per-model patch isolation that keeps concurrent tabs safe. Removed the trim. Entries are about a dozen numbers each, so the map is small in practice.

Preset provenance (P2). Confirmed: hasUnsavedPresetChanges compares params for named presets but falls back to activePresetSource === "modified" for Default, so a replay that changed params while provenance still said Default reported no changes. A replay that changes params now marks provenance modified.

Checks: 2316 frontend tests pass (two new ones for the outgoing snapshot and the load-response replay), backend suites pass, typecheck and build clean. Lint matches main apart from one extra cognitive-complexity warning on setParams, a rule the file already trips five times; I extracted two helpers to keep it as close as I could.

Correct, and it was the more important half of the earlier provenance comment. Fixed in 772af93.

I had wired getReplayStatePatch into setCheckpoint only, so the local load path, which replays through setParams on a checkpoint change, left provenance describing the model being left.

The consequence is bigger than the settings sheet, and it is what makes this the right lever rather than a cosmetic fix. Every post-load hook that re-applies model defaults is already gated on the preset source:

• mergeBackendRecommendedInference returns early with only checkpoint and trustRemoteCode when presetSource !== "builtin-default", so the status refresh stops replacing sampling values
• the Qwen thinking params check activePresetSource === "builtin-default" at both sites, the inline one in use-chat-model-runtime.ts and applyQwenThinkingParams

So leaving provenance alone let those overwrite the values that had just been replayed, and the next switch snapshotted the overwritten values back over the model's memory. Marking the replay closes all of them at once through a mechanism already in the codebase, instead of my chasing individual call sites, which is what I had started doing with fromModelLoad. That flag stays for the auto-load's maxTokens, which has no such gate.

Pinned by a test that drives the real mergeBackendRecommendedInference both ways: with builtin-default the replayed temperature is overwritten with the backend's, with modified it survives.

Checks: 2317 frontend tests, backend suites, typecheck and build clean.

Correct, and a regression from my own previous fix. Fixed in a8d54dd.

Verified the sequence: a queued external message calls autoLoadSmallestModel({ preserveVisibleSettings: true }), then restoreVisibleModelState switches the checkpoint back and does setState({ ...snapshot.runtime, ...snapshot.settings, params }). activePresetSource is in neither VISIBLE_MODEL_RUNTIME_KEYS nor the queued-settings snapshot, so the mark my previous commit added survived the restore and left the visible model reading as modified after every background load. As you say, that both shows Default as unsaved and stands the backend and Qwen default hooks down, which is precisely backwards for a load that exists to preserve visible settings.

Provenance is now restated only for a switch that is a visible settings change. trackQueuedSettings is the existing signal for this: restoreVisibleModelState passes it false, and both auto-load paths pass !preserveVisibleSettings. I checked every setCheckpoint call site in the tree, and those three in chat-adapter.ts are the only ones that pass the flag at all; chat-page, shared-composer, use-chat-model-runtime, apply-inference-status, hub-page and adopt-inference-status all pass no options, so every user-visible switch stays marked.

I considered adding activePresetSource to the snapshot instead. Suppressing is the better fit: a hidden load has no visible replay to describe, and the snapshot deliberately covers model runtime state rather than preset bookkeeping.

Checks: 2317 frontend tests, backend suites, typecheck and build clean. The two branches still combine to a clean build.

The P1 is right, and chasing it showed the provenance mark from the last round was the wrong mechanism. Both are addressed in 14dc706.

Status-derived snapshots were fenced as local edits (P1). Confirmed against the real store, not just by reading. With the settings response held open, applyActiveModelStatusToStore's setParams recorded the recommendation under the resident checkpoint and added it to locallyRememberedModels, so hydration preferred that transient snapshot over the persisted entry:

pre-hydration  map: { Qwen: { temperature: 0.9, maxTokens: 131072, systemPrompt: "" } }
post-hydration map: { Qwen: { temperature: 0.9, maxTokens: 131072, systemPrompt: "" } }

and it was durable, not just a session loss. Switching away wrote that snapshot back:

PUT inferenceParamsByModel: { Qwen: { temperature: 0.9, maxTokens: 131072, ... } }

Per-model memory is now only recorded and fenced after hydration, matching the rule the HTTP write already followed. That alone was not enough: the global params still held the recommendation, so the later switch-away snapshot would have picked it up anyway. A model that is resident at startup, or an external checkpoint restored from storage, never crosses a checkpoint transition, so nothing ever replays its memory. Hydration now does. Same scenario after the fix:

post-hydration map: { Qwen: { temperature: 0.2, maxTokens: 4096, systemPrompt: "Be terse." } }
PUT on switch away: temperature 0.2, maxTokens 4096

Persisting the replayed provenance (P2). The observation about the mark is accurate: it is state only, so an in-flight hydration restores the saved source over it and a reload has no record of it. But persisting it would have made things worse, so I have removed the mark instead.

The mark existed to stand down the hooks that re-apply a model's defaults, all of which bail on a source other than builtin-default. That flag is global, so pinning it to modified also stops a model with nothing remembered from getting its own recommended sampling, and it hands that model whatever the previous one was running with. Persisting it makes that permanent. That is the behaviour this PR set out to fix, so buying protection with it was the wrong trade.

There are exactly three places that re-apply a model's defaults: the load response and the Qwen3 thinking params in use-chat-model-runtime.ts, and the status merge in apply-inference-status-to-store.ts. Each now asks for the replay directly, so the model's remembered settings go back over its defaults and a model with nothing remembered keeps its recommendation. fromModelLoad is renamed fromModelDefaults to match. A test reads the three call sites so a fourth cannot be added silently.

That also removes the failure from the previous round: nothing writes activePresetSource on a replay any more, so a background load cannot leave the visible model reading as modified.

One thing worth flagging separately. The status race also clobbers the global inferenceParams, because getChangedInferenceParams bumps the hydration versions for whatever the status moved. That predates this PR and I have left it alone; the hydration replay covers the active model, which is the case that matters here.

Also fixed while verifying: tests/per-model-params.test.ts pulled the whole chat UI into the test program through preset-load-config, which put src/speech-recognition.d.ts out of scope and produced five type errors I had reported as clean. PersistedInferenceParams now lives beside InferenceParams in types/runtime.ts, which is what per-model-params.ts claims about itself, and the test tsconfig picks up the ambient declarations.

Checks: 2321 frontend tests, typecheck, build, lint at parity with main on the touched files, and 79 chat settings and history backend tests. The rest of the backend suite fails identically on origin/main in this environment.

Still not verified: none of this has been clicked through in a browser.

All five hold, and two of them are regressions from the last round. Fixed in 20ec42d.

Model defaults were being recorded as memory (P1). Confirmed against the real store. A fresh Qwen3 load applies the load response, which creates a full entry for the destination, and the thinking-mode hook that runs straight after then replays that entry over its own values:

map[Qwen] after the load merge: { temperature: 0.7, minP: 0.01, presencePenalty: 0, ... }
qwen thinking params applied:   { temperature: 0.7, minP: 0.01, presencePenalty: 0 }

so minP: 0 and presencePenalty: 1.5 were cancelled on every fresh load. The rule is now that only an edit is recorded. A model's defaults are not settings it was used with, and nothing is lost by not recording them: the snapshot taken when the model is left records what it actually ran with. After the fix the same sequence keeps 0.6 / 0 / 1.5 and leaves no entry for a model that has not been tuned.

Staged load params were filed against the outgoing model (P1). Confirmed. applyPerModelConfigToRuntime sets the target model's maxSeqLength while the previous one is still current, and that landed as a full snapshot of A carrying B's context length:

map after staging: { Llama-4-8B: { maxSeqLength: 32768, ... } }

Returning to A would then have replayed another model's context length, which is a VRAM change rather than a cosmetic one. That call is now marked as staged: it still applies to the runtime, and it is no longer recorded.

clearCheckpoint bypassed the outgoing snapshot (P2). Correct. An unload or eviction leaves a model exactly the way a switch does, and ten call sites reach it. It takes the same snapshot now, so a model that was never edited is still remembered when it is dropped.

A pre-hydration edit lost to the replay (P2). Correct, and it was the trade I made last round when adding the hydration replay. The fence that protects a user edit from the hydrated global set now protects it from the replay too, per key. That works because model defaults no longer bump those versions: a model's own defaults must not outrank the settings the user saved for it, which is what the hydration response is delivering. A slider moved while the request is in flight now survives, and a key the user did not touch still replays.

That also removes the caveat I raised last round about the status race clobbering the global inferenceParams.

Clamping the replayed budget (P2). Correct. A GGUF reloaded with a smaller context would have had its older, larger maxTokens replayed straight into the next request. The three sites that know the context the model actually loaded with now pass it, and the replay clamps to it. Only those sites pass one: for a non-GGUF load the merge's 4096 is an output default rather than a context cap, and clamping to it would lower a remembered budget for no reason.

Checks: 2328 frontend tests, typecheck, build and lint at parity with main on the touched files. Every new test was confirmed to fail against the previous commit. The two branches still merge to a working build (2344 tests).

Still not verified: none of this has been clicked through in a browser.

Both correct. Fixed in e781182.

The staged value still reached the outgoing model (P1). Confirmed, and it is the half my previous fix missed: marking the staging call stopped that call recording, but the switch that follows snapshots the params staging left behind, so the outgoing model was recorded with the incoming model's context length anyway:

A on maxSeqLength 4096, stage B's 32768, switch to B
map[A].maxSeqLength = 32768

The snapshot now puts the staged values back before recording. Deliberately narrow: only the keys staging wrote, and only while the live value still matches what staging wrote. A context the user sets themselves between staging and the load is theirs, and is recorded as theirs. Both cases are pinned by tests.

My first attempt kept the whole pre-staging params object and swapped it in wholesale, which quietly reverted unrelated edits made after staging; an existing test caught it. Worth mentioning since the narrower rule is the reason for the extra bookkeeping.

Partial entries borrowed from the previous model (P2). Correct. Entries this app writes are full snapshots, but a stored entry can be partial: an older write, a field that did not survive sanitising, or a hand-written payload, since the backend accepts a partial per-model dict. Replay lays what the entry has over the params on screen, so the gaps were filled by whichever model was selected beforehand, which is the bleed this PR exists to stop.

Entries are completed as they hydrate, from the saved global set in the same response. That is the same answer every time and it is what the model would have run with before this PR, rather than snapping unpinned values to library defaults. A key missing from both is still left alone.

Checks: 2331 frontend tests, typecheck, build and lint at parity with main on the touched files. Both new behaviour tests were confirmed to fail against the previous commit. The two branches still merge to a working build (2349 tests).

Still not verified: none of this has been clicked through in a browser.

Both correct. Fixed in 477e38b.

The resident model lost its saved settings (P1). Correct, and it is the earlier finding coming back through last round's fix. Reproduced on an upgraded install, with only inferenceParams saved and the status for the already-resident model beating hydration:

checkpoint before the status: ""
temperature after hydration:  0.9   (saved 0.2)

The keepModelDefaults exception is right for a model loaded while the request was in flight and wrong for the model already resident, which is the one the saved global set describes. The signal that separates them is what the defaults replaced: at startup a local checkpoint is not persisted, so the first status publishes it over an empty one, while a model loaded during the request replaces a model that was already named. The exception now applies only in the second case, and both are pinned by tests.

A restore recording the hidden model (P2). Correct. restoreVisibleModelState switches back through setCheckpoint, and the model it steps off is the one the background load put there, so the outgoing snapshot recorded and persisted parameters the user never chose, despite the load itself passing persist: false. setCheckpoint takes the same option now, and the restore passes it. A visible switch still records the model being left; there is a test for each.

Checks: 2332 frontend tests, typecheck, build and lint errors at parity with main on the touched files. Both new behaviour tests were confirmed to fail against the previous commit, including one that only discriminated after I pinned its starting sampling: state left by an earlier test made the status a no-op and it passed for the wrong reason. The two branches still merge to a working build (2353 tests).

Still not verified: none of this has been clicked through in a browser.

Codex Review: Didn't find any major issues. 👍

Reviewed commit: 060ae5d806

@codex review

@codex review

Codex Review: Didn't find any major issues. Delightful!

Reviewed commit: b8f9f41356