Prepare your AI workflow for a model change
A model retirement is easier to manage when a replacement can be tested against the workflow's recorded tasks.
An AI workflow may run for years after the model it first used has been retired.
I wrote the original GPT-5.1 note in November 2025 to consider how to divide tasks between fast responses and deeper reasoning. By November 2026, the launch details had become a maintenance question: what would a model change require us to change in the application?
OpenAI's November 10, 2026 deprecation notice schedules the GPT-5.1 API shutdown for April 1, 2027. The notice applies to that API dependency; other products with similar names have their own lifecycles. A workflow using the affected API needs a replacement before the deadline. OpenAI deprecations
Define each stage's task
A publishing workflow can begin with a voice transcript, pass through research, then produce an article for publication. A social post needs a separate output. Each stage has its own failure conditions: removing repeated words can change the speaker's meaning, while using a statistic requires evidence that it supports the claim.
Each stage needs an explicit contract. Transcript cleanup preserves the speaker's meaning. Research returns evidence with its uncertainty. Article writing uses that evidence without inventing anecdotes. Publishing accepts a validated document, then reports whether publication succeeded.
A task description continues to explain the node after a provider change. A model name tells a maintainer which dependency was chosen; the responsibility tells them which behavior an upgrade must preserve.
Select the model against that responsibility. GPT-5.1's API allowed configurable reasoning effort, so the workload could be tested with different settings. Requesting more reasoning still needed evidence that it helped the task. GPT-5.1 model documentation
Contain provider-specific code
A small application can put provider access in one module. The module receives application input, sends the request, then converts the provider's response into the application's result format.
Store model identifiers with their supported settings in that module. Business rules belong in the application. The publishing stage should receive an article title without having to parse a provider-specific response envelope.
The module needs to expose differences that affect behavior. Providers may support different input types or tool-calling conventions. Structured-output support can differ too, as can error reporting. A universal wrapper that hides those differences can leave downstream code handling them unexpectedly.
In n8n, normalize model output before the CMS branch receives it. Downstream nodes can then consume a defined article object. When the generation node changes, check that its output still satisfies the normalization stage's requirements.
Keep examples that detect regressions
An endpoint can return successfully while producing an answer the application cannot use. A replacement needs tests of the work itself.
Keep representative inputs with expected behavior. A content pipeline could use an article with an expired launch date or a brief containing an unsupported statistic. A transcript with digressions tests cleanup. A source with insufficient evidence tests whether the workflow limits its conclusion.
Automated checks can validate JSON with its required fields. Citation URLs can also be compared with the research notes. Editorial review has a different job: determine whether the rewrite kept the author's point without increasing the certainty of a claim.
OpenAI's evaluation documentation describes tests built around specified criteria with datasets. Define the application's acceptance criteria before comparing models; a general benchmark answers a different set of questions. Working with evals
Maintaining examples takes time. A small set also leaves gaps, so start with failures the application has encountered. Add a case when another failure reveals behavior the existing tests missed. The set needs regular review to remain useful.
Measure time to an accepted result
Generation latency leaves out the time spent repairing an answer. Measure the full interval from input to acceptance, counting retries with review time. For publishing, corrections made after publication belong in the measurement too.
METR's February 2026 update described selection problems in a follow-up developer study. Measurement problems also limited its ability to estimate the current speedup. METR called the evidence for its size weak. Both that update and the earlier study concern particular settings; applying either result to a purchasing decision requires comparing those conditions with your own. METR's experiment update
I prefer to compare configurations on my own tasks. Run the same inputs through both versions, then record each change in behavior with the checking time it required. Keep the previous configuration available until the replacement passes those checks.
Assign the next dependency review
A production model dependency needs an owner with a review date. Record which version ran, then monitor its lifecycle notices alongside the application's other dependencies.
My original GPT-5.1 note proposed routing tasks according to the reasoning they needed. I'd now give that routing decision a maintenance procedure: test a replacement against recorded examples before switching the workflow to it.
The dependency owner should know when the next review is due, even after the launch announcement is forgotten.