AI agents · OpenClaw · self-hosting · automation

Quick Answer

How to Switch LLM Providers Without Breaking Quality

Published:

The Short Answer

Six steps, in order, and the order matters:

  1. Build a frozen eval set — 100-300 real production cases
  2. Baseline the incumbent on it
  3. Shadow-run the candidate on live traffic, output discarded
  4. Compare on cost per task, never headline token price
  5. Cut over behind a flag — 5% → 25% → 100%
  6. Keep rollback wired for 30 days

The failure mode is skipping straight to step 5 because the new model is cheaper on paper. Quality regressions in LLM systems are silent — no exception, no alert, just slightly worse answers that surface as churn a month later.

Step 1 — Build the Eval Set Before You Look at Any Model

Sample 100-300 real cases from production logs. Not synthetic examples. Include the hard ones, the ambiguous ones, and the ones that generated support tickets.

For each case record the input, the current output, and a graded label — pass/fail for objective tasks, a 1-5 rubric score for subjective ones. Grade by hand or with a model-as-judge, but use the same grader for every candidate.

Then freeze it. An eval set that changes between candidates measures nothing.

Completion criterion: a version-controlled file of ≥100 cases with graded reference outputs, unchanged from this point forward.

Step 2 — Baseline the Incumbent

Run your current model against the frozen set and record the score. This is the number the candidate must beat, and it is almost never 100%.

Most teams discover their existing model scores 82% and their tolerance for the new one was implicitly 100%. Knowing the real baseline converts an unwinnable comparison into a fair one.

Record cost per task at the same time: 30 × (in_price/1000) + 5 × (out_price/1000) for a 30K-in/5K-out shape, adjusted to your actual token mix.

Completion criterion: a single baseline quality score and a baseline cost per task, both written down.

Step 3 — Fix Format Drift Before Blaming the Model

Most “the new model is worse” findings are prompt-format problems, not capability problems. Check these four before drawing conclusions:

System prompt handling. Providers weight system instructions differently. A prompt tuned over months against one model is, in effect, overfitted to it.

Structured output. JSON mode, tool-call schemas and stop sequences differ. A model that emits perfect JSON on one API may wrap it in prose on another. This looks like a reasoning failure; it is a formatting failure.

Reasoning-mode defaults. Some models think by default, some on request, and at least one — GLM-5.3 — makes thinking mandatory. This changes latency, output-token count and cost, not just quality.

Tool-calling conventions. Schema formats and multi-tool-call semantics diverge. Agent loops break here first.

Completion criterion: the candidate produces well-formed output on ten hand-checked cases before you run the full eval.

Step 4 — Compare on Cost Per Task, Not Token Price

Headline per-MTok rates are close to meaningless across providers. Four things distort them:

Tokenizer differences. Claude 4.7 and later use a newer tokenizer producing roughly 30% more tokens for the same text than Sonnet 4.6 and earlier. A price that looks 20% lower can be 10% higher in practice.

Invisible reasoning tokens. Thinking tokens are billed and usually not shown. A model that reasons more costs more at an identical headline rate.

Time-of-day pricing. DeepSeek has charged peak/off-peak since August 16, 2026 — peak (01:00-04:00 and 06:00-10:00 UTC) is exactly double off-peak. Your geography decides your real price.

Promotional rates. GPT-5.6 Sol’s August 21, 2026 cut to $4/$20 was reported as promotional for roughly three months. Gemini 3.7 Flash’s $0.75/$3.75 intro reverts to $1.50/$7.50 on January 1, 2027. GLM-5.3-Flash’s 50% launch discount ends September 9, 2026.

Budget at the post-promotional rate. Migrating onto a promo price and migrating off again six months later costs more than never moving.

Completion criterion: a cost-per-task figure for both models using your measured token counts at post-promotional rates.

Step 5 — Shadow-Run on Live Traffic

Offline evals miss distribution drift. Send a slice of real traffic to both models, serve only the incumbent’s response, and log both.

Run for at least a week — long enough to cover a weekend, a Monday, and whatever your weekly traffic shape is. Compare on quality-sampled outputs, p50 and p99 latency, error and timeout rate, and real blended cost.

Watch p99 latency specifically. Median latency is usually fine on a new provider; the tail is where capacity problems and rate limits live, and the tail is what users actually notice.

Completion criterion: seven days of paired logs with no unexplained gap in quality, latency tail, or error rate.

Step 6 — Cut Over Behind a Flag, Keep Rollback Wired

Ramp 5% → 25% → 100%, holding at each stage long enough to see a full traffic cycle.

Keep the old provider’s credentials, code path and quota live for 30 days. A rollback that requires a deploy is not a rollback.

Instrument three things and alert on each:

  • Quality proxy — thumbs-down rate, retry rate, escalation rate
  • Cost per task — actual, daily, not projected
  • Error and timeout rate — by model

Completion criterion: 100% of traffic on the new provider, 30 days elapsed, no alert fired, old path then removed.

The Structural Fix: A Thin Abstraction

Put every model call behind one function that takes a model identifier and returns text. Then switching is a config change, not a refactor, and shadow-running is trivial to implement.

Keep it thin. Heavy abstraction frameworks hide the provider-specific features — prompt caching, structured output modes, extended thinking controls — that are frequently the reason you picked a provider. A leaky, thin abstraction beats a complete, opaque one.

The teams that migrate easily in 2026 are the ones who built this before they needed it. Given that the frontier reshuffles roughly quarterly and prices moved four times in the last two months alone, assume you will migrate again within six months and build accordingly.

Sources