A prompt tuned carefully against one model doesn't always transfer cleanly to another - not because the underlying techniques are different, but because each model family has learned slightly different defaults for tone, instruction-following strictness, and how it handles a system prompt. If you're building something that needs to work across providers, or you're just moving a prompt you liked from one tool to another, knowing what tends to shift saves a round of confused debugging.
What stays the same
The core techniques from earlier in this series - zero-shot, few-shot, chain-of-thought, role/context/format structure - work across every major model family. None of it is provider-specific; it reflects how instruction-tuned language models in general respond to structured input. If a prompt is failing across the board, the fix is almost always in the technique, not in swapping providers.
What tends to shift
Three things commonly need adjustment when porting a prompt between model families: how strictly the model follows an explicit format instruction, how much it front-loads a system prompt's instructions versus treating them as loose guidance, and its default verbosity - some models default to more concise answers, others to more explanatory ones unless told otherwise. None of these are technique changes; they're calibration differences you tune for once per model family.
System prompts aren't handled identically
Every major provider supports a system-level instruction that sits outside the regular conversation, but how strongly the model weighs it relative to user-turn instructions varies by provider and by model version. A prompt that relies heavily on a system instruction being followed to the letter is worth testing explicitly on each model you deploy to, rather than assuming a system prompt is a universal, interchangeable lever.
One prompt core, three small per-model calibrations - not three separate prompts written from scratch.
Test on the actual model, not just the technique
The safest habit when supporting more than one model is treating each provider as its own entry in the test set and rubric from the evaluation guide in this series - the same inputs, the same scoring criteria, run against each model you support. Differences show up quickly and concretely instead of as a vague sense that "it works better on one than the other."
Where this matters most
If you're building a single internal tool on one model, this is mostly a non-issue - pick a model, tune against it, move on. It matters when you're building a product that supports model choice, evaluating providers against each other, or maintaining a prompt library that needs to stay portable as models change over time.