The AI Model Routing Field Guide

What you are actually setting up

If you know OpenRouter exists but still open a model menu and wonder whether to choose Claude, Gemini, DeepSeek, GLM or whatever arrived this week, this guide is for you.

OpenRouter is a gateway to hundreds of AI models through one API and one billing account. It is not the coding assistant on your screen. OpenCode, Claude Code or another agent is the workbench; OpenRouter sits behind it and supplies the model.

You can select a specific model through OpenRouter, but you can also select a router. A router receives the prompt, decides which eligible model fits it, and sends the request to that model. That is the part that removes constant model switching.

OpenRouter

The gateway: one connection to many model companies, with consolidated billing, provider fallbacks and routing controls.

Auto Router

A general router for writing, analysis, coding and agent work. It classifies the task, then chooses one model from an eligible pool.

Pareto Code

A coding-only router. It seeks the cheapest available coding model that clears a chosen benchmark threshold.

Preset

A named OpenRouter configuration that can hold the model, provider rules, fallbacks, parameters and price ceiling.

Curated pool

Your short allow-list of models that the router may use. This is how you prevent an automatic choice becoming an unlimited spending decision.

This is not tied to one coding tool

The interface and the model behind it are separate decisions. A familiar tool may be able to send work to another provider, but that capability belongs to the specific surface you are using. A shell launcher, a desktop chat and a desktop coding session may all say "Claude" while following different configuration and billing paths.

OpenCode is the easiest place to expose the full menu. It supports more than 75 providers, includes an OpenRouter connection, and lets you add named model entries to its picker. That makes it a good home for Everyday, Quality and Frontier choices.

Terminal Claude Code can also run through OpenRouter. A shell function can set OpenRouter's Anthropic-compatible endpoint, API key and model mappings before it launches Claude Code. That opens access to OpenRouter models and routers inside a familiar terminal agent, although compatibility varies and OpenRouter recommends its Anthropic first-party provider path when maximum Claude Code compatibility matters.

Claude Desktop can use another inference provider, but it does not inherit your shell switch. Current builds have a separate Third-Party Inference mode, configured under Developer → Configure Third-Party Inference. It can point Chat, Cowork and Code at Anthropic, Bedrock, Vertex, Foundry or a compatible gateway, with its own model list, labels and pricing. This is a deployment-level configuration that takes effect after restarting the app, not a per-session equivalent of a Fish function such as cc_openrouter.

Your own scripts and agents can use the same presets. A preset is a stable model-like name, so several tools can share the same limits without each carrying a separate copy of the policy.

Venice is a separate route, not another OpenRouter mode. Venice offers an OpenAI-compatible API, private inference options and monthly API credits on paid plans. It can power coding tools too, but it does not give you OpenRouter Auto or Pareto. A separate Venice field guide is coming because the economics and model-selection strategy are different.

Why automatic routing is worth using

There is no single "best AI model" any more. The model that is excellent at planning may be wasteful for a small edit. The cheap model that writes clean code may be the wrong model for image analysis. New releases change the answer again next week.

An automatic router can inspect the task and choose for you. The dangerous version is to give that router the entire market and hope it shares your attitude to money. The useful version is automatic choice inside a fenced garden: a short list of models you trust, a quality band you chose, and a hard price ceiling the router cannot override.

The setup most people should start with

1. Use Auto for mixed work. Let it classify writing, coding, analysis and tool tasks rather than forcing one model to handle everything.
2. Create three visible quality choices. Everyday is the default, Quality is a manual step-up, and Frontier is a deliberate exception.
3. Give each choice a curated pool. Three to five models is enough. Include different strengths rather than four near-identical premium models.
4. Add hard input and output price ceilings. A cost tier influences selection; a provider ceiling actually blocks overspend.
5. Use Pareto as a coding reference. It is valuable evidence for coding work, but it should not silently rewrite a general writing-and-analysis pool.
6. Review real outcomes. Router popularity tells you what the market uses. Your own good and bad sessions tell you what deserves to remain.

Four decisions hiding behind one dropdown

"Which model should I use?" sounds like one decision. It is actually four, and each belongs in a different layer.

1. Classify the work

OpenRouter's Auto Router classifies each prompt into one of roughly 30 task types: debugging, multi-step planning, research, copywriting and so on. That is what makes one OpenCode choice useful across mixed work.

2. Select an eligible model

Auto uses the trailing seven-day share of spend for that task type as a market signal. The cost tier and your allow-list narrow the candidates. It follows what people are actually paying to use, not a benchmark and not your personal evaluation.

3. Enforce the ceiling

A cost tier is a preference band. It is not a budget limit. The provider-level max_price filter is the hard boundary. If nothing qualifies, the request fails instead of escaping to an expensive model.

4. Pick a provider

Several companies may serve the same model. Their speed, price and capacity differ. Provider routing chooses an endpoint and keeps fallbacks ready for outages or rate limits without changing the underlying model unless the model-routing strategy says to.

Create three choices, not a model zoo

The person doing the work should choose a quality posture, not memorise model names. Name the choices so they sort together in the picker. Each can contain several models, while the router still selects only one model for each request.

Presets: the named configuration layer

An OpenRouter preset is a versioned configuration exposed as a model-like slug: @preset/name. It can store model choice, provider rules, generation settings, prompts and tools. That lets a harness call a stable name while the configuration evolves behind it.

There was one wrinkle in the live build: the Preset API stored the Auto model and provider ceiling, but did not retain the Auto plugin settings. So the controls are deliberately split:

• OpenRouter preset: stable name, Auto model, provider price sorting, fallbacks, privacy rule and hard price ceiling.
• OpenCode model entry: the Auto cost tier and exact allowed-model list.

That is not theoretical. A deliberately fake allow-list failed with "no models match". A Fable-only request under a cheap ceiling also failed. Neither silently escaped the restriction.

// The shape, simplified
{
  "model": "openrouter/auto",
  "plugins": [{
    "id": "auto-router",
    "cost_tier": "low",
    "allowed_models": ["deepseek/...", "z-ai/...", "openai/...", "google/..."]
  }],
  "provider": {
    "sort": "price",
    "allow_fallbacks": true,
    "max_price": { "prompt": 1, "completion": 5 }
  }
}

Auto and Pareto are not the same thing

Why does Pareto show only one model?

Because one request is ultimately served by one model. Pareto computes the efficient coding frontier, finds the cheapest available candidate above the requested threshold, and returns that serving model. It also prepares up to two same-tier fallbacks for transient failures, but they are not three simultaneous answers and the response names the model that actually ran.

In one constrained test, Pareto Low, Medium and High all returned Gemini 3.8 Flash. That did not mean the tiers were identical. It meant the price ceiling and current endpoint availability left Gemini as the serving candidate each time.

What testing revealed

Are the probes good enough?

A one-line welcome message and a toy JavaScript function are smoke tests. They prove the router is alive; they do not prove it is seeing your real work. The first draft used probes like that, and they were not robust enough to promote a model.

The production scout now uses nine realistic prompts:

• Writing: conversion copy, editing and plain-English explanation.
• Code: debugging, implementation with tests and service architecture.
• Analysis: risk ranking, option comparison and implementation planning.

Each runs through Everyday Auto (Low tier) and Quality Auto (Medium tier). Router metadata records the task classification, the serving model and billed cost. A new model must win at least two probes in one run, repeat that in a second weekly run, remain under the hard ceiling and pass the frontier exclusions before it can join a pool.

Which mode should you choose?

Start from Everyday. Tick the statements that are true about the task in front of you.

Planning, building and review

Use Everyday for the first pass and routine implementation. Step up to Quality at a real phase boundary when the plan is complex, the bug is stubborn or the review matters. Frontier is not the automatic third stage. It is the manual exception after evidence says the cheaper pools are not enough.

Writing, images and code

Auto can route writing, analysis, code and image understanding if the pool contains a multimodal model and an image is attached. Image generation is different: it needs an image-generation model or tool exposed by the harness. A model selector does not magically install an image generator.

Long sessions

Routers use short-lived affinity and model switching can rebuild prompt caches. For a long plan-build-review job, deliberate mode changes at phase boundaries are more predictable than expecting every turn in one enormous conversation to jump models perfectly.

Add a weekly learning loop

A small scheduled scout can test the routers every week and report what changed. On a Mac, Launchd is the right scheduler. The job should call OpenRouter directly; there is no reason to wake a coding assistant just to run a timer. Its report should show:

• Every selectable mode, its current four models and hard cap.
• The Everyday Auto (Low) and Quality Auto (Medium) winners across the nine realistic probes.
• OpenRouter's classifier tags, so bad probes cannot masquerade as good evidence.
• Pareto Low, Medium and High as a read-only coding comparison.
• Exactly what changed, if anything.
• The exact probe cost for the run, split by tier, plus cumulative scout spend.

Seven traps

1. Treating Low, Medium and High as fixed prices. They are task-relative bands. Add a hard ceiling.
2. Calling Auto a budget. It is a selector. The provider filter is the budget boundary.
3. Assuming Pareto High means "best cheap model". It means cheapest coding model above a high relative score. That can be frontier.
4. Confusing one serving model with one-model configuration. A pool can contain four models while each request still returns one winner.
5. Promoting from toy prompts. Probe the work you actually do and inspect the classifier tag.
6. Letting a benchmark rewrite a general-purpose pool. Pareto stays observational because it measures coding only.
7. Automating frontier escalation. Make expensive capability a visible, manual choice.

A sensible starting recipe

1. Create three named presets that sort together: Everyday, Quality, Frontier.
2. Put three to five known models in each pool. Include one multimodal option if you inspect images.
3. Set both input and output price ceilings. Test that an over-ceiling request fails.
4. Make Everyday the only default. Label Frontier "manual only" in the name.
5. Run realistic prompts through Everyday Auto (Low) and Quality Auto (Medium). Capture router metadata and actual cost.
6. Keep Pareto as a coding signal unless your whole workload is coding.
7. Record whether real sessions were good enough. Replace market opinion with personal evidence over time.

Primary sources

• OpenRouter overview and quickstart
• OpenRouter Presets
• Auto Router
• Pareto Router
• Provider routing and max_price
• Router metadata
• Prompt caching
• OpenCode integration
• Claude Code integration
• Claude Code LLM gateway configuration
• Claude Desktop third-party inference configuration
• Claude Desktop enterprise configuration
• OpenCode providers
• Venice API and coding-tool guides
• Venice plans and API credits