El router de modelos de LangChain reduce los costos de los agentes sin una pérdida de calidad medible

LangChain afirma que su router de modelos de LangChain redujo en un 64% los costos medianos de los agentes de programación en 973 hilos activos, sin una caída medible en los resultados de las solicitudes de extracción. El resultado cuestiona una decisión habitual en el diseño de agentes: asignar el modelo más potente disponible a cada tarea.

La empresa probó el router dentro de Open SWE, su agente de programación de código abierto utilizado mediante Slack y una interfaz web. Los hilos enrutados produjeron solicitudes de extracción fusionadas con una tasa del 29,2%. El grupo de control, que siempre usó GPT-6 Astra, alcanzó el 27,3%.

Esa diferencia no fue estadísticamente significativa. Por lo tanto, el experimento no demuestra que el enrutamiento mejore la calidad del código. Ofrece un hallazgo más acotado: Open SWE utilizó mucha menos capacidad de modelo sin detectar una pérdida de calidad correspondiente.

Esta distinción importa porque los agentes de programación manejan una carga de trabajo mixta. Investigar una funcionalidad puede requerir razonamiento prolongado, mientras que ejecutar pruebas o responder una pregunta sobre un repositorio podría no requerirlo. El argumento de LangChain es que la selección del modelo debería reflejar esas diferencias antes de que un agente comience a trabajar.

Qué cambió en 973 hilos de Open SWE

LangChain reemplazó un modelo frontier fijo como opción predeterminada por un enrutamiento a nivel de tarea y luego probó el cambio con tráfico interno activo.

La empresa describió los resultados en su análisis de enrutamiento de modelos del 1 de octubre. La prueba dividió 973 hilos de Open SWE entre un grupo enrutado y un grupo de control.

Cada hilo de control utilizó GPT-6 Astra con un esfuerzo de razonamiento bajo. Los hilos enrutados podían usar uno de tres niveles según el primer mensaje humano.

El nivel de rendimiento utilizó GPT-6 Astra. El nivel equilibrado utilizó GPT-5.6 Sol, mientras que el nivel rápido utilizó GLM-5.3-Flash. Cada nivel representaba una combinación distinta de capacidad del modelo, latencia y costo operativo.

El experimento se realizó del 16 al 22 de septiembre, según las fechas del gráfico publicado por LangChain. El costo mediano por hilo enrutado cayó un 64% en comparación con el grupo de control que solo usó modelos frontier.

La reducción también fue visible más allá de la mediana. LangChain informó una disminución del 42% en el costo medio y una reducción del 37% en el percentil 90. Estas cifras sugieren que el resultado no estuvo impulsado únicamente por una pequeña colección de solicitudes triviales.

La mayor parte del trabajo enrutado evitó el nivel de rendimiento. El modelo equilibrado recibió el 56% de los hilos enrutados, mientras que el modelo rápido gestionó el 34%. Solo el 10% fue al modelo más potente.

Esa distribución es el evento central. Indica que el router clasificó nueve de cada diez solicitudes entrantes como adecuadas para algo por debajo del nivel más alto.

Open SWE abarca más que la generación autónoma de código. Los ingenieros lo usan para hacer preguntas sobre repositorios, investigar comportamientos, ejecutar pruebas, corregir defectos y solicitar funcionalidades. El repositorio de Open SWE subyacente también admite integraciones, entornos aislados de programación y flujos de trabajo de solicitudes de extracción.

LangChain examinó primero una semana de trazas interactivas para comprender esa carga de trabajo. Las nuevas funcionalidades representaron el 22% de los hilos clasificados, mientras que las correcciones de errores supusieron el 17%. Las ejecuciones de pruebas o sin operación aportaron otro 16%.

Esas etiquetas procedían de un clasificador LLM que utilizaba títulos y metadatos de los hilos. LangChain las denomina explícitamente heurísticas, por lo que no deben tratarse como una verdad de referencia verificada manualmente.

Aun así, las categorías revelaron una variación significativa. Las investigaciones de funcionalidades tendían a requerir más turnos y consumir más recursos. Las tareas de pruebas y lanzamiento solían ser más cortas y menos costosas.

Esa variación abrió la puerta al enrutamiento. Una política de modelo fijo asume que cada solicitud merece el mismo presupuesto de razonamiento. Los datos de producción sugirieron lo contrario.

Por qué el router de modelos de LangChain vive dentro del harness

La afirmación más amplia de LangChain se refiere a la ubicación: el enrutamiento de modelos debería situarse dentro del harness del agente, donde el contexto de la tarea ya está disponible.

Un harness de agentes es el sistema de ejecución que rodea a un modelo. Proporciona prompts, herramientas, memoria, límites de ejecución, permisos y contexto específico de la aplicación.

Una puerta de enlace suele ubicarse más abajo en la pila. Puede centralizar el acceso a proveedores, aplicar presupuestos, distribuir tráfico o seleccionar endpoints mediante reglas generales.

LangChain sostiene que esas señales generales son insuficientes para el enrutamiento sensible a la tarea. El modelo adecuado más económico depende de lo que el agente debe hacer, de las herramientas que puede utilizar y de qué significa tener éxito.

Una solicitud de programación ilustra la diferencia. «Explica este archivo de configuración» y «rastrea un defecto de concurrencia intermitente» pueden llegar mediante la misma interfaz. Es poco probable que requieran la misma profundidad de razonamiento.

El harness puede ver el contexto del repositorio, las herramientas disponibles, el prompt de sistema y el objetivo declarado por el usuario. Una capa de tráfico genérica quizá solo vea un sobre de solicitud y metadatos generales del modelo.

Por eso el enrutamiento de modelos de Open SWE comienza con el primer mensaje humano. Un clasificador compara esa solicitud con criterios en lenguaje natural para los tres niveles.

Su instrucción base pide el modelo menos costoso que probablemente pueda completar la tarea. El router no selecciona automáticamente la opción más rápida. Intenta identificar el nivel más bajo que siga siendo adecuado.

LangChain implementa esta decisión mediante middleware de agentes. El middleware es código que puede inspeccionar o modificar una operación de un agente sin reescribir todo el bucle del agente.

El enfoque de selección dinámica de modelos de la empresa permite que ese middleware sustituya el modelo sin alterar las herramientas ni el flujo de trabajo general. Esta separación facilita las sustituciones de modelos a medida que los proveedores lanzan nuevas opciones.

Esta ubicación también convierte el enrutamiento en una forma de ingeniería de contexto. En lugar de mejorar solo el prompt de respuesta del agente, los desarrolladores diseñan la información utilizada para elegir el modelo que responderá.

Esa decisión puede incluir el tipo de solicitud, el uso esperado de herramientas, la sensibilidad del repositorio, los requisitos de latencia o patrones de fallos previos. Un agente de soporte y un agente de programación necesitarían definiciones de niveles diferentes.

Esta arquitectura presiona las estrategias de enrutamiento basadas únicamente en puertas de enlace. Las puertas de enlace centrales siguen siendo útiles para autenticación, límites, registro y conmutación por error entre proveedores. Sin embargo, esas funciones no revelan automáticamente si una tarea es semánticamente difícil.

Las dos capas pueden coexistir. Un harness puede realizar la selección a nivel de aplicación, mientras una puerta de enlace aplica controles organizacionales por debajo.

Por lo tanto, el experimento no debería interpretarse como evidencia de que las puertas de enlace están obsoletas. Muestra que un harness consciente del dominio puede poseer información de enrutamiento que la infraestructura por sí sola no tiene.

Para los equipos de ingeniería, esto también crea un requisito de observabilidad. El router necesita registros del trabajo real, los resultados y los modos de fallo. Sin esos registros, los criterios de nivel se convierten en conjeturas.

Open SWE utilizó trazas de LangSmith para examinar tipos de solicitudes, costos e invocaciones de modelos. Los equipos que construyan sistemas similares necesitan un ciclo de retroalimentación equivalente, ya sea que usen LangSmith u otra plataforma de trazado.

Un registro consultable de las decisiones de diseño también ayuda a los equipos a interpretar esas trazas. Los desarrolladores pueden conectar los fallos de enrutamiento con detalles del repositorio mediante una base de conocimientos de ingeniería, en lugar de evaluar prompts aislados.

Cómo el enrutamiento de modelos de Open SWE toma su decisión

El router combina patrones de tareas observados con criterios específicos de cada modelo y luego asigna cada hilo a un nivel.

LangChain comenzó con un análisis de la carga de trabajo, en vez de con una clasificación genérica. Este orden importa porque un modelo puede rendir bien en benchmarks públicos y, aun así, adaptarse mal a las tareas de una organización.

El equipo utilizó el costo por hilo y el número de invocaciones como señales aproximadas de complejidad. Ninguna de las dos medidas es una etiqueta perfecta.

Un costo más alto puede reflejar una solicitud más larga o más difícil. También puede reflejar un comportamiento ineficiente. Más invocaciones pueden indicar complejidad genuina, correcciones repetidas o llamadas a herramientas innecesarias.

Luego, LangChain comparó los modelos candidatos mediante una curva de inteligencia frente a costo. El trío seleccionado cubría posiciones de rapidez, equilibrio y rendimiento, en lugar de tres modelos frontier casi equivalentes.

Los criterios del router combinaron dos entradas. Una fue la distribución de tareas observada en Open SWE. La otra fue orientación sobre las fortalezas previstas de los modelos.

En tiempo de ejecución, el clasificador lee la solicitud inicial. Devuelve un nivel y Open SWE utiliza ese modelo durante todo el hilo.

La primera versión utilizó un LLM general con salida estructurada, lo que significa que el modelo debía devolver un formato de clasificación predefinido. LangChain trasladó posteriormente la clasificación a Jev, un modelo especializado en decisiones.

La empresa afirma que Jev hizo la clasificación casi 50 veces más rápida. Ese es un resultado informado por el proveedor, y el experimento de enrutamiento publicado no ofrece una réplica independiente de la latencia.

Una clasificación más rápida sigue resolviendo un problema práctico. Un router que ahorra costos de modelos, pero añade un retraso perceptible a cada solicitud, puede debilitar la experiencia del usuario.

La decisión única también protege la caché de prompts. Reutilizar un modelo permite al proveedor reutilizar contenido de prompts elegible, en lugar de procesar de nuevo toda la conversación.

Sin embargo, comprometerse al comienzo del hilo crea una limitación importante. Los prompts iniciales no siempre predicen el trabajo posterior.

Un usuario puede comenzar con una pregunta sobre un repositorio y luego solicitar una corrección de errores. Un cambio aparentemente pequeño puede revelar un problema de dependencias después de que el agente ejecute pruebas.

El router actual no responde automáticamente a esa evolución. Una vez que elige un nivel, la misma selección permanece activa durante el hilo.

Esto hace que la clasificación inicial sea más determinante de lo que parece a primera vista. Un enrutamiento insuficiente puede atrapar una tarea difícil en un modelo más débil. Un enrutamiento excesivo puede eliminar los ahorros esperados.

El diseño publicado por LangChain incluye tres componentes comprensibles: una instrucción base, criterios de nivel y un clasificador. Esa simplicidad facilita la auditoría, pero no puede captar todas las fuentes de complejidad.

El tamaño del repositorio, el lenguaje, la salida de pruebas fallidas y los permisos de herramientas necesarios podrían hacerse visibles solo después de que comience la ejecución. El clasificador no puede utilizar evidencia que todavía no existe.

El enfoque funciona mejor cuando las solicitudes iniciales contienen suficiente información para separar el trabajo rutinario del exigente. Los prompts vagos son más difíciles de clasificar de forma fiable.

Esta limitación no invalida la selección de modelos en el harness de agentes. Define el siguiente problema de ingeniería: ¿cuándo debería un agente reconsiderar su modelo después de recopilar nueva evidencia?

El resultado de costos es más sólido que la afirmación sobre calidad

El experimento respalda una conclusión clara sobre costos, mientras que su evidencia de calidad sigue siendo útil, pero incompleta.

LangChain utilizó las solicitudes de extracción fusionadas como su principal medida de éxito. Un hilo contaba positivamente cuando Open SWE abría una solicitud de extracción que los usuarios fusionaban después.

El grupo enrutado registró una tasa de fusión del 29,2%, frente al 27,3% del grupo de control. El valor p informado fue 0,49.

Un valor p de ese nivel no respalda la afirmación de que el sistema enrutado funcionó mejor. Tampoco demuestra que ambos sistemas fueran equivalentes en todas las dimensiones de calidad.

La conclusión más prudente es la que usa LangChain: en esta prueba no apareció un cambio de calidad medible. Esa formulación reconoce los límites de detección del experimento.

Las tasas de apertura de pull requests fueron igualmente cercanas. Los hilos enrutados abrieron pull requests a una tasa del 38,9 %, mientras que el control alcanzó el 39,6 %. El valor p reportado fue de 0,82.

Estas cifras reducen la preocupación por un colapso evidente en la finalización de tareas. No muestran si los pull requests enrutados requirieron más edición humana ni si introdujeron defectos más sutiles.

Un merge es una señal significativa de producción porque refleja la aceptación del usuario. También está influido por factores que van más allá de la calidad del modelo.

La disponibilidad de revisores, la urgencia de la tarea, las convenciones del repositorio y los cambios en el comportamiento de los usuarios pueden afectar a que un pull request se fusione. Algunos hilos valiosos nunca necesitan un pull request.

LangChain añadió reacciones de pulgar arriba y pulgar abajo para cubrir esas interacciones sin PR. La empresa afirma que la participación fue escasa, lo que limita el valor estadístico de la medida.

Los comentarios sí revelaron errores visibles de enrutamiento. Los ingenieros se quejaron cuando tareas sencillas llegaban al nivel de rendimiento porque los recursos parecían innecesarios.

El fallo inverso recibió una prueba más breve. LangChain comparó el enrutamiento con un control de solo modelos rápidos, pero finalizó el experimento en un día.

Según la empresa, los ingenieros informaron de inmediato de baja calidad de resultados e interrupciones de productividad en el grupo de solo modelos rápidos. La prueba terminó antes de poder generar resultados estadísticamente significativos.

Ese episodio ayuda a definir el principal contrincante. La elección no es entre el enrutamiento y elegir siempre el modelo más barato.

Es entre una asignación contextual y una política fija en cualquiera de los extremos. Operar solo con modelos de frontera desperdicia capacidad en trabajo rutinario, mientras que operar solo con modelos rápidos puede fallar cuando las tareas se vuelven exigentes.

La prueba en producción favorece la asignación contextual en costes. Aún no establece los mejores criterios de enrutamiento, el número óptimo de niveles ni ahorros universales para otros agentes.

El tráfico procedía de los propios ingenieros de LangChain trabajando con Open SWE. Esa población conoce las bases de código de la empresa, el comportamiento de los agentes y el flujo de trabajo interno.

Los usuarios externos pueden redactar solicitudes menos estructuradas. Otros entornos de programación pueden tener distribuciones de tareas o estándares de revisión distintos.

El modelo de comparación también importa. LangChain eligió como control principal su nivel más potente y costoso. Un equipo que ya utiliza un valor predeterminado equilibrado debería esperar una oportunidad menor.

La asignación de niveles podría cambiar a medida que evolucionen las capacidades de los modelos y las condiciones de los proveedores. Un router no es una clasificación permanente de las marcas de modelos.

En cambio, es una política operativa que requiere evaluación repetida. Los modelos mejoran, las mezclas de tareas cambian y la opción equilibrada de ayer puede convertirse en el nivel rápido de mañana.

Por eso la reducción reportada del 64 % no debería convertirse en una previsión genérica. Es un resultado medido para un agente, una carga de trabajo, una semana y una política de control.

El experimento sigue siendo valioso porque utiliza trabajo real en lugar de un conjunto de prompts sintético. El tráfico de producción captura ambigüedad, comportamiento de seguimiento y variación de tareas que los benchmarks estáticos a menudo pasan por alto.

Un seguimiento más sólido combinaría resultados en vivo con evaluación offline controlada. LangChain ha identificado benchmarks como DeepSWE como una posible vía hacia comparaciones repetibles.

Las pruebas offline podrían reproducir un conjunto fijo de tareas representativas entre versiones del router. La revisión humana podría entonces evaluar la corrección, la mantenibilidad y las ediciones necesarias.

Las pruebas en vivo seguirían siendo necesarias porque los usuarios cambian su comportamiento en torno a los agentes. Juntos, ambos métodos ofrecerían mejores pruebas que cualquiera de ellos por separado.

Los valores predeterminados fijos de modelos de frontera ahora afrontan más escrutinio

El resultado presiona a los equipos que tratan el modelo más potente como un valor predeterminado automático de producción.

Ese valor predeterminado es comprensible durante el desarrollo inicial. Usar un solo modelo elimina una variable y permite a un equipo centrarse en las herramientas, los prompts, los permisos y la fiabilidad de ejecución.

Se vuelve más difícil de defender a medida que crece el tráfico. Una carga de trabajo heterogénea obliga a las organizaciones a pagar por capacidad máxima incluso cuando las solicitudes necesitan mucho menos.

LangChain se encontró con esa presión al aumentar su gasto mensual en agentes de programación. Según los informes, los clientes plantearon preocupaciones similares, lo que impulsó el experimento de Open SWE.

El cambio más amplio va de comparar modelos mediante benchmarks a comparar sistemas. Una puntuación alta de un modelo no revela si cada tarea dentro de un agente se beneficia de esa capacidad.

Los resultados de los agentes dependen del sistema completo. La calidad de las herramientas, la recuperación de información, los permisos, la gestión de estado, los prompts y la revisión humana pueden pesar más que una pequeña diferencia entre modelos.

El enrutamiento añade otra variable al sistema. La cuestión pasa a ser qué combinación de modelo, contexto y arnés produce un resultado aceptable para cada clase de tarea.

Los proveedores de modelos ya fomentan la adecuación a la carga de trabajo. La guía de selección de modelos de Anthropic recomienda considerar inteligencia, velocidad y coste en lugar de elegir únicamente por capacidad.

LangChain extiende ese principio desde el diseño de aplicaciones hasta los hilos individuales de los agentes. En vez de seleccionar un único modelo de compromiso para todo un producto, el arnés toma una decisión por tarea.

Esto también puede ampliar el papel de los modelos abiertos. El nivel rápido de Open SWE utilizó GLM-5.3-Flash, que LangChain describe como un modelo abierto situado cerca de alternativas cerradas en la curva elegida.

El experimento no aísla la contribución de GLM. Los resultados se reportaron para el sistema enrutado en su conjunto, no como comparaciones aleatorizadas entre todos los niveles.

Aun así, el enrutamiento puede crear un punto de entrada práctico para modelos que no llegarían a convertirse en un valor predeterminado para toda la organización. Un nivel más limitado reduce la exposición mientras genera datos de resultados reales.

La diversidad de proveedores también reduce la dependencia de una sola línea de modelos. La interfaz común de LangChain permite al equipo sustituir un nivel sin reconstruir la arquitectura del agente.

Esa flexibilidad introduce complejidad operativa. Distintos proveedores pueden tener comportamientos diferentes en llamadas a herramientas, límites de contexto, reglas de caché y controles de seguridad.

Una ruta que parece eficiente sobre el papel puede fallar si un modelo da formato distinto a los argumentos de herramientas. Por ello, las pruebas entre proveedores deben formar parte del proceso de evaluación.

Las políticas de seguridad también deben seguir la ruta seleccionada. Los datos sensibles del repositorio no deberían pasar a un proveedor simplemente porque su modelo encaja en un nivel de menor coste.

Los equipos necesitan reglas explícitas de elegibilidad antes de comparar la capacidad de los modelos. El cumplimiento, la región de despliegue, la retención de datos y el soporte de herramientas pueden excluir por completo a algunos candidatos.

El enrutamiento debería ocurrir solo entre modelos ya aprobados para los datos y las acciones de la tarea. La optimización de costes no puede sustituir al control de acceso.

El propio clasificador crea otra frontera de confianza. Una solicitud manipulada o ambigua podría influir en la selección de nivel de maneras no deseadas.

Para los agentes de programación, el impacto puede ir más allá de la calidad de las respuestas. El modelo seleccionado puede recibir acceso al shell, credenciales del repositorio o la capacidad de proponer cambios.

La arquitectura de Open SWE utiliza entornos aislados y acotados por hilo, pero su propia documentación advierte que los sandboxes de programación siguen requiriendo credenciales de mínimo privilegio y aprobaciones cuidadosamente adaptadas.

El enrutamiento de modelos debería preservar esos controles en todos los niveles. Un modelo más débil no debería recibir permisos más amplios para compensar una menor capacidad de razonamiento.

Para los usuarios que evalúan estos sistemas, la trazabilidad importa tanto como los ahorros anunciados. Los operadores deberían poder explicar qué modelo gestionó una tarea y por qué.

Ese registro puede respaldar la depuración, las revisiones de auditoría y la reproducción posterior. También proporciona a los equipos evidencia para cambiar los criterios de nivel en lugar de depender de anécdotas.

Un flujo de trabajo de IA práctico puede ayudar a los equipos a resumir cambios de enrutamiento, métricas de resultados y fallos recurrentes para las partes interesadas.

Qué observar tras la prueba del router de modelos de LangChain

Tres señales mostrarán si el enrutamiento a nivel de arnés se convierte en un patrón duradero para agentes o sigue siendo un prometedor experimento interno.

La primera señal es el rendimiento en benchmarks controlados. LangChain afirma que quiere probar el enrutamiento frente a DeepSWE u otro benchmark de programación.

Una evaluación repetible podría examinar si el clasificador envía de forma consistente las tareas difíciles a modelos capaces. También podría medir la calidad más allá de los merges de pull requests.

Busque tasas de aprobación, puntuaciones de revisión humana, recuentos de regresiones y la cantidad de trabajo correctivo requerido. Estas medidas reforzarían el caso si los resultados enrutados siguen siendo comparables.

Lo debilitarían si los niveles inferiores producen cambios que superan comprobaciones superficiales pero requieren más mantenimiento. Un conjunto de datos estable también facilitaría la comparación de revisiones del router.

La segunda señal es el reenrutamiento a mitad del hilo. Open SWE actualmente toma una decisión a partir de la solicitud humana inicial y mantiene ese modelo durante todo el hilo.

LangChain ha identificado el reenrutamiento como una dirección futura. El desencadenante podría ser una solicitud de usuario modificada, fallos repetidos de herramientas, sentimiento negativo o una complejidad inesperada de la tarea.

Un reenrutamiento exitoso resolvería la limitación más clara del sistema. Podría rescatar trabajo clasificado por debajo de lo necesario sin asignar capacidad de frontera desde el principio.

La contrapartida implica la reutilización del contexto. Cambiar de modelo puede descartar las ventajas de la caché de prompts y obligar al nuevo modelo a procesar de nuevo la conversación.

Los equipos deberían observar si LangChain publica reglas explícitas de escalado. Una implementación útil explicaría cuándo el cambio cuesta menos que continuar con un modelo inadecuado.

La tercera señal es el rendimiento entre subagentes. Los subagentes de Open SWE actualmente eligen sus modelos de forma separada del router a nivel de hilo.

Las ejecuciones largas de agentes pueden delegar investigación, análisis de pruebas o exploración de repositorios a trabajadores especializados. Esas tareas pueden necesitar niveles de capacidad diferentes.

El enrutamiento coordinado de subagentes podría aumentar los ahorros porque un único hilo puede contener muchas llamadas a modelos. También podría multiplicar los errores de clasificación.

Por tanto, la evidencia debería cubrir los resultados totales de la tarea, no los costes de llamadas aisladas. Un subagente barato que envía evidencia incompleta al agente principal puede encarecer toda la ejecución.

La adopción más amplia dependerá de si otros equipos reproducen el resultado de LangChain con cargas de trabajo diferentes. Los agentes de atención al cliente, investigación y datos no comparten la estructura de tareas de Open SWE.

Cada uno necesita sus propias definiciones de éxito. Un agente de soporte puede optimizar las tasas de resolución y escalado, mientras que un agente de investigación puede priorizar la precisión y cobertura de las fuentes.

Esta es la lección duradera del experimento. El enrutamiento no es un prompt universal pegado delante de un catálogo de modelos.

Es un sistema de control específico del dominio construido a partir de trazas, categorías de tareas, evidencia de modelos y resultados medibles. El arnés es un hogar natural porque ya coordina esos elementos.

Las cifras de LangChain ofrecen una razón creíble para probar ese diseño. No justifican copiar sus tres niveles sin una evaluación local.

Los equipos deberían empezar por mapear su tráfico real y definir el fallo antes de activar el enrutamiento automático. También deberían mantener una alternativa de modelo fijo para errores del clasificador o solicitudes inciertas.

La siguiente pregunta ya no es si todos los agentes deberían usar el modelo más potente. Es si los equipos pueden identificar dónde el razonamiento de frontera cambia los resultados y reservarlo para esos momentos.

Si los benchmarks controlados, el escalado a mitad del hilo y el enrutamiento de subagentes respaldan los resultados iniciales, el router de modelos de LangChain representará más que un experimento de costes. Ofrecerá una arquitectura práctica para asignar inteligencia de modelos según el trabajo real.