fix(opencode): keep the session model on injected prompts

[iceteaSA]

Issue for this PR

Closes #38770

Also relevant to #28735 and #23369, which describe the same symptom through paths this does not fully cover.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A background subagent finishing can silently switch the parent session's model to the agent's configured default. Since Anthropic prompt caching keys on the model, the next turn misses the cache prefix and re-uploads the entire context — on a long session that is the expensive kind of silent. #38770 reports being billed on both models sequentially, which is the same thing seen from the invoice side.

createUserMessage resolves an injected prompt's model as:

const model = input.model ?? ag.model ?? (yield* currentModel(input.sessionID))

So any injected prompt that omits model lands on ag.model — the configured default — regardless of what the session was actually using. Two call sites on dev do exactly that:

TaskTool.injectBackgroundResult (packages/opencode/src/tool/task.ts) passes agent and variant but no model. This is #38770: the completion notification for a background child re-prompts the parent, and the parent's model changes underneath them. It now reads the parent's latest user message and forwards that model explicitly, with the existing variant retained as a fallback.

That also explains the detail in #38770 that looks strange at first — the agent kept reporting the old model as its identity. The system prompt was assembled before the switch; nothing re-runs it when an injected message changes the resolved model, so the prompt and the billed model disagree until the next assembly.

The shell-execution message (packages/opencode/src/session/prompt.ts) carries provider and model but drops the variant, so a session running xhigh quietly falls back to default reasoning effort. The variant is now preserved when the resolved model carries one. Separate bug, same shape, found while fixing the first.

Both fixes only supply what was already implied — neither changes agent resolution, so a genuine agent switch still adopts the new agent's model as before.

I found this from the other end: a live session moved claude-fable-5 → claude-opus-5 at a user message with no text (the injected notification), timestamp-matched to its child session completing, landing on exactly that agent's configured default.

How did you verify your code works?

Red-first, one test per site, each failing for its own distinct reason against unmodified dev:

task injection:  19 pass, 1 fail — expected parent model, received undefined
shell execution: 56 pass, 1 skip, 1 fail — expected variant "xhigh", received none

Mutation-checked separately, so neither fix is riding on the other's coverage:

task.ts reverted    → RED 19 pass / 1 fail   restored → GREEN 20 pass / 0 fail
prompt.ts reverted  → RED 56 pass / 1 fail   restored → GREEN 57 pass / 0 fail

Full suite in packages/opencode: 3208 pass / 0 fail. bun typecheck exit 0.

Note on scope: #35195 fixes this class more broadly at the shared resolution point, by consulting the durable session row before the agent default — these two sites would be covered by it. This PR fixes the call sites directly, which is independently useful and does not conflict with that approach.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.