Session-scoped model and effort selection

[antst]

• Queued (not yet posted): DSH Discussion (Ideas): session-scoped model/effort selection. rc.1 selectModel always calls agentDefaultModel.saveSelection (packages/api/session-controller/src/commands.ts:119-145) and neither SessionCreateRequest, resolveAgent, nor AgentPreset carries a model or effort, so a launch flag like --model cannot avoid moving the deployment default (W-025). Release to the lane with the install-hazards report.

Target: DSH Discussion (Ideas)

[argszero]

Two things are fused in one call here, and only one of them is the one you asked for.

selectModel (packages/api/session-controller/src/commands.ts:133-159) does both halves:

• this.agents.selectForNextRequest(agent, selected) (:151) — session-local and durable: it appends model/selection, so this half is already the right shape;
• await this.ctx.agentDefaultModel.saveSelection(selected) (:153) — a deployment-wide settings write, and the only production writer of that section (definition at agent-default-model/src/index.ts:100, docs at tool-cordis/src/api-catalog.ts:96; no other call site).

So a lane cannot put this session on that model without also re-pointing every later session in the same DSH home — and, as your second case shows, the headless lane has no surface to carry a model at all: SessionCreateRequest, resolveAgent and AgentPreset each carry neither a model nor an effort.

Two details the report does not state, both of which make a fix cheaper:

1. The docstring at :129 reads "Validate and install one Session-local model selection." — while the body also writes the deployment default. Same shape as 本地提交回显在持久节点落地前就被退役 —— 任何耗时的 `agent/pre-step` 监听器都会变成可见的消息延迟 #7167's observeSubmissionQueue: the description covers half the effect. Worth correcting on its own, whichever fix is chosen.
2. That default write is best-effort, not fatal — :152-158 wraps it in try/catch and only logger.warns, then returns normally. Making it conditional (or moving it to an explicit "change the default" entry point) therefore costs no robustness: nothing downstream depends on it succeeding.

The capability already exists in-tree for exactly one lane. installInitialModelSelection (packages/webhook/webhook/src/session.ts:92) applies a creation-time selection to one Agent and never touches the settings document — but it is reachable only from a webhook rule result. The public generalization is the agent/request waterfall (packages/core/agent/src/runtime-types.ts:337): its payload carries the agent and it returns the resolved LlmCallConfig, so a listener can rewrite the route for one session without any settings access. In-tree, that waterfall is emitted by installModelSelection (model-selection.ts:92) — the same place the default model is otherwise resolved.

What I shipped

@argszero/cordis-plugin-session-model@0.1.0 — npm: https://www.npmjs.com/package/@argszero/cordis-plugin-session-model — source: https://github.com/argszero/cordis-plugin-session-model

Two surfaces, one per missing lane:

• a composition pin (provider / model / reasoningEffort, optionally per-session under sessions) gives a lane its starting route. It is applied while the session has no model choice of its own — no durable request header and no pending model/selection in the sessionProjections registry — which is exactly the window installInitialModelSelection covers, so an explicit switch made inside that session later always wins;
• a runtime pin (the session_model tool, or ctx.sessionModel.pin/read/clear for another plugin) re-points the session the caller is already in, from that moment until it is cleared or the session records a durable selection of its own.

- set:
    - id: session-model
      config: { provider: deepseek, model: deepseek-chat, reasoningEffort: high }

A pin that changes the route without naming an effort clears the inherited effort — the effort belonged to the route that carried it, the same rule the harness's own selection uses — and every other resolved field (maxTokens, temperature, stop) survives untouched. The prompt variables move with the route, so the system prompt and the dispatch never disagree about which model the session is on. A runtime pin that re-points a session already under way appends one durable notice through agent/pre-step, the same mechanism the harness uses for its own model switch, so a transcript whose turns came from two models says so.

Evidence: 42 tests against a real cordis context (real service injection, real waterfall dispatch, real dsh-tools argument validation), 5/5 deliberately injected mutations killed (including "the waterfall returns the resolved config untouched" and "a durable selection no longer retires a runtime pin"), the behaviour suite re-run against the published artifact from a clean project (25/25), and a by-name npm install into an empty directory that imports the package. The manifest declares exactly one dependency (@deepseek-ai/schemastery); every harness package is a peer, so the runtime is never nested.

Honest boundary: this supplies a path that never writes the deployment default; it cannot stop the path that does. The session model picker still calls selectModel and still moves the default. A runtime pin lives in memory (per process), so a pin that must exist before the session starts belongs in config, and an out-of-process child has no agent/request in this process, so its route is untouched by construction.

Sibling assets on the same seam: @argszero/cordis-plugin-subagent-model (routes a subagent per request, #7116) and @argszero/cordis-plugin-subagent-effort (carries a subagent's effort, #4666). All three mount agent/request — which may be the more useful finding than any of them: naming a route for one agent, without the settings document, is a capability the public seam already expresses.