Why does a jailbreak prompt that works on one vendor's model usually fail on another's?

## What a jailbreak is aimed at A jailbreak is a construction aimed at a model's *trained refusal* — the preference, installed by post-training, to decline certain requests. It is not the same thing as a prompt injection, which aims at the *application's* own instructions using data the application feeds to the model. That distinction matters here, because a refusal lives in the weights. It changes when the weights change: on a new tune, on a point release, and above all on a different vendor's model. ## Two separable layers in one prompt - **The family** is the mechanism — the general property of an instruction-following model that the construction leans on. Examples of the kind of property meant: a long history of compliance in the context makes further compliance the likely continuation; a plausible reason that the task is not what it appears to be shifts how the request is read; splitting a request across turns means no single turn looks like the thing being asked for. - **The instantiation** is the wording — the particular turns, phrasing, ordering and formatting that somebody refined, usually by trial and error, until they landed on one model on one day. A person who has only ever copied a working prompt cannot tell these apart, and that is exactly what an interviewer is probing for. ## Why the wording is fitted, and to what Refusal is a learned preference over token sequences, not an if-statement. The line between answered and declined is a surface shaped by one vendor's post-training data and one preference-optimisation run. The wording that works is the wording that happened to land on the permissive side of *that* surface. Several things that differ between vendors move it, and none of them is the mechanism: | Differs between vendors | Effect on a copied prompt | | --- | --- | | Tokenizer | The same characters segment into different tokens | | Chat format and role markers | Turn structure copied from one vendor reads oddly on another | | Safety tuning data and objectives | The refusal boundary sits in a different place | | Deployment defaults around the model | A different system prompt and sampling settings wrap the request | ## Why the family crosses anyway Models from different vendors are more alike than their positioning suggests. They are pretrained on heavily overlapping corpora — the public web, code, books — so they have absorbed the same conversational patterns. Their architectures are similar. They are aligned with similar recipes against similar objectives. A mechanism that exploits something all instruction-following models do is therefore a hypothesis worth testing anywhere. The string is a fact about one tune. ## Reading results correctly The direction of the claim is where candidates slip. - A **failed replay** of an exact prompt on a new model shows that this instantiation did not land. It does not show the family is absent, and it does not show anything was fixed. - A **successful replay** shows the model produced the output once, on that version, in that deployment. Decoding is stochastic, so a construction that fires some of the time gives a different verdict on different runs; one replay is one sample. - Someone who says "we tried the known jailbreaks and they all failed" has tested strings, not families. ## What practitioners actually do when crossing They expect to re-fit. The mechanism is kept; the wording is rebuilt for the target's formatting conventions and its refusal behaviour, and repeats are run before anything is claimed. That is why the *family* is the durable asset and the string is the perishable one: the family survives a retune and often survives a move to another vendor, while the wording is fitted to a single boundary that the next release moves.