OmniRoute Auto/Model Variants Explained: Coding vs Fast vs Cheap vs Smart

The auto/coding, auto/fast, auto/cheap, and auto/smart variants in OmniRoute are virtual routing profiles that pre-configure scoring weights to prioritize code quality, low latency, minimal cost, or balanced quality with exploration, respectively.

OmniRoute is an open-source LLM routing proxy that lets you request models using the auto/* prefix. The suffix you choose determines how the routing engine scores and selects a provider-model combo at runtime. Understanding these OmniRoute auto/model variants is essential for optimizing your AI workload performance and cost.

---

How Auto-Combos Work Under the Hood

When you send a request with model: "auto/smart", the auto-routing handler in src/sse/handlers/autoRouting.ts parses the string, looks up the variant in AUTO_TEMPLATE_VARIANTS, and creates a virtual combo via createVirtualAutoCombo. This combo then runs through OmniRoute's standard 9-factor scoring engine with variant-specific weights.

The variant definitions live in [open-sse/services/autoCombo/builtinCatalog.ts](https://github.com/diegosouzapw/OmniRoute/blob/release/v3.8.50/open-sse/services/autoCombo/builtinCatalog.ts#L20-L28), specifically the AUTO_TEMPLATE_VARIANTS map at lines 20-28.

---

auto/coding: Quality-First for Code Generation

auto/coding prioritizes task-fit and stability for programming workloads.

• Scoring pack: coding — emphasizes quality metrics tuned for code generation
• Best for: Debugging, code completion, refactoring, technical documentation
• Behavior: Selects models with proven performance on coding benchmarks, even at higher cost or latency

Use this variant when output correctness matters more than speed or price.

curl -X POST https://your-omniroute.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
        "model": "auto/coding",
        "messages": [{ "role": "user", "content": "Write a Python function to compute Fibonacci numbers." }]
      }'

---

auto/fast: Latency-Optimized for Real-Time Use

auto/fast minimizes response time by targeting the provider with the lowest p95 latency.

• Scoring pack: ship-fast — latency-inverse weighting plus health checks
• Best for: Conversational assistants, live demos, reactive applications
• Behavior: Sacrifices some quality and cost efficiency for speed

According to the source code in [src/sse/handlers/autoRouting.ts](https://github.com/diegosouzapw/OmniRoute/blob/release/v3.8.50/src/sse/handlers/autoRouting.ts#L33-L35), this variant is resolved at lines 33-35 during request processing.

curl -X POST https://your-omniroute.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
        "model": "auto/fast",
        "messages": [{ "role": "user", "content": "What time is it in Tokyo?" }]
      }'

---

auto/cheap: Cost-First for Budget Workloads

auto/cheap (also aliased as auto/floor) selects the cheapest token-price provider that still meets basic quality thresholds.

• Scoring pack: cost-saver — sorts by price-per-token ascending
• Best for: Bulk processing, non-critical summarization, background jobs
• Behavior: Maximizes cost savings; accepts trade-offs in latency and occasionally output quality

This variant is ideal when you're processing large volumes where per-token costs accumulate quickly.

curl -X POST https://your-omniroute.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
        "model": "auto/cheap",
        "messages": [{ "role": "user", "content": "Summarise this 10-page PDF." }]
      }'

---

auto/smart: Quality with Exploration

auto/smart balances quality-first scoring with a 10% exploration boost to surface newer or under-tested models.

• Scoring pack: quality-first plus exploration factor
• Best for: Creative tasks, research, scenarios where you want optimal results but also want to discover emerging capabilities
• Behavior: 90% exploitation of proven high-quality models, 10% chance to try alternatives that might outperform

The 10% exploration factor is implemented as a configurable weight in the scoring engine, allowing the router to escape local optima in model selection.

curl -X POST https://your-omniroute.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
        "model": "auto/smart",
        "messages": [{ "role": "user", "content": "Suggest a novel plot for a sci-fi thriller." }]
      }'

---

Key Implementation Files

File Path	Purpose
open-sse/services/autoCombo/builtinCatalog.ts	Declares AUTO_TEMPLATE_VARIANTS mapping variants to scoring packs
src/sse/handlers/autoRouting.ts	Parses model strings, resolves variants, builds virtual combos
src/app/api/v1/models/catalog.ts	Exposes variants to the /v1/models discovery endpoint
src/app/api/combos/auto/route.ts	Generates virtual combo payloads for REST API requests
docs/routing/AUTO-COMBO.md	Official documentation of variant semantics and examples

---

Choosing the Right Variant

• Need working code? → auto/coding
• Need instant responses? → auto/fast
• Need to minimize spend? → auto/cheap
• Need best quality with occasional experimentation? → auto/smart

All variants use the same OpenAI-compatible endpoint. Only the model field changes, making it trivial to switch strategies without code rewrites.

---

Summary

• auto/coding — coding scoring pack; quality-first for code tasks
• auto/fast — ship-fast pack; minimum p95 latency
• auto/cheap — cost-saver pack; cheapest token price (alias: auto/floor)
• auto/smart — quality-first pack with 10% exploration boost

The OmniRoute auto/model variants are resolved at runtime through the AUTO_TEMPLATE_VARIANTS map in builtinCatalog.ts, processed by the handler in autoRouting.ts, and applied via the common 9-factor scoring engine.

---

Frequently Asked Questions

What happens if I request an unsupported auto variant?

OmniRoute returns an error through the standard /v1/models validation path. Available variants are discoverable via the catalog endpoint defined in src/app/api/v1/models/catalog.ts, which exports Object.keys(AUTO_TEMPLATE_VARIANTS).

Can I create custom auto variants?

The current implementation in builtinCatalog.ts uses a hardcoded AUTO_TEMPLATE_VARIANTS map. Extending or overriding this requires modifying the source and redeploying. The modular structure in open-sse/services/autoCombo/ suggests this could become configurable in future releases.

Do all variants support streaming responses?

Yes — the variant selection happens before the response path is determined. Once createVirtualAutoCombo resolves the provider-model pair, standard streaming behavior follows from the underlying provider configuration.

How does the 10% exploration in smart actually work?

The scoring engine applies a modified weight vector where 90% of the score derives from quality metrics (task fit, stability, benchmark performance) and 10% from randomized or novelty-biased factors. This is implemented in the same scoring loop used by all variants, just with different weight coefficients.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}