Why a Prompt Works in One Model but Not Another

Prompts contain instructions, examples, context, and output requirements. Different models can interpret the same wording differently, produce different levels of detail, or support different structured-output and tool-call features. Even versions within one family may change behavior. API compatibility means requests can share a format; it does not mean model behavior is identical. Portability can fail in several ways: a model may ignore a formatting rule, interpret an example differently, refuse a benign task, omit a tool call, or use a different language style. Models may also differ in tokenization, context limits, decoding settings, and available features. These differences are not necessarily bugs; they reflect distinct systems and configurations. To compare prompts fairly, define the target behavior and use the same task examples, relevant settings, and scoring criteria. Test typical and edge cases, including structured outputs, safety requirements, and tool use where applicable. Record exact model identifiers and dates. If a model needs a prompt adjustment, preserve the baseline and evaluate that change rather than assuming equivalent prompts should yield equivalent responses. Prompt portability is possible for simple tasks but must be measured. Use a shared core prompt where it works, then add model-specific adapters only when tests justify them. Keep evaluation sets independent of prompt tuning and monitor after model or provider updates. A successful migration depends on the full application, not only the wording of one instruction.