OmniRoute Auto-Combo Engine (Español)
2. cost / eco — proveedor saludable más barato
Sección titulada «2. cost / eco — proveedor saludable más barato»Ordena el conjunto de candidatos por costPer1MTokens (en orden ascendente) y selecciona el más barato.
Primero filtra los candidatos en 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 /* ... */ }; }}Cuándo usarla: cargas de trabajo sensibles al coste, procesamiento por lotes o trabajos en segundo plano.
Alias: cost, eco
3. latency / fast — menor latencia p95 con penalización por fiabilidad
Sección titulada «3. latency / fast — menor latencia p95 con penalización por fiabilidad»Ordena por p95LatencyMs + (errorRate * 1000). La penalización por tasa de errores garantiza que
los proveedores poco fiables se clasifiquen en posiciones inferiores, incluso si su latencia nominal es baja.
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 /* ... */ }; }}Cuándo usarla: Cargas de trabajo sensibles a la latencia, como chat en tiempo real, autocompletado o asistentes de programación interactivos.
Alias: latency, fast
4. sla-aware / sla — cumplimiento de los SLO de latencia/error/coste
Sección titulada «4. sla-aware / sla — cumplimiento de los SLO de latencia/error/coste»Puntúa a cada candidato según lo bien que satisfaga la política de SLO configurada:
| Factor | Peso | Fórmula |
|---|---|---|
| Puntuación de latencia | 35% | threshold / max(value, ε) |
| Puntuación de errores | 35% | threshold / max(value, ε) |
| Puntuación de salud | 15% | 1.0 (CLOSED) / 0.5 (HALF_OPEN) / 0.0 (OPEN) |
| Puntuación de coste | 10% | threshold / max(value, ε) o inversa normalizada |
| Puntuación de estabilidad | 5% | desviación estándar de latencia inversa normalizada |
Cuando hardConstraints: true, los candidatos se ordenan principalmente por puntuación de incumplimiento
(cuánto superan cualquier SLO) y, a continuación, por la puntuación compuesta. De lo contrario, se usa únicamente
la puntuación compuesta.
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) { // ... puntúa a cada candidato según la política: { targetP95Ms, maxErrorRate, maxCostPer1MTokens, hardConstraints } }}Campos de SLA (se establecen en la configuración de la combinación):
{ "strategy": "auto", "config": { "routerStrategy": "sla-aware", "slaTargetP95Ms": 1500, "slaMaxErrorRate": 0.05, "slaMaxCostPer1MTokens": 5, "slaHardConstraints": true }}Cuándo usarla: Cargas de trabajo de producción con presupuestos estrictos de latencia, tasa de errores o coste.
Alias: sla-aware, sla
5. lkgp — primero, el último proveedor conocido como válido
Sección titulada «5. lkgp — primero, el último proveedor conocido como válido»Prueba primero el último proveedor conocido como válido (si está establecido) y, después, recurre a la
estrategia rules. Resulta útil para la afinidad de sesión: el mismo proveedor gestiona
las solicitudes posteriores de una conversación.
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 /* ... */ }; } }
// Recurrir a la estrategia rules return getStrategy("rules").select(pool, context); }}Cuándo usarla: Conversaciones de varios turnos en las que se desea que el mismo proveedor gestione las solicitudes posteriores (por ejemplo, para el almacenamiento en caché, la continuidad del contexto o la coherencia de precios).
Alias: lkgp (sin alias)
Estrategias de enrutamiento personalizadas
Sección titulada «Estrategias de enrutamiento personalizadas»Puede registrar su propia implementación de RouterStrategy mediante la 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) { // Su lógica de enrutamiento aquí 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());Después, úsela:
{ "strategy": "auto", "config": { "routerStrategy": "my-custom" }}Guía de selección de estrategias de enrutamiento
Sección titulada «Guía de selección de estrategias de enrutamiento»| Caso de uso | Estrategia | Motivo |
|---|---|---|
| Carga de trabajo equilibrada | rules |
Predeterminada: considera todos los factores |
| Minimizar el coste | cost |
Siempre selecciona la opción más barata |
| Minimizar la latencia | latency |
Selecciona el proveedor fiable más rápido |
| SLO estrictos | sla-aware |
Filtra por umbrales de p95/errores/coste |
| Chat de varios turnos | lkgp |
Afinidad de sesión |
Campos compatibles con SLA:
{ "strategy": "auto", "config": { "routerStrategy": "sla-aware", "slaTargetP95Ms": 1500, "slaMaxErrorRate": 0.05, "slaMaxCostPer1MTokens": 5, "slaHardConstraints": true }}Adecuación por tarea
Sección titulada «Adecuación por tarea»Más de 30 modelos evaluados en 6 tipos de tareas (coding, review, planning, analysis, debugging, documentation). Admite patrones comodín (p. ej., *-coder → puntuación alta en programación).
Resumen de variantes automáticas
Sección titulada «Resumen de variantes automáticas»Incluyendo auto sin variante (valor predeterminado) y los 6 valores de AutoVariant declarados en autoPrefix.ts, hay 7 ID de modelo invocables:
auto, auto/coding, auto/fast, auto/cheap, auto/offline, auto/smart, auto/lkgp
(AutoVariant enumera 6 valores; la séptima opción es «sin variante» — auto sin variante — que parseAutoPrefix() gestiona como variant: undefined).
Cómo encajan los niveles en Auto-Combo
Sección titulada «Cómo encajan los niveles en Auto-Combo»La función de puntuación de 16 factores (open-sse/services/autoCombo/scoring.ts) trata la
pertenencia a un nivel como dos señales: tierPriority (0.0476) y tierAffinity (0.0476). Consulta la
tabla canónica de factores de puntuación anterior para ver el conjunto completo de
DEFAULT_WEIGHTS; las anulaciones por paquete (ship-fast/cost-saver/quality-first/
offline-friendly) aparecen en la tabla «Perfiles de ponderación por paquete».
El nivel por sí solo no fuerza que el Nivel 1 sea el primero: si la latencia del Nivel 1 es mala o
la relación coste-calidad no es óptima, gana el Nivel 2. Para forzar el orden por niveles, utiliza la
estrategia de combinación priority y organiza los proveedores por nivel.
Para favorecer claramente el Nivel 1 (suscripción), aumenta el peso de tierPriority:
{ "strategy": "auto", "config": { "auto": { "weights": { "tierPriority": 0.3, "costInv": 0.05 } } }}Consulta docs/marketing/TIERS.md para conocer las definiciones de los niveles y la clasificación de proveedores.
Pruebas y cobertura
Sección titulada «Pruebas y cobertura»Matriz determinista de decisiones de enrutamiento (npm run test:combo:matrix)
Sección titulada «Matriz determinista de decisiones de enrutamiento (npm run test:combo:matrix)»tests/integration/combo-matrix/*.test.ts demuestra la decisión de enrutamiento de las 19
estrategias públicas de extremo a extremo mediante el flujo real de combinación con un servicio ascendente simulado.
La cobertura incluye:
- Las 19 estrategias de
ROUTING_STRATEGY_VALUES(ordered, weighted, cost, context, fusion, …). quota-share(interna) de extremo a extremo: equidad DRR + pérdida de prioridad por saturación mediante el punto de integración realselectQuotaShareTarget(registerQuotaFetcher/setLKGP/__setHeadroomSaturationFetcherForTests).- Cobertura de transferencia universal de
context-relaypara cada número de destinos.
Este conjunto se ejecuta en CI (trabajo test:integration) con --test-concurrency=1 y
--test-force-exit, por lo que es determinista y no requiere credenciales reales.
Pruebas rápidas reales con activación condicional (NO incluidas en CI — proveedores reales)
Sección titulada «Pruebas rápidas reales con activación condicional (NO incluidas en CI — proveedores reales)»| Comando | Qué hace |
|---|---|
npm run test:combo:live |
Enrutamiento real en proceso con RUN_COMBO_LIVE=1; crea una instantánea de una BD de OmniRoute activa |
npm run test:combo:live:vps |
Llamadas HTTP a un servidor OmniRoute activo (configura COMBO_LIVE_BASE_URL) |
npm run test:combo:live:vps:failover |
Lo mismo, con escenarios deliberados de conmutación por error |
Estas pruebas rápidas ejercitan la ruta de comunicación real (combinación → proveedor → finalización). Se excluyen deliberadamente de CI porque requieren credenciales reales y acceso a un VPS.
Archivos
Sección titulada «Archivos»| Archivo | Propósito |
|---|---|
open-sse/services/autoCombo/scoring.ts |
Función de puntuación de 16 factores, DEFAULT_WEIGHTS, normalización del conjunto |
open-sse/services/autoCombo/taskFitness.ts |
Consulta de idoneidad modelo × tarea |
open-sse/services/autoCombo/engine.ts |
Lógica de selección, bandit, límite de presupuesto |
open-sse/services/autoCombo/selfHealing.ts |
Exclusión, sondas, modo de incidentes |
open-sse/services/autoCombo/modePacks.ts |
6 perfiles de ponderación (envío rápido, ahorro de costes, prioridad a la calidad, apto para uso sin conexión, prioridad a la fiabilidad, modo caos) |
open-sse/services/autoCombo/autoPrefix.ts |
Analizador del prefijo auto/ + 6 variantes |
open-sse/services/autoCombo/virtualFactory.ts |
Crea un AutoComboConfig en memoria a partir de conexiones activas |
open-sse/services/autoCombo/providerRegistryAccessor.ts |
Punto de extensión para pruebas que permite simular el registro de proveedores |
src/shared/constants/routingStrategies.ts |
ROUTING_STRATEGY_VALUES (19 estrategias) |
src/sse/handlers/chat.ts |
Integración: cortocircuito del prefijo automático |
HagiCode
HagiCode es un espacio de trabajo de programación con agentes, flujos estructurados, ejecución multiagente y vistas de Hero Dungeon.
Convierte ideas en software útil con un flujo de trabajo con agentes más inteligente, rápido y ameno.

- SmartLos flujos estructurados convierten la intención en un itinerario ejecutable desde la idea hasta la entrega.
- EfficientLos flujos multiagente permiten avanzar en paralelo con la investigación, implementación y revisión.
- FunHero Dungeon hace que las largas sesiones de programación sean visuales y colaborativas.