What a Model Family Is, and Why Prompts Do Not Transfer Across One

People use “model family” to mean whatever the vendor brands together. That is a marketing boundary and it predicts almost nothing about whether your prompt will keep working. The boundary that predicts it is training lineage: which base run a model descends from, and which post-training recipe shaped it afterwards.

The definition

Two models are in the same family when they share enough of their training history that they have inherited the same habits. In practice, that means some combination of:

• The same pretraining run, or a descendant of it. A checkpoint that was continued, distilled from, or fine-tuned from another carries that ancestor’s representations forward.
• The same tokenizer and vocabulary. This is the single most reliable technical marker, because a vocabulary is expensive to change and models in one lineage almost always share one.
• The same post-training recipe. The instruction and preference data that decides how the model formats an answer, how verbose it is, how it handles ambiguity, when it declines, and how eagerly it calls tools. This is the layer your prompt is actually talking to.

A release of several sizes announced together is normally one family: same tokenizer, same recipe, different capacity. A model fine-tuned by a third party from a published open base is in that base’s family, whatever the fine-tuner calls it — it inherits the vocabulary, most of the formatting priors, and usually the licence too, which is a separate consequence covered in fine-tuning licences.

What a family is not

• Not the vendor. A large vendor ships several unrelated lineages simultaneously — a flagship line, a small efficient line, an open-weights line, sometimes an acquired one. Two models from one company can be less alike than two models from different companies where one is derived from the other.
• Not the API. A great many models are served behind an OpenAI-compatible endpoint. The request shape being identical tells you nothing about the model behind it; that compatibility is a serving decision made by whoever hosts it.
• Not the size. A 7B and a 70B from one release share a family. Their behaviour on your prompt still differs, for the reasons in the last section — but the direction of the difference is predictable in a way that a cross-family difference is not.
• Not the version number. Vendors reuse a product name across a genuine architecture change. The name is continuous; the lineage may not be.

What the lineage actually fixes

Concretely, the shared post-training is what sets each of these — and each is something a prompt tuned on one model is implicitly relying on:

• Delimiter preference. Whether the model responds better to XML-style tags, markdown headings, or fenced blocks, is a consequence of how its instruction data was formatted. It is a learned prior, not a parser. See rewriting XML-delimited prompts.
• Default verbosity and structure. Whether an unconstrained answer arrives as three paragraphs or a bulleted list with headings.
• Instruction precedence. What happens when the system prompt and the user turn conflict, and how strongly a negative instruction (“never mention X”) holds over a long conversation.
• Tool-calling eagerness. How readily the model reaches for a tool, whether it emits several calls at once, and whether it narrates before calling.
• The refusal boundary and the wording used to decline.
• Few-shot sensitivity. How much weight examples get relative to the instruction, which is why few-shot sets stop working across families.

A prompt is a set of bets on those six things. Move within a family and most of the bets hold; move across one and several are being re-rolled at once, which is why cross-family migrations produce diffuse quality complaints rather than a single identifiable break.

Telling from the outside

Vendors do not always state lineage, especially for hosted models. You can still get a usable answer.

1. Compare tokenizations. Send a stress string — mixed script, code, long numbers, unusual punctuation — and compare reported input token counts. Identical counts across a set of adversarial strings is strong evidence of a shared vocabulary; a consistent divergence is strong evidence against. Providers that expose a token-counting endpoint make this cheap, and Anthropic documents one for its Messages API. Anthropic’s token counting documentation describes that endpoint.
2. Read the model card for a lineage statement. Open releases usually name their base explicitly, because the licence requires it. Model cards are where this is recorded when it is recorded at all.
3. Follow the licence. A derivative carries obligations from its base. A model distributed under a base model’s community licence is telling you its ancestry in a legally binding document.
4. Look at the formatting priors directly. Give both models the same open-ended prompt with no formatting instruction, a dozen times. Models in one family produce recognisably similar shapes. This is soft evidence but it is the evidence that matters for your actual question.

Same family is not same behaviour

The boundary is useful, not magic. Before the list of within-family differences, there is a prior one: the same weights served by two hosts are not necessarily the same product. A host may serve a quantised copy, apply its own default system prompt, set different default sampling parameters, or truncate the context below the model’s nominal window to fit its hardware. None of that appears in the model name. If you are moving between two deployments of what is nominally one open model, treat the serving stack as part of the identity and ask the host what it does — the distinction between a model and the party running it is the subject of provider versus deployer.

Within one family you should still expect these to move:

• Capacity effects. A smaller sibling follows long multi-clause instructions less reliably. Prompts that work by piling up conditions degrade first, and the fix is usually to split the task rather than to reword it.
• Reasoning variants. A reasoning-tuned member of a family can respond badly to explicit step-by-step instructions that help its non-reasoning sibling, because you are asking it to do in the output what it already does internally.
• Version drift. A revision within a family is still a revision. This is the same phenomenon as a silent model update.

So the operational rule is a triage rule rather than a guarantee. Within a family, expect to re-verify and budget a small amount of re-tuning. Across a family, expect the prompt library itself to need a review pass before you trust any of it — which is what auditing a prompt library for provider idioms is for.