There is a tempting fantasy in cross-model work: write one perfect prompt, run it against every model, and let the abstraction layer handle the rest. It works until it does not. The moment one model needs an XML wrapper that another ignores, or one model reasons better without the step-by-step scaffold another requires, the single-prompt dream collides with reality. Now you have a decision to make, and the decision is not obvious.
The competing approaches sit on a spectrum. At one end, a single shared prompt for all models — minimum maintenance, maximum compromise. At the other end, a separately tuned prompt per model — maximum quality, maximum maintenance. In between sit hybrids: a shared core with model-specific overrides, or a shared prompt with a thin adaptation layer that adjusts format and reasoning style per model. Each point on the spectrum is correct for some situations and wrong for others.
This article lays out the approaches, the axes that actually determine which one fits, and a decision rule you can apply without re-litigating the whole question every time. The goal is not to declare a winner but to give you a fast, defensible way to land on the right point of the spectrum for a given prompt.
The Competing Approaches
Three positions cover most of what teams actually do. Knowing the shape of each tells you what you are signing up for.
One shared prompt for all models
- A single prompt runs unchanged across every model. You maintain one artifact.
- Pro: minimal maintenance, trivial to add a new model. Con: quality is capped at the lowest common denominator, and model-specific features are unreachable.
One tuned prompt per model
- Each model gets its own prompt, optimized for its reasoning style, format handling, and quirks.
- Pro: best possible quality on each model. Con: maintenance multiplies with every model and every prompt edit, which is exactly the cost analyzed in Why Maintaining One Prompt Per Model Quietly Drains Your Budget.
A shared core with per-model overrides
- A common prompt body with small, model-specific adjustments — a different delimiter style here, a reasoning toggle there.
- Pro: most of the quality of per-model tuning with much of the maintenance savings of sharing. Con: the override logic adds complexity and can drift out of sync.
The Axes That Decide
The right approach is not a matter of taste. It falls out of a few measurable properties of your situation.
How much quality you actually need
- For a low-stakes internal tool, lowest-common-denominator quality is often fine, and the shared prompt wins. For a customer-facing feature where output quality drives revenue, per-model tuning earns its cost.
How many models and how often they change
- Two stable models make per-model tuning cheap. Five models that change quarterly make per-model tuning a maintenance nightmare and push you toward sharing or a thin override layer.
How divergent the models are
- Two models in the same family with similar reasoning styles share a prompt easily. A reasoning-optimized model and a fast completion model diverge enough that a shared prompt compromises both. The mechanics of this divergence are covered in The TRACE Method for Porting Prompts Between Model Families.
Reading the Trade-off Curve
Plotting effort against quality makes the choice concrete rather than philosophical.
Where the curve bends
- The first increment of per-model tuning buys a large quality gain for modest effort — fixing format and reasoning style. Beyond that, additional tuning buys diminishing returns at rising cost.
- The shared-core-with-overrides approach usually sits near the bend, capturing most of the quality before the curve flattens.
Where the curve misleads
- The curve hides maintenance cost, which compounds over time rather than appearing upfront. A per-model approach that looks affordable for two prompts becomes punishing at fifty. Factor the ongoing cost, not just the setup.
A Decision Rule You Can Apply
You do not need to rederive the answer for every prompt. A short rule covers most cases.
The default and its exceptions
- Default to a shared core with per-model overrides. It sits near the quality-versus-effort bend for most teams.
- Drop to a single fully shared prompt when the prompt is low-stakes and the models are similar enough that the shared version loses nothing meaningful.
- Escalate to fully tuned per-model prompts only when output quality directly drives revenue and the models diverge enough that overrides cannot bridge the gap. The checklist for executing any of these moves is in Twelve Checks Before You Reuse a Prompt on a New Model.
Revisiting the Decision Over Time
A choice that was right when you made it can become wrong as conditions change, so the decision is not permanent. The same prompt may move along the spectrum as your models, volume, and stakes evolve.
Triggers that should reopen the question
- A new model joins the portfolio that diverges sharply from the others, breaking a shared prompt that previously worked across a more uniform set.
- Request volume grows to the point where routing cheaper requests to a cheaper model justifies per-model tuning that was not worth it at low volume.
- The feature moves from internal tool to customer-facing, raising the quality bar and tilting the math toward tuning.
How to move without churn
- When you escalate from shared to overrides to per-model, do it incrementally and only where measurement shows the quality gap is real, rather than tuning models that were already fine.
- When you simplify back down — because models converged or stakes dropped — consolidate overrides into the shared core and retire the ones that no longer earn their complexity. The measurement that tells you which overrides still matter is in Reading the Signal: What Tells You a Cross-Model Prompt Is Drifting.
A Worked Example of the Decision
Abstract rules land better against a concrete case. Consider a team running a customer-facing summarization feature across two models — a fast, cheap model and a slower, more capable one — and walking the decision rule.
Applying the axes
- Quality need is high, because the summaries reach customers and shape their impression of the product, which pushes away from a fully shared prompt.
- The models diverge meaningfully: the fast model needs an explicit instruction to preserve key entities that the capable model handles on its own, a divergence that a single shared prompt would force into compromise.
- There are only two models and they change rarely, so per-model maintenance is not yet punishing.
Landing on the answer
- The rule points to a shared core with one override: a shared summarization instruction plus a fast-model-only clause about preserving entities. This captures the capable model's quality without dragging it down and lifts the fast model close to parity.
- Fully per-model prompts would add maintenance for a gain the single override already captures, so the team stops at the override — exactly where the quality-versus-effort curve bends. The checklist for validating that override across both models is in Twelve Checks Before You Reuse a Prompt on a New Model.
Frequently Asked Questions
Is a single shared prompt ever the right answer?
Yes — for low-stakes prompts running across similar models, the maintenance savings outweigh the modest quality cap. The shared prompt becomes wrong when output quality matters commercially or when the models diverge enough that the shared version compromises both.
How do I know if my models are too divergent to share a prompt?
Run the same prompt on both and compare output on your hardest cases. If both models produce acceptable output, share. If one needs a different format or reasoning scaffold to match the other, you have found a divergence that warrants an override or a separate prompt.
What is the hidden cost of per-model prompts?
Maintenance that compounds. Every prompt edit now has to be made and tested across every model's version. For two prompts it is trivial; for a library of fifty across four models it becomes the dominant cost, which is why the override approach usually wins at scale.
Can I start shared and move to per-model later?
Yes, and that is often the right sequence. Start shared, measure where quality falls short per model, and add overrides only where the data shows they pay off. This avoids tuning models that were already fine.
Does using an abstraction layer force the shared-prompt approach?
No. Most abstraction layers let you store per-model prompt variants or overrides. The layer handles routing; the prompt strategy is a separate decision you control independently.
Key Takeaways
- The approaches form a spectrum from one shared prompt to one tuned prompt per model, with shared-core-plus-overrides in between.
- The deciding axes are how much quality you need, how many models you run and how often they change, and how divergent those models are.
- The quality-versus-effort curve bends early: the first increment of tuning buys most of the gain, and the override approach usually sits near that bend.
- Default to a shared core with per-model overrides; drop to fully shared for low-stakes similar models, escalate to per-model only when quality drives revenue.
- Per-model maintenance cost compounds over time and is the factor teams most often underestimate.