[FEATURE]: Inconsistent persistence semantics for model vs variant/effort in session APIs #24299

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Summary

model and variant/effort currently have inconsistent persistence behavior in OpenCode session APIs:

1. POST /session with model is not reliably applied as the session default.
2. variant/effort is message-scoped only (one-shot), while model can be made persistent.
3. There is no clean, explicit session config API to atomically read/update both model and variant/effort.
   This forces clients to implement workarounds (empty no-reply messages, local state shims), which introduces side effects and complexity.

Environment

• opencode server versions observed: 1.14.x
• Reproduced on both normal port mode and serve mode
• Client behavior validated via HTTP API (/session, /session/{id}/message, /provider)

Reproduction

1) POST /session with model does not reliably persist as default

POST /session
{
  "title": "test",
  "model": {"providerID":"deepseek","modelID":"deepseek-v4-pro"}
}

Then first message without explicit model:

POST /session/{id}/message
{
  "parts":[{"type":"text","text":"reply ok"}]
}

Observed model can still be default fallback (e.g. openai/gpt-5.3-codex), not the requested one.

2) variant/effort is one-shot only

POST /session/{id}/message
{
  "parts":[{"type":"text","text":"reply ok"}],
  "variant":"high"
}

Next message without variant:

POST /session/{id}/message
{
  "parts":[{"type":"text","text":"reply ok"}]
}

Observed: variant is not persisted (reverts to null/default behavior).

Expected behavior
A clean and consistent config model:

• Either both model and variant/effort are session-persistent by config API,
• Or both are message-scoped,
• But not mixed persistence semantics.

At minimum:

1. POST /session should reliably honor initial model (and optionally initial variant/effort).
2. Provide explicit config endpoints, e.g.:
   • GET /session/{id}/config
   • PATCH /session/{id}/config with {model, variant/effort}
3. Config updates should be side-effect free (no placeholder user messages).

Why this matters
Current behavior causes:

• Hidden side effects (empty placeholder messages for model pinning),
• Client-side state shims for pseudo-persistent effort,
• Hard-to-reason temporary overrides (--temp) and rollback logic,
• Increased risk of silent misconfiguration in automation pipelines.

Additional note
In codex app-server workflows, both model and effort can be managed more consistently at turn level, which highlights the gap in OpenCode REST session semantics.