Repository navigation
[FEATURE]: Unify provider system prompts #13605
Description
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
System prompts for Anthropic, Codex, and Gemini models are very different, in ways that might not have good justification with recent models. Some if it, like Gemini system prompt, seem to be just inheritance from prior work (e.g. imported from gemini-cli).
This makes all of them diverge in guidance: some have rules about OpenCode help and support, others don't, different tone, different tool usage guidance, etc.
I have been using a fork with OpenAI/Anthropic/Google models all using the default anthropic.txt system prompt. They all work just fine with it. In fact, the gemini.txt has some verifiable issues (see #10438).
So, to improve mainteinance and consistence across providers, I'm thinking a single baseline system prompt should be used for all providers. Where some divergences are demonstrably needed (e.g. via benchmark or any decent set of reproducible test cases), a lightweight templating system could be applied to have some conditionals (e.g. make some section conditional to certain provider, or certain tool being available).
Activity
[-][FEATURE]: Unify providers system prompts[/-][+][FEATURE]: Unify provider system prompts[/+]smola commentedon Feb 16, 2026
@ariane-emory Hey, I'd be curious to hear about objections to this proposal. Is there some principle such as trying to preserve per-provider prompts close to the vendor harness (e.g.
gemini.txtclose togemini-cli)? I might be missing something about how the project currently sets the default prompts.ariane-emory commentedon Feb 16, 2026
Yes, the prompts are specifically tailored to suit each model family. For instance, Anthropic blocks access to Claude Code subscriptions if the prompt contains the string "You are OpenCode", therefore the Anthropic block prompt specifically excludes this string, and the GPT models have access to an
apply_patchtool on which they are trained and to which no other models have access.There's no single prompt that would work well with every family of model, prompt engineering of specialized prompts for each model is needed to get the best results from them - really, we should probably have more of them than we do now.
Hubedge commentedon Feb 16, 2026
Sorry for being a bit off topic here, but this relates to how we handle model diversity.
People want to customize system prompt.
Anthropic / Gemini / GPT all have their tailor-made system prompts and they work well. But for the rest of the models, like Kimi K2.5 / GLM-5 / MiniMax M2.5, they are all very capable but the system prompt routed to them is too conservative and restrictive and these capable models never get the autonomy they deserve.
This table consolidates comparison of the 4 coding agent system prompts, generated by Gemini 3 Pro, and it is in line with my personal experience of using them.
If we unify to a lowest-common-denominator prompt (like the 'Silent Tool' archetype), we lose the power of these newer models.
I acknowledge the OpenCode team might not have the bandwidth to maintain per-model prompts for every emerging vendor. Allowing custom system prompts would solve this effectively—it empowers users to optimize for specific models (like Kimi or DeepSeek) without requiring the core team to maintain and validate 50+ different vendor files.
micuintus commentedon Feb 20, 2026
The science shows that prompts don't transfer well across models. Each requires different formatting conventions, different capability references, different safety constraint wording, and different example structures to perform best, see e.g. https://arxiv.org/pdf/2512.01420
In #14398 I suggest to implement model adaptive tool specification:
PR 3: Tool Format Detection - Auto-select XML/JSON/native by model family
BUT: what is also suggested there is to use a builder pattern where common specifications don't need to be repeated
smola commentedon Feb 22, 2026
I get the desire to optimize system prompt for each provider, and in fact, before I tried OpenCode I believed they would be highly optimized. But it seems to me that the current set of system prompts is not really that optimized for each provider?
Yes, there's some specifics such as the Anthropic headers, or the availability of certain tools, that are tweaked for each provider, and they certainly need to continue that way.
Other divergences do not seem to be justified (
gemini.txtbeing the most clear example).Perhaps unifying or not is not the real problem, but the lack of systematic benchmarking we can use to make sure optimizations do work for each providers, whether they are based on fully independent system prompt, or a primary one plus conditionals.
NamedIdentity commentedon Feb 24, 2026
I think the discussion about the system prompts needs to acknowledge the rapid improvements in model intelligence and capabilities that has occurred in just the past four months. Gemini 3.1 has had a massive improvement in reasoning capabilities compared to 3.0, which was already very strong, and substantially improved over 2.5.
I've noticed often that Gemini models seem to perform poorly in OpenCode, with better quality analysis and reporting in the Gemini web app. This makes sense given that the Gemini.txt is over 7 months old.
The OpenCode system prompts are stale and outmoded, not keeping pace with the models.
It doesn't much matter if they were created to be tailored to the models, if the models they were tailored are no longer relevant.
One reason I totally abandoned oh-my-opencode was the system prompts for agents and hook system was poorly constructed, and basically made smart models like Opus 4.5 act very stupid.
I suspect something similar is occurring with OpenCode's system prompts. Both, because they're stale/outdated, and because they focus myopically on coding. Today's models are much more intelligent, and trained well enough to code that I don't think they need the hand-holding they required 6 months ago. They need to be focused on using coding as just another tool in the problem-solving toolbox.
An Opus 4.6 analysis of the OpenCode v1.2.10 git history finds:
System Prompt Staleness: Git-Proven
I came to this Issues thread because after spending the past month carefully constructing sophisticated prompts for my Agentic Collaboration Framework and it's subsystems, I wondered if the OpenCode system prompts were helping or hindering, or if my prompts were duplicative of existing instruction.
What I found was the OpenCode system prompts seem to be in a sorry state. That many of the instructions limit the intelligence and autonomy of today's models.
I can probably just load my ACF agents grounded in core ACF SPEC docs and point them at this system prompt problem, and say 'please fix' and produce superior system prompts. But without model specific data on current models, the prompts will be generalized.
What's needed is to create a solid foundational template for OpenCode system prompts. Then develop a methodology and process to keep the system prompts updated by collecting performance data from community-members session data, extract insights from it, and apply it to the system prompts. The infrastructure is in place to support this. What's missing is OpenCode maintainers embracing their leadership role and organizing community members.
github-actions commentedon Apr 25, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.