Best LLM Routers and Model Routing Tools in 2026

TL;DR

• Weave Router suits engineers who want automatic model selection across Claude Code, Codex, opencode and pi, with hosted or self-hosted deployment.

• Vercel AI Gateway connects coding agents to shared model access, spend tracking, provider routing and configured model fallbacks. It also documents session affinity to preserve provider caches.

• OpenRouter Auto Router selects models through a managed endpoint, while Cursor Router gives Cursor users native cost and quality controls.

• Ramp Router provides standalone model routing, while LiteLLM Router gives platform teams a self-hosted gateway with broad provider support.

• RouteLLM supports custom router research, Not Diamond provides managed learned routing, and Portkey adds rule-based routing to enterprise gateway controls.

• Microsoft Foundry Model Router and Amazon Bedrock Intelligent Prompt Routing fit organizations already committed to their respective cloud platforms.

Try Weave Router for automatic model selection across supported coding tools, with source code and a public evaluation harness.

Who is the best coding agent router?

We recommend Weave Router for teams that want automatic model selection across Claude Code, Codex, opencode and pi, with the option to self-host. Its source and coding-task evaluation harness are public. Cursor Router fits teams staying inside Cursor; Vercel AI Gateway fits shared provider access and controls; OpenRouter and Not Diamond offer managed model selection. The best fit depends on accepted task results, retries, elapsed time and total cost in your workflow.

Which router should you use for coding agents?

For Claude Code, Codex or another coding agent, start with the decision you want to automate. If you want model selection for each action, evaluate Weave Router. If you want centralized access, billing and provider controls for coding tools, evaluate Vercel AI Gateway. If you want a managed model selector with a configurable candidate pool, evaluate OpenRouter Auto Router.

These products overlap. Supporting coding agents, tracking spend or offering fallbacks does not by itself make one router better. Compare the selection policy, cache behavior, tool-call compatibility and completed-task results for your workflow.

For a closer buying comparison, read Weave Router vs OpenRouter, Weave Router vs Martian, or Weave Router vs Nadir. Each page includes current source links, pricing terms and an evaluation workflow. The OpenRouter comparison also charts Weave’s published historical coding runs and their limitations.

Weave publishes coding-agent benchmark results and their limitations, plus an open benchmark harness. The published results compare Weave with direct GPT-6 Astra and a separate OpenRouter run. They do not establish a win over Vercel or every router in this guide.

The real cost of routing wrong

Sending every coding request to a frontier model raises token spend without guaranteeing a useful quality gain. Routine actions such as formatting code or generating boilerplate may perform similarly on a cheaper model. Complex refactors and multi-step tool calls can justify the frontier model’s higher price when its stronger reasoning prevents mistakes.

Sending every request to the cheapest model can create costs outside the model invoice. If a model edits the wrong files or returns an invalid tool call, the coding agent may retry with a larger prompt. A developer may then spend time correcting or abandoning the output. Cost per request can fall while cost per completed task rises.

A useful LLM router predicts which model can complete each request at an acceptable quality level. It sends routine work to lower-cost models and escalates requests when predicted quality separates. Provider fallback and budget rules can keep requests available or within a spending ceiling, but those controls do not establish whether the selected model can handle the work.

Router evaluations should therefore examine completed work, retries, and code quality alongside token cost. The products in this list differ most in how they make that selection and what evidence they expose afterward.

Learned routers vs. rule-based gateways

Some routers describe trained or learned model selection, while others expose configurable policies. The underlying methods and candidate models differ, so the label alone does not establish routing quality. Not Diamond currently documents pretrained and custom routers; the entries below link to each product's current explanation.

Weave Router uses an on-box cluster scorer for each upstream API request. RouteLLM applies trained preference models to a strong and weak model pair. Not Diamond documents pretrained and customer-trained routers. OpenRouter Auto documents a separate task-classification and market-spend method, described below. Cursor publishes model-selection modes; Ramp says it matches requests to lower-cost models that meet a quality target. Microsoft Foundry and Amazon Bedrock describe trained or predictive selection inside their own cloud platforms.

Policy-driven gateways execute rules you configure, such as request metadata conditions, provider order, load balancing and fallbacks. LiteLLM documents routing across deployments with retries, cooldowns and fallbacks. Portkey documents conditional routing and fallback policies. These controls address availability and routing policy; do not assume every product has the same model-quality objective.

Products may combine capabilities. Vercel documents coding-agent access, provider options, configured model fallbacks, virtual models and session affinity. Cursor, Not Diamond, Microsoft Foundry and Bedrock document model-selection modes. Inspect the policy you actually configure rather than inferring quality from the product label.

LLM routers and gateways compared at a glance

Routing products solve different problems. Some predict a model for each request; others centralize provider access, apply policies, or retry a failed call. This is a sourced product comparison, not a ranking: no common coding-task benchmark covers every entry below. Check the linked current documentation and test the exact plan, models, deployment and workflow you would use.

These entries summarize vendor documentation. Vendor-published performance and savings figures are not directly comparable because workloads, baselines, model pools and methods differ.

What to look for in an LLM router

Routing unit. Check whether the router decides per action, per turn, or per session. Per-action routing selects a model for every upstream API request, while per-turn routing covers one user interaction. Per-session routing keeps one model throughout the working session.

Decision method. Learned selectors predict which model can handle a request at the required quality. Rule-based gateways follow conditions such as budgets or request metadata, while fallback layers primarily react to provider health.

Model pool breadth. A broad pool gives the router more price and capability options. Check support for proprietary providers and open-weight models, along with any restrictions to one cloud or model family.

State and caching awareness. Model changes can affect conversation continuity and provider prompt caches. Ask whether the router considers prior context and cache availability before switching models.

Observability. Useful telemetry should show which model handled each request and why the router chose it. Cost, latency, and failure data should remain available at the request and session levels, preferably through exports or standard telemetry protocols.

Deployment model. Hosted routers reduce operational work but place more infrastructure under vendor control. BYOK keeps provider billing under your accounts, while full self-hosting gives you greater control over routing data and credentials. Check where keys reside, how the router encrypts them, and whether its license permits your intended deployment.

Weave Router

Best for

Engineers who want automatic model selection across supported coding tools and the option to inspect or self-host the routing service.

What it is

Weave Router selects a model for each action, which means each upstream API request rather than each conversation turn or session. A small on-box cluster scorer derived from Avengers-Pro predicts which model fits the request. Weave does not send the prompt through another LLM for classification.

The router acts as a drop-in proxy for Anthropic Messages, OpenAI Chat Completions, and Gemini native APIs. It supports streaming, tools, and vision. You can also reach DeepSeek, Kimi, GLM, Qwen, Llama, and Mistral through OpenRouter or another OpenAI-compatible endpoint.

The setup wizard supports Claude Code, Codex, opencode and pi, including project-scoped configuration. Early beta support connects Cursor through a base URL override. Harness-native routers such as Cursor Router keep their policies inside one coding tool.

Pros

• The hosted setup wizard runs through npx @weave-os/router without requiring a repository clone, Docker or Postgres. A fully self-hosted deployment is separate: you operate the router and database, and the README documents local, encrypted provider-key storage. Review credential handling for the deployment you choose.

• Codex retains its native ChatGPT OAuth login after installation. Codex skills and Claude Code commands let you pin a model for the current session, inspect available models, or turn routing off without removing the configuration.

• Weave exposes routing telemetry through OTLP. You can inspect it in the Weave dashboard or export it to Honeycomb and other OTLP backends such as Datadog or Grafana. The /v1/route endpoint previews a routing decision without calling the selected model, while separate endpoints expose session costs, estimated savings, and raw routing decisions.

• In Weave’s published Terminal-Bench 4.0 evaluation, Router solved 62.1% of 66 tasks versus 60.6% for GPT-6 Astra at pass@2, meaning either of two attempts could pass. Mean cost per trial was $5.22 for Router versus $10.03 for Astra. Router and Astra used the same Codex harness, tasks, day and package. These are vendor-reported results with overlapping confidence intervals, not proof that Router is more capable. The separate 124-task SWE-Atlas evaluation favored Astra on solve rate, 66.1% versus Router’s 62.1%, while Router cost less per trial.

• The broader Weave platform provides engineering output, quality and AI-cost measurement. Evaluate that separately from Router’s request telemetry, and verify your integrations before assuming that a routing trace proves a merged-PR outcome.

Cons

• Cursor support remains in early beta and requires a base URL override.

• The strongest SDLC-based evaluation depends on using Weave’s engineering intelligence data. Buyers seeking only provider failover may prefer a narrower gateway.

• The published performance and quality figures are vendor-reported and need validation against your repositories, prompts, and model pool.

Pricing

Weave publishes Code Max at $10 per month, including $50 in monthly credits, and Code Boost at $100 per month, including $200 in monthly credits. Subscription capacity is separate from API benchmark results; see the subscription evaluation methodology.

Vercel AI Gateway

Best for

Teams that want shared model access, billing, provider controls and request traces across coding agents and applications.

What it is

Vercel explicitly documents Claude Code, Codex, Cursor and other coding-agent integrations. Its setup command connects supported tools to the gateway. The documentation describes centralized spend tracking, model access, provider fallbacks and observability.

Provider options control provider order and allowed providers. Model fallbacks specify backup models after execution failure or unavailability. Virtual models save a model and its routing settings under one reusable ID, including for coding agents that cannot attach gateway options to each request.

Evaluation considerations

• Vercel documents session affinity that keeps a conversation on the provider holding its prompt cache. Cache-aware behavior is therefore not unique to Weave.
• Provider failover and selecting a model for task difficulty address different decisions. Check which model-selection policy your configured gateway uses, what triggers a switch and how tool calls behave afterward.
• The cited integration documentation does not establish a head-to-head coding-task advantage over Weave. Compare both using your actual tasks, accepted results, retries, cost and elapsed time.

Pricing

Use Vercel’s current AI Gateway pricing and the rates of your chosen models and providers. Compare total billed cost, including cache behavior, rather than treating catalog token rates as the cost of a finished task. Sources reviewed October 16, 2026.

OpenRouter Auto Router

Best for

Applications that want model selection through OpenRouter's managed API.

What it is

OpenRouter classifies a request into a task type, then ranks eligible models using aggregate community spend from the trailing seven days. Cost tier and model/provider restrictions shape the candidates. It can prefer the prior model on later turns when that model remains a top candidate, and the response identifies the model used. Both openrouter/auto and early-access openrouter/auto-beta are documented. Official Auto Router documentation, reviewed October 16, 2026.

Evaluation considerations

• Test your actual multi-turn tool workflow and inspect model changes.
• Measure accepted output and retries; market popularity alone does not establish quality on your repositories.
• Confirm the model and provider policies required by your application.

Pricing

OpenRouter documents standard selected-model charges with no additional Auto Router fee. Check current account and model terms when estimating total spending. Auto Router pricing.

Cursor Router

Best for

Teams using Cursor who want its native model-selection modes.

What it is

Cursor documents a classifier that evaluates each agent request and routes among eligible models. Teams and Enterprise users can choose Cost, Balance or Intelligence optimization; admins can control the available modes and model access. The model pool changes as Cursor adds models. Routing happens inside Cursor, so it does not supply one policy across independent tools such as Claude Code and Codex. Cursor's current documentation describes routing and plan eligibility.

Evaluation

Compare the models it selects, accepted task results, cost and elapsed time on your team's coding tasks. Cursor's current pricing documentation says Auto requests bill according to the model routed to; third-party model charges and plan allowances vary. Check the current plan before estimating spend.

Ramp Router

Best for

Teams evaluating Ramp's model-selection gateway and its connection to Ramp's AI spend tools.

What it is

Ramp describes Router as an endpoint that matches requests to a low-cost model meeting a quality target, with automatic fallbacks and request-level observability. Ramp also publishes savings figures and internal workload examples on its own site. Treat those as vendor-reported evidence: the public page does not establish a head-to-head result on your coding-agent workload. Review the current Ramp Router description and its linked methodology, then test with the same tasks, model pool and acceptance checks you use for alternatives.

Evaluation

Ask which model handled each request, what quality signal triggers selection, how tool calls and multi-turn state work, what is logged, and how costs are calculated. Do not infer integration, deployment or quality details that Ramp's current docs do not specify.

LiteLLM Router

Best for

Platform teams that want a self-hosted gateway with broad provider compatibility.

What it is

LiteLLM provides one interface for more than 100 LLM providers through a Python SDK or an OpenAI-compatible proxy server. Its Router balances requests across deployments and retries failed calls. Configured fallbacks can send a request to another deployment or provider.

LiteLLM's cited router documentation describes configured deployment strategies. Teams define and maintain routing priorities; the comparison does not infer behavior from unrelated extensions or integrations.

Pros

• The unified API covers major hosted providers and local runtimes, including OpenAI, Anthropic, Bedrock, Gemini, Ollama, and vLLM.

• Self-hosted deployment options include Docker, Kubernetes, and cloud infrastructure modules.

• Virtual keys support scoped access, while built-in cost tracking records spend by project or user.

• Guardrails and an administrative dashboard support centralized governance.

Cons

• The deployment-routing setup requires you to define routing policy, fallbacks and deployment priorities.

• Operating the proxy can require databases, caches, and cloud infrastructure at larger scales.

• Enterprise controls such as SSO and audit logs require the separate Enterprise Tier.

Pricing

LiteLLM publishes its core project as open source. The vendor does not publish Enterprise Tier pricing in the cited repository, so you must request a quote for commercial features and support.

RouteLLM

Best for

Research-minded teams that want an open framework for training and evaluating routers across a strong and weak model pair.

What it is

RouteLLM uses a matrix-factorization router by default to estimate whether each prompt needs the stronger model. A cost threshold controls the share of requests sent to that model. Its Performance Gap Recovered metric measures how much of the quality difference between the weak and strong models the router recovers at a given cost level.

The Apache-2.0 framework includes matrix factorization, similarity-weighted ranking, BERT, and causal LLM routers. You can run it as an OpenAI-compatible server or use it as a replacement for the OpenAI client.

Pros

• RouteLLM exposes its training and evaluation methods for modification.

• The framework provides explicit controls for studying cost and quality tradeoffs.

• The published research reports generalization to model pairs outside its original training pair.

Cons

• The included routers were trained on GPT-4 and Mixtral preference data, so you should validate performance on your own models and workloads.

• RouteLLM focuses on binary strong and weak model selection rather than broad provider orchestration.

• You must operate the service and evaluation pipeline yourself.

Pricing

RouteLLM is free under Apache-2.0. You pay for hosting and model usage.

Not Diamond

Best for

Teams comparing managed model selection for coding-agent tasks.

What it is

Not Diamond's current routing documentation describes pretrained chat and coding routers, custom routers trained on customer data, and quality, cost and latency modes. It offers Python, TypeScript and REST integrations. Its public documentation makes this a relevant coding-agent comparison; older third-party claims about catalog size, training requirements and pricing are not used here.

Evaluation

Check which models and coding harnesses the current plan supports. Compare model choice, accepted task results, retries, latency and total cost on your own workload. Confirm its data handling and commercial terms directly before sending proprietary prompts.

Portkey AI Gateway

Best for

Portkey suits teams that need enterprise gateway controls such as caching, guardrails, and spend management alongside predictable routing rules.

What it is

Portkey applies sequential query and then conditions rather than predicting which model will produce the best answer. Rules can inspect request metadata, model parameters, or URL paths. Gateway configurations support conditional routing, fallbacks, and load balancing, while a required default handles unmatched requests. Conditional routing works across Portkey’s catalogue of more than 250 models.

Pros

Portkey combines one provider interface with retries, caching, key management, budgets, rate limits, and guardrails. You can self-host the open-source gateway or use managed and hybrid deployment options.

Cons

The cited Portkey documentation describes user-defined routing conditions rather than promising an automatic quality selector. Teams must define and maintain the conditions that send requests to each model. The current plan comparison identifies which caching, access-control and compliance features require a paid tier.

Pricing

Portkey's plan comparison lists a self-hosted open-source option, a Dev plan with 10,000 requests per month, a Pro plan with 100,000 requests, and custom Enterprise terms. Check the current base price, overage rates, retention and feature limits for your deployment.

Microsoft Foundry Model Router and Amazon Bedrock Intelligent Prompt Routing

These managed options fit teams already using Azure or AWS. Their supported models, regions and deployment settings differ.

Microsoft Foundry Model Router

Microsoft describes per-request model selection with Cost, Balanced and Quality modes, model subsets and automatic failover. It runs as a Foundry deployment and can route among eligible models from several providers. Review the current model-router documentation, especially the supported model list, Claude deployment requirement, region and context-window limits. Microsoft recommends evaluating the router against your own baseline.

Amazon Bedrock Intelligent Prompt Routing

Bedrock predicts response quality and selects between configured models within one model family, with a fallback model. Available families, models and regions are limited to those currently supported by Bedrock. Its current documentation describes setup and limitations, including that routing is not optimized using application-specific performance data. Compare the selected model and task results on your workload; do not transfer savings claims from another test.

Which router fits your team

• Engineering teams using several coding tools should evaluate Weave Router. Its installer supports Claude Code, Codex, opencode and pi. Check the current integration and run representative tasks before a team rollout.

• Teams wanting shared gateway controls should also evaluate Vercel AI Gateway. Its coding-agent integrations, virtual models, session affinity and provider controls overlap with several reasons teams consider a router.

• Cursor-only shops should pick Cursor Router. Its native modes provide model selection and cost control without adding another tool outside the IDE.

• Platform teams needing broad provider reach should choose OpenRouter or LiteLLM. OpenRouter offers a managed endpoint with a large model catalogue, while LiteLLM suits teams that want a self-hosted gateway and control over provider configuration.

• Azure-committed teams should use Microsoft Foundry Model Router, and AWS-committed teams should use Amazon Bedrock Intelligent Prompt Routing. Both keep routing inside the existing cloud platform, but each limits model choice to its supported ecosystem.

• Teams that want to train and evaluate their own selector should pick RouteLLM. Its open framework supports custom strong-versus-weak model routing experiments rather than prescribing a managed routing policy.

When to choose Weave Router

Choose Weave when automatic model selection across supported coding tools and the ability to inspect or self-host the router match your needs. Its open source and published evaluation harness give you a starting point for testing those claims on your own work.

Before rollout, compare Router against your current fixed model on a held-out set of representative tasks. Keep the harness, repository revision, task instructions, tool permissions and completion criteria consistent. Record accepted task results, retries, elapsed time and total billed cost, including cache writes and reads. Repeat trials because agent results vary.

If centralized provider access and billing are your main requirements, include Vercel AI Gateway in that evaluation.

Try Weave Router with your existing coding setup.

FAQs

What is an LLM router?

An LLM router selects a model for each request based on factors such as predicted quality, cost, or availability. Weave Router scores every upstream API request with an on-box cluster scorer. Request-level selection can reduce model spend while preserving stronger models for harder work.

How does an LLM router differ from an AI gateway?

An LLM router chooses which model should handle a request, while an AI gateway manages access, retries, limits, and provider failures. Products can combine both functions. Vercel documents coding-agent support, provider controls and configured model fallbacks; Weave documents per-action scoring and compatible proxy endpoints. Inspect the configured model policy and test its results.

Is Weave Router self-hosted or open source?

Weave Router supports hosted and fully self-hosted deployment. The README at the reviewed source commit identifies Apache-2.0 beginning with release router-v0.2.24; earlier releases keep their original licenses. In self-hosted mode, provider keys stay on your infrastructure. Review the hosted service’s credential and data handling separately.

Does model routing hurt code quality?

Model routing can reduce quality when a router sends difficult requests to models that cannot handle them. Compare accepted results, test failures and retries on your own tasks. The published Weave benchmarks show a cost and solve-rate tradeoff on specific task sets; they do not guarantee the same result on your repositories.

Can you force a specific model when the router picks wrong?

Model pinning overrides automated selection for a defined session. Weave Router supports per-session model forcing and lets you turn routing off without removing its configuration. You can keep automated routing as the default while retaining manual control for sensitive work.

What is the best coding agent router for Claude Code or Codex?

We recommend starting with Weave Router when you want automatic model selection across Claude Code and Codex, public source code and a self-hosted option. Compare Vercel AI Gateway for shared gateway controls and OpenRouter Auto Router for managed selection. Use the same coding tasks and completion checks to compare accepted results, total cost and elapsed time.