Three teams that changed models cut retries, a repair loop and separate routing calls. None of them removed the checks that compare output with something outside the model, and the work they saved reappeared as validation, boundary checks and cost routing. Their accounts point to a sorting rule. Code written to work around the old model's failures can go once your own replay shows it no longer fires. Code that checks output against the world, or gates an irreversible action, stays.
\nAt Cliprise, an image or video could come back from the generation models in the wrong style or with the wrong composition. When that happened, the pipeline used to rewrite the prompt and run the job again. Kruno Sulić, founder and SaaS product builder at Cliprise, said in a written response to PSEEDR that his team cut back this \"repair loop\" after moving to newer image and video generation models over the past 12 months. The first output now stands more often, and the software will \"only trigger follow-up logic when a simple validation check fails.\"
\nHe did not delete the loop. Cliprise kept moderation, output validation and usage controls. \"We removed some orchestration, not the need for orchestration,\" he wrote. He named no model versions or dates and gave no figures.
\nHis sentence describes the decision in front of any team that switches models. A stronger model makes some wrapper code idle and leaves other wrapper code exactly as necessary as before. Both kinds sit in the same pipeline, sometimes in the same function, and a launch post does not say which is which. What separates them is why the code was written. Code that worked around the old model's failures can go, but only after your own measurement shows it has stopped firing or stopped helping. Code that checks output against the world, or gates an action that cannot be undone, stays, because a better model does not change why it exists. Two other teams, at TEK Systems and CISIN, drew a similar line when they changed models. In all three accounts, the saved effort moved somewhere else rather than disappearing.
\nSulić's case is a useful start partly because of what it does not claim. He described \"the strongest measured outcome on our side\" as operational: fewer moving parts to monitor, fewer edge-case retries and less time spent retuning prompt-routing logic after each model change. He also reported lower average end-to-end generation time \"because fewer requests entered a retry cycle,\" and a better cost per successful asset, though he would describe the maintenance benefit \"as more directly observed than any single universal cost figure.\" His models generate images and video, not text, so the text-model vendor guidance later in this piece does not explain why his outputs improved. What his case shows is structure. The check stayed, and the repair it triggers became an exception instead of a routine.
\nMost code around a production model exists for one of two reasons.
\nThe first is compensation, meaning workarounds for failures the old model made predictably. To absorb those failures, teams built retries, prompt-rewrite loops, blocks of step-by-step instructions, or separate calls to extract fields the model could not reliably produce alongside its answer. This code is aimed at the model's error rate. When a stronger model lowers that rate, the reason for the code weakens, and the code may stop doing anything useful.
\nThe second is contact with the world. Some facts lie outside the model: whether a tool call's arguments satisfy business rules, whether a database write is authorized, what a request actually cost, whether an output passes a deterministic test. Code that checks these facts does not exist because the model was weak. It exists because the model cannot see or vouch for these facts at all. Anthropic's guide Building effective agents, in the current version of a post first published in December 2024, states the agent's side of this plainly: during execution, \"it's crucial for the agents to gain 'ground truth' from the environment at each step.\" For coding agents it adds that \"whereas automated testing helps verify functionality, human review remains crucial for ensuring solutions align with broader system requirements.\"
\nKarmendra Pandey, practice architect in the AI and ML practice at TEK Systems, described a migration that split along this line. In a written response to PSEEDR, he said his team moved its production agent workflows from Anthropic's Claude Sonnet 4.5 to OpenAI's GPT-5.1 in August 2026. They \"stripped out our programmatic retry logic,\" which he attributes to GPT-5.1 handling multi-step structural instructions on the first pass. They also kept two things: \"We retained our deterministic evaluation gate and cost accounting infrastructure.\"
\nThe pairing matters more than either half. A deterministic gate is what lets a team see whether its retries have gone idle. Without one, deleting retries is a bet on a launch announcement. With one, any first-pass failures keep showing up in the gate's results after the retries are gone. Pandey did not say what his workflow now does when the gate rejects an output. That path is the one to design before the retry disappears.
\nKuldeep Kundal, founder and CEO of CISIN, kept a different kind of check. In his written response to PSEEDR, he said his team kept human-in-the-loop verification \"for any action involving database writes or financial transfers, as no level of model reasoning replaces the need for an enterprise audit trail.\" His reason is not about how often the model errs. A model that never made a mistake would still leave an organization needing a record of who approved a transfer. Anthropic's current prompting guidance offers a prompt-level version of the same caution. In a sample prompt written for Claude Opus 4.6, aimed at teams that want the model to confirm before risky steps, it tells the model to ask the user before proceeding with actions \"that are hard to reverse, affect shared systems, or could be destructive.\" That is an instruction to the model, not a system gate. It does show the model's maker treating irreversibility as a reason to pause, not as a capability gap that a better model closes.
\nApplied component by component, the distinction looks like this:
\n| Component | \nWhy it was built | \nDoes a stronger model remove that reason? | \nIn these accounts | \n
|---|---|---|---|
| Unconditional retry or repair loop | \nOld outputs often missed | \nOften, but confirm by measurement | \nReduced at Cliprise; removed at TEK Systems | \n
| Validation check that decides whether to repair | \nSomeone must know whether the output meets the requirement | \nNo | \nKept at Cliprise; deterministic evaluation gate kept at TEK Systems | \n
| Emphatic or step-by-step prompt instructions | \nOld model under-used tools or lost the thread | \nOften; on some newer models, keeping them causes overtriggering or extra work | \nVendor guidance (next section) | \n
| Separate classify, extract and select calls | \nOld model could not do them reliably in one pass | \nSometimes, but the inspection points go with them | \nCollapsed at CISIN | \n
| Human approval on writes and transfers | \nIrreversibility and audit | \nNo | \nKept at CISIN | \n
| Cost accounting | \nSpend is a fact about the world | \nNo; it matters more if the new model costs more | \nKept at TEK Systems | \n
Many real components mix the two purposes, and that is where the useful work is. Sulić's repair loop combined a check (did the output meet the brief?) with a repair (rewrite the prompt and run it again). The repair was compensation. The check was not. Splitting them let him keep the second and shrink the first.
\nRetry code that never fires mostly costs maintenance. Prompt-level compensation is different, because it acts on every request. Instructions written to push an older model can push a newer one too far.
\nAnthropic's prompting guidance documents this on its own models. For Claude Opus 4.5 and Opus 4.6, it warns: \"If your prompts were designed to reduce undertriggering on tools or skills, these models might now overtrigger.\" Its fix is to soften emphatic wording such as \"CRITICAL: You MUST use this tool when...\" into ordinary instructions. Under the heading \"Tune anti-laziness prompting,\" its migration notes say Claude 4.6 models \"might overtrigger on instructions that were needed for previous models.\" For Claude Opus 5, it says verification instructions carried over from prompts tuned for earlier models \"can cause over-verification, adding tokens and latency,\" and advises removing them rather than rewriting them.
\nThe same kind of instruction can help on one model and cost on another, even within one vendor's line-up. Anthropic's page generally recommends self-checks, suggesting a line such as \"Before you finish, verify your answer against [test criteria],\" which it says \"catches errors reliably, especially for coding and math.\" Claude Opus 5 is the stated exception. OpenAI's GPT-5.1 prompting guide, dated November 13, 2025 and now marked as archived, makes a similar case for its model. In its section on running GPT-5.1 with reasoning set to none, it reports that on longer executions, \"encouraging the model to 'verify' its outputs results in better instruction following for tool use.\" For other behavior problems after a migration, it says \"you should be able to shape the behavior significantly by checking for conflicting instructions and being clear.\"
\nAnthropic's page states the conclusion directly: \"Where a technique names a specific model, treat it as measured on that model and re-check it against your own evals before applying it to another.\" Verification prompts, like emphatic tool instructions, are tuned to a particular model. A team that switches vendors, as Pandey's did, inherits prompts written for a model it no longer runs, and neither guide covers that crossing. OpenAI's migration advice addresses teams coming from GPT-5 and GPT-4.1.
\nThe limit of this evidence is worth stating once. These are vendors describing their own models on current pages, not records of what the three teams experienced. None of the three contributors reported a prompt that misfired after the switch. The guidance shows why keeping old scaffolding \"to be safe\" has a cost. It does not say how large that cost is in any given system.
\nKundal's change went further than retries. His team's older pipelines made separate model calls for intent classification, JSON extraction and tool selection, which he called \"a brittle chain where a single failure point compromised the entire process.\" In his account, one call replaced the chain: \"Modern models now handle intent discovery and tool selection in a single inference pass.\" The team removed its hard-coded routing logic and parameter-extraction wrappers. He counted maintenance as the largest gain: removing \"hundreds of lines of brittle orchestration code\" let his engineers stop building agent plumbing and focus on the quality of the data the agent accesses.
\nHe reports two numbers: a 30 percent reduction in end-to-end latency \"by eliminating multiple API round-trips,\" and a 15 percent decrease in total cost per completed task, even though cost per token rose, \"because the models reached the correct output on the first attempt more consistently.\" He did not say whether these figures were measured or estimated, over what period, or on which models. They are his reported results.
\nTwo things in his account are useful regardless of the exact figures. First, the latency gain has two causes that a team should keep apart. A stronger model made the single pass possible, but the time saved comes from fewer network round trips, which is an architecture change. Second, the cost result depends on the denominator. A pricier model can raise cost per token and still lower cost per finished task if fewer tasks need a second attempt. A team that tracks only token price would read the same switch as a loss.
\nWhat merging costs is less visible. A chain of separate calls produces intermediate outputs: an intent label, an extracted JSON object, a chosen tool. Each is something a program can check. Anthropic's agents guide describes adding programmatic checks, or \"gates,\" to the intermediate steps of a prompt chain \"to ensure that the process is still on track.\" Its prompting page says explicit chaining is still useful \"when you need to inspect intermediate outputs or enforce a specific pipeline structure.\" When the chain collapses into one pass, those inspection points disappear with it.
\nKundal's team added checks at a different place. \"While we removed the manual routing code, we introduced system-level checks to ensure the model does not hallucinate tool arguments that bypass our business logic,\" he wrote. They also added an observability layer to watch for what he called \"reasoning drift.\" The check moved from between steps to the point where the model's output touches the business system. That is a sensible place for it, because tool arguments are where a wrong decision becomes a real action. But it is new code, and it exists because an old inspection point was removed.
\nPandey's team added a layer as well. \"To mitigate the flagship model's pricing, we implemented a semantic tiered routing layer at the system entry point,\" he wrote. Under it, \"simple queries hit the lightweight tier, while GPT-5.1 handles complex edge cases.\"
\nHis case is also a reminder that an \"upgrade\" is not always a jump in model generation. Claude Sonnet 4.5 was released in September 2025, and OpenAI's GPT-5.1 prompting guide is dated two months later. His team switched in August 2026 and described the work as balancing \"capability against production unit economics.\" He reports that first-pass validation success rose sharply and that net production costs fell, but gives no figures or measurement method.
\nRouting by difficulty is a documented pattern. Anthropic's agents guide lists \"routing easy/common questions to smaller, cost-efficient models\" and harder ones to more capable models. It also states the condition: routing works \"where classification can be handled accurately.\" That condition is the catch. A router is a classifier, and its mistakes have a particular shape. A hard request sent to the lightweight tier gets a weaker answer at a lower price, and nothing fails loudly.
\nThe two accounts make an instructive pair. Kundal's team deleted an intent classifier because one model pass could do the job. Pandey's team added a difficulty classifier because one model was too expensive to use for everything. These classifiers have different jobs, so there is no contradiction, but each new classifier needs some way to be checked. In Pandey's setup, the deterministic gate and cost accounting he kept are the instruments that could show whether routing sends work to the right tier. He did not describe how his team monitors the router, so that connection is PSEEDR's inference, not his report.
\nSulić described the same movement in product terms. In his words, the work shifted from \"force the model into compliance\" toward \"lightweight validation, better defaults, and product-level controls.\" Across the three accounts, the effort went to validation and defaults at Cliprise, to boundary checks and drift monitoring at CISIN, and to cost routing at TEK Systems. Three accounts do not make a general rule. They do suggest that a team should plan for new work after a switch, rather than count the deleted lines as pure savings.
\nNone of the three contributors supplied before-and-after evaluations. The procedure below is PSEEDR's synthesis of their accounts and the vendors' guidance, not a method any of them described.
\nAnthropic's agents guide gives a rule for building: \"you should consider adding complexity only when it demonstrably improves outcomes.\" The same standard works in reverse for deletion. Remove a component when measurement shows it no longer improves outcomes, not when a launch post suggests it might not.
\nAfter a model switch, the code you can delete is code that existed to absorb the old model's errors: unconditional retries, repair loops, emphatic prompt instructions and, in some cases, separate calls the model can now merge. Delete it after your own replay shows it has stopped firing or stopped helping, and turn retries into on-failure retries first. Keep the code that compares output with something outside the model, and keep the gates on irreversible actions, because a better model does not change why they exist. Then expect to add something: checks at the new boundaries where merged calls touch your systems, a way to verify the router if you introduce one, and cost tracking per completed task.
\nOne question remains open after these accounts. Some retries were never catching model errors. They were covering a flaky dependency, a timeout or a rate limit, and deleting one after an upgrade would remove protection the model never provided. How should a team tell from its own logs which retries were catching the model and which were catching the world, before it deletes either?
\nHow this was reported: The three cases come from written responses to PSEEDR by the named contributors. PSEEDR did not test their systems or reproduce their results. None of the three described a commercial relationship with a model vendor in their responses. Vendor documentation is quoted from the current versions of the linked pages, which change as models ship.
\n", "articleImage": { "url": "https://content-edge-frzs2wwjiq-uc.a.run.app/assets/article-covers/after-a-model-upgrade-delete-the-workarounds-and-keep-the-checks.1d987da9.jpg", "width": 1280, "height": 720, "alt": "A dark blue machined block with temporary clamps removed and a steel inspection gate kept at its output, under the words \"Delete workarounds. Keep checks.\" and the PSEEDR wordmark." }, "image": { "@type": "ImageObject", "url": "https://content-edge-frzs2wwjiq-uc.a.run.app/assets/article-covers/after-a-model-upgrade-delete-the-workarounds-and-keep-the-checks.1d987da9.jpg", "width": 1280, "height": 720, "alt": "A dark blue machined block with temporary clamps removed and a steel inspection gate kept at its output, under the words \"Delete workarounds. Keep checks.\" and the PSEEDR wordmark." } }