Stop hardcoding model names: a switching and fallback guide for vibe projects

The core idea: depend on capability tiers, not on a model's name

Almost every vibe project that calls a large language model API will one day hit the same wall: the model that worked fine yesterday is suddenly slow, rate-limited, repriced, or announced for deprecation. In October 2026 alone, GitHub previewed the mid-November deprecation of a batch of Copilot models. Model deprecation is not a rare event in this industry; it is the normal state of affairs. If you hardcode model names throughout your code, your prompts, and your user-facing interface, every change becomes a site-wide rework.

This guide offers one core method: inside your product, only capability tiers exist, and model names appear only in a single routing table in configuration. Tiers might be "fast and cheap," "balanced," and "deep reasoning." The routing table decides which model serves each tier today, who it falls back to, how many retries are allowed, and how long to wait. When a model changes, you edit one line of the routing table. The user interface, the business code, and the prompt templates do not move. The example project and configurations in this article are fictional and exist only to illustrate the method.

Step one: define three capability tiers, not a list of models

Before choosing models, define what capabilities your product actually needs. Three tiers cover almost every vibe project: a fast tier for classification, tagging, title generation, and summaries, tasks where an error is tolerable and speed matters; a balanced tier for everyday conversation, rewriting, and question answering; and a reasoning tier for complex calculations, long document analysis, and multi-step planning, tasks where an error is expensive and waiting is worth it. Each tier needs three hard numbers written down: the maximum acceptable latency, a per-call cost ceiling, and a quality floor, for example, the reasoning tier must never produce a malformed output.

Take the fictional example project "Ledger Pal," an app that helps small shop owners organize invoices and cash flow. Invoice classification runs on the fast tier, with results in under three seconds and cost kept to a minimum. Monthly business questions run on the balanced tier. End-of-month reconciliation and anomaly investigation run on the reasoning tier, allowed to take up to thirty seconds, but every number must be verifiable. Once tiers are defined, business code only ever names a tier, for example call_model(tier="fast", ...), never a specific model. Three months later, swapping the fast tier from model A to model B touches zero business code.

A common anti-pattern is tier inflation: starting with eight tiers, "creative," "rigorous," "humorous," and so on, until nobody remembers what distinguishes them and the routing table becomes unmaintainable. Tiers are a contract for the system, not marketing copy for users. Start with three, and add one only when three genuinely prove insufficient.

Step two: one routing table owns every switching decision

The routing table is the single source of truth for this design. Keep it in a standalone configuration file, or a table in an admin console, with at least these fields per tier: the primary model, the fallback chain in order, a per-call timeout, a maximum retry count, and a per-minute budget. Before each call, business code asks the routing table exactly one question: "Who should the fast tier call right now?" The table answers, and nothing else matters.

In the fictional example, the fast tier's primary is M1 with a fallback chain of M1, then M2, then M3. The balanced tier's primary is M4 with a fallback to M5. The reasoning tier's primary is M6 with a fallback to M4, a deliberate step down in capability but a guarantee of availability, and the reasoning tier must tell the user when it steps down. Note that the reasoning tier has no same-level backup, because deep reasoning capacity is itself scarce. Stepping down honestly is the right choice; pretending nothing changed is deception.

The routing table should also support per-task tuning within a tier. The same fast tier can have different timeouts and retries for different tasks: invoice classification may retry twice, but live autocomplete suggestions while the user types may retry only once, because the user is waiting on every keystroke and an extra retry is extra stutter. Write those differences into the routing table, not into if-statements scattered through business code, or nobody will dare touch them in six months.

Step three: classify failures. Only retry what retrying can fix

A fallback chain is not simply "on failure, try the next one." First, classify the failure. Rate limits (429), server errors (5xx), and timeouts are retryable: switching models might help. Bad requests (400), authentication failures, and content policy refusals are not retryable: switching models will not help at all. For non-retryable failures, the correct action is to return a clear error immediately, not to burn through the whole fallback chain, tripling cost and tripling user waiting time for nothing.

Second, give retries a budget: cap total retries per user request, two to three is a good default, and cap total elapsed time, no more than twice the tier's latency ceiling. Retries without a budget become a retry storm during an upstream outage: each of your requests becomes three requests, the upstream gets slower, you retry more, and the whole service collapses together. Put the budget in the routing table and enforce it in the calling layer, so business code never needs to know retries exist.

Third, idempotency and deduplication. If a call performs a write, such as placing an order, recording a transaction, or sending a message, you must confirm before retrying whether the previous attempt already took effect, or the "retry" becomes a duplicate execution. The simplest protection is an idempotency key per business operation, with the server deduplicating on that key. A write operation without idempotency protection should not enter an automatic retry chain at all. Better to return "please retry manually in a moment" than to hand the user two identical charges.

Step four: when a fallback happens, the user should see it

The biggest user experience mistake in fallback design is silent degradation. A user paying for the reasoning tier gets an answer from the balanced tier, notices only that "this answer feels dumber than usual," and loses trust in the product, while you never learn which response cost you that trust. The correct approach is tiered transparency. For free or low-tier tasks, a small note in a corner of the interface is enough. For paid or reasoning-tier degradation, say so explicitly, for example: "Completed with the balanced model because the reasoning model is temporarily unavailable. This run does not count against your reasoning quota."

Transparency needs a compensation rule, written in advance, not invented on the spot: does a reasoning-tier fallback refund quota, can the user choose to "wait and rerun with the reasoning tier," and is a fallback result labeled as generated by a backup model? Those rules belong in your help documentation, not in a support agent's improvised reply. Users can accept "temporarily degraded." They cannot accept "kept in the dark."

Continuing the fictional example: when Ledger Pal's month-end reconciliation falls back from the reasoning tier to the balanced tier, the interface does three things at once: a banner explains the fallback, the result is labeled with its tier, and the run does not consume reasoning quota, with a "recompute when recovered" button offered. All three are required. Miss any one, and the user feels quietly shortchanged.

Step five: prompts and tool calls are not portable across models by default

The easiest place to fail when switching models is not the routing table but prompt and tool-format differences. Models differ in how strictly they follow system prompts, how reliably they produce JSON, and how they support tool calling. A prompt that performs perfectly on the primary model can produce format errors, missing fields, or refused tool calls on the backup.

Three practices address this. First, decouple prompt templates from models: templates state only the task requirements, never assumptions tied to a specific model, and model-specific format requirements, such as a JSON mode switch or a thinking-budget parameter, live in the routing table's model configuration. Second, give each tier a "validate format, attempt one repair" mechanism: if output fails validation, try a rule-based repair once, and only fall back if repair fails, rather than handing dirty data to the user. Third, run regressions after any model switch: keep twenty to fifty representative cases per tier, record the primary model's outputs as a baseline, and compare case by case after switching. If differences exceed your threshold, do not ship.

Context length is another invisible difference. A primary model supporting 200k tokens and a backup supporting only 32k will break long-document tasks outright on switchover. The routing table should record each model's context limit, and the calling layer should check input length before sending, truncating or routing through a summarization step when over the limit, instead of waiting for an upstream error.

Step six: cost and observability. An unlogged switch is a switch that never happened

Every call must log four things: which tier requested it, which model actually served it, how long it took, and what it cost, in money or tokens. Without those four records, you cannot answer three essential questions: why last month's bill went up, whether a quality dip coincided with a fallback, or how much traffic a backup model actually carried. Logs must land in a log store or a data table, not scroll past in a console and vanish.

With records in place, three high-value practices become possible. First, a cost dashboard by tier, by model, and by task, so abnormal cost movement is visible the same day, not when the monthly bill arrives. Second, fallback-rate alerts: if a tier's fallback rate crosses a threshold, say five percent, alert someone, because either the primary model is in trouble or the routing configuration needs adjusting. Third, a monthly review: look at each tier's actual model distribution and ask whether the backup has quietly become the de facto primary. If it has, the primary selection is wrong and should be formally changed, rather than living on the fallback chain forever.

Pre-launch drills: rehearse the failure before it happens

Before shipping this design, run four drills, none of which requires a real outage. First, a forced-fallback drill: temporarily point the primary at an address guaranteed to fail, and confirm the chain reaches the backup, the user sees the notice, and the retry budget holds. Second, a timeout drill: set a very short timeout and confirm slow requests are cut off promptly instead of hanging forever. Third, a long-input drill: send an over-long document to the backup model and confirm truncation or summarization catches it. Fourth, a billing drill: simulate a traffic peak and confirm the cost dashboard reflects call volume in real time rather than by after-the-fact reconstruction.

The point of drills is not to prove the system perfect. It is to turn "the first real failure" into "the second rehearsal." The first real failure happens at night, while users are active and you are asleep. A drill happens in daylight, while you can read logs calmly. The cost difference between the two is an order of magnitude.

When not to build automatic switching

Model switching is not mandatory for every product, and three cases argue for holding off. First, a product with a single model call site where quality is extremely sensitive, such as legal document generation: switching models there is a product change requiring review, not something to automate, and the right behavior on failure is a clear error with queued retry, not a quietly substituted model. Second, latency-critical realtime scenarios, such as streaming voice conversation, where the extra latency of a fallback chain may be worse than the failure itself; fast failure with a clear message is better. Third, compliance-constrained scenarios, such as medical or financial auditing, where a locked model version may be a contractual commitment; confirm the compliance boundary before building any switching.

The test is a single question: is fallback output still above your quality floor? If the answer is "we don't know," do not automate the fallback. Offer it as a manual option, or stick to manual switching. Automatic fallback is justified only after regression cases have validated the backup model's quality. Automatic fallback without validation is not resilience. It is gambling.

Anti-patterns: six things not to do

To close, six anti-patterns to check your code against. First, model names scattered through business code, so changing models means a site-wide search and replace. Second, unbounded retry chains that knock your own service over during an outage. Third, running non-retryable errors through the fallback chain, burning money and time for nothing. Fourth, silent degradation on paid tiers, destroying trust the moment users notice. Fifth, switching models without regression runs, letting format errors reach users directly. Sixth, no call records, so a rising bill cannot be attributed to anyone. If any one of these is true, model switching is not really in place yet. If all six are avoided, your product has the infrastructure to survive in an industry where models change fast.

Appendix: a minimal routing table template

Here is the field list from this guide, condensed into a template you can copy, with fictional values. One record per tier: tier name, primary model, fallback chain, per-call timeout in milliseconds, maximum retries, total per-request time cap, context limit, whether fallback is allowed, whether fallback must notify the user, and a per-call cost ceiling. A fast-tier example: primary M1, fallback M1 then M2, 8-second timeout, 1 retry, 15-second total cap, fallback allowed without mandatory notice. A reasoning-tier example: primary M6, fallback M6 then M4, 60-second timeout, 1 retry, 120-second total cap, fallback allowed but must notify the user and waive reasoning quota.

The key property of the template is "change the table, not the code." Adding a backup model, adjusting a timeout, or replacing a primary should mean editing configuration and reloading it, not redeploying business code. Configuration changes need their own audit trail: who changed the primary from M1 to M2, and when, so problems can be traced. Many teams start with a config file and grow into an admin console, which is a healthy evolution. What is unhealthy is routing logic living in three places, where changing one misses the other two.