The session pin added in 60b8ecc was read from the global active runtime at create time, so it only held if api.useModel({runtime_id:'scripted'}) had already landed. Two paths defeat that: - useModel returns an ApiResult and never throws, so its `{ok:false}` result is swallowed by the best-effort try/catch. The tutorial then runs unpinned on app.state.runtime — the fake NPC — which is the exact symptom of issue #427, with no error surfaced. - On the "Start now" path a model is downloading. If the install pipeline finishes in the window between useModel and createSession it calls set_active_config(llama_cpp), and the tutorial session is created unpinned. Let the session declare its own runtime instead: SessionCreateRequest takes an optional runtime_id, restricted by a Literal to the model-free runtimes ("scripted", "fake") so a client can never point a session at a sidecar-backed one. An explicit value wins; otherwise the active-config sniff still pins demo and scripted sessions created through the ordinary setup form. When neither applies, no runtime_id key is written to setup_json, so old and new sessions resolve identically. Also add the missing regression test for the 204 fix in ce5c496: no test covered handleResponse's empty-body path, which is what regressed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Uh oh!

Try New fails on first open #427

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions