Como criar um roteador de modelos no harness

Autoria: LangChain · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How to Build a Model Router in the Harness · Canal: LangChain · 13:16 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos, Modelos locais e open source

Resumo

Sydney, gerente de produto da equipe open source da LangChain, explica como criar um roteador de modelos no harness para reduzir custos sem comprometer a qualidade. No experimento com o agente de programação Open SWE, a equipe analisou os tipos e a complexidade das tarefas, selecionou modelos com diferentes relações entre custo e capacidade e implementou uma decisão de roteamento por thread. Em um teste A/B com quase 500 threads, o custo mediano por thread caiu 64%, sem mudança mensurável na qualidade. A apresentação também aborda os riscos dos testes com usuários, possibilidades de aprimoramento e quatro recomendações para começar.

Pontos-chave

Roteadores de modelos podem reduzir custos ao encaminhar tarefas para modelos de capacidades diferentes, sem sacrificar a qualidade quando bem configurados.
Entender a variedade e a complexidade das tarefas do agent é a base para definir os critérios de roteamento.
A equipe escolheu GLM-5.3-Flash para o nível rápido, GPT-5.6 Sol para o equilibrado e GPT-6 Astra para o nível de desempenho.
O roteador inicial escolhia o modelo com base na primeira mensagem da thread e mantinha essa escolha durante a tarefa.
O experimento com Open SWE reduziu em 64% o custo mediano por thread, sem mudança mensurável na qualidade.
A avaliação combinou métricas como taxa de PRs mesclados e feedback positivo ou negativo dos usuários.
Um teste com o modelo rápido como controle foi interrompido após reclamações de usuários, mostrando que ele não atendia a todas as tarefas.
Melhorias possíveis incluem evals adicionais, seleção de modelos para subagents, novo roteamento durante a thread e sinais de avaliação mais ricos.
A recomendação é entender as tarefas, escolher modelos na fronteira de Pareto, integrar o roteamento ao harness e medir os resultados antes de começar a rotear tráfego real.

Capítulos

Início	Capítulo	Resumo
00:00	Por que usar um roteador de modelos	A apresentadora introduz o problema do custo dos modelos avançados e explica como o roteamento pode combinar modelo, harness e tarefa.
02:07	Análise das tarefas do Open SWE	A equipe usa traces do LangSmith para identificar os tipos de tarefa do agente e comparar sua complexidade.
04:46	Escolha dos modelos e implementação do roteador	A apresentação descreve a seleção de modelos em diferentes níveis e a implementação do roteamento no harness.
08:03	Medição dos resultados e experimento A/B	A equipe compara custos e indicadores de qualidade, relata os resultados do teste e explica por que outro experimento foi interrompido.
10:38	Próximos passos e recomendações	A apresentadora discute melhorias possíveis e resume quatro passos para criar e avaliar um roteador de modelos.

Citações

Como criar um roteador de modelos no harness para reduzir custos sem sacrificar a qualidade. — 00:00

Conseguimos reduzir em 64% o custo mediano por thread, sem mudança mensurável na qualidade. — 02:07

O roteador roda uma vez, na primeira mensagem da thread, e então seleciona o modelo para o restante da tarefa. — 06:27

Trate o roteamento como engenharia de contexto e construa o roteador no harness. — 12:46

Conceitos e entidades

Sydney (pessoa): Apresentadora e gerente de produto da equipe open source da LangChain.
LangChain (empresa): Empresa cuja equipe open source desenvolveu e avaliou o roteador de modelos apresentado.
Open SWE (ferramenta): Agente de programação open source usado como ambiente de teste para o roteamento de modelos.
LangSmith (ferramenta): Ferramenta usada para registrar e analisar traces das execuções do Open SWE.
GLM-5.3-Flash (modelo): Modelo rápido escolhido para o roteador inicial e descrito como open model.
GPT-5.6 Sol (modelo): Modelo selecionado para o nível equilibrado do roteador.
GPT-6 Astra (modelo): Modelo selecionado para o nível de desempenho do roteador.
Jev (ferramenta): Decision model adotado posteriormente para tomar decisões de roteamento com mais rapidez e menor custo.
Artificial Analysis Intelligence Index (ferramenta): Índice usado como referência para comparar inteligência de modelos e sua relação com custo.
Deep SWE (benchmark): Conjunto de evals citado como opção para avaliar o roteador além do teste A/B.
Deep Agents (ferramenta): Harness mencionado no contexto da orquestração de subagents pelo agente principal.
model routing middleware (ferramenta): Middleware da LangChain apresentado como forma de adicionar roteamento de modelos a um agent.

Tradução completa (pt-BR)

00:00 Olá, pessoal. Meu nome é Sydney. Sou gerente de produto da equipe de open source da LangChain. Hoje, estou muito animada para mostrar como você pode criar um roteador de modelos no harness para reduzir custos sem sacrificar a qualidade. Vamos começar. O problema que nos motivou a criar um roteador de modelos é que a inteligência de ponta é muito cara. Então, se você está criando agents que trabalham em escala, esse custo pode ser proibitivo. O roteamento de modelos pode ajudar a reduzir custos, teoricamente sem sacrificar a qualidade, se for bem feito.

00:33 Tenho aqui uma citação que mostra que provedores de modelos, como a Anthropic, recomendam até começar com modelos menores, neste caso, como Claude Haiku, antes de passar para um modelo mais inteligente, como Opus, porque muitas tarefas podem ser realizadas com esses modelos mais baratos. Então, basicamente, estou partindo do princípio de que muitas vezes não precisamos do melhor modelo para várias tarefas que pedimos ao nosso agent. Depois de certo ponto, você acaba tendo retornos decrescentes: o custo e a latência aumentam, mas a qualidade das respostas não melhora significativamente.

01:05 E, idealmente, um agent tem um bom ajuste entre modelo, harness e tarefa. O que isso significa? Significa ter o modelo certo para o trabalho na curva de inteligência e custo. E, então, o harness faz um bom trabalho ao fornecer ao modelo o contexto certo para a tarefa em questão. Então, o que um roteador de modelos realmente faz? Ele escolhe o modelo certo para cada tarefa. Uma solicitação de tarefa chega, e o roteador tem um modelo classificador e um prompt

01:35 com alguns critérios que o ajudam a decidir qual modelo é mais adequado para determinada tarefa. Seria um modelo rápido e barato, talvez algo equilibrado, ou um modelo focado em desempenho, que será mais lento e mais caro? Então, ele seleciona o modelo para a tarefa, e esse modelo é usado para alimentar o agent que a conclui. Nosso ambiente de testes foi o Open SWE, nosso agent de programação open source. Para antecipar os resultados do experimento, conseguimos observar uma redução de 64% no custo mediano

02:07 por thread, sem mudança mensurável na qualidade. Há quatro etapas para criar um roteador de modelos, e vou explicá-las com base no experimento que fizemos com o Open SWE. Mas aqui vai uma pequena prévia. Primeiro, você precisa entender as tarefas que seu agent realiza. Precisa entender os modelos disponíveis para essas tarefas. Depois de concluir as etapas um e dois, você pode criar o roteador no harness do seu agent. E é muito importante acompanhar os resultados das tarefas para entender se o roteador está funcionando bem, ou seja, se está reduzindo custos sem sacrificar a qualidade.

02:40 Certo, vamos falar da etapa um: entender as tarefas. A primeira coisa que fizemos foi tentar entender quais tarefas eram atribuídas ao nosso agent de programação, o Open SWE. Fizemos tudo isso usando o LangSmith. Toda vez que nosso agent de programação é executado, ele envia um trace ao LangSmith, que registra cada etapa realizada pelo agent. Assim, pudemos usar todos esses traces e fazer uma análise agregada para determinar que tipos de tarefas nosso agent realizava. Como você pode ver aqui, sem surpresa, para um agent de programação, as alterações de código predominavam, como solicitações de funcionalidades, correções de bugs e testes.

03:11 Mas também havia coisas como perguntas sobre design e perguntas de propósito geral. De todas as etapas, eu diria que esta é a mais importante. É a base para definir os critérios do roteador: decidir que tipos de tarefas devem ser atribuídos a cada modelo. Então, se você não tiver uma compreensão clara

03:42 desse espaço de tarefas, será muito difícil desenvolver um roteador eficaz. Como mencionei, o LangSmith foi muito importante para ajudar a entender esse espaço. Na verdade, criei um app personalizado sobre o LangSmith para me ajudar a entender melhor esses dados de trace. Aqui você pode ver as categorias, o tempo ativo do agent e o custo observado de LLM, filtrados por diferentes tipos de solicitações. No geral, isso foi muito útil para fazer uma análise exploratória de dados dos meus traces.

04:14 Ainda como parte da etapa um, eu queria entender melhor como a complexidade variava de acordo com o tipo de tarefa, sabendo que provavelmente queremos um modelo mais inteligente para tarefas mais complexas. Aqui você pode ver que medimos o número mediano de invocações, ou seja, quantas vezes o Open SWE foi chamado. Também medimos o custo mediano de LLM para esses diferentes grupos de tarefas. Em geral, considerávamos uma tarefa mais complexa quando o número de invocações era maior ou o custo de LLM era mais alto.

04:46 E, como você pode ver, sem surpresa, o trabalho com funcionalidades era geralmente mais complexo do que, por exemplo, o trabalho de testes. Certo, esta parte é bem divertida. A etapa dois é entender os modelos disponíveis para suas tarefas. Esses dados vêm do Artificial Analysis Intelligence Index em 9 de setembro de 2026, quando começamos este experimento. No eixo X, temos o custo por tarefa de inteligência. No eixo Y, temos o Artificial Analysis Intelligence Index.

05:18 É o que chamamos de fronteira de Pareto dos LLMs. Trata-se do conjunto de modelos ideais que oferecem um bom equilíbrio entre a precisão em benchmark e os evals, em comparação com custo e latência. Em geral, queremos selecionar modelos ao longo dessa fronteira. Como estávamos projetando um roteador de modelos, queríamos escolher um pequeno conjunto de modelos com diferentes equilíbrios entre velocidade e índice de inteligência. Os modelos que acabamos escolhendo foram GLM-5.3-Flash para o modelo rápido, GPT-5.6

05:53 Sol para o modelo equilibrado e GPT-6 Astra para a categoria de desempenho. A etapa três é criar o roteador no harness. Usamos duas fontes de dados para definir os critérios da versão inicial do roteador. A primeira foi o conhecimento das tarefas que obtivemos na etapa um. A segunda foram os guias oficiais dos provedores, como os da OpenAI, sobre quais modelos usar para cada tarefa. Aqui você pode ver alguns dos descritores que usamos nos critérios de cada modelo.

06:27 Também é importante observar que, no nosso roteador, ele é executado apenas uma vez, na primeira mensagem da thread, e então seleciona o modelo para o restante da tarefa. Isso é diferente de alguns roteadores que fazem o roteamento durante a execução. Decidimos começar com uma versão simples, mas, quando eu falar das melhorias previstas ou dos próximos trabalhos, vou abordar o roteamento no meio da thread. Quando criamos inicialmente esse roteador, no começo de setembro, usamos um LLM pequeno, especificamente o GLM-5.3-Flash, para tomar a decisão de roteamento com saída estruturada. Mas, depois do experimento,

07:02 Jev, um decision model popular, foi lançado com alegações de ser significativamente mais rápido e barato do que os LLMs, com poderes de tomada de decisão mais limitados. Agora, estamos usando Jev, o decision model, para alimentar o roteador do nosso Open SWE. Ele é muito mais rápido e barato, como Jev anunciava. A última coisa que vou destacar neste slide é que o GLM-5.3-Flash é, na verdade, um modelo open. Há algum tempo, na LangChain, escrevemos um artigo sobre modelos open ultrapassando um certo patamar.

07:33 Com certeza achamos que isso é verdade. Usamos bastante modelos open internamente. E um roteador de modelos é uma ótima oportunidade para experimentar modelos open mais baratos e rápidos em tarefas que eles são mais do que capazes de realizar. Certo. Para a etapa quatro, você precisa decidir como vai acompanhar os resultados das tarefas. Há duas formas principais de fazer isso. A primeira é por meio de evals offline. É uma opção muito segura. Você pode fazer comparações e experimentos reproduzíveis. Mas o porém é que pode ser um pouco difícil e caro

08:03 desenvolver um conjunto de dados representativo. Então, a abordagem mais rápida é fazer um teste A/B, em que você sabe que o tráfego ao vivo é representativo. Mas o porém, nesse caso, é que estamos fazendo esse experimento com nossos usuários ativos, que podem acabar usando um roteador não ideal — esse é o risco. Os dois resultados que acompanhamos com nosso teste A/B foram a taxa de PRs mesclados. Também permitimos que os usuários dessem feedback sobre as execuções do Open SWE, podendo votar positivamente

08:34 ou um voto negativo. Então, dá para imaginar que queremos garantir que, nos 50% das threads que passam por esse novo router, a taxa de PRs merged não caia significativamente e que o feedback também não seja significativamente diferente. Certo, então, quais foram os resultados do experimento número um? Tivemos quase 500 threads. E dá para ver que o custo mediano por thread do router foi muito menor: 64% menor. O custo médio também foi menor, e o custo P90 por thread

09:05 foi 37% menor. Na verdade, vemos que, neste caso, mais threads da versão com roteamento terminaram em um PR merged, embora a diferença não tenha sido estatisticamente significativa. Também vemos que a taxa de abertura de PRs foi bastante semelhante entre nossos grupos A e B. Neste detalhamento, dá para ver a proporção de tarefas enviadas a cada nível de modelo. Enviamos 34% para o nível rápido, 56% para o nível equilibrado e apenas 10% para o nível de desempenho.

09:37 À extrema esquerda, dá para ver as diferentes distribuições de custos do modelo sempre no nível de desempenho em comparação com o modelo com roteamento. À direita, dá para ver que, nas threads com roteamento, as execuções rápidas foram muito mais baratas que as execuções no nível de desempenho. E, mais à direita, dá para ver o agregado: as execuções rápidas foram muito mais baratas, enquanto as dos níveis equilibrado e de desempenho foram mais caras, respectivamente. Uma observação interessante: vimos, sem dúvida, algumas threads muito longas contribuindo

10:07 de forma desproporcional para o custo. Isso aconteceu tanto no grupo com roteamento quanto no grupo sem roteamento do experimento. Vale observar que iniciamos um segundo experimento, comparando o router com um modelo rápido de controle. No primeiro experimento, o modelo de controle era o modelo de desempenho. Encerramos esse teste em menos de um dia porque recebemos muitas reclamações de usuários que ficaram presos ao grupo com o modelo rápido. Recebemos reclamações suficientes e não queríamos degradar significativamente a experiência dos usuários. Por isso, decidimos interromper o experimento. Mas o resultado foi bastante revelador.

10:38 Certamente não poderíamos passar a usar o GLM-5.3-Flash para todas as tarefas que o Open SWE precisa gerenciar. Então, o que vem a seguir? Há, sem dúvida, muitas coisas que poderíamos fazer para explorar ainda mais as otimizações de model routing. Acho que a primeira seria avaliar o router em outros conjuntos de evals, como o Deep SWE, em vez de fazer apenas testes A/B; ou talvez até usar outros benchmarks mais voltados à revisão, porque, em geral, a tarefa do Open SWE é gerar PRs bons e fáceis de revisar. A segunda coisa que não abordamos

11:09 é a seleção de modelos para subagents. Ainda há mais otimizações de custo a fazer se também selecionarmos modelos de tamanho adequado para os subagents com os quais o agent principal se coordena usando o harness do Deep Agents. Uma terceira coisa que mencionei antes e que poderíamos explorar é mudar o roteamento no meio da thread. Imagine que, no Open SWE, um usuário faça uma pergunta e depois descubra que talvez seja necessário corrigir um bug bastante complexo ou queira projetar um novo recurso no meio da thread. Nesse caso, talvez seja melhor passar para um modelo mais capaz.

11:43 Mudar o roteamento no meio da thread pode ajudar a garantir que o modelo certo seja escolhido para a tarefa em qualquer momento daquela thread. Uma desvantagem é que, ao trocar de modelo, ocorre um cache miss, o que pode ser custoso. Mas, para agents assíncronos como o Open SWE, já há muitos cache misses de qualquer forma, simplesmente porque há mais de cinco minutos de inatividade entre a resposta de um agent e o momento em que um desenvolvedor consegue responder no Slack. Portanto, esse cache miss talvez não seja uma preocupação muito significativa.

12:15 E a quarta coisa seria buscar sinais de roteamento mais ricos. Não recebemos muito feedback sobre os traces. A taxa de PRs merged foi uma métrica muito confiável, mas também seria útil tentar obter mais feedback ativo. Certo, então, se quiser começar a criar seu próprio router, recomendo seguir as quatro etapas que usamos neste experimento. Primeiro, entenda o espaço de tarefas do seu agent. Segundo, escolha modelos ao longo da fronteira de Pareto, a curva de inteligência em relação ao custo.

12:46 Terceiro, trate o roteamento como engenharia de contexto e crie seu router dentro do harness, onde o contexto adequado esteja disponível para as tarefas em questão. Quarto, certifique-se de ter como medir o sucesso antes de começar o roteamento em produção. Você pode adicionar facilmente o roteamento ao seu próprio agent com nosso middleware de model routing. Na LangChain, sempre nos orgulhamos de oferecer software open source agnóstico em relação aos provedores de modelos. Por isso, trocar os modelos no seu router deve exigir apenas uma alteração em uma linha de código.

13:16 Você também pode conferir o Open SWE em langchain-ai/open-swe no GitHub. Saiba mais sobre como criar um harness com Jev, um decision model incrivelmente poderoso para a etapa de model routing, no artigo do blog indicado abaixo. E sempre gostamos de ouvir você. Fique à vontade para marcar a gente em @LangChain no X. Obrigado por assistir e até a próxima.

Transcrição original

[00:00] Hey, folks. My name is Sydney. I’m the product manager for the open source team at LangChain. And today, I’m super excited to share with you how you can build a model router in the harness to reduce cost without sacrificing quality. Let’s jump in. So the motivating problem for building a model router is that frontier intelligence is really expensive. And so if you’re building agents that work at scale, this cost can be prohibitive. And so model routing can help to reduce cost, theoretically without sacrificing quality if it’s done well.

[00:33] I have a quote here showing that model providers like Anthropic even recommend starting with smaller models, in this case like Claude Haiku, before graduating to a more intelligent model like Opus, because a lot of tasks can be done with these cheaper models. So I’m basically assuming here that we often don’t need the best model for a lot of tasks that we ask our agent to do. Past a certain point, you kind of hit diminishing returns where your cost and latency are increasing, but the quality of the outputs are not significantly better.

[01:05] And ideally, an agent has good model-harness-task fit. And what does that mean? It means you have the right model for the job on the intelligence and cost curve here. And then your harness does a good job of getting the right context to the model for the given task at hand. So what does a model router actually do? It picks the right model for each task. And so a task request comes in, and a router has a classifier model, and then a prompt

[01:35] with some criteria that help it decide what model would be most appropriate for a given task. So would that be a fast and cheap model, maybe something balanced, or a performance-focused model that’s going to be slower and more expensive? And then it selects the given model for the task, and then that model is used to power the agent that completes the task. And so our test bed here was Open SWE, our open source coding agent. And to kind of spoil the results of the experiment here, we were able to see a 64% reduction in median cost

[02:07] per thread with no measurable change in quality. There’s four steps for building a model router, and I’ll explain them through the lens of this Open SWE experiment that we ran. But a little sneak peek here. First, you need to understand the tasks that your agent works on. You need to understand the models available for these tasks. Then with one and two done, you can build the router in your agent’s harness. And it’s very important to track task outcomes so that you can understand if your router is working well. That is reducing cost without sacrificing quality.

[02:40] OK, so let’s talk about step one, understanding the tasks. The first thing that we did was try to understand what our coding agent Open SWE is being tasked with. This was all done using LangSmith. So every time our coding agent runs, it sends a trace to LangSmith that has a record of every step that that agent took. And so we were able to use all of those traces and do aggregate analysis over them to determine what types of tasks our agent was doing. So you can see here, unsurprisingly, for a coding

[03:11] agent that code changes dominated things like feature requests, bug fixes, and tests. But there were also some things like design questions and general purpose questions. Out of all of the steps, I would actually say that this one is the most important. This is what you use as the foundation for building your criteria for the router. You know, deciding what types of tasks should be assigned which model. And so if you don’t have a clear understanding

[03:42] of this task space, it’s going to be very hard to develop an effective router. And LangSmith, as I mentioned, was very instrumental in helping understand this space. I actually built a custom app on top of LangSmith to help me better understand this trace data. So you can see kind of the categories here and then active agent time and observed LLM cost filtered by different types of requests. Overall, this was super helpful for basically exploratory data analysis over my traces.

[04:14] Also as part of step one, I wanted to better understand how complexity varied by task type, knowing that we probably want a more intelligent model for more complex tasks. So you can see here, we measured median invocations. So that’s the number of times Open SWE was called. And then also the median LLM cost for these different buckets of tasks. And then we generally rated a task as more complex if the number of invocations were higher or the LLM cost was higher.

[04:46] And you can see kind of unsurprisingly here that like feature work was generally more complex than say testing work. All right, so this part is actually quite fun. Step two is understanding the models available for your tasks. So this data is pulled from the Artificial Analysis Intelligence Index as of September 9th, 2026, which is when we began this experiment. And you can see on the X-axis, we have the cost per intelligence task. And then on the Y-axis, we have the Artificial Analysis Intelligence Index.

[05:18] This is what we call the Pareto frontier for LLMs. It’s this set of optimal models that have a good trade-off between like benchmark accuracy and evals compared to cost and latency. And so generally we want to select models along this frontier. And then given that we were designing a model router, we wanted to choose a small set of models here that had some trade-offs between their speed and intelligence index. The models that we ended up choosing were GLM-5.3-Flash for our fast model, GPT-5.6

[05:53] Sol for our balanced model, and then GPT-6 Astra for our performance tier. Step three is building the router in the harness. So we used two sources of data to decide on the criteria for our initial version of the router. The first was the understanding of those tasks that we saw in step one. And the second was the official provider guides from OpenAI, for example, on which models to use for which tasks. And so you can see a couple of the descriptors that we used for each of the criteria for a given model.

[06:27] Also important to note for our router here, the router just runs once on the thread’s first message and then selects the model for the remainder of the task. This is different from some routers which do this mid-flight routing. We decided to just do a simple version first, but when I talk about upcoming improvements or further work, mid-thread routing is covered. So when we initially built this router in early September, we used a small LLM, specifically GLM-5.3-Flash, to do the routing decision with structured output. But after the experiment,

[07:02] Jev, a popular decision model, came out and had claims of being significantly faster and cheaper than LLMs with more constrained decision-making powers. And so we are now powering our Open SWE router with Jev, the decision model. And it’s much faster and much cheaper as Jev advertised. The last thing I’ll call out on this slide is that GLM-5.3-Flash is actually an open model. At LangChain a while ago, we wrote a blog about open models crossing a threshold.

[07:33] We definitely think that’s true. We use open models a lot internally. And a model router is a great opportunity to experiment with using cheaper and faster open models for tasks that they’re more than equipped to handle. OK. And then for step four, you need to decide how you’re going to track your task outcomes. There’s two main ways you can do this. The first is through offline evals. So this is very safe. You have repeatable comparisons and experiments that you can run. But the catch is that it can be a little bit hard and expensive

[08:03] to develop a representative data set. And so the faster approach here is to do an A/B test, where you know that your live traffic is representative. But the catch here is that we’re running this experiment for our live users, and so they may experience a non-optimal router, which is the risk. And so the two outcomes that we were tracking with our A/B test were the merged PR rate. And then also, we enabled users to provide feedback on Open SWE runs so they could either give a thumbs up

[08:34] or a thumbs down. And so you can imagine we want to make sure that for the 50% of threads that run through this new router, the merged PR rate doesn’t go down significantly, and the feedback is not significantly different either. All right, so experiment number one, what were our results? We had almost 500 threads. And you can see that the median cost per thread for the router was much lower, 64% lower. The mean cost was also lower, and then the P90 cost per thread

[09:05] was lower by 37%. We see actually for this case more threads from the routed version ending in a merged PR, although the difference was not statistically significant. And then we also see that the PR open rate was pretty comparable across our A and B branches. You can see on this breakdown kind of the proportion of tasks that were sent to each of the model tiers. So we had 34% sent to the fast tier, 56% sent to the balanced tier and only 10% sent to performance.

[09:37] You can see on the far left, kind of the different distribution of costs for the always performance model versus the routed. And then you can see on the right side, for the routed threads, we had much cheaper fast runs and then the performance runs. And then on the right, you can see in aggregate, the fast runs were much cheaper and then balanced and performance more expensive accordingly. One interesting note, we definitely did see a couple of very long threads contributing

[10:07] disproportionately to cost. And this was true for both the routed and non-routed arms of the experiment. I will note, we actually started a second experiment, which was router versus a controlled fast model. So in the first experiment, it was a control of the performance model. We did end this test within a day because we got so many complaints from users who were stuck on the fast arm. And so we got enough complaints. we didn’t want to significantly degrade user experience. And so we decided to stop this experiment. But it was pretty telling.

[10:38] We certainly couldn’t switch over to GLM-5.3-Flash for all of the tasks that Open SWE needs to manage. So what’s next here? There is definitely a lot that we could do to further explore model routing optimizations. I think the first thing would be benchmarking the router on other eval sets like Deep SWE, rather than just doing the A/B testing, or even perhaps other benchmarks that are more review focused, because generally the task for Open SWE is to generate good, reviewable PRs. The second thing that we didn’t touch

[11:09] is model selection for subagents. So there’s definitely more cost optimizations to be made if we also select appropriately sized models for the subagents that the main agent orchestrates with the Deep Agents harness. A third thing that I mentioned earlier we could certainly explore is rerouting mid-thread. So you can imagine if for Open SWE, a user asks a question and then discovers that maybe a pretty complex bug fix is in order or wants to design a new feature mid-thread, you might want to upgrade to a more capable model.

[11:43] And rerouting mid-thread could help to ensure that the right model is chosen for the task at any point in the given thread. One trade-off here is that if you do switch a model, you experience a cache miss, which can be costly. But for async agents like Open SWE, there’s actually a lot of cache misses anyways, just because there’s more than a five minute idle time between when an agent responds and a developer has time to respond back in Slack. So this cache miss might actually not be a super significant concern.

[12:15] And then the fourth thing would be digging for richer routing signals. So we didn’t get a ton of feedback on traces. We did get, you know, the PR merge rate was a very reliable metric, but trying to get more active feedback would be helpful as well. All right, so if you want to get started building your own router, I would recommend following the four steps that we did in this experiment. So one, understand your agent’s task space. Two, pick models along the Pareto frontier, the cost intelligence curve.

[12:46] Third, treat routing as context engineering and build your router into the harness where the appropriate context is for the given tasks at hand. And fourth, make sure you have the power to measure success before you begin live routing. You can easily add routing to your own agent with our model routing middleware. And at LangChain, we’ve always prided ourselves on offering open source software that’s model provider agnostic. And so changing models in your router should just be a one line of code change.

[13:16] You can also check out Open SWE at langchain-ai/open-swe on GitHub. You can learn more about building a harness with Jev, which is a decision model that’s incredibly powerful for the model routing step at the blog linked below. And we always love hearing from you. Feel free to tag us @LangChain on X. Thanks for watching and see you in the next one.