# OmniRoute Auto-Combo Scoring Factors Explained: 15 IS Factors for AI Model Routing

> Discover the 15 IS factors OmniRoute's Auto-Combo scoring engine uses for AI model routing. Understand how OmniRoute optimizes provider-model selection for better performance.

- Repository: [Diego Rodrigues de Sa e Souza/OmniRoute](https://github.com/diegosouzapw/OmniRoute)
- Tags: deep-dive
- Published: 2026-08-25

---

**OmniRoute's Auto-Combo engine evaluates each provider-model candidate using 15 distinct scoring factors defined in `ScoringFactors` interface and combined via weighted sum in `calculateScore()`.**

The Auto-Combo scoring engine is the heart of OmniRoute's intelligent routing system. Located in [`open-sse/services/autoCombo/scoring.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/scoring.ts), it implements a weighted multi-factor decision matrix that ranks provider-model pairs for every incoming request. This article breaks down all 15 **Input-Scoring (IS) factors** that power this engine.

## Core Scoring Factors

The `ScoringFactors` interface defines the complete set of signals used to evaluate candidates. These factors fall into four logical groups: resource health, performance efficiency, routing alignment, and operational constraints.

### Resource and Health Factors

These four factors assess provider viability and remaining capacity:

- **quota** — Percentage of quota remaining (0–100%). Higher remaining quota yields higher scores.
- **health** — Circuit-breaker state mapping: CLOSED → 1.0, HALF_OPEN → 0.5, OPEN → 0. Degraded providers are deprioritized.
- **resetWindowAffinity** — Preference for providers with nearer quota-reset windows. Providers resetting sooner score higher, maximizing usable quota.
- **quality** (optional) — Feedback-driven quality signal from the routing-event quality tracker. Defaults to neutral 0.5 when unavailable.

### Performance Efficiency Factors

These four factors optimize for speed, cost, and stability:

- **costInv** — Inverse cost signal normalized against the pool's maximum cost. Cheaper providers receive higher scores.
- **latencyInv** — Inverse latency normalized against the pool's maximum latency. Faster providers are preferred.
- **stability** — Derived from latency standard deviation. Lower variance indicates more predictable performance and higher scores.
- **connectionDensity** — Penalty factor that discourages over-concentration on specific providers, encouraging load distribution across the pool.

### Routing Alignment Factors

These four factors match requests to appropriate provider capabilities:

- **taskFit** — Fitness score measuring how well a model matches the requested task type, computed via task-specific fitness functions.
- **tierPriority** — Account tier ranking: Ultra > Pro > Standard > Free, combined with quota-reset interval considerations.
- **tierAffinity** — Affinity to tiers recommended by routing hints in request manifests.
- **specificityMatch** — Alignment between provider specificity and routing hint requirements.

### Session and Context Factors

These three factors maintain routing consistency and cache efficiency:

- **contextAffinity** — Score for maintaining the same provider/account/model path within a session.
- **cacheAffinity** (optional) — Preference for providers matching the stable prompt-cache key selection.
- **sessionAvailability** (optional) — Provider availability status for the current user session.

## How Scoring Factors Are Calculated

The `calculateScore()` function in [`scoring.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/scoring.ts) combines all factors with their corresponding weights from `ScoringWeights` configuration. The engine supports both default weights and custom mode-packs for different routing strategies.

### Factor Calculation Flow

```

calculateFactors() → individual factor values
        ↓
normalizeScoringWeights() → weight normalization (sum to 1.0)
        ↓
calculateScore() → weighted sum → final ranking score

```

## Practical Implementation Examples

### Using Built-In Default Weights

```typescript
import {
  scorePool,
  DEFAULT_WEIGHTS,
} from '@omniroute/open-sse/services/autoCombo/scoring';

const ranked = scorePool(
  candidates,
  'coding',                // task type
  DEFAULT_WEIGHTS,         // built-in weight distribution
  (model, task) => 0.8     // task-fitness function
);
console.log(ranked[0]);     // highest-scoring provider/model

```

The `DEFAULT_WEIGHTS` constant provides balanced weighting across all 15 factors suitable for general-purpose routing.

### Applying Performance-Optimized Mode-Packs

```typescript
import { scorePool } from '@omniroute/open-sse/services/autoCombo/scoring';
import { MODE_PACKS } from '@omniroute/open-sse/services/autoCombo/modePacks';

const fastPack = MODE_PACKS['ship-fast'];
const ranked = scorePool(candidates, 'coding', fastPack);

```

Mode-packs in [`modePacks.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/modePacks.ts) are predefined `ScoringWeights` bundles. The `ship-fast` pack elevates `latencyInv` and `health` weights while reducing `costInv` emphasis.

### Normalizing Custom UI Weights

```typescript
import { normalizeScoringWeights } from '@omniroute/open-sse/services/autoCombo/scoring';

const uiWeights = {
  quota: 0.2,
  health: 0.2,
  costInv: 0.2,
  latencyInv: 0.2,
  taskFit: 0.2
};
const normalized = normalizeScoringWeights(uiWeights);
// normalized now sums to 1.0

```

The `normalizeScoringWeights()` utility ensures weight validity before passing to `scorePool()`.

## Source Code Reference

The OmniRoute Auto-Combo scoring implementation spans four key files:

| File | Purpose |
|------|---------|
| [`open-sse/services/autoCombo/scoring.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/scoring.ts) | `ScoringFactors` interface, `ScoringWeights` type, `calculateScore()`, `scorePool()`, `normalizeScoringWeights()` |
| [`open-sse/services/autoCombo/modePacks.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/modePacks.ts) | Predefined weight bundles (`MODE_PACKS`) for common routing presets |
| [`open-sse/services/autoCombo/engine.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/engine.ts) | Execution orchestration, factor gathering, scoring invocation |
| [`open-sse/services/autoCombo/virtualFactory.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/virtualFactory.ts) | Virtual "auto" combo creation and scoring application |

Factor values are computed per-request in `calculateFactors()` according to the `ScoringFactors` interface definition at lines 12–31 of [`scoring.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/scoring.ts).

## Summary

- **15 scoring factors** drive OmniRoute Auto-Combo decisions, defined in the `ScoringFactors` interface
- **Four factor categories**: resource health, performance efficiency, routing alignment, and session context
- **Weighted sum aggregation** via `calculateScore()` with configurable `ScoringWeights`
- **Mode-packs** enable preset weight configurations for common routing scenarios
- **Optional factors** (`quality`, `cacheAffinity`, `sessionAvailability`) gracefully default when data unavailable

## Frequently Asked Questions

### What happens when optional scoring factors are unavailable?

Optional factors default to neutral values. According to the OmniRoute source code in [`scoring.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/scoring.ts), `quality` defaults to 0.5 when no feedback data exists. `cacheAffinity` and `sessionAvailability` contribute zero or neutral scores when their underlying data is absent, ensuring scoring continuity without degradation.

### How does OmniRoute prevent overloading a single high-scoring provider?

The `connectionDensity` factor explicitly penalizes providers with dense connection pools. This encourages distribution across available providers even when one candidate dominates other factors. Additionally, the circuit-breaker `health` factor rapidly degrades overloaded providers to HALF_OPEN or OPEN states.

### Can Auto-Combo scoring weights be customized per request?

Yes. The `scorePool()` function accepts any `ScoringWeights` configuration. Applications can define custom weights, normalize UI-provided values with `normalizeScoringWeights()`, or select from predefined `MODE_PACKS`. The engine does not require recompilation for weight changes.

### Where does taskFit get its fitness scores?

The `taskFit` factor receives scores from a pluggable task-fitness function passed to `scorePool()`. OmniRoute's implementation maps task types (coding, reasoning, creative, etc.) to model-specific fitness heuristics. This function operates independently of the core scoring engine in [`scoring.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/scoring.ts).