OmniRoute Auto-Combo Engine (Português (Brasil))

2. cost / eco — provedor saudável mais barato

Ordena o conjunto de candidatos por costPer1MTokens (em ordem crescente) e seleciona o mais barato. Primeiro, filtra os candidatos com estado 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 /* ... */ };
  }
}

Quando usar: Cargas de trabalho sensíveis a custos, processamento em lote ou tarefas em segundo plano.

Aliases: cost, eco

---

3. latency / fast — menor latência p95 com penalidade de confiabilidade

Ordena por p95LatencyMs + (errorRate * 1000). A penalidade da taxa de erros garante que provedores não confiáveis tenham uma classificação inferior, mesmo que sua latência nominal seja baixa.

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 /* ... */ };
  }
}

Quando usar: Cargas de trabalho sensíveis à latência, como chat em tempo real, preenchimento automático ou assistentes de programação interativos.

Aliases: latency, fast

---

4. sla-aware / sla — conformidade com SLOs de latência/erro/custo

Atribui uma pontuação a cada candidato de acordo com o quanto ele atende à política de SLO configurada:

Fator	Peso	Fórmula
Pontuação de latência	35%	threshold / max(value, ε)
Pontuação de erro	35%	threshold / max(value, ε)
Pontuação de integridade	15%	1.0 (CLOSED) / 0.5 (HALF_OPEN) / 0.0 (OPEN)
Pontuação de custo	10%	threshold / max(value, ε) ou inversa normalizada
Pontuação de estabilidade	5%	desvio padrão de latência normalizado inversamente

Quando hardConstraints: true, os candidatos são ordenados principalmente pela pontuação de violação (o quanto excedem qualquer SLO) e, depois, pela pontuação composta. Caso contrário, usa-se apenas a pontuação composta.

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) {
    // ... pontua cada candidato em relação à política: { targetP95Ms, maxErrorRate, maxCostPer1MTokens, hardConstraints }
  }
}

Campos de SLA (definidos na configuração combinada):

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

Quando usar: Cargas de trabalho de produção com orçamentos rígidos de latência, taxa de erros ou custo.

Aliases: sla-aware, sla

---

5. lkgp — último provedor em bom estado conhecido primeiro

Tenta primeiro o último provedor em bom estado conhecido (se estiver definido) e, depois, recorre à estratégia rules. Útil para afinidade de sessão — o mesmo provedor processa as solicitações subsequentes de uma conversa.

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 /* ... */ };
      }
    }

    // Recorre à estratégia rules
    return getStrategy("rules").select(pool, context);
  }
}

Quando usar: Conversas com vários turnos nas quais você deseja que o mesmo provedor processe as solicitações subsequentes (por exemplo, para cache, continuidade de contexto ou consistência de preços).

Alias: lkgp (sem alias)

---

Estratégias personalizadas de roteamento

Você pode registrar sua própria implementação de RouterStrategy por meio da API pública:

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) {
    // Sua lógica de roteamento aqui
    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());

Em seguida, use-a:

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

---

Guia de seleção de estratégias de roteamento

Caso de uso	Estratégia	Motivo
Carga de trabalho equilibrada	rules	Padrão — considera todos os fatores
Minimizar custo	cost	Sempre escolhe o mais barato
Minimizar latência	latency	Escolhe o provedor confiável mais rápido
SLOs rígidos	sla-aware	Filtra por limites de p95/erro/custo
Chat com vários turnos	lkgp	Afinidade de sessão

Campos para SLA-aware:

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

Adequação a tarefas

Mais de 30 modelos avaliados em 6 tipos de tarefa (coding, review, planning, analysis, debugging, documentation). Oferece suporte a padrões curinga (por exemplo, *-coder → pontuação alta em programação).

Recapitulação das variantes Auto

Incluindo o auto simples (padrão), além dos 6 valores de AutoVariant declarados em autoPrefix.ts, existem 7 IDs de modelo que podem ser invocados:

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

(O próprio AutoVariant enumera 6 valores; a 7ª opção é “sem variante” — o auto simples — tratada por parseAutoPrefix() como variant: undefined.)

Como os níveis se encaixam no Auto-Combo

A função de pontuação de 16 fatores (open-sse/services/autoCombo/scoring.ts) trata a associação a níveis como dois sinais: tierPriority (0.0476) e tierAffinity (0.0476). Consulte a tabela canônica de fatores de pontuação acima para ver o conjunto completo de DEFAULT_WEIGHTS — as substituições por pacote (ship-fast/cost-saver/quality-first/ offline-friendly) estão listadas na tabela “Perfis de peso por pacote”.

O nível, por si só, não força o Nível 1 a vir primeiro — se a latência do Nível 1 for ruim ou a relação custo-qualidade não for ideal, o Nível 2 vence. Para forçar a ordenação por nível, use a estratégia de combinação priority e organize os provedores por nível.

Para favorecer fortemente o Nível 1 (assinatura), aumente o peso de tierPriority:

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

Consulte docs/marketing/TIERS.md para ver as definições dos níveis e a classificação dos provedores.

Testes e cobertura

Matriz determinística de decisões de roteamento (npm run test:combo:matrix)

tests/integration/combo-matrix/*.test.ts comprova a decisão de roteamento de todas as 19 estratégias públicas de ponta a ponta, passando pelo pipeline real de combinação com um upstream simulado. A cobertura inclui:

• Todas as 19 estratégias de ROUTING_STRATEGY_VALUES (ordered, weighted, cost, context, fusion, …).
• quota-share (interna) de ponta a ponta: equidade DRR + redução de prioridade por saturação por meio do ponto de integração real selectQuotaShareTarget (registerQuotaFetcher / setLKGP / __setHeadroomSaturationFetcherForTests).
• Cobertura de transferência universal de context-relay para todas as quantidades de destinos.

Esse conjunto é executado na CI (job test:integration) com --test-concurrency=1 e --test-force-exit, portanto é determinístico e não exige credenciais reais.

Smoke test real controlado (NÃO executado na CI — provedores reais)

Comando	O que faz
npm run test:combo:live	Roteamento real no processo com RUN_COMBO_LIVE=1; captura um snapshot de um banco de dados ativo do OmniRoute
npm run test:combo:live:vps	Chamadas HTTP para um servidor OmniRoute ativo (defina COMBO_LIVE_BASE_URL)
npm run test:combo:live:vps:failover	O mesmo, com cenários deliberados de failover

Esses smoke tests exercitam o caminho real da comunicação (combinação → provedor → conclusão). Eles são intencionalmente excluídos da CI porque exigem credenciais reais e acesso a VPS.

---

Arquivos

Arquivo	Finalidade
open-sse/services/autoCombo/scoring.ts	Função de pontuação com 16 fatores, DEFAULT_WEIGHTS, norma do pool
open-sse/services/autoCombo/taskFitness.ts	Consulta de adequação entre modelo × tarefa
open-sse/services/autoCombo/engine.ts	Lógica de seleção, bandit, limite de orçamento
open-sse/services/autoCombo/selfHealing.ts	Exclusão, sondagens, modo de incidente
open-sse/services/autoCombo/modePacks.ts	6 perfis de pesos (ship-fast, cost-saver, quality-first, offline-friendly, reliability-first, chaos-mode)
open-sse/services/autoCombo/autoPrefix.ts	Analisador do prefixo auto/ + 6 variantes
open-sse/services/autoCombo/virtualFactory.ts	Cria uma AutoComboConfig em memória a partir de conexões ativas
open-sse/services/autoCombo/providerRegistryAccessor.ts	Gancho de teste para simular o registro de provedores
src/shared/constants/routingStrategies.ts	ROUTING_STRATEGY_VALUES (19 estratégias)
src/sse/handlers/chat.ts	Integração: curto-circuito do prefixo auto

---

Código-fonte do OmniRoute (a58000c7685f)