Proposal: model-tier-specific system prompt variant behind an opt-in option #32315

Summary

I'd like to propose an opt-in promptVariant provider/model option that selects an alternate system prompt for frontier-class models, while keeping the current prompt as the unchanged default.

Hypothesis

packages/opencode/src/session/prompt/*.txt is currently a "works for any model" baseline. On frontier models (GPT-5.4, Claude Opus/Sonnet 4), that baseline appears to under-use the model's capability — it leans toward shallow, "looks fine" conclusions rather than driving the model to reason to root cause.

Measurement

I ran a within-session controlled comparison on a public code-review task (planetiler, reviewing its last 10 commits for known seeded regressions). Same model, same agent prompt, same session — only the system prompt was swapped between the baseline and a frontier-tuned variant. Recall of public-API silent-semantic-change bugs:

The frontier variant improved recall by ~45–71pp at the same (zero) false-positive rate.

Proposal

Add a promptVariant option (provider- or model-level). The only value would be "frontier", which routes GPT (non-codex) and Claude families to a frontier-tuned prompt; every other family falls back to the baseline. Unset is the default and means baseline, so the change is non-breaking and fully opt-in — existing users see no difference unless they enable it.

I have a branch ready (mechanism + the two prompt files + unit tests + attribution). The implementation is small: the mechanism is ~30 lines; the prompt files are text.

Attribution

The frontier prompts paraphrase selected operating principles from the Codex CLI prompts (Apache-2.0); no source is copied verbatim. A repo-root NOTICE documents the adapted scope and the clauses added independently.

Question

Does a system-layer, opt-in prompt variant fit the project's scope? If it sounds reasonable I'll open the PR.