Routing discipline: which model runs which job

A week with four significant model releases in it is now an ordinary week, and the lineups have got long enough that this is arithmetic rather than atmosphere. Anthropic’s public price list carries 17 models today [1]. Google’s Gemini model page lists 11 stable models alongside 8 more in preview [6]. Every one of those entries is a decision you are making implicitly, every time you send a request, whether or not you ever think about it.

The two obvious reactions are both expensive. If you tune the whole thing out, you keep paying premium rates for jobs a cheap model does identically, and one day a model you depend on stops answering. If you re-evaluate everything each time a headline lands, you spend more hours comparing models than using them, and you make the decision on someone else’s test set instead of your own. What actually decides your bill and your output quality is narrower and duller than either: which of your jobs go to a cheap model, which go to an expensive one, and whether you have anything of your own to check that with. This guide is about setting that up once. It is not for people building a product where model selection is the product, and it is not for teams already running formal evaluation pipelines. It is for one person, or five, who send a few hundred or a few thousand requests a day and would like to stop re-litigating the choice.

Three lanes cover almost everything you send a model

Stop thinking in vendors and start thinking in tiers. Every major provider now sells the same three-step ladder, and inside a single vendor the gap between the bottom step and the top step is around an order of magnitude.

On Anthropic’s own price list, Claude Haiku 4.5 costs $1 per million input tokens and $5 per million output, Claude Sonnet 5 costs $2 and $10, and Claude Fable 5.1 costs $10 and $50 [1]. That is a tenfold spread from bottom to top without leaving one vendor. OpenAI’s ladder is steeper: GPT-5.6 Luna at $0.20 and $1.20, GPT-5.6 Terra at $2 and $12, GPT-5.6 Sol at $5 and $30, which is twenty-five times the input price from bottom rung to top [2]. Google’s stable range includes Gemini 3.5 Flash-Lite at $0.30 and $2.50, Gemini 3.8 Flash at $0.75 and $3.75, and Gemini 3.5 Flash at $1.50 and $9 [3]. Those numbers do not line up neatly across vendors at any given tier, and it does not matter, because the choice that moves your money is which tier a job sits in rather than whose logo is on it.

So decide the lane, not the logo. The cheap lane takes the work where the answer is short and the shape is known: classification, tagging, extracting fields from a document, deciding which of six folders an email belongs in, cleaning up formatting, turning a transcript into a rough summary before a human touches it. The default lane takes ordinary drafting and analysis, the work you would be mildly embarrassed to hand a client without reading it first. The heavy lane takes the long multi-step jobs, code that spans several files, and anything where a wrong answer costs more than the tokens ever will.

Two mechanics make the lanes cheaper still and are worth wiring in at the same time. Anthropic, OpenAI and Google all run a batch mode at a 50% discount on input and output, for work that does not need an answer this second [1][2][3]. And caching repeated input is dramatic at the top of the ladder: a cache read on Claude Fable 5.1 costs $0.25 per million tokens against $10 for the same tokens sent fresh, a fortieth of the price [1]. If you send the same long brief or the same codebase with every request, the cache is doing more for your bill than switching vendors would.

A fixed task set is the only benchmark that decides anything

A vendor’s benchmark tells you how a model did on a test you did not write, using prompts you did not send, scored against answers you would not have asked for. It is a signal that something changed. It is not evidence about your work.

The replacement is unglamorous. Collect 12 to 20 real jobs, the actual requests you send week after week, and save each one with its real input and a short note on what a good answer looks like. Not a description of the input. The input. Then run the set against the model you already use, before you run it against anything new, so that you have a baseline instead of an impression. This is the step people skip, and skipping it is why model comparisons so often end in a shrug.

None of this needs tooling. A folder of numbered files and an afternoon of reading outputs is a real task set. If you want to automate the scoring later, OpenAI ships eval tooling for it, and its own guidance puts the point plainly: writing evals to understand how your applications are performing against your expectations matters especially when you are upgrading or trying new models [8]. But the tooling is the optional part. The fixed, written-down set of jobs is the part that turns “the new one felt better” into a decision you can defend to yourself in three months.

Once the set exists, a release stops being an event and becomes an input. A new model claims a gain on long-horizon coding. You use the heavy lane for exactly that. So you run your 15 jobs, compare against the baseline, and either switch or do not, in about an hour. A new model claims a gain on something you never do. You write down the date and move on.

Pin the version, because the name you type decides how much can change under you

There is a difference between a model name that means one specific model and a model name that means whichever model is newest, and the difference is not visible in the string you type.

Anthropic’s naming changed on this exact point. Older names such as claude-sonnet-4-5 are shorter aliases that point to the most recent dated snapshot for that minor version, so the thing behind the name could move. For the 4.6 generation and later, the dateless ID is the canonical model ID and maps to a single fixed snapshot; Anthropic states that it does not update the weights or configuration of an existing model ID, and that updated versions ship under a new model ID instead [7]. That is a good arrangement, but it only helps if you know which kind of name you are using. If a job runs unattended and its output feeds something else, type the exact ID and check what that ID guarantees.

The interface around the model shifts too, not just the weights. Anthropic has deprecated the temperature, top_p and top_k parameters for Claude Opus 4.7 and later, and setting any of them to a non-default value now returns a 400 error [4]. That is not a subtle quality drift you might miss. That is an automation that stops running, on a day you did not choose, because a parameter you set two years ago is no longer accepted. Any workflow that calls a model API directly with a fixed parameter block is exposed to exactly this, and the failure surfaces as an error in whatever runs the call rather than as a warning in advance.

Notice periods tell you how often you actually have to look

You do not have to watch the release stream, because the vendors have published how much warning you get. That number is what sets your review cadence.

Anthropic notifies customers with active deployments of upcoming retirements and commits to at least 60 days’ notice before retiring a publicly released model [4]. OpenAI commits to at least 6 months for generally available models and at least 3 months for specialised variants such as chat variants, Codex versions and deep research models, and says preview models, identified by preview in the model name, may be retired with much shorter notice, such as 2 weeks [5]. Google says the same thing about its own preview shelf: preview models are deprecated with at least 2 weeks’ notice [6].

Read those together and the cadence falls out. If everything you depend on is a generally available model, a look once a quarter sits comfortably inside every notice window, and you will never be surprised. If any part of your stack runs on a preview model, a quarterly review is not enough, and the honest fix is not to check more often but to have a named fallback you can switch to in an afternoon.

The retirements are real, not theoretical. Anthropic deprecated claude-opus-4-1-20250805 on 5 June 2026, retired it on 5 August 2026, and points users at claude-opus-4-8 instead [4]. OpenAI announced in June 2026 that the gpt-5-2025-08-07, gpt-5-mini-2025-08-07 and o3-2025-04-16 snapshots shut down on 11 December 2026, and it shut down the Assistants API on 26 August 2026, a year after announcing the move, in favour of the Responses and Conversations APIs [5]. Retirement is a normal part of the product, and the only version of it that hurts is the one you find out about from an error log.

Introductory pricing is a date, not a rate

The other thing that changes under you is the bill, and it changes on a schedule that is usually already published.

Gemini 3.8 Flash costs $0.75 per million input tokens and $3.75 per million output through 31 December 2026. From 1 January 2027 those rates become $1.50 and $7.50 [3]. The doubling is not a rumour or a risk. It is printed on the pricing page, with the date on it, months in advance. If you costed a workflow on the current rate and your margin depends on it, you have until the end of December to either accept the new number or move that job to a different lane.

Treat every introductory or promotional rate the same way. Find the end date, put it in the calendar with two weeks of lead time, and note which of your workflows it touches. This costs about five minutes per model and is the single highest-return thing in this guide, because a price change does not break anything loudly. It just quietly makes a job cost twice what you budgeted, and you find out at the end of the month.

A release earns a re-test only when it moves a lane you use

Here is the whole standing process, applied to a week with four announcements in it.

For each release, read past the benchmark chart for three things. Which lane does it land in, cheap, default or heavy. What does it cost, and is that price introductory. What is its status, generally available or preview, and therefore what notice period applies. Those three answers take about two minutes per release and you can get all of them from the vendor’s own pricing and model pages.

Then apply one rule. A release earns time on your task set only if it claims to beat the model currently sitting in one of your lanes, at the kind of work that lane actually does. A cheaper model in a lane you already run is worth an hour. A better model in a lane you do not use is worth a line in a file. A preview model is worth nothing until you have decided what you would fall back to. Most weeks, four releases produce zero re-tests and four lines in a file, and that is the correct outcome, not laziness.

What still goes wrong

Task sets rot. The 15 jobs you saved in March describe the work you were doing in March, and if your business moved, your benchmark is now measuring the wrong thing carefully. The failure is quiet, because the set keeps producing scores. Rewrite a third of it whenever the shape of your work changes, and prefer jobs you did last week over jobs you did last year.

A task set is also a small sample. Fifteen jobs scored by hand carry enough noise that a one-job or two-job margin tells you nothing, so a narrow win is a reason to run the set again rather than a reason to switch. And price is not the whole cost of a lane: a cheap model that needs two attempts and a human correction is more expensive than the expensive one, in money as well as in your afternoon. The calculator above assumes one pass and no rework.

The largest gap is that most of this assumes API access. If you work inside the ChatGPT, Claude or Gemini apps rather than through the API, you cannot pin a version, the deprecation notice periods quoted here describe API model retirement rather than what happens to a chat product’s default model, and your only routing control is the model picker in the corner. The lane discipline still applies, and it is still worth keeping a task set to sanity-check a new default. But you are a passenger on the version question, and the honest advice is to move anything you genuinely cannot afford to have change underneath you onto an API call with a pinned ID.