OrcaRouter Infraestructura de Enrutamiento: Enrutamiento Consciente de Sesiones y Escalación de Frontera

ORCAROUTER · ARQUITECTURA DE ENRUTAMIENTO

Todo gateway de LLM que almacena en caché prompts debe fijar una conversación a un solo modelo. Todo gateway que fija una conversación toma su decisión de enrutamiento basándose en el turno menos informativo de esa conversación. Este es un informe sobre esa compensación y sobre el mecanismo de adherencia por niveles que OrcaRouter incluye para escapar de ella.

Asunto: Pasarela LLM OrcaRouter (Go / Gin / Redis) · Componente: afinidad de sesión + motor de escalamiento Frontier · Método: repetición de 400 sesiones contra el código de decisión de producción · Fecha: 14 de agosto de 2026

RESUMEN — El enrutamiento de LLM a nivel de solicitud — evaluar cada solicitud de forma independiente y enviarla al modelo adecuado más barato — es el régimen que aborda casi todo el trabajo publicado sobre enrutamiento. También es el régimen equivocado para el tráfico que ahora domina el volumen de las pasarelas: sesiones de agentes de múltiples turnos, donde el prompt es 90 % contexto acumulado y la caché de prompts del proveedor recompensa la continuidad. Cambiar de modelo a mitad de conversación hace perder un descuento de 10× en el prefijo compartido, así que las pasarelas fijan las sesiones. Pero una fijación hecha en el turno 1 es una fijación hecha en el turno con menos evidencia, y persiste durante toda la vida de la conversación.

100 / 100 — sesiones de dificultad latente cuya puntuación en el turno 1 es indistinguible de la de una sesión trivial

+16% — deriva de la puntuación de dificultad debida únicamente a la longitud de la transcripción, con idéntica dificultad de tarea

45 % — del costo de frontera permanente, por el 67 % de su cobertura de giros cerrados

0.019 — margen entre el umbral publicado y el techo de las puntuaciones realistas

1 Dos regímenes de enrutamiento

Una puerta de enlace de LLM que se sitúa frente a muchos proveedores tiene que responder una pregunta por cada solicitud: ¿qué modelo atiende esta? Hay dos formas estructuralmente diferentes de responderla, y la literatura y la realidad de producción se han distanciado sobre cuál de ellas importa.

Enrutamiento a nivel de solicitud trata cada solicitud como independiente. Un evaluador estima la dificultad de la consulta o la calidad prevista de la respuesta, y la solicitud se envía al modelo más barato que se espera que pueda manejarla. Este es el régimen de prácticamente todos los trabajos publicados sobre enrutamiento: RouteLLM entrena enrutadores con datos de preferencia que alcanzan el 95 % de la calidad de GPT-4 con un 14 % de llamadas a modelos fuertessup>[1]/sup>; FrugalGPT utiliza una cascada de modelos de barato a caro con una comprobación de aceptación/rechazo y reporta una reducción de costos de hasta el 98 %sup>[2]/sup>; RouterArena construye un punto de referencia de 8,400 consultas para comparar enrutadores exactamente en este ejesup>[3]/sup>. La unidad de análisis es la consulta.

Enrutamiento consciente de la sesión

La razón por la que existe el enrutamiento consciente de sesión no es la elegancia. Es aritmética.

2 La economía de la caché que hace obligatoria la adherencia

En una sesión de agente multi-turno, el prompt del turno n es el prompt del turno n−1 más un delta. Para el turno 10, el prefijo acumulado constituye la gran mayoría de los tokens de entrada. Todos los principales proveedores ahora cobran ese prefijo de manera diferente según si es un acierto de caché:

Tabla 1. Semántica de la caché de prompts por proveedor. La caché utiliza como clave un prefijo exacto y la clave de servicio: un cambio de modelo o una rotación de clave conlleva una lectura en frío a precio completo.

OrcaRouter codifica exactamente estas duraciones como TTL de pines: un mapa por tipo de canal de las ventanas de caché de proveedor — 5 minutos para OpenAI, Anthropic y Gemini, 60 minutos para DeepSeek — con un valor predeterminado de 5 minutos para proveedores no mapeados. El pin de canal+clave expira con esa ventana, porque un índice de clave obsoleto no tiene valor de caché y solo distorsiona el equilibrio de carga. El modelo pin, en un despliegue con respaldo de Redis y para un id de sesión elegible para pin largo, persiste durante 30 días — no por su valor de caché, que hace tiempo que desapareció, sino por la continuidad del formato de solicitud. Un cambio de modelo a mitad de conversación fuerza una conversión del formato de solicitud que puede ser incompatible con los datos: los bloques de pensamiento y los id de llamadas a herramientas no sobreviven necesariamente a la traducción entre esquemas de proveedor.

EL DETALLE POCO APRECIADO

Las cachés de prompt se indexan por clave de API, no por modelo. Una puerta de enlace que fija el modelo pero equilibra la carga entre tres claves en el mismo canal aún lee en frío dos de cada tres turnos. Esa es la razón por la que el pin de canal de OrcaRouter almacena {ChannelID, KeyIndex} en lugar de un id de canal, y por la que el pin se descarta cuando el índice de clave registrado ya no se resuelve a una clave habilitada — una clave impulsada pero rotada sesgaría hacia una caché fría mientras eludiría el balanceo, lo cual es lo peor de ambos mundos.

Las fijaciones son flexibles en todos los casos: un ID de sesión no resoluble es una operación nula, un canal fijado deshabilitado o no saludable se degrada a la selección balanceada normal, y una fijación a un canal de peso cero en un grupo mixto se descarta para que un administrador que drena un canal no se vea frustrado por la adherencia. Nunca hacen que una solicitud falle.

3 La trampa: la adherencia desactiva el router

Aquí está el modo de falla. En OrcaRouter, la ruta de código de pre-escalamiento, para un router consciente de sesión en cualquier estrategia no DSL, el pin devuelto de sesión→modelo

Eso sería tolerable si el turno 1 fuera representativo. Sistemáticamente no lo es, por dos razones que se combinan.

3.1 El turno 1 es el turno menos informativo.

El escalar de dificultad (service/model_router_difficulty.go) es una combinación lineal ponderada sobre seis características léxicas:

LogPromptTokens × 0.20 con tope en log(8001) ≈ 8.99

ReasoningCueCount × 0.15, tope 5

SystemPromptLogLen × 0.10 con un tope de log(2001) ≈ 7.60

CodeKeywordDensity × 0.20 tope 5.0 (coincidencias por cada 100 caracteres)

HasTools × 0.15 ya 0/1

MathMarkerCount × 0,20 tope 5

Una apertura corta sin historial puntúa bajo casi por construcción: el término de token ponderado al 0,20 está cerca de su mínimo, y los términos de razonamiento/matemáticas se activan con vocabulario que el usuario aún no ha tenido razón para usar. Las sesiones, por lo tanto, se comprometen con un modelo de pool débil en el momento de menor información — y con un anclaje de modelo de 30 días respaldado por Redis, ese compromiso es largo.

Figura 1. Dificultad media de la última ronda por turno de conversación, en 100 sesiones latentes difíciles y 200 genuinamente fáciles, puntuadas por el puntuador de producción. En el turno 1 — el turno en el que se escribe el pin fijo — las dos poblaciones son indistinguibles (0.210 frente a 0.208). La población difícil cruza el umbral en el turno 5. Con una política de solo pin, las 100 sesiones latentes difíciles se asignan al grupo de bajo costo antes de que exista cualquier evidencia de ello.

3.2 La longitud se hace pasar por dificultad

El segundo problema es más sutil y socava la solución obvia. Si simplemente reejecutas la compuerta de dificultad en cada turno, la estás reejecutando sobre una puntuación calculada sobre la transcripción concatenada completa. Esa puntuación tiene una deriva ascendente incorporada: el término LogPromptTokens con peso 0.20 aumenta monótonamente con la longitud de la conversación, y en cualquier sesión de agente los términos HasTools (0.15) y SystemPromptLogLen (0.10) son efectivamente pisos constantes. Una sesión larga y aburrida parece progresivamente más difícil.

Figura 2. El artefacto de sesgo de longitud, medido en 60 sesiones compuestas enteramente por ediciones triviales (“renombrar esta variable”, “añadir una comprobación de nil”). La puntuación de la transcripción completa se desvía +16 % a lo largo de 25 turnos con dificultad de tarea constante; la puntuación del último turno (delta) es plana. Una reevaluación ingenua de la puntuación de la transcripción completa en cada turno escalaría las sesiones por el crimen de ser largas.

La corrección que OrcaRouter incluye es, por separado, un delta extractor (service/model_router_delta.go) que puntúa solamente el último turno — el nuevo texto del usuario más cualquier resultado de herramienta adjunto después del último mensaje del asistente — reutilizando los mismos pesos y límites pero poniendo deliberadamente a cero SystemPromptLogLen, que no forma parte del delta. La línea azul plana de la Figura 2 es ese extractor.

4 Diseño: adherencia por niveles

La salida ingenua del bloqueo del turno 1 es redirigir cada turno — lo que es solo enrutamiento a nivel de solicitud y renuncia a la caché. La corrección ingenua en la otra dirección es convertir el pin en la memoria de «esta sesión se puso difícil» — lo que no puede expresar desescalada ni puede tener un tope. El diseño de OrcaRouter rechaza ambas.

El replanteamiento: una sesión se fija a un modelo dentro de un nivel, y un pequeño estado del nivel de Redis es la única memoria de escalado. La fijación del modelo nunca es la memoria.

Grupos de niveles. El nivel fuerte es el grupo de escalado resuelto (escalation_pool, que por defecto es strong_pool del router). El nivel base es AllowedModels \ grupo del nivel fuerte; un modelo que esté en ambos pertenece al nivel fuerte. Dentro del nivel base, las bandas de dificultad débil/media/fuerte de gated_adaptive siguen funcionando exactamente igual que antes.

Pines con alcance de nivel. La clave de pin de modelo del nivel fuerte recibe un sufijo :t:strong; el nivel base mantiene la clave heredada sin cambios. Por lo tanto, la escalación conserva el pin base, de modo que una sesión desescalada — o una reanudada después de que expire el estado del nivel — vuelve al modelo exacto en el que comenzó, no a una nueva selección arbitraria. Los pines fuertes se escriben solo con el TTL corto de la ventana del proveedor: un pin fuerte de 30 días sobreviviría al estado de nivel de 4 horas que lo justificó.

La compuerta se ejecuta primero. En selectByStrategy (service/model_router.go:1374), el nivel se resuelve de antemano, el conjunto de candidatos se reduce al grupo del nivel, y solo entonces se consulta el pin persistente — dentro de ese nivel. Esta es la corrección estructural para §3: el cálculo de dificultad y los disparadores de escalada se ejecutan en cada turno, antes de que el pin pueda cortocircuitarlos.

4.1 Tres clases de disparadores, ordenadas por confianza

Tabla 2. Disparadores de escalada. Ninguna señal difusa se incrementa jamás por sí sola; solo una solicitud explícita del cliente se compromete en n=1, e incluso esta respeta los topes.

Tres invariantes de higiene son fundamentales. Los strikes se deduplican por ID de solicitud a través de un búfer circular, de modo que los reintentos de cliente intercalados no pueden contarse dos veces. Una falla de infraestructura nunca es una falla de capacidad — los 429, los 5xx y los fallbacks de canal nunca generan strikes; solo cuentan las señales de calidad posteriores al éxito. Y un “turno” se define como una solicitud completada y facturada como exitosa que ejecutó la evaluación de strikes, por lo que las solicitudes fallidas no hacen avanzar ni el decaimiento de los strikes ni el contador de turnos limpios.

4.2 Resolve es puro; el commit se difiere

La propiedad estructural más importante del motor es que ResolveEscalation no escribe nada. Devuelve una decisión más una lista de intenciones pendientes. El distribuidor aplica esas intenciones en su bloque posterior al éxito, sobre una lectura nueva dentro de una transacción WATCH de Redis. Esto importa porque el resolutor se ejecuta en rutas que nunca deben mutar estado: resoluciones especulativas de cadenas de respaldo, los endpoints de diagnóstico de solo lectura y las solicitudes que luego devuelven 403 o fallan en el upstream. Reaplicar intenciones sobre un estado nuevo también significa que un escritor concurrente obsoleto no puede sobrescribir una escalación confirmada, y dos escalaciones idénticas en competencia se fusionan de forma idempotente.

4.3 Límites, y por qué lo vinculan todo

Una escalada de falso positivo cuesta (fuerte − base) precio × tokens de episodio cálido restantes, y lo cuesta en silencio — nada falla. El radio de explosión está limitado por topes que se aplican a cada clase:

escalation_max_per_session (por defecto 1). La desescalada y los reinicios del cliente no lo reembolsan, lo que cierra la vía de explotación del bucle de reinicio.

Un por-router tope de participación escalada (20 % por defecto) durante una ventana deslizante de 24–48 horas de cubos diarios de Redis, además de un tope transversal entre routers en todo el workspace. Al alcanzar el tope, se suprime todo el enrutamiento de escalamiento, incluidas las solicitudes explícitas y los impulsos únicos.

Desescalada solo en los límites de caché frío, por lo que un falso positivo queda acotado a un episodio cálido.

La razón por la que la Clase A obedece los topes es una conclusión del modelo de amenazas, no una preferencia de política: en una puerta de enlace de API, quienquiera que posea el token del espacio de trabajo controla las cabeceras. Una vía "el cliente lo pidió" exenta de topes es un canal de gasto sin medir. §7 mide lo que ocurre cuando todos los clientes abusan de ella.

4.4 La desescalada es asimétrica por diseño

Escalar con evidencia corroborada; desescalar solo cuando no tenga costo. Una sesión fuerte regresa a la base solo cuando se cumplen todas las condiciones siguientes: la sesión tiene la caché fría (inactiva más allá de la ventana del proveedor registrada al escalar), ha acumulado ≥3 turnos evaluados sin fallos, y el último delta de dificultad está por debajo de T1. Dentro de la ventana cálida, un cambio paga una relectura en frío a precio completo — el aleteo es la única forma garantizada de hacer que el escalamiento tenga un costo negativo.

5 Método

Medimos el mecanismo reproduciendo un corpus de sesiones sintéticas a través del código real de decisión de producción. El arnés es una prueba de Go en el paquete de servicio que llama a ResolveEscalation y CommitEscalationDecision por turno contra un almacén de niveles respaldado por miniredis, con los evaluadores de dificultad reales, los productores reales de strikes del lado de la solicitud y el mecanismo real de límite de cuota. Nada de la ruta de decisión se reimplementa ni se simula, excepto el sumidero de eventos de auditoría.

QUÉ ES REAL Y QUÉ NO

Real: cada decisión de enrutamiento, puntuación de dificultad, detección de strikes, regla de racha, evaluación de límites y transición de estado de Redis — estas son las funciones implementadas. Sintético: el tráfico. El corpus se genera, no se muestrea de los registros de producción. Su mezcla de arquetipos (50 % difícil) es una mezcla de estrés elegida para poner a prueba el mecanismo, no una estimación del tráfico real; §6.4 reporta la sensibilidad a esa elección, y es grande. Los números de precisión limpios que se muestran a continuación reflejan un corpus cuyas clases son separables por construcción, y deben leerse como «el mecanismo se activa donde fue diseñado para hacerlo», no como una estimación de precisión en producción.

5.1 Corpus

400 sesiones, 3,968 turnos, con semilla y deterministas. Cada turno es un cuerpo de solicitud de chat-completions completo que lleva el historial acumulado, una matriz de definición de dos herramientas y un prompt de sistema realista: la forma que un agente de codificación realmente envía. Cinco arquetipos, cada uno con una etiqueta de verdad fundamental:

Tabla 3. Composición del corpus. “Needs strong” es la verdad de referencia utilizada para las puntuaciones de precisión y cobertura.

Los turnos difíciles incluyen un volcado de goroutines pegado o un extracto de código fuente de 3–8 KB además de la prosa, porque eso es lo que contiene un turno de depuración difícil real. Este detalle resultó ser de enorme importancia — véase §6.2.

5.2 Modelo de costos

Los costos se calculan a partir de los precios de lista publicados con semántica de caché por proveedor; el modelo se expone en su totalidad para que se pueda discrepar.

Tabla 4. Parámetros del modelo de costos. Los precios son $ por 1M de tokens, lista de agosto de 2026.

Un turno cálido cuesta 0.1·p_in·prefix + write·p_in·delta; un turno frío cuesta write·p_in·prompt. El turno 1 es siempre una escritura de caché completa. El turno de cambio de nivel bajo la política de escalada se cobra explícitamente como frío, por lo que el mecanismo paga por su propia invalidación de caché.

La calidad se informa como cobertura de turnos difíciles — la fracción de turnos difíciles según el ground truth que el modelo fuerte realmente atendió — en lugar de como una cifra de exactitud. No ejecutamos inferencia upstream, por lo que nos abstenemos de inventar cifras de exactitud.

6 Resultados

6.1 El mecanismo se dispara donde fue diseñado para hacerlo.

Tabla 5. Resultados de escalada por arquetipo, modo automático, canary 100 %, T2 = 0.70 (predeterminado del producto).

Cero falsos positivos en las 200 sesiones fáciles, incluidas las 60 largas que un evaluador de transcripción completa habría dejado derivar hacia la banda difícil. Las clases de activación se especializan de forma limpia y sin solapamiento: la dificultad detecta el trabajo con alto contenido de razonamiento; los strikes capturan los bucles de fallo. Nótese que la puntuación máxima de dificultad de failure_loop es 0.262 — el filtro de dificultad nunca ve esas sesiones en absoluto. Un agente atascado en un bucle de error de compilación no está produciendo prosa densa en señales de razonamiento; está produciendo el mismo prompt corto con una traza de pila diferente. Sin los strikes de Clase C, cada una de esas 60 sesiones se arrastraría indefinidamente en el modelo barato.

Figura 3. Cuando las sesiones escalan, se dividen según el desencadenante. Las escaladas impulsadas por strikes se concentran marcadamente (turno 4, el primer turno en el que pueden acumularse dos strikes dentro de la ventana de decaimiento); las escaladas impulsadas por dificultad se distribuyen a lo largo de los turnos 2 a 11 siguiendo la distribución de inicio del corpus. La regla de la racha de dos turnos consecutivos implica que la escalada de dificultad más temprana posible es el turno 2.

6.2 Hallazgo: la compuerta enviada se encuentra al borde de un acantilado

Nuestro primer corpus produjo cero escalaciones impulsadas por la dificultad. Los turnos difíciles — cargados de condiciones de carrera, invariantes, análisis de complejidad y vocabulario de demostración — alcanzaron un máximo de 0.658 frente a un umbral de 0.70. Añadir las trazas de pila pegadas que los turnos de depuración reales efectivamente llevan elevó la puntuación a 0.719. El umbral se supera por un margen de 0.019.

Figura 4. Dónde va realmente el presupuesto de dificultad, promediado sobre 855 turnos difíciles y 3,113 turnos fáciles. Un turno difícil realista alcanza 0.719 de un máximo teórico de delta de 0.90. El término CodeKeywordDensity contribuye con 0.069 de su presupuesto de 0.20 — la densidad medida es de 1.72 coincidencias por cada 100 caracteres frente a un límite de saturación de 5.0 — y el 0.10 de SystemPromptLogLen es estructuralmente cero en el extractor de delta. Aproximadamente un tercio del rango nominal de la puntuación es inalcanzable para texto realista.

El barrido de umbrales confirma que esto es un acantilado, no una pendiente. En T2 de 0.35 a 0.65 el resultado es idéntico — 200 de 400 sesiones escalan, con cero fallos. En el 0.70 enviado, el clasificador empieza a perder sesiones; en el 0.75, la escalada impulsada por dificultad colapsa de 122 sesiones a 23.

Figura 5. Sensibilidad del umbral. Todo el rango de 0,35–0,65 es conductualmente idéntico porque ningún texto delta realista cae en él — la distribución de puntuaciones es bimodal, con los turnos fáciles agrupados cerca de 0,23 y los difíciles cerca de 0,72, y nada en el medio. El valor predeterminado de fábrica se sitúa en el borde superior del modo superior.

IMPLICACIÓN DE INGENIERÍA

T2 is calibrated for the full-transcript distribution the gated_adaptive bands were tuned on, and it is being reused as the delta extractor's threshold. The design document flags that the delta extractor “needs its own tuning”; this measurement quantifies how much. Either the delta gate needs a lower T2 of its own — anywhere in 0.45–0.60 buys identical behaviour with real margin — or the percentile-based threshold already scheduled for Phase 3 (“top X % of this router's recent traffic”) should land, which makes the escalation rate the operator's knob and sidesteps absolute calibration entirely.

6.3 Costo y cobertura

Figura 6.Cinco políticas sobre las mismas 400 sesiones. Izquierda: costo por 1,000 sesiones (escala logarítmica). Derecha: fracción de turnos realmente difíciles atendidos por el modelo fuerte.

Tabla 6. Comparación de políticas. Costo por 1.000 sesiones según el modelo de la Tabla 4.

Dos resultados merecen separarse. Primero, la afinidad de sesión por sí sola ahorra un 24 % con la misma elección de modelo (16.64 → 12.63) y un 35 % en el par frontera (290.93 → 188.30). Eso es pura economía de caché — los mismos modelos, todo igual, solo difiere la persistencia de la clave. El ahorro es mayor en el par frontera porque el recargo de escritura de 1.25× de Anthropic hace que los turnos en frío sean desproporcionadamente caros.

En segundo lugar, la escalada llega donde debería actuar un mecanismo de rescate: el 45 % del costo de estar siempre en la frontera para el 67 % de su cobertura de turnos difíciles, sirviendo al modelo fuerte solo en el 21,4 % de los turnos.

La tercera parte faltante de la cobertura no es un defecto; es el precio del trinquete. Las reglas de corroboración que dan cero falsos positivos también significan que el mecanismo no puede actuar en el primer turno de un problema:

Tabla 7. Latencia de escalamiento — solicitudes difíciles atendidas en el modelo barato antes de que se dispare el trinquete.

Dos giros es exactamente lo que especifica la regla de racha de dos giros consecutivos, y un giro es exactamente lo que especifica la regla de dos golpes para el trinquete. La latencia es el diseño, y es la misma propiedad que produjo cero falsos positivos. Quien quiera un rescate más rápido tiene la cabecera de Clase A, que actúa en n=1 — es precisamente por eso que la escotilla de escape manual se lanzó primero.

6.4 La proporción del titular depende por completo de tu tráfico

El corpus es 50 % difícil por construcción. El tráfico real de routers no lo es, y la comparación de costes es extremadamente sensible a eso. Re-ponderando los costes medidos por arquetipo en un rango de prevalencias de sesiones difíciles:

Figura 7. Costo por 1,000 sesiones en función de cuánto de su tráfico realmente necesita el modelo fuerte. El comportamiento dentro de cada clase se mantiene en los valores medidos; solo cambia la combinación.

Tabla 8. Sensibilidad de prevalencia, $ por 1,000 sesiones.

Con la tasa de escalamiento objetivo del propio documento de diseño, de ≤5 % de las sesiones, los costos de escalamiento 1.6× la factura del pool barato y el 12 % de la factura de frontera. Con la mezcla de estrés al 50 %, cuesta 6.7× la factura del pool barato. Ambas afirmaciones son verdaderas; responden a preguntas distintas. La relevante a efectos operativos es la primera, y es por eso que el tope de participación se establece por defecto en 20 % y no en “off”: el tope, no la precisión del disparador, es lo que realmente limita la factura.

6.5 Los topes se mantienen bajo abuso adversarial

Volvimos a ejecutar el corpus con la maquinaria real de tope de acciones — sin stub, con cubos diarios reales de Redis — bajo el modelo de amenaza del §8: cada cliente envía X-OrcaRouter-Tier: strong en cada turno.

Figura 8. Abuso adversarial de cabeceras contra el límite del 20 % de participación escalada. Las primeras 20 solicitudes no están restringidas por diseño: el suelo de calentamiento evita que «1 escalada de 2» se lea como 50 % y bloquee la función en un router nuevo; después, la participación converge y se mantiene. Estado final: 296 de 1,439 solicitudes se sirvieron como fuertes (20.6 %), con 1,143 solicitudes explícitas denegadas y auditadas como eventos denied_cap.

El exceso residual del 0,6 % es el comportamiento previsto de una comparación estrictamente mayor en un contador de seguimiento aproximado, y el tope de 1 por sesión evita que las sesiones individuales consuman el presupuesto. Cada denegación es visible para el cliente en el encabezado de respuesta X-Orca-Session-Tier: base; reason=denied:share_cap y para el operador en la tabla de auditoría: una escalada suprimida nunca es silenciosa.

7 Lo que cambiaríamos

Asigne al extractor delta su propio umbral. Reutilizar el T2 de la transcripción completa deja un margen de 0,019 (§6.2). Un T2 específico para delta entre 0,45 y 0,60 es conductualmente idéntico en este corpus con dos órdenes de magnitud más de margen. El trabajo ya programado sobre el umbral percentil subsume esto y es la mejor corrección.

No permitas que el término de densidad de código siga siendo decorativo. Aporta 0,069 de su presupuesto de 0,20 en el texto realista más denso que pudimos construir, porque su tope de saturación de 5 coincidencias por cada 100 caracteres implica aproximadamente una palabra clave de código cada veinte caracteres. O bien vuelve a fijar su tope según una distribución de producción medida, o reasigna su peso.

La clase C es el caballo de batalla del tráfico de agentes, y es la menos desarrollada. La población de failure_loop es invisible al umbral de dificultad (pico 0.262) y es capturada por completo por los strikes. Las sesiones de agentes fallan por entrar en bucle, no por volverse léxicamente más difíciles. Los productores restantes del lado de la respuesta — y el hook de captura de streaming nativo de Gemini que aún falta — valen más que seguir afinando la dificultad.

Publique la latencia de escalado. Dos rondas de trabajo duro realizadas en el modelo económico son el costo honesto de un trinquete de corroboración, y los operadores deberían verlo en el panel de análisis junto a la precisión, no descubrirlo.

8 Limitaciones

El corpus es sintético. Fue construido para separarse limpiamente, por lo que el resultado de cero falsos positivos caracteriza la especificidad del mecanismo sobre entrada separable, no su precisión en tráfico de producción. El número real de precisión solo puede provenir del trabajo de etiquetado en modo sombra que especifica el diseño — pipeline de disparo completo, sin enrutar nada, decisiones etiquetadas retroactivamente — con un umbral de lanzamiento de precisión etiquetada ≥70 %.

El modelo de costos asume un número fijo de 500 tokens de salida por turno, lo que oculta un efecto real: los modelos de frontera emiten más tokens de razonamiento, por lo que la prima real de frontera está subestimada. También modela la calidez de caché a nivel de solicitud como una uniforme 1/N sobre los espacios clave; un grupo ponderado usaría el índice de Herfindahl Σw², y un canal de clave única no mostraría ninguna ventaja de caché para la afinidad de sesión en la capa de canal — aunque la fijación a nivel de modelo sigue siendo importante para estrategias adaptativas.

No realizamos inferencia ascendente, por lo que no se hace ninguna afirmación sobre precisión o éxito de la tarea. La cobertura de turnos difíciles es un indicador de calidad y asume que el modelo fuerte es realmente mejor en esos turnos; esto es plausible para los arquetipos construidos, pero no se ha verificado aquí.

Por último, esto mide la implementación de una pasarela concreta. El modo de fallo de bloqueo en el turno 1 debería generalizarse a cualquier router consciente de caché que fije sesiones, pero los números específicos son propiedades de estos umbrales, estos pesos y estos precios.

9 Trabajos relacionados

El enrutamiento a nivel de solicitud está bien cubierto. FrugalGPTsup>[2]/sup> introdujo la cascada de LLM — consultar el modelo barato, puntuar la respuesta, escalar ante baja confianza — reportando una reducción de costos de hasta el 98 % con una precisión equivalente. RouteLLMsup>[1]/sup> entrena enrutadores con datos de preferencias de Chatbot Arena y reporta un 95 % de la calidad de GPT-4 con un 14 % de llamadas a modelos potentes, con enrutadores que se transfieren entre pares de modelos sin reentrenamiento. RouterArenasup>[3]/sup> proporciona la base de evaluación que faltaba: 8,400 consultas en distintos dominios y niveles de dificultad, evaluadas en exactitud, costo, optimalidad del enrutamiento, robustez y sobrecarga del enrutador.

Lo que ninguno de estos aborda es la conversación como unidad de enrutamiento. Una cascada escala una solicitud y olvida; el siguiente turno vuelve a ejecutar el mismo modelo barato en la misma tarea que ahora se sabe difícil. Un enrutador entrenado por preferencias puntúa una consulta, no una trayectoria. La brecha que aborda este informe es qué debe recordar un enrutador entre turnos, durante cuánto tiempo, y a qué se le debería permitir cambiar de opinión — una cuestión que solo se vuelve urgente una vez que el almacenamiento en caché de indicaciones hace que olvidar sea costoso.

OrcaRouter incluye un banco de pruebas RouterArena dentro del árbol (eval/) que evalúa sus cinco estrategias a nivel de solicitud — cheapest, quality, balanced, linucb, gated_adaptive — contra el conjunto de datos abierto sin modificar el repositorio ascendente. El mecanismo a nivel de sesión descrito aquí es ortogonal y se compone con las cinco.

10 Conclusión

El almacenamiento en caché de prompts cambió la economía del enrutamiento de LLM de una manera que la literatura sobre enrutamiento no ha podido seguir el ritmo. Una vez que la continuidad supone un descuento de 10× sobre la mayoría de tus tokens de entrada, un enrutador debe fijar — y en el momento en que fija, toma su decisión en el turno donde menos sabe, y convive con esa decisión durante toda la conversación. El enrutamiento a nivel de solicitud no tiene este problema y lo paga con fallos de caché; la reevaluación ingenua por turno reintroduce los fallos y añade además un artefacto de sesgo de longitud.

La adherencia por niveles lo resuelve separando dos cosas que parecen una: qué modelo atiende esta sesión (el pin, estable dentro de un nivel) y a qué nivel pertenece esta sesión (una pequeña pieza de estado, con tope, corroborada y que expira). En nuestra repetición, esa separación recupera el 87 % de las sesiones cuya dificultad es indetectable en el turno 1, con cero falsos positivos en 200 sesiones fáciles, al 45 % del coste de siempre-frontera — y mantiene un límite de gasto del 20 % frente a clientes que intentan activamente derrotarla.

Las debilidades honestas del mecanismo son de calibración, no de arquitectura: una compuerta de dificultad reutilizada de una distribución para la que no fue ajustada, un término de característica que no puede alcanzar su presupuesto, y dos turnos de latencia de rescate ineludible. Esas son tratables. La afirmación arquitectónica — de que la memoria de escalamiento debe estar separada del pin, de que ninguna señal difusa puede actuar como trinquete por sí sola, y de que los topes deben vincular la propia solicitud explícita del cliente porque el cliente posee el token — es la parte que conservaríamos.

11 Fuentes

1. LMSYS Org. RouteLLM: un marco de código abierto para el enrutamiento rentable de LLM. a href="https://www.lmsys.org/blog/2024-07-01-routellm/">u>lmsys.org/blog/2024-07-01-routellm//u>/a> · código: a href="https://github.com/lm-sys/RouteLLM">u>github.com/lm-sys/RouteLLM/u>/a>

2. Chen, Zaharia y Zou. FrugalGPT: cómo usar grandes modelos de lenguaje mientras se reduce el costo y se mejora el rendimiento. arXiv:2305.05176. a href="https://arxiv.org/abs/2305.05176">u>arxiv.org/abs/2305.05176/u>/a>

3. Lu, Liu, Yuan, Cui, Zhang, Liu y Xing. RouterArena: Una plataforma abierta para la comparación integral de enrutadores de LLM. arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI. Caché de prompts en la API. a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — almacenamiento automático en caché, prefijo de ≥1024 tokens en incrementos de 128 tokens, desalojo por inactividad de 5 a 10 minutos, ≤1 hora; descuento en entradas cacheadas según el nivel del modelo. Precios: a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic. Caché de prompts. a href="https://platform.claude.com/docs/en/build-with-claude/prompt-caching">u>platform.claude.com/docs/en/build-with-claude/prompt-caching/u>/a> — lecturas de caché: 0.1× la entrada base; escrituras de caché: 1.25× (TTL de 5 minutos) o 2× (TTL de 1 hora); el TTL se renueva con el uso. Precios: a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek. La API de DeepSeek introduce el almacenamiento en caché de contexto en disco. a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — automático, facturado según los aciertos de caché reales, reducción de un orden de magnitud en caso de acierto.

7. Google. Caché de contexto de Gemini API. a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — caché implícita y explícita con TTL con precio basado en almacenamiento.

8. Código fuente de OrcaRouter, este repositorio: service/session_affinity.go (anclajes, TTLs, claves con ámbito por nivel) · service/session_escalation.go (el motor) · service/model_router.go:1374 (selectByStrategy: reducción de nivel antes de la lectura del anclaje) · service/model_router_difficulty.go (pesos y límites) · service/model_router_delta.go (extractor de delta) · service/escalation_strikes.go (productores del lado de la solicitud) · service/escalation_caps.go (límites de participación) · docs/features/frontier-escalation.md (diseño, rondas de revisión 1–4).

Reproducibilidad. El arnés de medición es una prueba de Go en el paquete de servicio que impulsa ResolveEscalation / CommitEscalationDecision contra miniredis, además de un pipeline de análisis y figuras en Python. La generación del corpus se siembra (rand.NewSource(20260814)) y la ejecución completa es determinista: 400 sesiones, 3968 turnos, tres experimentos (repetición principal, ejecución con tope adversarial, barrido de umbral de 9 puntos). Las figuras utilizan una paleta categórica validada para CVD; cada figura está emparejada con su tabla subyacente. No se accedió a datos de producción, y ninguna parte de este análisis se ha enviado al repositorio.