Through OrcaRouter the base model and the tuned build are one key and one model string apart, which makes moving traffic to Qwen3.8 Flash Next for security work a one-line change in most clients and a four-part audit everywhere else. They share an output ceiling, a modality list and a tokenizer, and differ on price, window, cache economics and refusal behaviour [OURS].
The four differences are what a migration plan has to cover.
One: the price multiplies on input
$0.15 to $0.80 on input is 5.33×; $0.47 to $1.60 on output is 3.40×. Blended at 3:1 the move is $0.230 to $1.00 per million [OURS].
For budgeting that is simple arithmetic on your current spend. For a product with a per-request cost ceiling, it may be a decision point: a pipeline designed around $0.23 per million does not necessarily tolerate $1.00.
Two: the window shrinks to a quarter
262,144 against 1,000,000. Any request that currently sends more than a quarter of a million tokens will start failing — not degrading, failing, because the API rejects inputs over the limit.
The migration audit is therefore a query: what share of your traffic in the last 30 days exceeded 262,144 input tokens? If the answer is a fraction of a percent, route those requests to the base model and send everything else to the tuned build. If it is ten percent, the split pipeline is doing real work and needs a design, not a flag.
Three: the cache economics change
The base prices cache reads at $0.0184 per million and cache writes at $0.23. The tuned build prices reads at $0.15 and lists no write rate [OURS]. Reads are 8.15× more expensive; writes, if they are billed at all, need checking against your first invoice rather than assumed.
For an agent loop with a large stable prefix, this is the difference between a cheap and an expensive architecture. A million-token prefix at ninety percent cache hits costs 0.1 × $0.15 + 0.9 × $0.0184 = $0.0316 on the base and 0.1 × $0.80 + 0.9 × $0.15 = $0.215 on the tuned card — a 6.8× gap that no other lever closes.
Four: refusals stop
This is the reason for the move, and it is also the one difference that cannot be verified from a page. Sample two hundred of your real prompts, run them against both models, and count.
Two outcomes matter: requests the base declined and the tuned build completed, and requests the tuned build handles differently in ways you did not want — a looser answer where you needed a guardrail, for example. Both belong in the report that justifies the migration.

The migration checklist
Six items, in the order they bite.
- Measure the long-tail inputs. The percentage of requests over 262,144 tokens decides whether you need a routing rule.
- Check the gate. Access requires an engagement, a passkey and acceptance of the terms; start it early [OURS].
- Re-price the budget at the blended rate, not the headline input rate.
- Re-tune the cache strategy. Shorter prefixes, or accept the higher read rate.
- Set a fallback for requests that exceed the window, pointing at the base model on the same key.
- Log refusals on both models for a week. The delta is the migration’s justification.
What to leave on the base
Three workloads should not move, whatever the tuning buys.
Anything routinely over 200,000 tokens. The window is the constraint, and splitting is a redesign.
Anything that never gets refused. You would be paying 5.33× for identical behaviour.
Anything whose outputs feed a compliance trail that has already been validated. Re-validating a regulated pipeline costs more than the model change saves.
Everything else is a candidate, and the routing rules are simple enough to express in a config file rather than code.
What the rollback looks like
Keep the old model string behind a flag that can be flipped without a deploy. A one-day-old card is not a place to be brave, and the cost of the flag is a few lines of configuration.
The same key reaches both models, so the rollback path and the rollout path are the same code with a different constant [OURS]. That symmetry is worth preserving: if rolling back requires a release, the migration is riskier than it needs to be.
Write down what would trigger the rollback before you ship. A failure-rate threshold and a rework-rate threshold are enough, and having them decided in advance is the difference between a decision and an argument.
What to tell the people paying for it
A 5.33× input multiple is easy to approve as a line item and hard to defend when someone asks what it bought.
Prepare the answer before the migration, in the same units the budget uses. Not “the model refuses less” but “we removed N refusals per thousand requests, which previously cost M retries and K minutes of analyst time”. The arithmetic from the sampling step is exactly this, and it is worth doing even if nobody asks.
The framing also protects against the opposite mistake: if the sampling shows the refusals were rare, the honest recommendation is not to migrate, and having the number makes that a decision rather than a preference.
Bring the sampled prompts to that conversation too. A list of twelve requests the base model declined, with the tuned build’s answers beside them, is more persuasive than any percentage — and it doubles as the regression set you will run against the next candidate.
Keep that list afterwards. It is the artefact that makes the next model release a comparison instead of a fresh evaluation, and it costs nothing to maintain once it exists.

The takeaway
The switch is a string in a config and four audits in a spreadsheet: price, window, cache, refusals. Three of the four are on the model page; the fourth needs your own sample.
Move the traffic that needs the tuning, keep the giant inputs on the base, and route between them — the same key reaches both, which makes the split cheap to build and cheap to undo.
The migration is finished when nobody is thinking about it any more — when the routing rule is boring, the fallback has never fired in a week, and the cost line is stable enough that finance stopped asking. Until then it is still a project, whatever the config says.
Sourcing note: prices, cache rates, context windows, output ceilings and the access gate are OrcaRouter catalogue data, checked 2026-10-27 [OURS]. The cache arithmetic is computed on those rates at the stated hit rate. No latency, throughput or benchmark figures are used, because the tuned card’s production sample is 1,345 tokens [OURS].

