A prompt that produces excellent output on one model is not a portable asset. It is a configuration tuned to the quirks of a specific system — its tokenizer, its instruction-following style, its context window, its preferences for structure. When you paste that same prompt into a different model and the output degrades, the instinct is to blame the new model. Usually the real problem is that you skipped the work of checking whether your assumptions still hold.
This checklist exists because that work is repetitive and easy to forget under deadline pressure. Each item is something we have personally watched break a transplanted prompt: a formatting convention that one model honors and another ignores, a token budget that fits comfortably in one context window and overflows another, a system-prompt instruction that one model treats as binding and another treats as a suggestion. The justifications matter as much as the checks. Knowing why an item is on the list tells you whether it applies to your specific case or whether you can safely skip it.
Treat this as a working tool, not a reading exercise. Open the prompt you intend to move, open the model you intend to move it to, and walk down the list. Most prompts will fail two or three checks. The point is to find those failures in review rather than in production.
Verify the Instruction-Following Contract
Different model families honor instructions with different strictness. Some treat a numbered list of constraints as hard rules; others treat the same list as soft preferences that get overridden when they conflict with the model's own sense of a good answer.
Check the constraints survive
- Confirm each hard constraint in your prompt is still respected by the target model. Run three to five examples and read the output for violations.
- Justification: A constraint like "never exceed 200 words" or "always return valid JSON" is the kind of thing that silently breaks across models and corrupts downstream parsing.
Check the refusal behavior
- Test how the new model handles the edge cases your prompt was designed to manage gracefully.
- Justification: Refusal thresholds and safety behavior differ by model. A prompt that elicited a helpful answer on one model may trigger a hedge or a decline on another.
Confirm the Output Format Holds
Formatting is where transplants fail most visibly. A prompt that reliably produces a clean markdown table on one model may produce prose with embedded pipes on another.
Validate structured output
- If your prompt depends on JSON, XML, or a specific schema, validate the target model's output against that schema across several runs.
- Justification: Schema adherence varies widely. Some models need explicit examples; others need a dedicated structured-output mode. Assuming parity here breaks pipelines.
Re-check delimiter handling
- Verify the target model respects the delimiters you use to separate instructions from data — triple backticks, XML tags, or whatever convention you chose.
- Justification: Models differ in how strongly they treat delimiters as boundaries, which directly affects injection resistance and section separation.
Recheck the Token and Context Budget
The same text occupies a different number of tokens in different tokenizers, and context windows vary by an order of magnitude across model families.
Measure the real token count
- Re-tokenize your full prompt — system instructions, examples, and the largest expected input — against the target model's tokenizer.
- Justification: A prompt that fits comfortably in one context window can overflow another, silently truncating your instructions or your data.
Reassess few-shot example load
- Decide whether the number of examples you include is still optimal for the target model's capability level.
- Justification: A stronger model may need fewer examples to reach the same quality, freeing budget and reducing cost. A weaker one may need more. For the underlying mechanics, see The TRACE Method for Porting Prompts Between Model Families.
Re-tune for the Model's Reasoning Style
Some models reason better when you ask them to think step by step explicitly; others reason internally and produce worse output when you force visible reasoning into the response.
Adjust the reasoning scaffold
- Test whether your chain-of-thought instructions help or hurt on the target model.
- Justification: Reasoning-optimized models often perform worse when you bolt on manual step-by-step prompting that conflicts with their native process.
Recalibrate temperature and sampling
- Re-test your temperature and top-p settings rather than carrying them over blindly.
- Justification: The same temperature produces different levels of variability across models. A setting that gave you controlled creativity on one may give you chaos or blandness on another.
Pressure-Test the Edge Cases
The middle of the distribution usually transplants fine. The failures hide in the long tail — empty inputs, adversarial inputs, and inputs near the context limit.
Run the adversarial set
- Replay any prompt-injection or jailbreak test cases you maintain against the new model.
- Justification: Injection resistance is model-specific. A prompt that was hardened against a known attack on one model may be vulnerable on another. The deeper version of this is covered in Edge Cases That Separate Portable Prompts From Brittle Ones.
Test the empty and oversized inputs
- Feed the prompt an empty input and an input that nearly fills the context window.
- Justification: Boundary behavior diverges across models, and these are exactly the cases that cause production incidents.
Lock In a Regression Baseline
Before you ship the transplanted prompt, capture a baseline you can compare against later.
Save a labeled output set
- Store the target model's outputs on your evaluation inputs as the new reference point.
- Justification: Without a baseline you cannot tell whether a future model update or prompt edit improved or regressed quality. The measurement side of this is detailed in Reading the Signal: What Tells You a Cross-Model Prompt Is Drifting.
Confirm the Operational Fit
A prompt that passes every quality check can still fail in production if its cost or latency profile does not match what the new model imposes. These final checks cover the operational reality of running the transplanted prompt at scale.
Recheck cost per request
- Calculate the per-request cost on the target model using its token count and pricing, not the source model's.
- Justification: The same prompt can cost meaningfully more or less on a different model. A transplant that quietly triples your inference bill is a failure even when the output is excellent, and the economics deserve a deliberate look as covered in Why Maintaining One Prompt Per Model Quietly Drains Your Budget.
Recheck the latency tail
- Measure not just the average response time but the slowest responses, since the tail is what breaks user-facing time budgets.
- Justification: A model with an acceptable average latency can have a long tail that violates a user-facing SLA your source model met. The tail, not the mean, determines whether the prompt is viable in an interactive feature.
Confirm the maintenance plan
- Decide whether this transplanted prompt becomes a separate artifact, a shared prompt, or a shared core with a model-specific override.
- Justification: The decision you make now determines how much work every future edit costs. Choosing a shared core with overrides usually captures most of the quality at a fraction of the ongoing maintenance, a trade-off examined in When a Single Prompt Stops Working Across Two Model Families.
Frequently Asked Questions
How many of these checks actually matter for a simple prompt?
For a short, low-stakes prompt, the format check, the token check, and the instruction-following check cover most of the risk. The edge-case and regression items matter most when the prompt runs in production or feeds a downstream system. Skip nothing on a prompt that customers depend on.
Can I automate this checklist?
Several items automate well — token counting, schema validation, and adversarial replay can all run in a test harness. The reasoning-style and instruction-following checks usually need a human to read the output and judge quality, at least until you build a reliable automated evaluator.
Why does output format break so often across models?
Models are trained on different data with different formatting conventions and have different levels of structured-output capability. Some need explicit examples to produce clean JSON; others have a dedicated mode. The convention that worked implicitly on one model often needs to be made explicit on another.
Should I rewrite the prompt or just patch the failures?
Patch first. Most transplants need two or three targeted fixes, not a rewrite. Rewrite only when the model's reasoning style is fundamentally different enough that your prompt's structure no longer fits — for example, moving between a reasoning-optimized model and a fast completion model.
How often should I re-run these checks?
Re-run the full list whenever you change the target model or its version. Re-run the format, token, and regression checks whenever you edit the prompt itself. Model providers ship updates that change behavior, so a prompt that passed last quarter is not guaranteed to pass today.
Key Takeaways
- A prompt is a configuration tuned to one model, not a portable asset; treat every transplant as a change that needs review.
- The highest-frequency failures are output format, token budget, and instruction-following strictness — check these first on every move.
- Reasoning style, temperature, and sampling settings should be re-tuned rather than carried over, because identical settings behave differently across models.
- Edge cases and adversarial inputs hide the failures that cause production incidents; replay your hardest test cases against the new model.
- Capture a regression baseline before shipping so you can detect future drift from model updates or prompt edits.