Short answer
Because the prompt is only one input to a system. Model weights, system instructions, safety rules, tools, retrieval content, sampling settings, context order and provider infrastructure can all change; generation can also be non-deterministic. Identical visible text is therefore not an identical experimental condition. For material workflows, pin versions where possible, preserve full configuration, run regression tests on representative work, and treat an upgrade as a software change—not an automatic delivery of “more intelligence.”
The “same prompt” is rarely the complete same input
The text box is only the outer layer. A service may add role instructions, date, language, account policy, memory, file passages, search results and tool descriptions. These components may change along with a model. The words entered by the user can be identical while the full context differs.
A multi-turn conversation also contains preceding messages in a particular order. Continuing an old thread and testing a new thread are different conditions. A re-uploaded file may be parsed into different chunks or OCR. A retrieval-augmented answer changes when an index changes.
For diagnosis, record the full input package rather than a screenshot of the last user message: system and developer instructions, conversation history, file versions, retrieved passages, tool definitions and execution time.
An upgrade changes more than knowledge
A new model can change instruction following, refusal, tool use, preferred structure, long-context handling, language style and expression of uncertainty. Better aggregate benchmarks do not prevent regression on a particular task.
An old model may reliably emit fixed JSON while a new one prefers an explanation. An old model may copy terminology literally while the new model rewrites for readability. An old model may interpret ambiguity conservatively while the new one fills gaps. These are not necessarily universally good or bad; they may no longer match the workflow contract.
“Upgrade” describes a provider's general capability or product direction. It is not a compatibility guarantee for every local use. Your inputs and quality criteria determine fitness.
Generative output can vary by design
Language models generally choose subsequent content probabilistically. Temperature, top-p, seed and serving implementation influence sampling. Even where an interface accepts a seed, it may not guarantee exact reproduction across hardware or model versions. Lower temperature can reduce variability without turning a model into an ordinary deterministic function.
Different wording does not necessarily mean different quality. Two answers can express the same conclusion; identical openings can conceal different figures. Regression tests should compare meaning and task outcome—required fields, factual correctness, calculation, citation, action selection and risk rules—rather than only character differences.
If exact wording is a true business requirement, keep fixed templates and deterministic logic outside the model and constrain the model to filling validated fields.
System instructions and safety policy can change outside your view
Hosted chat products continually adjust policy, interfaces and hidden instructions to improve safety and experience. Users usually cannot pin every backend condition. Material answered one day may later be refused, or the reverse. Format and depth may change for the same request.
This makes consumer chat appropriate for assistive work but unsuitable for critical automation that depends on undocumented behaviour. Formal workflows should use an interface with version and compatibility mechanisms, record service changes and acknowledge components that cannot be fixed.
OpenAI's API compatibility documentation notes that behaviour can change between model snapshots and recommends pinned versions and evaluations to monitor prompting behaviour. It distinguishes API schema compatibility from stable model output. OpenAI API: Backwards Compatibility
Tools and retrieval may change more than the model
A prompt that asks for a current price comparison depends on search index, web pages, time, region, connector permissions and extraction. The model can remain unchanged while external data changes, producing an appropriately different answer. An agent's revised tool description can alter the API or parameters it chooses.
Preserve external calls and returned content to determine whether a difference comes from model reasoning or the data environment. During model comparison, use a fixed offline retrieval set; during release evaluation, use live data to inspect the whole system.
Manage tool definitions like code dependencies. Adding a tool can affect behaviour even if it is not ultimately called, because its description enters context.
Long context and input order change emphasis
The same material in another order can attract different attention. Chunk size, overlap, retrieval rank and available context length move evidence to the beginning, middle or end. Long-context research has found substantial performance differences based on relevant-information position, so “everything was included” does not mean it was used identically. Lost in the Middle: How Language Models Use Long Contexts
A model upgrade may also change tokenisation, maximum context or how truncation behaves. Preserve input order and retrieved passages, and place critical evidence in explicit fields with precise citations instead of supplying an undifferentiated bundle of files.
Aliases and fixed snapshots carry different risks
Providers often offer aliases pointing to a current recommended version and may also expose fixed date or version identifiers. Aliases deliver improvements automatically and suit interaction or low-risk work. Fixed snapshots support testing, audit and controlled release, although they may eventually retire.
Google Cloud's generative AI lifecycle material distinguishes stable model versions, automatically updated aliases and lifecycle stages, including retirement. Names differ by platform, but the governance question is the same: Are you using a moving alias or a fixed version, and what is the replacement window? Google Cloud: Model versions and lifecycle
Pinning does not mean never upgrading. It turns upgrade into a planned event: test, address differences, approve and switch instead of discovering production change accidentally.
Prompts acquire hidden dependencies on a model
Prompts often evolve by trial and error around one model's habits: capitalised emphasis, three examples, “do not explain,” repeated format rules. A new model may ignore or invert these techniques. They form an undocumented interface dependency.
Write prompts as explicit contracts: task, input definition, output fields, required rules, prohibited behaviour, treatment of unknowns and examples. Validate structured output against a schema. Require sources for facts. Enforce permissions outside the model. The more that code can verify, the less the workflow relies on a model understanding hints.
Version the prompt together with the model. If the prompt is changed to suit an upgrade, historical differences cannot be attributed only to the model.
Build a regression set from real work
Do not test only ideal examples. Collect ordinary, boundary, ambiguous, long-input, missing-data, hostile-input and past-incident cases. Remove or protect personal data while retaining the structure that made them difficult. Define expected and unacceptable behaviour for each.
Measures should fit the use: classification accuracy, field completeness, citation support, calculation error, appropriate refusal, sensitive-data disclosure, correct tool selection, human amendment and handling time. For open text, use a rubric and blind human review rather than demanding identical sentences.
Retain “must not” cases as well: no payment, no sending, ask when data are insufficient, and never let an external document change authority. A weaker safety boundary matters more than a change in prose style.
Use shadow testing, staged release and rollback
First run the new version on the same input without affecting users or external state, comparing it with the old model. Then expose a small share of low-risk traffic while monitoring quality, refusal, cost, latency and reviewer burden. Expand only after predefined thresholds are met.
Preserve rollback across model, prompt, tool configuration and data schema. If the old model is already unavailable, prepare a reduced-function or manual fallback. Lack of rollback does not always prohibit an upgrade, but it requires smaller stages and stronger stop conditions.
Notify business owners of the change window, particularly where output enters official material or action. Users saying “the answers feel strange today” should not be the first monitoring system.
Separate acceptable variability from material regression
Changes in word order, examples and expression are often acceptable. More factual error, missing mandatory fields, overconfidence, unsupported citations, permission violations and runaway cost are material. Define tolerance first so a team neither rejects every upgrade for cosmetic difference nor disguises failure as a new writing style.
Diversity may be the goal for creative work. Stability matters more for regulatory mapping, data extraction and agent action. The same organisation can use distinct gates for each use.
Human adaptation matters too. Reviewers learn an old model's common errors; a new error distribution can invalidate their checklist. Upgrade testing should include the human workflow, not just offline output.
How to locate the cause after an update
Reproduce a known set and establish the scope. Isolate one variable at a time: fix retrieval, disable tools, use the same prompt version, clear conversation history and compare pinned model identifiers. Review provider change and retirement notices, while recognising that not every behavioural detail will be published.
Classify differences as knowledge, instruction following, format, reasoning, refusal, tool use or performance. The category determines whether to amend the prompt, add validation, retrain reviewers, roll back or accept the change.
One bad case does not prove the new model is globally worse, and an aggregate benchmark does not invalidate a local failure. Production fitness comes from your use-case evaluation.
My assessment: treat model behaviour as an external dependency
A team would not replace a core database version in production without tests. A moving model alias deserves similar discipline. A model is a probabilistic and partly opaque dependency, increasing the value of explicit contracts, versioning, evaluation and fallback.
Do not pursue impossible permanent stability either. Models retire, external information changes and the business moves. Mature governance makes change visible, measurable, approvable and recoverable.
Upgrade checklist
- Are full input, prompt template, model identifier, tools, retrieval and key settings recorded?
- Is the system using an automatically updated alias or a fixed snapshot, and when does it retire?
- Does the test set include real cases, boundaries, hostile input and historical errors?
- Do measures cover facts, fields, citations, safety, tools, cost and human amendment?
- Will shadow traffic and a small release compare versions before wholesale replacement?
- Are hard rules and permissions enforced by code rather than only written in a prompt?
- Do reviewers understand new error patterns and changed inspection priorities?
- Can the system roll back, pause automation or temporarily return to manual work?
Conclusion
The same visible prompt can produce different answers after a model update because full system conditions and probabilistic behaviour change. An upgrade can improve capability while breaking an implicit contract in a particular workflow. Pin versions where possible, preserve configuration, regress on real tasks, release in stages and retain fallback. That turns model change from a surprise into a governable software change.
Related questions
- Why Can a Confident AI Answer Be Completely Wrong?
- How Should You Preserve Sources, Versions and Edits in AI-Assisted Work?
Continue reading: All articles in How Far Should You Trust AI?
Discover more from Geoffrey Chen
Subscribe to get the latest posts sent to your email.