TokenLab Fusion: Evidências do DRACO Weighted-100 Research Dataset

Nota sobre o status da pesquisa: TokenLab Fusion: este é um resultado de pesquisa de "prova de receita" e uma linha de base histórica forte, não uma alegação de produção. Os resultados foram produzidos usando uma âncora premium Gemini; uma execução de teste (canary) sem recursos premium e uma reexecução final apenas com Fusion estão pendentes para confirmar a reprodutibilidade sem dependências premium. O DRACO weighted-100 é uma avaliação interna proprietária da TokenLab e não é um benchmark externo ou padronizado. Interprete de acordo.

Resumo

Este relatório documenta o estado probatório atual do TokenLab Fusion, um sistema de orquestração de inferência multi-modelo avaliado em relação a um conjunto de pesquisa multidomínio fixo e ponderado em 100 (o manifesto de pesquisa DRACO weighted-100, cobrindo Finanças, Compras/Comparação de Produtos, Acadêmico, Tecnologia, Conhecimento Geral, UX Design, Direito, Medicina, Needle-in-a-Haystack e tarefas de Assistente Personalizado). A questão central da pesquisa não é se um conjunto de modelos pode obter uma pontuação agregada maior do que um único modelo em uma fatia de benchmark, mas se uma receita disciplinada (composição de painel, síntese, validação consciente de rubricas, fornecimento de evidências e contabilidade de custos) pode ser organizada em um sistema reprodutível, auditável e atualizável que supere as linhas de base de modelo único fortes em todos os domínios, e não apenas em um subconjunto favorável.

A evidência mais forte até o momento vem da execução de pesquisa weighted-100, uma avaliação pareada e habilitada por linha de base contra gpt-5.5 e claude-opus-4-8 no conjunto de dados fixo de 100 tarefas DRACO. O TokenLab Fusion obteve uma média de 86.04, com um delta médio pareado de +32.60 sobre o gpt-5.5 (vitória/derrota/empate 95/4/1, custo 0.71x, pontuação por dólar 2.26x) e +45.63 sobre o claude-opus-4-8 (vitória/derrota/empate 97/2/1, custo 0.69x, pontuação por dólar 3.06x). Esses números são fortes, pareados e reprodutíveis em relação a um manifesto fixo, mas trazem duas qualificações importantes que este relatório trata como descobertas de primeira classe, não como notas de rodapé: a receita vencedora usou um modelo Gemini Pro premium histórico (gemini-3.1-pro-preview) como sua âncora de síntese/julgamento/validação, e o estado de prontidão para lançamento do sistema ainda requer uma reexecução final apenas com Fusion antes que o resultado possa ser considerado completo. O restante deste relatório separa o que foi comprovado na execução de pesquisa de linha de base forte do que permanece bloqueado antes de qualquer alegação de produção, e apresenta as evidências específicas ainda necessárias, mais urgentemente um teste canary sem Gemini premium, para fechar essa lacuna.

1. Escopo e Objetivo da Pesquisa

O TokenLab Fusion é definido aqui como orquestração em tempo de inferência entre vários modelos upstream, não um modelo de pesos mesclados treinado. Uma única solicitação é roteada através de várias funções de modelo (painelista, sintetizador, validador, juiz, revisor, proprietário de ferramenta), e a receita controla como as saídas são geradas, comparadas, reescritas e retornadas. Isso é mais próximo de uma configuração de produção multi-modelo verificável do que de uma votação de conjunto sem estado; compartilha ancestralidade estrutural com Mixture-of-Agents e LLM-Blender, embora o aparato de seleção de receita e contabilidade de custos descrito abaixo vá além de ambos.

O alvo da avaliação é a suíte de pesquisa weighted-100: um conjunto fixo de tarefas de pesquisa multidomínio, densas em evidências e pontuadas estritamente por rubricas. O programa de pesquisa rejeita explicitamente comparações de linha de base fracas. As únicas linhas de base aceitas são gpt-5.5 e claude-opus-4-8, e ambas são mantidas estritamente fora das funções de painel, síntese, juiz, validador e proprietário de ferramenta do Fusion; contaminar o painel com o modelo de linha de base invalidaria qualquer alegação de que "uma receita multi-modelo mais barata supera um modelo único forte".

Os identificadores de modelo referenciados neste documento--gpt-5.5, claude-opus-4-8, gemini-3.1-pro-preview, deepseek-v4-pro e glm-5.2--são IDs de modelo lógicos da plataforma TokenLab Fusion e IDs de linha de base de pesquisa capturados do snapshot de fonte única de verdade (SSOT) do modelo TokenLab observado em 2026-07-07. Esses identificadores denotam rótulos internos de roteamento e avaliação, em vez de um ranking independente e auditado publicamente, e não se alega que esses nomes correspondam um a um com a nomenclatura de lançamento público de qualquer fornecedor externo. Identificadores como gpt-5.5 e claude-opus-4-8 são rótulos internos de linha de base e roteamento extraídos do SSOT da TokenLab e não devem ser interpretados como designações de versão de modelo de fornecedor público. Consequentemente, as comparações de linha de base forte neste documento não devem ser lidas como uma alegação completa de prontidão de produção: a avaliação canary sem Gemini premium e a reexecução restante apenas com Fusion ainda não foram concluídas e permanecem bloqueadas aguardando validação adicional. Os resultados apresentados aqui representam uma comparação de pesquisa em um snapshot no tempo, não um resultado de benchmark de produção finalizado ou totalmente validado.

Duas linhas de produtos compartilham essa infraestrutura de pesquisa, mas divergem na receita: uma linha de Deep Research (baseada em evidências, com verificação de suficiência de fonte, pesada em validação) e uma linha de Coding Agent (pesada em execução de ferramentas, sensível à latência, ainda pré-Fase-0). Este relatório trata principalmente da linha de Deep Research, uma vez que é onde existem evidências pareadas contra linhas de base fortes atualmente.

2. Por que um Manifesto Fixo de 100 Tarefas

Uma execução de benchmark de fatia única não pode sustentar decisões de receita. O manifesto de 100 tarefas existe para servir a seis funções de engenharia distintas simultaneamente: seleção de receita entre domínios (evitando overfitting em uma fatia de sorte), dados de treinamento de política de roteador, evidência de atribuição de função de modelo, construção de curva de custo/qualidade/latência, uma biblioteca de falhas para testes de regressão e futuros canaries de atualização de modelo, e um conjunto de regressão em camadas reutilizável que não precisa de uma reexecução completa toda vez que um modelo upstream muda.

O manifesto usado nos experimentos relatados é o weighted-100-v1, uma fatia ponderada determinística com um hash de conjunto de tarefas fixo (b08a09aacbc76c5e5aafd5ca0a6fa614a5061bc478f905007ae5aee4a93fc43a). Sua ponderação de domínio não é uniforme: Finanças (20), Compras/Comparação de Produtos (16), Acadêmico (12), Tecnologia (10), Conhecimento Geral (9), UX Design (9), Direito (6), Medicina (6), Needle-in-a-Haystack (6), Assistente Personalizado (6). Essa distribuição é importante porque os ganhos do Fusion dependem do domínio, e Finanças, em particular, carrega o risco aberto mais persistente (Seção 6).

O DRACO weighted-100 é um conjunto de dados de pesquisa interno da TokenLab usado exclusivamente dentro do pipeline de avaliação do TokenLab Fusion deste documento. Não é um benchmark externo mantido publicamente e não é afiliado, endossado ou extraído de qualquer suíte de benchmark de terceiros. O manifesto weighted-100, incluindo sua amostragem de itens, esquema de ponderação de categoria e metadados de proveniência, é regido por um mapa de fonte privado da TokenLab que não é publicado junto com este documento. As pontuações relatadas devem, portanto, ser interpretadas como sinais comparativos internos específicos da metodologia de avaliação da TokenLab, em vez de pontuações comparáveis a rankings públicos ou benchmarks da comunidade. Os leitores não devem presumir que os resultados do DRACO weighted-100 se generalizam ou podem ser referenciados cruzadamente contra qualquer outro conjunto de dados que tenha um nome ou estrutura semelhante.

3. Metodologia

O ciclo de pesquisa é baseado em evidências: toda alegação forte deve ser rastreável a um manifesto fixo, IDs de tarefa, pesos de domínio, configurações de tempo de execução, arquivos de resultados brutos, linhas de custo e linhas de base. Números de resumo agregados sem esses artefatos não são tratados como evidência.

Quatro compromissos metodológicos são os mais importantes.

Evidência compartilhada sobre pesquisa nativa opaca

Ferramentas de pesquisa, busca e leitura produzem um pacote de evidências externo aos modelos em teste, e esse mesmo pacote é fornecido tanto ao painel quanto aos modelos de linha de base sempre que possível. Isso isola "o modelo consegue raciocinar e sintetizar bem" de "o modelo por acaso pesquisou bem", e é um requisito estrito para execuções de prova da suíte de pesquisa weighted-100, comparações de linha de base forte, canaries de atualização de modelo e reexecuções finais.

Contabilidade de custos separada por função

Em uma execução habilitada por linha de base, a coluna de custo agregado mistura chamadas Fusion e chamadas de linha de base; usá-la diretamente superestimaria ou subestimaria a alegação de custo apenas do Fusion. A análise da execução de pesquisa weighted-100 exclui explicitamente as linhas de linha de base e de pontuação de linha de base para chegar a um total oficial apenas de Fusion de $12.837461 em 799 linhas de custo. Essa distinção, linhas de custo separadas por função em vez de totais misturados, é a base para cada alegação de qualidade ajustada ao custo neste relatório.

Comparação pareada sobre médias não pareadas

As saídas do Fusion e da linha de base são comparadas em IDs de tarefa idênticos, e os resultados são relatados como delta médio, intervalo de confiança bootstrap, valor-p de teste de sinal, contagem de vitória/derrota/empate, multiplicador de custo, multiplicador de latência e delta de taxa de falha. Médias não pareadas com cobertura de tarefa diferente não são aceitas como prova.

Execução retomável e fragmentada

A execução da pesquisa weighted-100 foi realizada como dez fragmentos de dez tarefas cada, depois agregados em um único artefato de prova. A reexecução final apenas com Fusion (Seção 6) usa o mesmo padrão escalonado e retomável.

Dimensão dos métodos	Abordagem usada	Justificativa
Seleção de tarefa	Manifesto fixo ponderado de 100 tarefas, com hash	Previne fatias escolhidas a dedo, permite reexecuções
Fornecimento de evidências	Pacote de evidências compartilhado e reprodutível	Isola a qualidade do raciocínio da sorte na pesquisa
Isolamento de linha de base	gpt-5.5, claude-opus-4-8 excluídos do painel/synth/juiz/validador	Previne contaminação da linha de base na alegação Fusion
Contabilidade de custos	Linhas separadas por função; totais apenas de Fusion excluem chamadas de linha de base	Evita distorção de custo/dólar de custo misturado
Design de comparação	Pareado, mesmos IDs de tarefa, IC bootstrap, teste de sinal	Controla a variância de domínio e amostra
Execução	Executores fragmentados e retomáveis	Permite rastreamento de progresso parcial e reexecuções escalonadas
Pontuação	Pontuação de validador/juiz baseada em rubrica contra rubricas de domínio	Permite ablação de validador e decomposição de pontuação

O TokenLab Fusion avalia as saídas do modelo por meio de um pipeline de pontuação automatizado que agrega vários sinais de métrica em uma pontuação composta. As regras de pontuação são aplicadas programaticamente sem revisão manual nesta fase. Dados públicos de auditoria humana ou concordância entre avaliadores para este método ainda não foram publicados; os resultados relatados refletem apenas a avaliação automatizada, aguardando verificação independente.

Disponibilidade de dados

O hash do manifesto, linhas de custo, arquivos de resultados brutos, snapshot de fonte única de verdade do modelo e mapa de fonte subjacente a este estudo são retidos no arquivo de pesquisa interno da TokenLab. Esses materiais têm acesso restrito e não são publicados junto com este documento. Consequentemente, a reprodutibilidade pública é limitada até que uma amostra editada ou subconjunto público dos dados subjacentes seja liberado.

4. Evolução da Receita: Mais Modelos Não É a Alavanca

Uma descoberta inicial e importante é negativa: adicionar mais modelos ao painel não melhora a qualidade de forma confiável e não se pode presumir que o faça. A receita evoluiu através de uma sequência de ablações controladas, em vez de aumentar o tamanho do painel.

Núcleo rápido como grupo de controle

Um painel de três modelos de baixo custo, diverso e estável (gemini-3.1-flash-lite, deepseek-v4-flash, grok-4-1-fast-non-reasoning) serve como a condição de controle de custo/latência contra a qual cada adição e cada variante de validador é medida.

Mix de modelos de baixo custo concretos

O TokenLab Fusion é uma camada de orquestração em tempo de inferência, não um modelo de pesos mesclados: ele coordena chamadas para diversos modelos existentes e combina suas saídas em tempo de execução. Para tornar isso concreto, os modelos de referência gpt-5.5 e claude-opus-4-8 são excluídos de todas as funções do Fusion — painel, síntese, juiz, validador, revisor e proprietário de ferramentas — para que os ganhos relatados não possam ser atribuídos a esses modelos de referência realizando trabalho oculto dentro do pipeline.

A configuração padrão é um painel de controle rápido e de baixo custo com três modelos executados em paralelo, com um quarto painelista opcional avaliado em modo de qualidade, uma âncora histórica de prova de teto e um candidato canary sem prêmio ainda aguardando evidências pareadas.

Função	Modelo(s)	Status
Painel de controle rápido de baixo custo	gemini-3.1-flash-lite, deepseek-v4-flash, grok-4-1-fast-non-reasoning	Painel padrão de baixo custo em teste
Candidato de adição de qualidade	kimi-k2.7-code	Avaliado como quarto painelista; não promovido — aumenta a latência, regride em alguns domínios com o validador
Âncora de prova histórica	gemini-3.1-pro-preview	Usado para síntese/juiz/validador/revisão na receita de referência forte; prova um teto, não o caminho de custo de produto pretendido
Candidato canary sem prêmio	deepseek-v4-pro (síntese/validação/revisão), glm-5.2 (juiz independente)	Caminho de custo pretendido; aguardando evidências canary pareadas

A orquestração ocorre como uma sequência fixa, em vez de um livre acesso a chamadas de modelos:

1. Construir um pacote de evidências compartilhado uma única vez, para que cada painelista raciocine sobre um contexto idêntico.
2. Executar os painelistas de baixo custo em paralelo contra esse pacote de evidências.
3. Normalizar as saídas do painel em um formato comum para comparação.
4. Executar a análise do painel para identificar concordância, conflito e evidências ausentes.
5. Sintetizar uma resposta única, executar um validador ciente de rubricas e revisar uma vez caso o validador aponte problemas.
6. Pontuar/julgar a resposta final, com um único proprietário de ferramenta designado — os painelistas nunca executam ferramentas diretamente.

O resultado do kimi-k2.7-code e o canary pendente deepseek-v4-pro/glm-5.2 são relatados separadamente dos números do painel padrão para evitar confundir uma configuração avaliada, mas avaliada mas não adotada, com a receita de custo de produto pretendida.

Adição do Kimi: um sinal real, mas marginal

Um piloto de 20 tarefas adicionando um modelo de codificação/diversidade ao núcleo rápido produziu uma pontuação média de 34.36 versus 31.37 do núcleo rápido (delta pareado +2.99, IC 95% -0.04 a 6.10, vitória/derrota/empate 11/6/3, custo ~1.01x, latência ~1.57x). O IC que abrange zero e um valor-p de teste de sinal de 0.3323 significam que isso não é forte o suficiente para justificar tornar a adição um padrão sensível à latência; também regrediu em algumas tarefas de Acadêmico, Medicina e Tecnologia. A conclusão tirada é específica da função: essa classe de modelo é melhor tratada como um especialista em codificação/front-end/contexto longo do que como um painelista de uso geral sempre ativo.

Adições de GLM e DeepSeek Pro precisam de funções, não de inclusão abrangente

Uma adição de GLM produziu apenas cerca de +1.22 a 1.49x de custo e 1.85x de latência em uma fatia pequena, evidência útil para uma função de juiz/synth/revisor de codificação, não evidência suficiente para promoção de painel padrão. A avaliação do DeepSeek V4 Pro mudou materialmente após uma correção de preço (entrada $0.435, saída $0.87 por 1M de tokens), o que invalidou um julgamento anterior de "muito caro" e o elevou a um candidato líder para uma função de synth/validador em uma receita de custo mais baixo (Seção 6). A correção de preço do DeepSeek V4 Pro deriva do SSOT de modelo interno observado em 2026-07-07 e constitui uma suposição de custo de pesquisa, em vez de uma citação de um preço publicado pelo fornecedor externo.

Validador/reescrita é a maior alavanca única encontrada

Em uma expansão de 20 tarefas, adicionar um estágio de validador/reescrita consciente de rubrica ao núcleo rápido produziu uma pontuação média de 81.70 versus 29.88 apenas para o núcleo rápido, um delta pareado de +51.81 (IC 95% 42.64 a 61.23), vitória/derrota/empate 20/0/0, a 2.14x de custo e 1.89x de latência. Isso não é uma melhoria incremental; é uma mudança estrutural no que a receita é capaz de fazer. Também não é gratuito: o multiplicador de custo excedeu o limite de manutenção automática de 2.0x em uma passagem de análise, o que significa que o mesmo resultado que vale inequivocamente a pena para uma camada de pesquisa profunda é uma restrição real para uma camada de produto rápida/barata. Alternativas mais baratas foram testadas e rejeitadas como padrões: uma variante de revisão leve/pilha leve perdeu cerca de 28 pontos em relação à validação completa e perdeu todas as comparações pareadas; a validação seletiva baseada em heurísticas de domínio fraco economizou apenas cerca de 11% do custo enquanto perdia -8.53 na pontuação média, e uma variante seletiva apenas de alto risco perdeu mais. A validação seletiva, portanto, permanece um problema de pesquisa de roteamento aberto, não uma técnica de redução de custos resolvida.

5. Resultados de Linha de Base Forte: O Que Foi Comprovado

A execução de pesquisa de linha de base forte weighted-100 é o artefato de evidência mais forte no programa. Ele mantém gpt-5.5 e claude-opus-4-8 como comparadores apenas de linha de base, excluídos de todas as funções Fusion.

Resumo apenas do Fusion nas 100 tarefas:

Métrica	Valor
Pontuação média	86.04
Custo total oficial	$12.837461
Custo médio oficial	$0.128375
Custo total da plataforma	$6.568959
Pontuação por dólar oficial	670.21
Chamadas falhas	0
Taxa de falha	0.0%
Latência média de chamada	216.4s
Linhas de custo	799
Tarefas de fallback agregadas	0

O valor relatado de 670.21 denota a pontuação média bruta apenas do Fusion dividida pelo custo médio oficial apenas do Fusion, enquanto as figuras 2.26x e 3.06x representam multiplicadores de pontuação por dólar relativos à linha de base pareada calculados contra configurações de comparação correspondentes.

Comparação pareada contra as duas linhas de base fortes:

Linha de base	Pontuação média da linha de base	Delta Fusion	IC 95%	Vitória/Derrota/Empate	Múltiplo de custo Fusion	Razão Pontuação/$	Múltiplo de latência
gpt-5.5	53.43	+32.60	28.13 – 37.28	95/4/1	0.71x	2.26x	1.23x
claude-opus-4-8	40.41	+45.63	40.85 – 50.21	97/2/1	0.69x	3.06x	2.15x

A qualidade e a qualidade ajustada ao custo são vitórias inequívocas do Fusion neste manifesto. O delta da taxa de falha de 0.0 pontos percentuais torna a estabilidade um empate em vez de um diferencial. A latência é uma perda clara do Fusion: 1.23x mais lenta que o gpt-5.5 e 2.15x mais lenta que o claude-opus-4-8. O enquadramento honesto do produto a partir desses dados é pesquisa profunda de alta qualidade, eficiente em termos de custo e verificável, não chat interativo de baixa latência.

A divisão por domínio mostra deltas positivos em todos os domínios contra ambas as linhas de base, o que argumenta contra a melhoria ser um artefato de domínio único. Valores selecionados: contra gpt-5.5, Finanças +37.13, Compras +38.20, Needle-in-a-Haystack +62.56, Tecnologia +33.49; contra claude-opus-4-8, Compras +55.96, Needle-in-a-Haystack +69.38, Tecnologia +52.43, UX Design +52.77. Finanças também é o domínio que carrega o risco não resolvido mais claro: oito avisos de evidência de alta severidade, todos em Finanças, sinalizados como finance:needs_more_sources, citando lacunas em termos de métricas, termos de período e fornecimento do período primário atual. Essas não são falhas de chamada; são avisos de suficiência de fonte, indicando que o roteamento de evidências específico para Finanças ainda não está totalmente resolvido, mesmo onde o delta de pontuação é grande.

6. Estado de Prontidão: Comprovado vs. Ainda Bloqueado

É importante separar duas camadas de status. Este é um resultado de prova de receita, não um resultado de sistema enviado, e o rastreamento de prontidão usado em todo o programa reflete essa distinção explicitamente.

Passou: manifesto fixo ponderado de 100 tarefas, política de painel, teste do roteador de evidências, prova de ablação de painel, prova de ablação de validador/synth, a configuração de linha de base forte em si, a prova de bloqueio de fonte fraca, artefatos de receita e a prova pareada de linha de base forte descrita na Seção 5.

Ainda não passou: a reexecução final apenas com Fusion.

A reexecução final não é uma segunda comparação contra as linhas de base fortes; seu propósito é diferente e mais restrito: confirmar que a receita vencedora congelada se reproduz no mesmo manifesto de 100 tarefas sem custo de linha de base na execução, que a configuração de tempo de execução corresponde à definição da receita, que as linhas de custo estão completas e que não há contaminação de linha de base no caminho apenas de Fusion. A partir da última execução escalonada, a cobertura está em 20 de 100 tarefas pontuadas, 20 de 20 compatíveis com tempo de execução, custo oficial apenas de Fusion de $2.619654, custo de linha de base $0, com as 80 tarefas restantes a serem executadas em estágios de compensação adicionais.

Essa distinção é importante para como os números da execução de pesquisa weighted-100 devem ser lidos: o delta de linha de base forte é real e pareado, mas foi medido com uma receita que ainda não foi reproduzida de forma independente de ponta a ponta sem custo de linha de base no loop, e usou uma âncora de síntese/validador/juiz que o caminho de custo do produto está tentando aposentar deliberadamente.

Sobre a âncora Gemini Pro especificamente, a receita congelada que produziu esses números usou o gemini-3.1-pro-preview, um modelo Gemini Pro premium histórico, como a âncora de síntese/julgamento/validador. Essa configuração estabelece o teto para o que a estrutura de receita e a validação consciente de rubrica podem alcançar, mas não é a configuração que o caminho de custo do produto pretende enviar. Como o preço do Gemini Pro premium não se encaixa no perfil de custo alvo, o próximo artefato de evidência necessário é um canary sem Gemini premium: uma reexecução pareada em menor escala substituindo o deepseek-v4-pro para síntese/validação e o glm-5.2 para julgamento, executada contra os mesmos IDs de tarefa antes que qualquer alegação seja feita de que a receita eficiente em termos de custo corresponde ao teto de qualidade comprovado.

7. Protocolo e Compatibilidade: Por Que Um Endpoint de Chat Não É Suficiente

Uma receita que só funciona contra um único endpoint de chat compatível com OpenAI não sobreviverá ao contato com clientes reais de agentes de codificação. Chat Completions é suficiente para uso conversacional simples, mas descarta semânticas das quais os clientes de agente dependem: itens de saída tipados, emparelhamento de chamada de função/resultado de ferramenta, eventos de item de streaming, histórico com estado versus sem estado e garantias de ordenação específicas do provedor.

As superfícies que importam, e as semânticas que cada uma carrega, diferem o suficiente para que não possam ser colapsadas em uma única forma sem perda:

Superfície	Semânticas-chave que devem ser preservadas
Respostas OpenAI	itens de saída tipados, hierarquia de instrução de desenvolvedor/sistema, chamadas de função e saídas de chamada de função, previous_response_id, store, eventos de item transmitidos, contabilidade de uso
Chat OpenAI	mensagens/ferramentas legadas; utilizável como uma fachada degradada, mas perdas de compatibilidade devem ser registradas
Mensagens Anthropic	campo de sistema de nível superior, blocos de conteúdo, tool_use/tool_result, solicitações de histórico completo sem estado, stop_reason, erros de fluxo pós-200
Perfil de cliente estilo Codex	Respostas primeiro, store, previous_response_id, argumentos de ferramenta transmitidos, repetição de resultado de ferramenta, ordenação estrita de eventos
Perfil de cliente estilo Claude Code	Mensagens Anthropic, ordenação imediata de tool_result, lotes de ferramentas paralelos, disable_parallel_tool_use, listas de permissão de descoberta de modelo

A resposta arquitetural é uma representação intermediária canônica (IR). Protocolos externos mapeiam para uma representação interna de solicitação/resposta/fluxo/ferramenta/uso/erro/rastreamento, e a execução da receita e os adaptadores de provedor operam contra essa IR em vez de contra qualquer protocolo de fio único. A IR é necessária para carregar, no mínimo: identificadores de conversa e turno mais ponteiros de estado do provedor (previous_response_id); protocolo do cliente e identificador de receita pública; a proveniência e precedência das instruções de sistema/desenvolvedor/gateway/receita; mensagens, blocos de conteúdo, imagens e texto derivado; ferramentas, resultados de ferramentas, escolha de ferramenta e política de ferramenta paralela; modalidades e configurações de geração; um registro de perdas de compatibilidade; linhas de uso e linhas de custo separadas por função; e um rastreamento cobrindo evidências, pesquisa, ferramenta, custo e atividade de função de modelo.

A justificativa prática é concreta: o tool_result da Anthropic deve seguir imediatamente seu tool_use correspondente; as saídas de chamada de função das Respostas OpenAI devem repetir por call_id; uma fachada de Chat não pode preservar totalmente a prioridade da mensagem do desenvolvedor; o Claude Code envia histórico completo sem estado a cada turno, enquanto clientes baseados em Respostas dependem de um ponteiro de estado do lado do provedor. Sem uma IR e uma suíte de compatibilidade que exercite esses casos diretamente, um sistema pode passar em um benchmark e ainda falhar dentro de um cliente de agente real porque o loop de ferramenta nunca é concluído corretamente.

O status atual da implementação deve ser declarado com precisão em vez de otimismo: a camada de compatibilidade existe como documentação de protocolo, definições de IR de adaptador, fixtures de contrato de gateway, um planejador de turno, um escritor de fluxo, fixtures de ferramenta/evidência e uma suíte de teste de compatibilidade agregada. É um esqueleto de compatibilidade offline, suficiente para restringir formas de protocolo, lacunas de superfície e evitar o desvio de design inicial, mas ainda não é um gateway de produção ao vivo. Ainda não inclui execução real de provedor em escala, uma superfície de produto de streaming voltada para o cliente, execução de ferramenta ao vivo, autenticação/tenancy de produção ou um backend de rastreamento persistente. A descoberta de modelo público foi projetada para expor apenas identificadores de receita pública com namespace; qualquer solicitação de ID de modelo não público ou sem namespace deve falhar fechada (por exemplo, model_not_public) em vez de permitir que um cliente ignore limites de receita, custo ou rastreamento.

8. Modelo de Controle de Uso de Ferramentas

A chamada de ferramenta multi-modelo é a parte operacionalmente mais perigosa de qualquer extensão de agente de codificação deste sistema. Se vários modelos puderem emitir chamadas de ferramenta independentemente no mesmo turno, o resultado pode ser edições de arquivo duplicadas, chamadas de API externas duplicadas, cobranças duplicadas, gravações simultâneas, comandos de shell conflitantes ou exposição de credenciais. O modelo de controle adotado é deliberadamente restritivo:

• Um turno tem, por padrão, exatamente um proprietário de ferramenta ativo.
• Outros modelos podem atuar como revisor ou crítico e podem propor alterações, mas não podem executar ferramentas.
• Texto em forma de ferramenta na saída de um modelo não é, por si só, autoridade de execução.
• Toda chamada de ferramenta é normalizada em uma IR ToolCall canônica antes que qualquer decisão de execução seja tomada.
• Um agendador classifica cada chamada como executable, advice_only, blocked ou requires_approval.
• Chamadas somente leitura, de leitura de rede e somente computação podem ser executadas simultaneamente em um grupo paralelo sob condições seguras.
• Chamadas de gravação, gravação de shell, pagamento, credencial e classe destrutiva são serializadas e bloqueadas por aprovação por padrão.
• Os resultados das ferramentas são repetidos deterministicamente de volta na forma esperada do protocolo de destino.
• JSON parcial nunca é executado; mesmo JSON bem formado ainda deve passar por verificações de esquema, efeito colateral, aprovação e proprietário.

Este é um afastamento significativo das demonstrações típicas de multi-agentes, onde vários agentes podem tentar "resolver" um problema simultaneamente. Uma receita de codificação voltada para a produção requer disciplina de função sobre a segurança da execução: um revisor pode sinalizar que um patch proposto quebrará uma suíte de testes, mas não pode executar um comando de shell destrutivo. Um proprietário de ferramenta pode iniciar uma edição de arquivo ou comando de shell, mas sua saída ainda é verificada pelo gateway antes da execução.

Isso também restringe como as tags de capacidade de ferramenta da biblioteca de modelos devem ser lidas: uma tag "tool-use" significa que um modelo pode expressar plausivelmente uma chamada de ferramenta, não que ele esteja liberado para ser um proprietário de ferramenta de produção. A promoção para o status de proprietário requer passar em uma suíte de compatibilidade cobrindo argumentos de ferramenta transmitidos, estabilidade de ID de ferramenta, reparo de JSON malformado, repetição de resultado de ferramenta, política de ferramenta paralela, contabilidade de uso e forma de erro. Um caso de borda relacionado é o "resgate" de ferramenta em linha: alguns provedores emitem chamadas de ferramenta como texto de assistente (blocos XML/JSON, tags de função privada, argumentos de objeto ou codificados duplamente). A camada de adaptador pode detectar e reparar esses dialetos, mas o reparo apenas produz uma IR ToolCall candidata; não concede autoridade de execução, é limitado apenas ao texto de resposta do proprietário atual (nunca ao texto do usuário, resultados de ferramenta, notas do revisor ou a resposta final fundida), e uma chamada reparada ainda deve limpar os bloqueios de proprietário, esquema, efeito colateral, aprovação, paralelismo e idempotência. JSON malformado repetido deve falhar na verificação de compatibilidade daquele proprietário para o turno em vez de ser executado silenciosamente.

9. Visão e Pesquisa na Web: Justiça vs. Experiência do Produto

Os caminhos de avaliação e produto divergem intencionalmente aqui. A prova de benchmark usa evidências compartilhadas e reprodutíveis; solicitações de produção podem usar pesquisa ou visão nativa, mas apenas quando rastreáveis.

A pesquisa é tratada por meio de três caminhos distintos: shared_evidence (um pacote de pesquisa/busca/leitura externo de propriedade do Fusion, reprodutível, obrigatório para execuções de prova da suíte de pesquisa weighted-100, comparações de linha de base forte, canaries de atualização de modelo e reexecuções finais), native_search (capacidade própria de web/navegação/grounding de um modelo ou provedor) e external_search (ferramentas externas rastreáveis, como busca, leitura de navegador ou extração de documentos). A pesquisa nativa não é proibida; pode melhorar a experiência do produto, mas não pode sustentar uma alegação de benchmark justa, porque se o comportamento de pesquisa, as fontes recuperadas e a trilha de citação de um modelo forem opacos, a comparação deixa de ser uma comparação de mesma tarefa.

A visão segue a mesma lógica. Visão nativa e texto de OCR/legenda derivado não são entradas equivalentes, e uma comparação entre modelos com visibilidade diferente em uma imagem não é uma comparação de visão justa. O rastreamento registra a visibilidade de cada modelo explicitamente como native_image, derived_text ou none. O padrão de produção recomendado é um híbrido: modelos primários podem usar visão nativa enquanto revisores de custo mais baixo trabalham a partir de texto derivado; tarefas de fatos atuais usam pesquisa/busca externa por padrão, e a pesquisa nativa só é permitida uma vez que uma rota tenha passado por um teste de capacidade e produza um rastreamento completo. A avaliação, no entanto, sempre usa evidências compartilhadas e um pacote de evidências com hash por padrão.

10. Biblioteca de Modelos como um Esquema de Seleção Consciente de Função

O catálogo de modelos subjacente ao TokenLab Fusion mudou de uma tabela de capacidade plana para um esquema de seleção em camadas com campos para camada de custo, funções Fusion, tags de capacidade, métricas de seleção, perfil de roteamento e trilha de avaliação recomendada. Isso reflete uma realidade de produto que um único ranking de "quão forte é este modelo" não captura: um modelo pode ser um excelente revisor de codificação e um pobre painelista de pesquisa de baixa latência; um modelo pode ser barato, mas ter IDs de chamada de ferramenta instáveis; um modelo pode carregar uma tag de capacidade de visão nativa sem ainda ter evidências de rastreamento suficientes para uma avaliação bloqueada por justiça.

Camada	Função representativa	Significado do produto
Sempre ativo barato	candidatos a painel/revisor/juiz de baixo custo	Composição de painel padrão, promovido apenas via evidência canary pareada
Atualização de raciocínio forte	escalonamento de tarefa difícil	Função de synth/validador/juiz para tarefas difíceis
Especialista em codificação/agente	loop de ferramenta, escala de repositório, revisão front-end	Candidatos a proprietário e revisor de ferramenta de agente de codificação
Especialista em visão/pesquisa	fluxos de trabalho de produto pesados em imagem/pesquisa	Requer teste de rastreamento antes do uso bloqueado por justiça
Holdout de contexto ultra-longo	diagnóstico de repositório/pacote de evidências enorme	Não é um membro de painel padrão
Comparador caixa-preta	sistemas multi-agente do lado do provedor	Apenas ponto de referência; atribuição interna Fusion não pode ser derivada dele

O julgamento atual sobre a âncora premium aposentada merece uma declaração explícita: o modelo Gemini Pro premium histórico que ancorou a prova weighted-100 foi aposentado do planejamento de receita de custo de produto ativo, e um modelo de camada flash Gemini de preço mais baixo também foi removido do plano padrão devido ao preço de saída que não se encaixa no perfil de custo da receita alvo. Isso não revisa o resultado da execução de pesquisa weighted-100, essa prova permanece como registrada, mas significa que a prova e a receita de envio pretendida não são atualmente o mesmo sistema, o que é precisamente por que o canary sem Gemini premium é o próximo passo de evidência necessário, não um opcional.

11. Bloqueios de Atualização da Biblioteca de Modelos

Uma preocupação operacional recorrente é se toda mudança de modelo requer uma reexecução completa de 100 tarefas. A resposta adotada pelo programa é bloqueios em camadas e proporcionais ao risco, em vez de qualquer um dos extremos (reexecuções completas cegas a cada mudança, ou substituição cega da mesma família sem evidência):

1. Fumaça de contrato: confirmar rota, preço, streaming, janela de contexto, limites de saída, modalidade e tags de ferramenta/pesquisa/visão.
2. Suíte de compatibilidade: exercitar Chat OpenAI, Respostas OpenAI, Mensagens Anthropic, chamada de ferramenta, resultado de ferramenta, ferramenta paralela, uso, erro e manuseio de fluxo.
3. Avaliação sentinela: executar um pequeno conjunto específico de domínio correspondente à função alegada do modelo (por exemplo, suficiência de fonte de finanças, loop de ferramenta de codificação, revisão visual front-end).
4. Canary pareado: comparar contra a receita atual em IDs de tarefa idênticos para qualidade, custo, latência e taxa de falha.
5. Execução completa de 100 tarefas: reservada para candidatos que poderiam mudar a receita padrão ou uma alegação de linha de base forte.

Mesmo uma atualização de mesma família aparentemente menor requer passar por este funil: preço, comportamento de chamada de ferramenta, streaming e qualidade pareada precisam de confirmação independente em vez de serem inferidos de um nome de família de modelo compartilhado. É também por isso que o manifesto de 100 tarefas não é executado continuamente; ele é reservado para confirmação final, enquanto as mudanças de modelo do dia a dia são regidas pelos bloqueios mais baratos e rápidos acima.

12. Trabalhos Relacionados e O Que É (e Não É) Reutilizado

O programa se baseia em várias direções de pesquisa e ferramentas públicas sem adotar seus objetivos no atacado. Mixture-of-Agents motiva a ideia de que saídas de modelo mais fracas ainda podem condicionar utilmente um sintetizador mais forte, mas as descobertas de inchaço de painel na Seção 4 alertam contra a estratificação sem ablação. LLM-Blender contribui com a estrutura de geração de candidatos, classificação pareada e fusão generativa que os estágios de painel/juiz/síntese se assemelham, embora nenhum classificador treinado dedicado substitua atualmente o juiz baseado em rubrica. FrugalGPT e RouteLLM motivam o cascateamento e roteamento conscientes de custo, mas o problema de roteamento aqui é multi-função (painel, síntese, juiz, validador, estratégia de pesquisa, proprietário de ferramenta podem cada um rotear independentemente), não uma escolha de modelo binária única. Ferramentas de avaliação como Inspect AI, OpenAI Evals, Promptfoo e Ragas informam o padrão de engenharia de um ciclo de avaliação sistemático e amigável ao CI, mas nenhum deles substitui o manifesto ponderado fixo, verificações de suficiência de fonte, linhas de custo separadas por função ou a estrutura de prova pareada ponderada por domínio usada aqui.

13. Limitações

Limitação	Estado atual	Por que importa
Dependência de âncora premium	A prova weighted-100 usou um modelo Gemini Pro premium histórico como synth/juiz/validador	Comprova o teto da receita, não a receita de custo de produto pretendida
Reexecução final incompleta	Reexecução apenas com Fusion em 20/100 tarefas, 20/20 compatíveis com tempo de execução	A reprodutibilidade sem custo de linha de base ainda não está totalmente confirmada
Sem dados públicos de auditoria humana ou concordância entre avaliadores	Resultados de auditoria humana e concordância entre avaliadores ainda não foram publicados ou disponibilizados publicamente para este pipeline de avaliação	A confiabilidade e consistência das pontuações automatizadas em relação ao julgamento humano permanecem não verificadas, limitando a confiança na interpretação absoluta da pontuação
Desvantagem de latência	1.23x vs. gpt-5.5, 2.15x vs. claude-opus-4-8	Pode ser aceitável para pesquisa profunda, provavelmente inaceitável para agentes de codificação interativos
Validador consciente de rubrica	O validador vê a rubrica/checklist de pontuação	As comparações devem divulgar isso; não diretamente comparável a sistemas cegos a rubricas
Avisos de fonte de Finanças	8 avisos de alta severidade finance:needs_more_sources	A suficiência de fonte em Finanças não está resolvida apesar dos grandes deltas de pontuação
Inferência de capacidade nativa	Tags de capacidade de pesquisa/visão não são prova de suporte de rastreamento de nível de produção	Requer sondagem por rota antes de qualquer uso de avaliação bloqueado por justiça
Maturidade da camada de compatibilidade	Esqueleto offline (IR, fixtures, contrato de roteador, planejador, escritor de fluxo)	Ainda não é um gateway de produção ao vivo com execução real de provedor, auth/tenancy ou armazenamento de rastreamento persistente
Volatilidade de preço/rota	A correção de preço do DeepSeek V4 Pro já mudou uma decisão estratégica	A estratificação da biblioteca de modelos deve ser reverificada à medida que o preço e o comportamento da rota mudam

14. FAQ

O resultado de 100 tarefas significa que o TokenLab Fusion supera o GPT-5.5 e o Claude Opus 4.8 em geral?

O resultado pareado se mantém especificamente no manifesto de pesquisa ponderado de 100 tarefas fixo, usando evidências compartilhadas e contabilidade de custos separada por função, com gpt-5.5 e claude-opus-4-8 mantidos fora do painel Fusion. É uma evidência forte e ampla em domínio dentro desse escopo, não uma alegação geral independente do tipo de tarefa, condições de evidência ou composição do manifesto.

Por que a âncora Gemini Pro importa se o delta de pontuação já é grande?

O delta foi produzido por uma receita usando um modelo Gemini Pro premium histórico para síntese, julgamento e validação. Essa configuração estabelece o que a estrutura de receita pode alcançar, mas não é o perfil de custo que o caminho do produto pretende enviar. Até que uma configuração sem Gemini premium seja executada como um canary pareado contra os mesmos IDs de tarefa, a qualidade alcançada e o custo de envio pretendido são comprovados separadamente, não juntos.

Um custo menor por chamada é o mesmo que um custo menor por unidade de qualidade?

Não, e os dois são relatados separadamente por esse motivo. Os multiplicadores de custo 0.71x e 0.69x descrevem o custo bruto contra as duas linhas de base; as razões de pontuação por dólar 2.26x e 3.06x descrevem a qualidade ajustada ao custo. Ambos são necessários, porque um sistema pode ser mais barato por chamada e ainda pontuar pior, ou mais caro por chamada e ainda ser mais eficiente em termos de custo por unidade de qualidade; esta avaliação relata ambos explicitamente em vez de colapsá-los.

Por que a ablação do validador importa para este resultado?

O estágio de validador/reescrita consciente de rubrica produziu a maior mudança de qualidade única medida neste programa (delta pareado +51.81 em uma expansão de 20 tarefas), a cerca de 2.14x de custo e 1.89x de latência versus o controle de núcleo rápido. Qualquer comparação entre receitas, ou entre o Fusion e uma linha de base, precisa divulgar se o estágio do validador está ativo, porque ele muda tanto o perfil de custo quanto o enquadramento de justiça (o validador tem visibilidade das rubricas de pontuação).

O TokenLab Fusion está pronto para rodar dentro de um cliente de agente de codificação real hoje?

Não. A arquitetura de controle de protocolo e uso de ferramentas (IR canônica, suíte de compatibilidade, modelo de proprietário de ferramenta) existe como um esqueleto de compatibilidade offline com mapeamentos de protocolo e fixtures documentados, mas ainda não inclui um gateway de produção ao vivo, execução real de provedor em escala, autenticação/tenancy ou armazenamento de rastreamento persistente. A prova de Deep Research e a linha de Coding Agent são avaliadas em cronogramas diferentes, e a linha de codificação ainda não completou sua primeira fase de validação de amostra pequena.

15. Encerramento da Pesquisa

O que está comprovado

Em um manifesto multidomínio fixo, com hash, ponderado de 100 tarefas, usando evidências compartilhadas e contabilidade de custos separada por função, uma receita multi-modelo equipada com validador alcançou um delta de pontuação média pareada de +32.60 sobre o gpt-5.5 e +45.63 sobre o claude-opus-4-8, a 0.71x e 0.69x de custo respectivamente, com zero falhas de chamada em 799 linhas de custo. A validação consciente de rubrica é confirmada como a maior alavanca de qualidade única testada, com um delta pareado de +51.81 sobre um controle de núcleo rápido. Deltas positivos se mantêm em todos os domínios no manifesto contra ambas as linhas de base, indicando que o ganho não está concentrado em um tipo de tarefa.

O que permanece bloqueado

A reexecução final apenas com Fusion da receita vencedora congelada está incompleta (20 de 100 tarefas na última verificação) e deve atingir cobertura total com uma auditoria de prontidão limpa antes que a prova possa ser chamada de reprodutível de ponta a ponta. A receita que produziu a prova depende de uma âncora Gemini Pro premium histórica que o caminho de custo do produto pretende aposentar; nenhuma evidência pareada ainda existe para a substituição pretendida sem Gemini premium. A latência permanece um tradeoff de produto não resolvido, particularmente para qualquer aplicação de agente de codificação. A suficiência de fonte de Finanças carrega oito avisos de alta severidade não resolvidos apesar de uma grande vantagem de pontuação naquele domínio. A camada de compatibilidade de protocolo é definida arquiteturalmente, mas ainda não é um gateway de produção em execução.

Que evidências devem ser coletadas a seguir

Concluir a reexecução final apenas com Fusion nas 80 tarefas restantes e refazer a auditoria de prontidão para confirmar a reprodutibilidade sem custo de linha de base no loop. Executar um canary pareado, com mesmo ID de tarefa, substituindo deepseek-v4-pro para síntese/validação e glm-5.2 para julgamento no lugar da âncora Gemini Pro premium, começando em pequena escala antes de qualquer alegação de manifesto completo. Fechar os oito avisos de suficiência de evidência de Finanças pendentes com trabalho de bloqueio de fonte específico de domínio antes de tratar o resultado do domínio de Finanças como totalmente resolvido. Estender a suíte de compatibilidade de um esqueleto offline para a execução real do provedor, e executar uma fase de validação de agente de codificação de amostra pequena (na ordem de cinco tarefas) para testar se a arquitetura proprietário/revisor de ferramenta produz uma vantagem mensurável de painel sobre modelo único antes de investir mais na infraestrutura de agente de codificação. Cada um desses é um próximo experimento específico e falseável, não um item de roteiro geral.