[FEATURE] Model selection when spawning a background task chip

Strong +1 — and one mechanism correction from empirical testing that I think sharpens this, plus a real-world impact data point.

The issue says spawned chips inherit "the settings model field, else the plan default." In testing on 2.1.104 (desktop), that's not what I observed — a model field in settings.json / settings.local.json / user settings had no effect. What actually determines the chip's model is the primary session's live model selector at the moment you click launch:

| Primary selector at launch | Chip booted as |
|---|---|
| Opus 4.8 | Opus 4.8 |
| Opus 4.8 (after app restart) | Opus 4.8 |
| Opus 4.8 (model set in ~/.claude/settings.json) | Opus 4.8 |
| Sonnet 5 (selector flipped before launch) | Sonnet 5 |

(Verified with four identical "identify your model, one reply, stop" spike chips. Restarts and worktree-vs-local start mode made no difference; only the live selector did.)

Why I'd argue this is more than "nice to have": because the only workaround is "flip the primary selector to the cheap model → launch → flip back," and there's zero per-chip signal of which model a chip will run, the failure mode is silent. In my case a full day of delegated executor work — intended to run Sonnet — actually ran on my primary (pricier) tier because the selector sat there at launch, and I didn't catch it until the usage dashboard. A per-chip selector that shows the chosen model on the chip before launch would turn a silent cost-inflation footgun into an explicit choice.

+1, with another angle on why this isn't just a cost optimization.

My common case is the inverse of the "cheap parent, expensive task" direction: I'm running Fable on a complicated multi-step project, and along the way the session notices a trivial unrelated fix and suggests it as a task chip. The chip then launches on Fable too, because that's what the primary selector is sitting on.

That's badly matched to the work. By the time the chip exists, the original session has already done the expensive part — it found the problem, understood the surrounding code, and wrote a fully-specified prompt describing exactly what to change. What's left is often a one-line cleanup. Spending a frontier-tier session on "apply this already-defined one-line edit" is pure overkill, and it happens silently every time.

The suggesting session is also the best-positioned party to make the call, since it knows how much of the thinking it already did. So option 2 in the proposal — an optional model hint passed through spawn_task, surfaced editably on the chip — would cover this well, as long as the chip shows the resulting model before launch and I can override it.

Concretely, what I'd want: choose the model per chip based on the nature of the task, not have every chip inherit whatever tier the parent happened to be on.

Still present on Claude Code Desktop 1.40609.1.0 (Windows 11, CLI 2.1.261). Adding the mechanism behind it, since the thread so far has established the behavior empirically but not the cause — and one dimension of the problem I haven't seen mentioned.

The code path

In the renderer bundle (app/resources/ion-dist/assets/v1/c11959232-DM8o5ho4.js), the chip-start handler looks up the parent session record and copies its settings verbatim:

const l = Tu.getState().sessions.find(e => e.sessionId === r)   // the spawning session
// ...
const y = d
  ? { permissionMode: d.permissionMode, model: d.model, effort: d.effort, sourceBranch: void 0 }
  : { permissionMode: l?.permissionMode, model: l?.model, effort: l?.effort, sourceBranch: l?.sourceBranch }
// ...
await se({ sessionId: e, cwd: h, message: c.prompt, title: c.title, spawnedFrom: ...,
           model: y.model, effort: y.effort, permissionMode: b, ... })

Both start branches do this — local/worktree and cloud ($({ ..., model: y.model, ..., effort: y.effort })).

This confirms @tjfunction412's correction upthread: it is the parent session's live model, and settings.json is not consulted anywhere on this path.

Effort inherits too

effort: y.effort copies the parent's effort level along with the model, and I haven't seen that mentioned in any of the related reports. For anyone running a high effort level on their driving session, this is a larger multiplier than the model tier — and it compounds with it, since both land on the same chip.

Why settings and env can't work around it

The desktop passes the resolved model to the CLI as an explicit --model. CLI precedence is initialMainLoopModel() (the flag) → ANTHROPIC_MODEL → settings.json model, so the flag wins over both. That is the mechanism behind the "settings.json had no effect" results reported in #85868 and in the comment above — it isn't that settings are ignored, it's that they're outranked before they're ever reached.

The app already has the fallback this needs

resolveDefaultSessionModel() exists in the app and is already used by the scheduled-task, title-generation, and one-shot sampling paths. The chip path is the one that doesn't call it. So proposal 1 in the original post is a small change rather than new machinery — and resolveSessionModel already treats a "default" model as "resolve the default" for the scheduled-task sources, so the semantics are in place too.

For proposal 2, spawn_task's current input schema is title, prompt, tldr, cwd — adding optional model and effort hints would fit alongside cwd, which is already a "where/how should this run" parameter rather than task content.

One scoping note on the fix: permissionMode and sourceBranch inheritance seem worth keeping. Those describe where the work happens and are genuinely parent-derived; model and effort describe how expensive it is, and that's the part the parent shouldn't be deciding.