A Baseten Grid faz uma pergunta concreta. Quanto custa concluir uma tarefa de programação?

Um agente de programação gera uma mudança bem organizada para um teste que está falhando. A mudança não passa na CI, e a pessoa que desenvolve pede que o agente tente novamente. A segunda tentativa mexe em uma parte maior do repositório, e a revisão toma meia hora para uma correção que deveria levar cinco minutos. Qual modelo saiu mais barato?

A Baseten apresentou a Grid em prévia pública em 4 de novembro. Ela combina um gateway para modelos aprovados, um roteador e controles centrais de uso e proteção. O serviço pode ficar entre ferramentas de programação compatíveis e seus modelos, permitindo que a equipe aplique uma política comum às solicitações. A página de acesso antecipado encaminha as equipes para uma lista de espera.

Escolha o denominador certo

Custo por tarefa aceita. Ilustração original da Telli.sh.

O preço de um token mede uma unidade de uso do modelo. A equipe precisa entregar algo que passe pelos critérios de aceitação. Uma solicitação pode gerar uma resposta e uma execução pode produzir um diff, mesmo que a tarefa continue incompleta. Contar esses eventos separadamente torna o teste de roteamento mais útil.

Imagine duas rotas que recebem 100 tarefas parecidas cada. A rota econômica gasta $50 nas tentativas e conclui 50 tarefas de forma aceitável. A outra gasta $90 e conclui 90. Nesse cálculo ilustrativo, ambas gastam $1 em uso do modelo por resultado aceito. Ao incluir o tempo da revisão humana, o custo das ferramentas e a espera por novas tentativas, as rotas podem divergir. Esses custos podem favorecer qualquer um dos lados.

Mantenha as falhas no numerador. Uma rota que desiste dos pedidos difíceis pode parecer eficiente se as tentativas abandonadas sumirem das contas. Mantenha estável também a definição de sucesso. Para uma alteração na documentação, um diff aprovado pode bastar. Uma migração precisa de testes com os dados existentes e de um caminho para reverter a mudança.

A categoria do trabalho faz diferença. Uma migração de API em todo o repositório pode ser difícil porque exige contexto, coordenação e muitas alterações pequenas. Uma correção de uma linha pode ser mais difícil por envolver um erro sutil de concorrência. O número de arquivos e o tamanho do prompt só são sinais úteis quando ajudam a prever resultados no seu ambiente.

Leia o experimento do roteador como um equilíbrio entre custo e resultado

Experimento de roteamento. Ilustração original da Telli.sh.

O relatório técnico da Baseten compara o uso exclusivo do Opus 5.5 com a distribuição de tarefas entre esse modelo e o GLM 5.3 Flash. No conjunto de tarefas de DeepSWE, SWE Atlas QnA e Terminal-Bench, a empresa relata um ponto com custo 72% menor e taxa de aprovação a até 0,8 ponto percentual da obtida usando sempre o Opus. O relatório também compara o roteador com o roteamento aleatório a um custo semelhante. Isso importa porque enviar mais trabalho ao modelo barato reduziria o custo médio mesmo se a escolha fosse feita ao acaso.

O limiar expressa quanto vale a pena pagar pela probabilidade de sucesso. Dar mais prioridade ao custo pode enviar mais tarefas à rota econômica. Outra configuração pode favorecer o modelo mais capaz quando o resultado tem maior importância. Os números da Baseten descrevem os modelos, as tarefas e os preços considerados no estudo. Sua equipe terá outra distribuição de trabalho e outro custo para as falhas.

O anúncio do produto usa uma afirmação arredondada à parte, de até 70% de redução de custo nos primeiros benchmarks. Separe essa afirmação dos 72% do experimento e da comparação de taxas de aprovação associada. O ponto útil do relatório técnico é mostrar como o custo e a taxa de aprovação variam juntos. A equipe pode escolher um ponto de acordo com suas prioridades e testar se ele se sustenta no trabalho real.

Um gateway pode tornar a política visível

O anúncio da Grid descreve modelos aprovados, controles por equipe e visibilidade do uso. A equipe de plataforma pode oferecer aos desenvolvedores modelos que a organização já avaliou e ver como o consumo se distribui. Isso ajuda a entender onde se gasta dinheiro mesmo antes de delegar a seleção da rota.

Na prática há várias decisões. Qual fornecedor pode receber código proprietário? Qual modelo está aprovado para um repositório específico? Qual equipe responde pelo orçamento de novas tentativas? Quem pode substituir uma rota após um incidente? Um gateway pode concentrar essas decisões em um ponto compartilhado, desde que os administradores saibam o que cada controle governa.

O gateway de modelos e o ambiente de execução do agente são pontos de controle distintos. O gateway pode decidir qual modelo recebe uma solicitação. A ferramenta ou o ambiente de execução decide se um agente pode ler credenciais, gravar um arquivo ou fazer uma chamada de rede. Restrições de rota funcionam junto com as permissões de execução. Uma rota econômica ainda precisa das mesmas restrições em torno de ferramentas privilegiadas.

Também há a questão dos registros. Os logs de roteamento ajudam a explicar mudanças de custo, mas podem conter código, caminhos de arquivos e detalhes de um incidente de cliente. Decida o que a plataforma pode registrar, quem pode ver e por quanto tempo os dados podem ser guardados. Se a pessoa que desenvolve não consegue examinar a política, fica difícil investigar por que uma solicitação foi negada ou encaminhada para uma rota inesperada.

Teste o roteamento antes de mudar o padrão

1. Escolha dois ou três tipos de tarefa comuns. Inclua um grupo simples, como atualizações rotineiras de testes, e um mais difícil, como migrações que precisam preservar compatibilidade.
2. Defina antes do teste as evidências necessárias para aceitar um resultado. Em uma tarefa de programação, elas podem incluir um teste de regressão aprovado, um diff limpo, o aval de quem revisa e a verificação de arquivos alterados sem necessidade.
3. Registre a referência com o modelo padrão atual. Inclua tentativas que falharam, novas execuções e trabalho concluído manualmente. Preserve as restrições de segurança e de dados usadas em produção.
4. Compare o roteamento em tarefas equivalentes. Se tiver acesso, confira na documentação oficial as ferramentas e permissões compatíveis com o gateway antes de conectar uma conta.
5. Decida quando escalar para outro modelo. Uma primeira falha pode acionar um segundo modelo, mas um ciclo de novas tentativas sem limite pode custar mais que usar um modelo mais forte desde o início. Defina um limite e registre por que a tarefa foi escalada.
6. Mantenha uma opção para substituir a rota em tarefas nas quais um erro tenha grandes consequências. Depois do teste, avalie as exceções junto com os custos e índices de aceitação agregados.

Em um piloto interno, compare um período em que as pessoas escolhem os modelos com um período de roteamento, usando trabalho parecido. O primeiro grupo pode se beneficiar de quem conhece o repositório. O segundo pode ganhar com uma política uniforme e melhor visibilidade. Documente as diferenças entre as tarefas para que a comparação mostre onde a automação ajuda e onde o julgamento humano continua valioso.

Examine um histórico de tarefas comparáveis

Um bom começo é um mês de pull requests concluídos. Classifique o trabalho pela solicitação inicial, como atualização de dependência, erro com teste reproduzível, mudança que atravessa repositórios ou pedido aberto para investigar uma implantação malsucedida. Salve a revisão do repositório e um critério de aceitação por tarefa. Reexecute uma amostra com uma referência estável e com o roteador. Use as mesmas ferramentas, o mesmo orçamento de tempo e o mesmo ambiente de testes.

Uma atualização de dependência é um caso com pouca ambiguidade. O trabalho é bem-sucedido quando a dependência indicada muda, os testes de compatibilidade passam e o pull request não inclui alterações alheias à tarefa. Uma mudança nas regras de cobrança precisa de revisão mais rigorosa. Também pode exigir que alguém interprete requisitos incompletos. Manter esses grupos separados ajuda a descobrir de onde vem a economia média. Se a rota barata ganha nas atualizações, mas precisa tentar várias vezes em mudanças de cobrança, a equipe pode rotear cada grupo de um jeito.

Registre quanto tempo uma pessoa leva para decidir se aceita o resultado. Imagine que a referência produza 19 resultados aceitos em 20 por $19 e que o roteador entregue 18 por $9. Nesse exemplo, o modelo custa $1,00 e $0,50 por resultado aceito, respectivamente. Se a revisão gastar mais 20 minutos corrigindo uma tarefa malsucedida do roteador, a comparação muda. A organização pode incluir esse retrabalho sem tratar dólares e minutos como a mesma medida.

Saiba com quais tarefas o roteador aprendeu

O texto técnico da Baseten cita DeepSWE 1.1, SWE Atlas QnA e Terminal-Bench 2.1. O estudo compara Claude Opus 5.5 e GLM 5.3 Flash e avalia o roteador com dados separados para o teste. Esses detalhes importam para decidir até onde generalizar o resultado. Perguntas para navegar no repositório têm um perfil de custo diferente de tarefas que executam comandos, usam ferramentas externas ou alteram vários arquivos. A avaliação do cliente deve representar o trabalho que realmente pretende enviar.

O texto descreve Cost, Balanced e Intelligence como ajustes que mudam o limiar na hora da solicitação. Uma equipe pode aproveitar essa diferença para rodar uma comparação em paralelo. Compare os ajustes no mesmo conjunto de reexecuções autorizadas e anote o modelo escolhido se sua integração exibir essa informação. Investigue as divergências. Se as escolhas caras ocorrerem principalmente em casos que a equipe considera sensíveis ou difíceis, a política pode estar funcionando. Se a maioria dos desacordos estiver em uma tarefa simples e comum, talvez valha ajustar a classificação ou a política.

Acompanhe as tarefas mais lentas e mais caras

A latência média pode esconder a espera por uma correção difícil que passou por vários modelos. Registre o tempo corrido da solicitação ao resultado aceito e identifique cada nova tentativa, escalonamento, tempo limite ou repasse. Um painel que mostra só a resposta do primeiro modelo pode apontar ganho mesmo quando alguém precisou recomeçar. Inclua o tempo e o gasto após os repasses.

Defina limites antes de ampliar o teste. Use um orçamento para a tarefa inteira e uma regra para parar ou subir para um modelo mais capaz. Uma tentativa fracassada deve deixar informação suficiente para a próxima continuar. Evite rodar de novo os testes ou reler os mesmos arquivos só porque o roteador escolheu outro modelo. O que importa medir é quanto o trabalho avançou.

Comece a adoção por uma família limitada, na qual a regra de aceitação é automatizada e uma pessoa pode conferir as exceções. Depois, inclua um grupo que exige julgamento. Compare separadamente custo por tarefa aceita, proporção de escalonamentos e tempo de revisão. Se o ganho resistir à mudança, a organização tem uma base melhor para escolher o padrão.

Mantenha a referência útil quando um modelo mudar

Um resultado colhido em uma semana pode envelhecer quando muda um modelo, uma ferramenta ou o repositório. Salve o identificador do modelo, a revisão de teste e as regras de aceitação junto com a decisão de roteamento. Reexecute um conjunto pequeno de tarefas representativas ao mudar a política. Inclua algumas falhas caras, pois o custo delas costuma desaparecer na média.

Peça a quem revisa que examine uma divergência de rota sem saber qual modelo foi escolhido. Se a pessoa não conseguir dizer qual saída é aceitável, refine o critério antes de reunir novas execuções. É mais fácil comparar políticas quando a equipe concorda sobre como reconhecer o sucesso.

A política deve evoluir junto com o trabalho

O roteamento é útil quando libera a equipe de repetir a mesma escolha pequena. Isso vale especialmente quando desempenho e preço podem ser medidos sobre a mesma unidade de trabalho. Modelos, preços e repositório vão mudar. Preserve as tarefas de referência e atualize o conjunto de testes para que a política acompanhe as mudanças.

O número que vale levar para uma reunião de planejamento é quanto a equipe pagou para entregar trabalho aceito, com um relato claro das contrapartidas. É um dado sobre o qual a liderança de engenharia e a pessoa responsável pelo orçamento podem agir juntas.

Fontes

• Anúncio da prévia da Grid pela Baseten em 4 de novembro
• Relatório técnico da Baseten sobre o Router, de 4 de novembro

---

Para guardar e encontrar as conversas e decisões que fazem parte do seu trabalho, crie uma conta na Telli.sh.