Provider Routing
When using OpenRouter as your LLM provider, Nastech Agent supports provider routing — fine-grained control over which underlying AI providers handle your requests and how they're prioritized.
OpenRouter routes requests to many providers (e.g., Anthropic, Google, AWS Bedrock, Together AI). Provider routing lets you optimize for cost, speed, quality, or enforce specific provider requirements.
Nastech Portal decides routing centrally per model and does not accept caller-supplied provider preferences; Nastech never sends the provider object to Portal, so provider_routing is simply ignored there.
Configuration
Add a provider_routing section to your ~/.nastech/config.yaml:
provider_routing:
sort: "price" # How to rank providers
only: [] # Whitelist: only use these providers
ignore: [] # Blacklist: never use these providers
order: [] # Explicit provider priority order
require_parameters: false # Only use providers that support all parameters
data_collection: null # Control data collection ("allow" or "deny")
Provider routing only applies when using OpenRouter. It has no effect on Nastech Portal or direct provider connections (e.g., connecting directly to the Anthropic API).
Options
sort
Controls how OpenRouter ranks available providers for your request.
| Value | Description |
|---|---|
"price" | Cheapest provider first |
"throughput" | Fastest tokens-per-second first |
"latency" | Lowest time-to-first-token first |
provider_routing:
sort: "price"
only
Whitelist of provider slugs. When set, only these providers will be used. All others are excluded. Use the lowercase slug shown by OpenRouter for each provider.
provider_routing:
only:
- "anthropic"
- "google"
ignore
Blacklist of provider names. These providers will never be used, even if they offer the cheapest or fastest option.
provider_routing:
ignore:
- "together"
- "deepinfra"
order
Explicit priority order. Providers listed first are preferred. Unlisted providers are used as fallbacks.
provider_routing:
order:
- "anthropic"
- "google"
- "amazon-bedrock"
require_parameters
When true, OpenRouter will only route to providers that support all parameters in your request (like temperature, top_p, tools, etc.). This avoids silent parameter drops.
provider_routing:
require_parameters: true
data_collection
Controls whether providers can use your prompts for training. Options are "allow" or "deny".
provider_routing:
data_collection: "deny"
Per-model overrides (models)
Pin a different provider set per model. Keys under models are model ids; each entry takes the same
sort / only / ignore / order / require_parameters / data_collection keys and overrides the
flat value for that model only. Anything you don't set per model falls through to the flat defaults.
provider_routing:
sort: "price" # applies to every model
models:
"openai/gpt-6-astra":
only: ["openai"] # never let a reseller serve this one
"anthropic/claude-fable-5.1":
only: ["anthropic"]
"moonshotai/kimi-k2.6":
order: ["moonshotai", "together"]
sort: "throughput"
Matching is spelling-tolerant like agent.reasoning_overrides (claude-fable-5.1 / claude-fable-5-1,
with or without the openrouter/ prefix). The override follows the model the agent is currently on, so
/model switches, fallback activation, cron jobs, and delegated subagents on another model each get their
own pins. Edit config.yaml directly for these keys: model ids contain dots, which nastech config set
reads as path separators.
Practical Examples
Optimize for Cost
Route to the cheapest available provider. Good for high-volume usage and development:
provider_routing:
sort: "price"
Optimize for Speed
Prioritize low-latency providers for interactive use:
provider_routing:
sort: "latency"
Optimize for Throughput
Best for long-form generation where tokens-per-second matters:
provider_routing:
sort: "throughput"
Lock to Specific Providers
Ensure all requests go through a specific provider for consistency:
provider_routing:
only:
- "anthropic"
Avoid Specific Providers
Exclude providers you don't want to use (e.g., for data privacy):
provider_routing:
ignore:
- "together"
- "lepton"
data_collection: "deny"
Preferred Order with Fallbacks
Try your preferred providers first, fall back to others if unavailable:
provider_routing:
order:
- "anthropic"
- "google"
require_parameters: true
How It Works
Provider routing preferences are passed to OpenRouter on agent chat requests and iteration-limit summaries via the extra_body.provider field. (extra_body is the OpenAI Python SDK argument; it becomes the top-level provider object in the JSON request.) Auxiliary tasks such as compression and title generation are configured independently under auxiliary.<task>.extra_body.
- CLI mode — configured in
~/.nastech/config.yaml, loaded at startup - Gateway mode — same config file, loaded when the gateway starts
The routing config is read from config.yaml and passed as parameters when creating the AIAgent:
providers_allowed ← from provider_routing.only
providers_ignored ← from provider_routing.ignore
providers_order ← from provider_routing.order
provider_sort ← from provider_routing.sort
provider_require_parameters ← from provider_routing.require_parameters
provider_data_collection ← from provider_routing.data_collection
You can combine multiple options. For example, sort by price but exclude certain providers and require parameter support:
provider_routing:
sort: "price"
ignore: ["together"]
require_parameters: true
data_collection: "deny"
Default Behavior
When no provider_routing section is configured (the default), the aggregator uses its own default routing logic, which generally balances cost and availability automatically.
Provider routing controls which sub-providers behind OpenRouter handle your requests. For automatic failover to an entirely different provider when your primary model fails, see Fallback Providers.