{"slug": "llm-routing-cuts-costs-here-s-how-to-check-it-doesn-t-cut-quality", "title": "LLM routing cuts costs. Here's how to check it doesn't cut quality", "summary": "A router that moves 70% of calls from Claude Sonnet 5.5 to Claude Haiku 5.5 cuts the API bill by 66.5% at November 2026 list prices, since Haiku 5.5 costs one-twentieth of Sonnet 5.5 on prompts under 100,000 tokens, according to an analysis by EvalShift developer and author of the post. The same analysis warns that published router benchmarks do not establish quality for a given application: RouteLLM's matrix-factorization router reached 95% of GPT-4's MT Bench score while sending 26% of calls to GPT-4, but an independent 2026 benchmark across 21 datasets found several routing methods, including the one commercial router tested, did not reliably beat the best single model. The author recommends replaying production traffic on both the strong and cheap models and routing only where the cheap model met limits written before the run.", "body_md": "[← all posts](https://www.evalshift.dev/blog)\n\n# LLM routing cuts costs. Here's how to check it doesn't cut quality\n\nWhat an LLM router saves at November 2026 API prices, the costs list prices leave out, and how to check routing doesn't cut quality before it ships.\n\nAn LLM router picks a model for each request: the easy ones go to a cheap model, the hard ones to a strong one. How much it can save depends on two numbers, the share of traffic it moves and the price gap between the two models. At November 2026 list prices, on prompts under 100,000 tokens, Claude Haiku 5.5 costs a twentieth of Claude Sonnet 5.5, so a router that moves 70% of calls from Sonnet to Haiku cuts the bill by 66.5%. A router choosing between Claude Opus 5.5 and Sonnet 5.5, where Sonnet costs half as much as Opus, can never save more than 50%, even if it routes everything.\n\nWhat routing costs in quality is a separate number, and no router's published results tell you what it is for your application. Those results are averages on public benchmarks: RouteLLM's matrix-factorization router reached 95% of GPT-4's MT Bench score while sending 26% of calls to GPT-4, and an independent 2026 benchmark across 21 datasets found that several routing methods, including the one commercial router it tested, did not reliably beat the best single model. In an agent, routing loses quality on a few routes: a wrong tool call, or an action the model claims and never takes, inside text that reads fine. Averages hide that.\n\nThe check is to replay your own production traffic on the strong model and on the cheap one, compare every example per route against limits you wrote before the run, and route only where the cheap model held. The rest of this post covers the kinds of router, what routing saves at today's API prices, the costs list prices leave out, and that check step by step. I build EvalShift, which automates the comparison, but the method works with any tooling.\n\n## What an LLM router is\n\nAn LLM router is a layer between your application and the model APIs that chooses which model answers each request. The application sends one request; the router decides whether Haiku, Sonnet or some other model handles it, usually by predicting whether the cheaper model is good enough.\n\nLLM model routing covers several different things, and only some of them route on quality:\n\n| Kind | Decides by | Examples | Routes on quality? | \n|---|---|---|---|\n| Rule-based or heuristic | Route, metadata, request parameters, a complexity score | Portkey conditional routing, LiteLLM auto routing (default scorer), a `switch` in your own code | Only as well as your rules | \n| Gateway load balancing | Availability, latency, rate limits, price | LiteLLM's router strategies and fallbacks | No | \n| Learned router | A classifier that predicts which model is good enough | RouteLLM, Not Diamond, Requesty, vLLM Semantic Router | Yes, as trained on someone else's data | \n| Managed router | The platform's classifier over its own model pool | Azure Foundry model router, Amazon Bedrock Intelligent Prompt Routing, OpenRouter Auto Router | By the platform's quality estimates; OpenRouter ranks by other users' spending | \n| Cascade | Try the cheap model first, escalate when a check fails | FrugalGPT | Yes, if the check is reliable | \n\nThe difference between an LLM router and an LLM gateway is mostly what the routing decision is\nfor. A gateway spreads requests across deployments so they stay up and inside rate limits:\nLiteLLM's router picks among deployments by `simple-shuffle` (its default), least busy, lowest\nlatency or lowest cost, and falls back when one fails. A router in the narrow sense chooses the\nmodel by how hard the request is. Many products do both, including LiteLLM, which added a beta\nauto-routing mode that scores each request with a rule-based heuristic by default and sorts it\ninto simple, medium, complex and reasoning tiers.\n\nA few details from the managed routers matter for testing them:\n\n- +**OpenRouter's Auto Router** (`openrouter/auto` ) classifies each request into one of about 30\ntask types, then ranks models by what OpenRouter's users spent on that task type over the past\nseven days. It adds no fee, and the[docs ↗](https://openrouter.ai/docs/guides/routing/routers/auto-router) say it can pick a\ndifferent model on every turn; with a session ID it reuses the earlier model only while that\nmodel is still one of the top candidates.\n- +**Azure's model router** has three modes. Balanced, the default, picks the cheapest model within\n1% to 2% of the top-quality model, Cost widens that band to 5% to 6%, and Quality ignores cost.\nIt routes on the request's text only, and Microsoft updates model version 2025-11-18 in place\n([docs ↗](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router) ).\n- +**Amazon Bedrock Intelligent Prompt Routing** chooses between two models from one family by\npredicted response quality, with a \"response quality difference\" threshold you set. AWS says it\nis optimized for English prompts only and can't adjust its decisions to application-specific\nperformance data ([docs ↗](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html) ).\n\nTwo of those three change their behavior without a deploy on your side. OpenRouter's ranking follows a trailing seven days of other people's spending, and Azure's router changes when Microsoft updates it. Keep that in mind for the last step of the check.\n\n## LLM API pricing and how much routing saves\n\nThe ceiling on what routing saves is simple arithmetic: **saving = share of calls routed × (1 −\ncheap price ÷ strong price)**. So the first input is the price gap between the models you would\nroute between.\n\nPrices below are per million tokens, standard tier, read from each provider's pricing page on\nNovember 6, 2026 ([OpenAI ↗](https://developers.openai.com/api/docs/pricing),\n[Anthropic ↗](https://platform.claude.com/docs/en/about-claude/pricing),\n[Google ↗](https://aistudio.google.com/docs/pricing),\n[DeepSeek ↗](https://api-docs.deepseek.com/quick_start/pricing/)). The last column assumes 3,000\ninput and 400 output tokens per call, uncached, roughly one turn of a small tool-calling agent,\nthe same call size as in [the cheapest LLM API comparison](https://www.evalshift.dev/blog/cheapest-llm-api).\n\n| Provider | Model | Input | Output | 1,000 calls | \n|---|---|---|---|---|\n| Anthropic | Claude Opus 5.5 | $4.00 | $20.00 | $20.00 | \n| Anthropic | Claude Sonnet 5.5 | $2.00 | $10.00 | $10.00 | \n| Anthropic | Claude Haiku 5.5 | $0.10 | $0.50 | $0.50 | \n| OpenAI | `gpt-6.1-terra` | $1.00 | $5.00 | $5.00 | \n| OpenAI | `gpt-6-luna` | $0.10 | $0.50 | $0.50 | \n|  | `gemini-3.8-flash` | $0.75 | $3.75 | $3.75 | \n|  | `gemini-3.1-flash-lite` | $0.25 | $1.50 | $1.35 | \n| DeepSeek, off-peak | `deepseek-v4-pro` | $0.66 | $1.98 | $2.77 | \n| DeepSeek, off-peak | `deepseek-flash` | $0.15 | $0.60 | $0.69 | \n\nHaiku 5.5's price holds for prompts up to 100,000 tokens. Above that every token in the request bills at $0.50 / $2.50, a quarter of Sonnet's price instead of a twentieth, which matters for an agent deep into a long conversation.\n\nApplied to same-provider pairs, the formula gives the most each router could save at list price:\n\n| Route from → to | Cheap ÷ strong | 50% routed | 70% routed | 90% routed | \n|---|---|---|---|---|\n| Claude Sonnet 5.5 → Haiku 5.5 | 5% | 47.5% | 66.5% | 85.5% | \n| `gpt-6.1-terra` →`gpt-6-luna` | 10% | 45.0% | 63.0% | 81.0% | \n| `deepseek-v4-pro` →`deepseek-flash` | 24.9% | 37.6% | 52.6% | 67.6% | \n| `gemini-3.8-flash` →`gemini-3.1-flash-lite` | 36% | 32.0% | 44.8% | 57.6% | \n| Claude Opus 5.5 → Sonnet 5.5 | 50% | 25.0% | 35.0% | 45.0% | \n\nThree things to read from it:\n\n- +**The price gap matters as much as the router.** Moving 70% of traffic within the Anthropic\npair saves 66.5%; moving the same share between Gemini 3.8 Flash and 3.1 Flash-Lite saves\n44.8%. The Gemini row moves on January 1, 2027, when 3.8 Flash's introductory price ends and it\ngoes to $1.50 / $7.50, which takes the 70% saving to 57.4%.\n- +**Cross-provider pairs need measured cost, not list price.** I left them out because the same\ntext is a different number of tokens on each provider. Anthropic says Claude 4.7 and later\nmodels count the same text as about 30% more tokens than earlier Claude models, so an LLM cost\ncomparison across tokenizers is off before any routing starts.\n- +**The 90% column is a ceiling, not a forecast.** It assumes every routed call costs the cheap\nmodel's list price and nothing else changes. The next section is the list of things that do.\n\nFor comparison, here are the published savings claims. LMSYS reported that RouteLLM cut costs by\nover 85% on MT Bench, 45% on MMLU and 35% on GSM8K while keeping 95% of GPT-4's performance\n([blog ↗](https://lmsys.org/blog/2024-07-01-routellm/)). Its best MT Bench router, trained on\naugmented data, sent 14% of calls to GPT-4 (26% when trained on Arena data alone), and the pair\nwas GPT-4 and Mixtral 8x7B, much further apart in price than any pair above. AWS says Intelligent Prompt Routing can\ncut costs by up to 30%. LiteLLM benchmarked its own auto-routing on 300 prompts graded by a\nblinded pairwise judge: its semantic router, now deprecated, saved 58.2% and scored a 46.8% win\nrate against the flagship model, where 50% means parity and a randomly shuffled control scored\n39.2%. Its newer tier-based complexity router did not beat that control\n([benchmark ↗](https://docs.litellm.ai/docs/proxy/auto_routing_benchmark)). Every one of those\nnumbers is measured on someone else's prompts.\n\n## What routing costs that the price table leaves out\n\nFour costs move the real saving below the table:\n\n- +**Prompt caching stops working across a switch.** A prompt cache holds the attention state one\nmodel computed for your prefix, so no other model can use it. Google's caching API says\ncached content can only be used with the model it was created for, and Azure's router docs say\ncaching benefits apply only when the same model handles consecutive requests. On Claude Sonnet\n5.5, a cached read costs $0.10 per million tokens and a five-minute cache write $2.50. Twenty\nthousand tokens into a conversation, an agent on Sonnet pays $0.002 a turn to read that context\nfrom the cache. If the router moves the conversation to Sonnet from another model, Sonnet has\nnever seen it, and the first turn pays $0.05 to write it, 25 times as much. A[measured write-up on Towards Data Science ↗](https://towardsdatascience.com/the-hidden-cost-of-llm-routing-why-switching-models-costs-more/) found that per-request routing at the gateway, under real pricing, delivered only 13 of the 40\npercentage points of saving the headline suggested, and destroyed almost twice as much cache as\nsticky routing.\n- +**A cascade pays twice for every escalation.** An escalated request costs the cheap call plus\nthe strong one, and the user waits for both. With Haiku 5.5 in front of Sonnet 5.5, a cascade\nthat escalates 30% of requests costs 35% of always-Sonnet, against 33.5% for a router that sends\nthe same 30% straight to Sonnet. Cascades are also only as good as their check: RouterBench found\ncascade performance drops rapidly as the judge's error rate rises\n([paper ↗](https://arxiv.org/abs/2403.12031) ).\n- +**Cheap models can take more turns per task.** An agent pays per finished task, not per call. A\nmodel that needs an extra tool round or retries a malformed call can cost more per task than its\nlist price suggests; the[cheapest LLM API post](https://www.evalshift.dev/blog/cheapest-llm-api) covers the mechanics.\n- +**The router itself.** A classifier call adds latency to every request, and some routers charge\nfor it: Amazon Bedrock lists a separate charge of $1 per 1,000 requests for Intelligent Prompt\nRouting, twice what 1,000 calls to Haiku 5.5 cost at the call size above.\n\nRouting is one LLM cost optimization among several, and the others are cheaper to try first. For the OpenAI and Anthropic models in the table, cached input costs 0.05x to 0.1x of the input price. OpenAI, Anthropic and Google all take 50% off batch requests for work that can wait. And if every route holds on the cheap model, you don't need a router at all; you need a migration.\n\n## Why router benchmarks don't tell you what your app loses\n\nEvery learned or managed router decides on a prediction of quality, or a proxy for one (OpenRouter's is other users' spending), and the predictions are trained and scored on someone else's data. RouteLLM's routers were trained mainly on Chatbot Arena preference data, augmented with LLM-judge and MMLU labels, and tested on MT Bench, MMLU and GSM8K, which are chat and question-answering sets. Its \"95% of GPT-4 performance\" means the routed mix scored 8.8 on MT Bench against GPT-4's 9.3, which closes half of the gap between the two models, averaged over the benchmark.\n\nIndependent benchmarks are more sobering. RouterBench, built from more than 405,000 inference\noutcomes, found that its predictive routers did not significantly beat a baseline that mixes\nmodels in fixed proportions without reading the query. LLMRouterBench (January 2026; 21 datasets,\n33 models) found that many routing methods, including OpenRouter's, the one commercial router it\ntested, fail to reliably beat the best single model. It reports OpenRouter at −24.7% against the\nbest single model, and its best methods cut cost by up to 31.7% while matching that model\n([paper ↗](https://arxiv.org/abs/2601.07206)). The paper\ntested OpenRouter's router as it was then, and the current one ranks models by spend, so treat\nthat number as a reason to test, not a verdict on today's version.\n\nMicrosoft's own guide to\n[evaluating its model router ↗](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/evaluate-model-router)\nmakes the point directly: group prompts by workload category \"so that an aggregate result doesn't\nhide a category-specific regression\". A Towards Data Science\n[case study ↗](https://towardsdatascience.com/we-built-a-routing-layer-to-cut-our-ai-costs-it-broke-the-product/)\nshows what happens when you don't. The cheap tier of a routing layer matched the strong model on\n94% of a 5,000-query holdout, quality monitoring that wasn't split by tier hid the long-tail\nfailures for months, and the team estimated the quality loss cost four to five times what routing\nsaved.\n\n### In agents, the loss is behavior\n\nRouting quality in an agent is mostly about what the agent *does*. I replayed 16 real examples\nfrom an agent on its current model and a cheaper candidate: 58.8% cheaper, 75.2% faster, not one\nfailed or truncated call. The migration report still returned **FAIL**.\n\nThe cheaper model picked a different tool on 25% of comparisons against a 10% limit, searched the\nweb where the current model answered in two sentences, and told a user an action was done without\ncalling the tool that does it. Every call succeeded at the API level. A router that sent that\nagent's traffic to the cheaper model would have shipped those failures on the requests it routed\nthere, and a dashboard of cost, latency and error rate would have called it a win. The full\nreport is in [the new model was 59% cheaper and 75% faster, and I still wouldn't ship it](https://www.evalshift.dev/blog/cheaper-faster-and-still-a-fail).\n\nThe opposite result is just as real. A customer-support agent with six tools moved to a cheaper\nmodel over 120 production examples and held every budget, including zero regressions on its\nsecurity slice, at 71.2% lower cost\n([the passing report](https://www.evalshift.dev/blog/what-a-passing-migration-proves)). Price told me nothing about which\nof the two would pass.\n\n## Where routing breaks an agent\n\nThe regressions routing introduces cluster in four places:\n\n- +**Requests that look easy and aren't.** \"Yes, cancel the second one\" is five words. A router\nthat scores the latest message sees an easy request; the work is in the conversation behind it.\nIn the case study above, \"where is my charge from\" read as a simple billing lookup and was\nsometimes the start of a fraud report.\n- +**Switching models mid-task.** OpenRouter's Auto Router can choose a different model on every\nturn, while Requesty's auto routing pins its choice for 60 minutes per conversation. A model\npicked mid-task inherits another model's half-finished plan, with different tool-call habits\nand a cold cache.\n- +**The cheap model's own agent failures.** It calls a tool where none was needed or skips a\nrequired lookup, claims an action it never took, picks a neighboring tool, or passes an id with\na typo. The[guide to evaluating agent tool calls](https://www.evalshift.dev/blog/evaluating-agent-tool-calls) covers the check for each.\n- +**Drift with no deploy.** Thresholds are tuned on last month's traffic. When the mix shifts, the\nshare routed to the cheap model shifts with it, and managed routers change their own pools and\nrankings on their own schedule.\n\n## How to check an LLM router doesn't cut quality\n\nSix steps. The first five run before the router takes traffic; the sixth keeps it honest after.\n\n## Step 1: sample production traffic and tag it by route\n\nTake 100 to 300 real inputs from production, stratified by route or intent so the rare and\nexpensive paths are in the sample, and tag each one with its route. For an agent, take whole\nconversations, not single messages, so a mid-conversation switch is part of what you test. A\n[golden suite built from production traffic](https://www.evalshift.dev/blog/build-a-golden-suite-from-production-traffic)\nis the reusable version of this.\n\nSize the routes you plan to decide on, not just the total. Zero regressions out of 20 examples\nstill leaves a true rate of up to about 15% at 95% confidence (the rule of three, 3/*n*); zero\nout of 100 brings it down to about 3%. [How many eval cases you need](https://www.evalshift.dev/blog/how-many-eval-cases-do-you-need)\nhas the full sizing.\n\n## Step 2: write the per-route limits before the run\n\nFor each route, a maximum regression rate, a maximum tool-selection divergence and a minimum saving that makes routing it worth the risk. Routes that move money or touch security get zero allowed regressions, zero tool divergence and zero argument drift. Deciding after you have seen the numbers is how a bad router gets approved, because a 66% saving makes almost any regression look acceptable in hindsight.\n\n## Step 3: run both models on every example\n\nRun the strong model and the cheap model on every example, not only on the ones the router would send cheap. With both outputs in hand you can score any routing policy offline: for each example, the router's decision picks which of the two outputs it would have served. One paired run then answers the question for every router and every threshold you are considering. RouteLLM's evaluation works the same way, scoring routers from both models' results on each query.\n\nCompare behavior, not just text: tool calls, arguments and structured fields per example, and read\nevery example that regressed. An LLM judge helps on open-ended answers, but\n[know when to trust it](https://www.evalshift.dev/blog/when-to-trust-an-llm-judge).\n\n## Step 4: score the router's decisions, not just the cheap model\n\nTwo numbers per route. The **misroute rate** is the share of requests the router sent to the cheap\nmodel on which the cheap model regressed against the strong one; that is the quality you are\ngiving up. The **missed-saving rate** is the share it kept on the strong model where the cheap one\nwould have held; that is money left on the table. A router with a low misroute rate overall and a\nhigh one on the refund route is a router you can't ship as it is.\n\n## Step 5: measure the blended cost on the same run\n\nFrom the paired run, add up what the router's choices would have cost: for each example, the measured cost of the output it would have served. Then add the router's fee per request, any escalations, and a cache write for every turn where the chosen model differs from the previous turn's. Compare the total with the always-strong baseline on the same inputs, not with the table above. If it is much smaller than the arithmetic said, cache writes and extra turns are usually why.\n\n## Step 6: route per route, and re-run when anything moves\n\nSend each route where it passed and keep the rest on the strong model. A static table from route to model is the simplest router there is, and the easiest to test exactly. Then re-run the check whenever the router's version, model pool or threshold changes, when either model changes version, when the prompt or tools change, and when the traffic mix shifts. Watch the share of traffic routed to the cheap model in production: when it moves without a change on your side, the router or the traffic did.\n\n## Doing this with EvalShift\n\nThis is the comparison EvalShift runs. It records real calls with its capture SDK and promotes them\ninto a frozen golden suite, and every distinct tag on an example becomes a slice, so tagging by\nroute gives you per-route results with no extra setup. `evalshift compare --from <strong-model> --to <cheap-model>` replays the suite on both models, scores every pair with the evaluators you\nconfigure (tool calls and arguments, structure, semantic similarity, an LLM judge), and measures\ncost and latency from the run's own calls.\n\nPer-route limits go in `migration_policy.slices` in `evalshift.yaml`, keyed by tag, and each one\noverrides the top-level budget only where you set it:\n\n```\nmigration_policy:\n  max_overall_regression_rate: 0.05\n  max_tool_divergence: 0.05\n  max_cost_increase: 0.0\n  slices:\n    refund:\n      max_overall_regression_rate: 0.0\n      max_tool_divergence: 0.0\n      max_tool_argument_drift: 0.0\n    security:\n      max_overall_regression_rate: 0.0\n      max_tool_divergence: 0.0\n```\n\n`max_cost_increase` caps a cost increase; it can't demand a saving, so read the minimum saving from\nthe report's cost delta. `evalshift init --profile cost-reduction` scaffolds budgets tighter than\nthe defaults. The report gives a verdict, the per-slice results and the per-example diffs, so the\nroutes that held become your routing table and the ones that broke stay on the strong model.\n\nOne limit: EvalShift compares two models, and it doesn't call your router. To score a learned\nrouter, take its decision for each example and read the per-example results for the examples it\nwould have sent to the cheap model, as in Step 4. The\n[step-by-step migration test guide](https://www.evalshift.dev/blog/test-llm-model-migration-before-you-ship) shows the\nwhole flow, and the [migration policy docs](https://www.evalshift.dev/docs/migration-policy) list every budget.\n\nAn LLM router's saving is arithmetic you can do before you build it. What it costs in quality is something you can only measure, route by route, on your own traffic.\n\n## FAQ\n\n**What is an LLM router?** An LLM router is a layer between an application and the model APIs that\nchooses which model handles each request, usually sending easy requests to a cheap model and hard\nones to a strong model. It can decide by fixed rules, by a learned classifier, by a platform's\nquality estimates, or as a cascade that tries the cheap model first and escalates.\n\n**How much does LLM routing save?** At most the share of calls routed times the price gap between\nthe two models. At November 2026 list prices, on prompts under 100,000 tokens, moving 70% of calls\nfrom Claude Sonnet 5.5 to Claude Haiku 5.5 saves 66.5%, and moving 70% from `gpt-6.1-terra` to\n`gpt-6-luna` saves 63%. Lost prompt caching, cascade escalations, extra turns and router fees\nbring the measured saving below that.\n\n**Does LLM routing reduce quality?** Usually somewhat, and the loss is uneven. Routers are scored\non benchmark averages, such as RouteLLM keeping 95% of GPT-4's MT Bench performance, while an\napplication loses quality in specific routes. In agents it shows up as wrong tool calls and claimed\nactions that never happened, which a successful API response and fluent text can hide.\n\n**What is the difference between an LLM router and an LLM gateway?** A gateway spreads requests\nacross deployments for availability, latency, rate limits and price, and falls back when one fails.\nA router chooses the model by how hard each request is. Many products, including LiteLLM, do both.\n\n**How do you evaluate an LLM router?** Replay 100 to 300 tagged production inputs on both the strong\nand the cheap model, write per-route limits before the run, and score the router's decisions\nagainst the per-example results: the misroute rate is the share of cheap-routed requests that\nregressed. Measure the blended cost on the same run, and re-run when the router, the models or the\ntraffic change.\n\n**Does LLM routing break prompt caching?** Switching models does. A prompt cache holds one model's\nstate for your prefix, so the first request after a switch writes the cache again at full or higher\nprice. A router that picks the model once per conversation, instead of per request, loses far less\nof it.\n\n**Is LLM routing worth it for AI agents?** Often, per route. Agents resend a long, cacheable prefix\nevery turn and fail in tool calls rather than prose, so per-request routing within a conversation\nis the riskiest form. Testing each route on real traffic and routing only the routes where the cheap\nmodel held keeps the saving on those routes and keeps out the failures the test can detect.\n\n## Keep reading\n\n- +[The cheapest LLM API in 2026, and whether it is good enough for your agent](https://www.evalshift.dev/blog/cheapest-llm-api) — the full price table and why list price is not what an agent costs.\n- +[The new model was 59% cheaper and 75% faster. I still wouldn't ship it.](https://www.evalshift.dev/blog/cheaper-faster-and-still-a-fail) — the failing report, evaluator by evaluator.\n- +[This one passed: 71% cheaper, and the agent still does the same thing](https://www.evalshift.dev/blog/what-a-passing-migration-proves) — per-slice budgets on a cheap swap that held.", "url": "https://wpnews.pro/news/llm-routing-cuts-costs-here-s-how-to-check-it-doesn-t-cut-quality", "canonical_source": "https://www.evalshift.dev/blog/llm-router", "published_at": "2026-11-06 23:52:05.567690+00:00", "updated_at": "2026-11-06 23:52:07.920062+00:00", "lang": "en", "topics": ["large-language-models", "ai-infrastructure", "ai-tools", "mlops"], "entities": ["EvalShift", "Claude Haiku 5.5", "Claude Sonnet 5.5", "Claude Opus 5.5", "RouteLLM", "GPT-4", "LiteLLM", "OpenRouter"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/llm-routing-cuts-costs-here-s-how-to-check-it-doesn-t-cut-quality", "markdown": "https://wpnews.pro/news/llm-routing-cuts-costs-here-s-how-to-check-it-doesn-t-cut-quality.md", "text": "https://wpnews.pro/news/llm-routing-cuts-costs-here-s-how-to-check-it-doesn-t-cut-quality.txt", "jsonld": "https://wpnews.pro/news/llm-routing-cuts-costs-here-s-how-to-check-it-doesn-t-cut-quality.jsonld"}}