OmniRoute Auto-Combo Engine (Français)

2. cost / eco — fournisseur opérationnel le moins cher

Trie le pool de candidats par costPer1MTokens (ordre croissant) et sélectionne le moins cher. Élimine d’abord les candidats à l’état OPEN.

class CostStrategyImpl implements RouterStrategy {
  readonly name = "cost";
  readonly description = "Always selects cheapest available provider";

  select(pool, context) {
    const healthy = pool.filter((c) => c.circuitBreakerState !== "OPEN");
    const sorted = [...healthy].sort((a, b) => a.costPer1MTokens - b.costPer1MTokens);
    return { provider: sorted[0].provider /* ... */ };
  }
}

Quand l’utiliser : charges de travail sensibles aux coûts, traitement par lots ou tâches en arrière-plan.

Alias : cost, eco

---

3. latency / fast — latence p95 la plus faible avec pénalité de fiabilité

Trie selon p95LatencyMs + (errorRate * 1000). La pénalité liée au taux d’erreur garantit que les fournisseurs peu fiables sont moins bien classés, même si leur latence nominale est faible.

class LatencyStrategyImpl implements RouterStrategy {
  readonly name = "latency";
  readonly description = "Prioritizes lowest p95 latency with reliability weighting";

  select(pool, context) {
    const healthy = pool.filter((c) => c.circuitBreakerState !== "OPEN");
    const sorted = [...healthy].sort(
      (a, b) => a.p95LatencyMs + a.errorRate * 1000 - (b.p95LatencyMs + b.errorRate * 1000)
    );
    return { provider: sorted[0].provider /* ... */ };
  }
}

Quand l’utiliser : Charges de travail sensibles à la latence, comme le chat en temps réel, l’autocomplétion ou les assistants de programmation interactifs.

Alias : latency, fast

---

4. sla-aware / sla — conformité aux SLO de latence/d’erreur/de coût

Attribue un score à chaque candidat selon son niveau de conformité à la politique SLO configurée :

Facteur	Pondération	Formule
Score de latence	35%	threshold / max(value, ε)
Score d’erreur	35%	threshold / max(value, ε)
Score de santé	15%	1.0 (CLOSED) / 0.5 (HALF_OPEN) / 0.0 (OPEN)
Score de coût	10%	threshold / max(value, ε) ou inverse normalisée
Score de stabilité	5%	écart-type de latence normalisé inversement

Lorsque hardConstraints: true, les candidats sont principalement triés selon leur score de violation (l’ampleur du dépassement des SLO), puis selon leur score composite. Sinon, seul le score composite est utilisé.

class SLAStrategyImpl implements RouterStrategy {
  readonly name = "sla-aware";
  readonly description =
    "Selects the provider most likely to satisfy latency, error-rate, and cost SLOs";

  select(pool, context) {
    // ... attribue un score à chaque candidat par rapport à la politique : { targetP95Ms, maxErrorRate, maxCostPer1MTokens, hardConstraints }
  }
}

Champs SLA (définis dans la configuration combinée) :

{
  "strategy": "auto",
  "config": {
    "routerStrategy": "sla-aware",
    "slaTargetP95Ms": 1500,
    "slaMaxErrorRate": 0.05,
    "slaMaxCostPer1MTokens": 5,
    "slaHardConstraints": true
  }
}

Quand l’utiliser : Charges de travail de production soumises à des budgets stricts de latence, de taux d’erreur ou de coût.

Alias : sla-aware, sla

---

5. lkgp — dernier fournisseur fonctionnel connu en premier

Essaie d’abord le dernier fournisseur fonctionnel connu (s’il est défini), puis se rabat sur la stratégie rules. Utile pour l’affinité de session : le même fournisseur traite les requêtes de suivi d’une conversation.

class LKGPStrategyImpl implements RouterStrategy {
  readonly name = "lkgp";
  readonly description = "Tries last known good provider first, then falls back to rules";

  select(pool, context) {
    if (context.lkgpEnabled === false) {
      return getStrategy("rules").select(pool, context);
    }

    if (context.lastKnownGoodProvider) {
      const candidates = pool.filter(
        (c) => c.provider === context.lastKnownGoodProvider && c.circuitBreakerState !== "OPEN"
      );
      if (candidates.length > 0) {
        return { provider: candidates[0].provider /* ... */ };
      }
    }

    // Repli sur la stratégie rules
    return getStrategy("rules").select(pool, context);
  }
}

Quand l’utiliser : Conversations à plusieurs tours pour lesquelles vous souhaitez que le même fournisseur traite les requêtes de suivi (par exemple, pour la mise en cache, la continuité du contexte ou la cohérence tarifaire).

Alias : lkgp (aucun autre alias)

---

Stratégies de routage personnalisées

Vous pouvez enregistrer votre propre implémentation de RouterStrategy via l’API publique :

import {
  registerStrategy,
  type RouterStrategy,
} from "@omniroute/open-sse/services/autoCombo/routerStrategy";

class MyCustomStrategy implements RouterStrategy {
  readonly name = "my-custom";
  readonly description = "My custom routing strategy";

  select(pool, context) {
    // Votre logique de routage ici
    return {
      provider: pool[0].provider,
      model: pool[0].model,
      strategy: this.name,
      reason: "MyCustomStrategy: ...",
      candidatesConsidered: pool.length,
      finalScore: 1.0,
    };
  }
}

registerStrategy("my-custom", new MyCustomStrategy());

Puis utilisez-la :

{
  "strategy": "auto",
  "config": {
    "routerStrategy": "my-custom"
  }
}

---

Guide de sélection d’une stratégie de routage

Cas d’utilisation	Stratégie	Raison
Charge équilibrée	rules	Par défaut — prend en compte tous les facteurs
Réduire le coût	cost	Choisit toujours le moins cher
Réduire la latence	latency	Choisit le fournisseur fiable le plus rapide
SLO stricts	sla-aware	Filtre selon les seuils p95/erreur/coût
Chat à plusieurs tours	lkgp	Affinité de session

Champs SLA :

{
  "strategy": "auto",
  "config": {
    "routerStrategy": "sla-aware",
    "slaTargetP95Ms": 1500,
    "slaMaxErrorRate": 0.05,
    "slaMaxCostPer1MTokens": 5,
    "slaHardConstraints": true
  }
}

Adéquation aux tâches

Plus de 30 modèles évalués sur 6 types de tâches (coding, review, planning, analysis, debugging, documentation). Prend en charge les motifs génériques (par ex., *-coder → score élevé en programmation).

Récapitulatif des variantes Auto

En incluant auto seul (valeur par défaut) ainsi que les 6 valeurs AutoVariant déclarées dans autoPrefix.ts, il existe 7 ID de modèle invocables :

auto, auto/coding, auto/fast, auto/cheap, auto/offline, auto/smart, auto/lkgp

(AutoVariant lui-même énumère 6 valeurs ; la 7e option correspond à « aucune variante » — auto seul — gérée par parseAutoPrefix() sous la forme variant: undefined.)

Intégration des niveaux dans Auto-Combo

La fonction de notation à 16 facteurs (open-sse/services/autoCombo/scoring.ts) traite l’appartenance à un niveau comme deux signaux : tierPriority (0.0476) et tierAffinity (0.0476). Consultez le tableau canonique des facteurs de notation ci-dessus pour l’ensemble complet de DEFAULT_WEIGHTS — les substitutions propres à chaque pack (ship-fast/cost-saver/quality-first/ offline-friendly) sont répertoriées dans le tableau « Weight profiles per pack ».

Le niveau seul ne force pas le niveau 1 à être prioritaire — si la latence du niveau 1 est mauvaise ou si le rapport coût-qualité est sous-optimal, le niveau 2 l’emporte. Pour imposer l’ordre des niveaux, utilisez la stratégie de combinaison priority et classez les fournisseurs par niveau.

Pour favoriser fortement le niveau 1 (abonnement), augmentez le poids de tierPriority :

{
  "strategy": "auto",
  "config": { "auto": { "weights": { "tierPriority": 0.3, "costInv": 0.05 } } }
}

Consultez docs/marketing/TIERS.md pour les définitions des niveaux et la classification des fournisseurs.

Tests et couverture

Matrice déterministe des décisions de routage (npm run test:combo:matrix)

tests/integration/combo-matrix/*.test.ts vérifie de bout en bout la décision de routage des 19 stratégies publiques à travers le véritable pipeline de combinaison, avec un service en amont simulé. La couverture comprend :

• Les 19 stratégies ROUTING_STRATEGY_VALUES (ordered, weighted, cost, context, fusion, …).
• quota-share (interne) de bout en bout : équité DRR + dépriorisation en cas de saturation via le véritable point d’intégration selectQuotaShareTarget (registerQuotaFetcher / setLKGP / __setHeadroomSaturationFetcherForTests).
• La couverture du transfert universel de context-relay pour chaque nombre de cibles.

Cette suite s’exécute dans la CI (tâche test:integration) avec --test-concurrency=1 et --test-force-exit afin d’être déterministe et de ne nécessiter aucun identifiant réel.

Tests rapides réels soumis à condition (PAS dans la CI — fournisseurs réels)

Commande	Fonctionnement
npm run test:combo:live	Routage réel dans le processus avec RUN_COMBO_LIVE=1 ; capture un instantané d’une base de données OmniRoute active
npm run test:combo:live:vps	Appels HTTP vers un serveur OmniRoute actif (définissez COMBO_LIVE_BASE_URL)
npm run test:combo:live:vps:failover	Même chose, avec des scénarios de basculement délibérés

Ces tests rapides utilisent le véritable chemin de communication (combinaison → fournisseur → complétion). Ils sont intentionnellement exclus de la CI, car ils nécessitent des identifiants réels et un accès VPS.

---

Fichiers

Fichier	Objectif
open-sse/services/autoCombo/scoring.ts	Fonction de notation à 16 facteurs, DEFAULT_WEIGHTS, normalisation du pool
open-sse/services/autoCombo/taskFitness.ts	Table de correspondance d’adéquation modèle × tâche
open-sse/services/autoCombo/engine.ts	Logique de sélection, bandit, plafond budgétaire
open-sse/services/autoCombo/selfHealing.ts	Exclusion, sondes, mode incident
open-sse/services/autoCombo/modePacks.ts	6 profils de pondération (ship-fast, cost-saver, quality-first, offline-friendly, reliability-first, chaos-mode)
open-sse/services/autoCombo/autoPrefix.ts	Analyseur du préfixe auto/ + 6 variantes
open-sse/services/autoCombo/virtualFactory.ts	Construit un AutoComboConfig en mémoire à partir des connexions actives
open-sse/services/autoCombo/providerRegistryAccessor.ts	Point d’injection de test pour simuler le registre des fournisseurs
src/shared/constants/routingStrategies.ts	ROUTING_STRATEGY_VALUES (19 stratégies)
src/sse/handlers/chat.ts	Intégration : court-circuit du préfixe auto

---

Code source d’OmniRoute (a58000c7685f)