Orquestração multi-modelo: metade do custo, 2 pontos abaixo

Orquestração multi-modelo troca qualidade por custo?

A Artificial Analysis mediu custo de US$ 5,59 por tarefa para a composição do GitHub, contra US$ 11,42 para Claude Code com Opus 5.5 na configuração máxima. A orquestração multi-modelo ficou dois pontos abaixo no índice. A economia é real na medição. A pontuação menor também.

A conclusão não é que misturar modelos vence sempre. É que escolher um modelo pela posição no ranking compra uma média; a conta chega por tarefa. O responsável por engenharia precisa saber se a diferença cai no trabalho que sua equipe não pode errar.

A tese é esta: a orquestração multi-modelo, ou composição de modelos, só merece a troca quando a economia por tarefa sobrevive ao teste de aceitação da carga real. Sem esse teste, preço menor é proposta, não decisão.

O que o índice mede, afinal?

O Coding Agent Index v2.0 reúne Terminal-Bench 4.0, FrontierCode e SWE-Atlas-QnA-AA, com peso igual para cada benchmark. O resultado agregado permite comparar configurações na distribuição escolhida pela medição. Ele não informa quanto uma organização economizará nem qual erro encontrará na própria aplicação.

Na configuração máxima, o Copilot Fusion no GitHub Copilot CLI lidera o Terminal-Bench 4.0 com 71. No FrontierCode, fica em terceiro com 51, atrás de 56 e 54. Em SWE-Atlas-QnA-AA, registra 57, segundo a Artificial Analysis. O mesmo resultado agregado abriga posições diferentes conforme a prova.

Esse detalhe muda a compra. O benchmark precisa representar o trabalho, e uma liderança não apaga a desvantagem nas outras provas.

Dois pontos no índice não são dois por cento a menos de qualidade. A relação entre pontuação e dano depende da tarefa, do critério de aceitação e da consequência do erro, nada disso recuperável de uma única média agregada. Quem transforma a diferença em taxa de falha sem medir vende precisão que o índice não oferece.

O que muda na composição de modelos?

Na composição de modelos, a decisão deixa de estar concentrada na escolha antecipada de um único modelo para todo o trabalho. O sistema seleciona modelos durante a execução. Isso muda a forma de avaliar gasto e resultado, mas o mecanismo específico precisa ser conhecido antes de atribuir mérito a qualquer etapa.

O caso medido é o Copilot Fusion. O GitHub descreve a seleção e a coordenação de modelos da Anthropic e da OpenAI em tempo de execução para equilibrar desempenho, custo e latência por tarefa, conforme relata a Artificial Analysis. A cobrança de tokens acompanha os modelos usados para concluir a requisição, não uma tarifa única da composição.

Uma arquitetura que escolhe modelos por etapa avalia cada passagem por seu objetivo: examinar a entrada, produzir uma alteração ou verificar o resultado. Essa é uma possibilidade de desenho, não uma descrição das decisões internas do produto medido. A fonte não publica a decomposição por etapa, o que limita qualquer afirmação sobre roteamento de modelos de IA, e não autoriza dizer qual modelo executou qual parte.

Há uma diferença entre trocar de modelo e terminar bem. A chamada mais barata pode exigir correção, outra chamada ou revisão humana, e isso entra na conta. Um erro de roteamento transfere o gasto para depois do primeiro resultado.

Um trace pode ligar a chamada ao contexto de execução, mas não comprova que o resultado foi aceito nem substitui a cobrança do provedor.

Como comparar os números publicados?

A comparação reúne custo, consumo e resultados dos benchmarks na mesma medição da Artificial Analysis. Os valores dizem respeito às configurações testadas, não a uma tarifa universal nem ao custo de implantação em outra empresa. Onde a fonte fornece apenas uma relação entre consumos, a tabela preserva essa relação.

Fonte da tabela: Artificial Analysis, medição publicada em 28 de outubro de 2026. A posição relativa no índice não revela os valores absolutos das configurações.

A terceira configuração da mesma medição, o Devin Fusion com Opus 5.5 na configuração máxima e GPT-6 Luna em high, entrega 62 pontos a US$ 8,00 por tarefa, 43% acima dos US$ 5,59 do Fusion do GitHub. Duas arquiteturas de composição, portanto, ficam em faixas de custo distintas, e o rótulo arquitetural não determina o custo por tarefa.

A medição compara produtos de agente, não políticas de gateway. Um gateway escolhe um modelo por requisição. Uma orquestração dentro do produto emite várias chamadas por tarefa, com estado. O harness do agente dá ferramentas, contexto e cache. A economia de um produto de agente não dimensiona uma decisão de gateway sem medição própria.

O consumo de 7,2 milhões de tokens por tarefa é aproximadamente metade do consumo do Opus 5.5 no Claude Code, segundo a Artificial Analysis. Menos tokens ajudam a explicar a diferença, mas a causa não é única: harness, desenho de ferramentas, reúso de cache e tarifas dos modelos competem pela explicação.

Quais medidas separam economia real de aparente?

A comparação útil começa com a mesma carga, a mesma definição de aceitação e uma conta que inclua o trabalho necessário para chegar ao resultado. A média publicada orienta a investigação. Não substitui a medição de qualidade, custo por etapa, tokens e recuperação quando o roteamento erra.

1. Qualidade por tipo de tarefa. O responsável separa as tarefas por características relevantes e define quem aceita o resultado, com critérios verificáveis. Depois compara os grupos, não o agregado. A média esconde falhas nas tarefas mais sensíveis.
2. Elegibilidade de dados. Antes do preço, a equipe marca as tarefas que não podem ir a um dos fornecedores por classificação da informação, residência de dados ou cláusula contratual. A rota que não atende fica fora, por mais barata que seja.
3. Custo por etapa e por tarefa. A equipe associa chamadas e tentativas à tarefa de origem, identifica modelos usados e aplica as condições de cobrança vigentes. Quando a cobrança não permite atribuição detalhada, o valor fica desconhecido nesse nível, e desconhecido não é custo zero. O custo por tarefa no roteamento de modelos detalha essa conta por rota.
4. Tokens por tarefa. Entrada e saída, quando disponíveis, devem ser acompanhadas junto ao modelo e à regra de preço. A contagem indica onde há consumo; não é a fatura. Tarefas simples e longas exigem comparação separada.
5. Custo do erro de roteamento. A equipe registra rejeição, correção, retentativa e intervenção humana, inclusive o custo das tarefas não aceitas. Se a medição excluir esses casos, uma rota que falha e abandona trabalho pode parecer mais barata do que uma que conclui.

A fórmula de custo por tarefa aceita exige declarar a coorte e o tamanho mínimo: somar os custos das tarefas incluídas, com rejeitadas e abandonadas conforme a política definida, e dividir pelo número de aceitas na mesma coorte. A conta precisa de dispersão e intervalo, porque coorte pequena transforma ruído em diferença. Sem aceitas, não há média; sem atribuição confiável, a conta é parcial.

Latência entra na mesma conta. Se a rota respeita o critério de qualidade e termina fora do prazo do processo, o desconto não recompõe o serviço. O comprador olha a distribuição dos tempos, não a média.

Quando o modelo único continua sendo a escolha certa?

O modelo único continua sendo a escolha certa quando a composição não alcança o critério de aceitação, não cumpre a latência exigida ou não oferece evidência suficiente para atribuir seus custos. A vantagem de uma rota mais simples não é estética: ela reduz a necessidade de justificar escolhas intermediárias sem observabilidade.

A objeção à orquestração multi-modelo merece ser levada a sério. Um sistema que escolhe entre modelos introduz decisões adicionais e exige investigação quando o resultado falha. Se o ganho medido é pequeno diante do custo de avaliação, integração e operação, manter a configuração existente pode ser a decisão econômica correta. A rota consome chamada própria, e trocar de modelo invalida cache de prompt.

Concentração de fornecedor é o custo que não aparece na tarifa. Uma orquestração acopla dois ou mais contratos, com termos de dados, limites e reajuste próprios, e a política de seleção é opaca por construção: não se reproduz nem se contesta em auditoria. Antes de adotar, exija termos por fornecedor, política versionada e custo de saída estimado.

Isso não transforma modelo único em vencedor automático. A medição da Artificial Analysis mostra que a orquestração multi-modelo reduziu o custo por tarefa, com diferença delimitada no índice, dentro daquela distribuição. Para outra carga, a resposta precisa vir do teste próprio.

A decisão deve ser reversível. Fixar a política sem monitorar os tipos de tarefa que ela atende transforma uma avaliação pontual em regra permanente, e mudança na mistura de trabalho exige refazer a conta.

FAQ sobre orquestração multi-modelo

<!-- FAQPage -->

A dúvida útil não é qual rótulo vence. É o que a medição permite concluir e o que a empresa ainda precisa medir. Um índice ajuda a escolher o teste. Ele não define, sozinho, a qualidade aceitável para uma aplicação específica.

Orquestração multi-modelo é sempre mais barata?

Não. A Artificial Analysis encontrou US$ 5,59 por tarefa para a composição do GitHub contra US$ 11,42 para Claude Code com Opus 5.5 na configuração máxima, no índice testado. Em outra carga, o consumo, os erros e a revisão são outros, e a comparação precisa ser refeita nela.

A diferença no índice equivale a uma taxa de erro?

Não. Os dois pontos de diferença relatados pela Artificial Analysis são pontos do índice agregado, não uma porcentagem de qualidade nem uma taxa de erro por tarefa. O risco operacional depende da distribuição dos tipos de trabalho e dos critérios de aceitação da própria equipe.

Menos tokens garantem custo menor?

Não. Tokens são uma parte da conta, e o preço depende dos modelos usados e das condições de cobrança. A Artificial Analysis informa 7,2 milhões de tokens por tarefa para a composição do GitHub, mas não detalha o custo de cada etapa nem prova a causa isolada da diferença.

Como comparar custo por tarefa entre rotas?

A equipe deve executar a mesma carga com o mesmo critério de aceitação, atribuir os custos relevantes à coorte e declarar o tratamento de rejeições e abandonos. Também precisa comparar latência, definir o tamanho mínimo da coorte e registrar custos desconhecidos. Média não prova nada quando a cobrança muda.

Referências e Leitura Complementar

A fonte primária reúne a comparação de custo por tarefa, o consumo de tokens e os resultados dos benchmarks para as configurações avaliadas. Os limites da medição acompanham qualquer aplicação desses dados fora do conjunto testado. A referência é esta:

• Artificial Analysis: orquestração de modelos, desempenho e custo por tarefa.
• Roteamento de modelos de IA em produção: o que muda quando a rota passa a ser escolhida por tarefa.

Qual decisão tomar antes de mudar a rota?

A equipe de TI deve selecionar uma carga representativa, declarar o resultado aceitável e comparar a composição com o modelo único na mesma coorte, com tamanho mínimo, dispersão e intervalo. Só depois decide se a economia paga a qualidade menor e o retrabalho. Um piloto inconclusivo é válido.

O Nexforce Router situa a discussão na infraestrutura de roteamento, não no placar de um benchmark. Para avaliá-lo ou avaliar qualquer alternativa, o comprador deve pedir evidência sobre os dados necessários para a própria conta e confirmar o que a implementação registra. A medição não comprova capacidades específicas do Router.

Se a composição não atender ao critério de aceitação para tarefas críticas, a equipe mantém o modelo único, desde que ele o cumpra. Se a carga não for elegível para um dos fornecedores, a decisão está tomada antes do custo. Se passar no critério e reduzir o custo da coorte, a rota escolhida paga a própria conta.