Do zero ao leaderboard: avaliação de agentes — Wolfram Ravenwolf, Weights & Biases

Ver no idioma original →

Autoria: AI Engineer · 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: From Zero to Leaderboard: Agent Evaluation — Wolfram Ravenwolf, Weights & Biases · Canal: AI Engineer · 52:27 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Modelos de IA

Resumo

Wolfram Ravenwolf apresenta uma abordagem prática para criar avaliações reproduzíveis de modelos e agentes, usando o WolfBench como exemplo. Ele argumenta que um único score não basta: é preciso considerar consistência, variação entre execuções, custo, uso de tokens e os traces que mostram como o resultado foi obtido. A palestra detalha as escolhas que compõem uma configuração de benchmark, incluindo dataset, harness de avaliação, sandbox, agent, modelo, provedor e parâmetros. Por fim, demonstra como analisar resultados e traces para entender falhas, comparar configurações e publicar avaliações mais transparentes.

Pontos-chave

• Uma avaliação mede uma configuração específica — com versões, dados, ferramentas e parâmetros definidos — e não apenas um modelo isolado.
• Uma única execução pode ser resultado de sorte; múltiplas execuções ajudam a revelar a variação e a confiabilidade.
• Média, melhor e pior resultado, consistência, teto de desempenho, custo e tokens usados oferecem perspectivas diferentes sobre uma avaliação.
• Alterar qualquer componente relevante, como a versão do benchmark, do agent, do harness ou do endpoint de inference, pode criar um experimento diferente.
• Sandboxes isolados evitam que tarefas interfiram umas nas outras ou alterem o sistema local.
• Parâmetros como context window, nível de reasoning, system prompt, ferramentas disponíveis, recursos do sandbox, timeout e temperature podem afetar os resultados.
• Os traces são evidências que permitem investigar o que aconteceu em cada tarefa, inclusive falhas causadas por infraestrutura, recusas ou overthinking.
• Um modelo que parece mais barato ou rápido pode consumir mais tokens e custar mais no total.
• O WolfBench reúne resultados e gera gráficos interativos, mas sua metodologia também pode ser adaptada para outros benchmarks e ferramentas.
• A transparência e o compartilhamento das configurações e dos resultados tornam as comparações mais úteis e reproduzíveis.

Capítulos

Início	Capítulo	Resumo
00:12	Apresentação e objetivos do workshop	O apresentador explica como acompanhar a oficina, apresenta sua trajetória e identifica os diferentes perfis de participantes.
03:18	Por que um único score não basta	Ravenwolf defende avaliar distribuições de desempenho, explicitar trade-offs e publicar resultados transparentes.
07:25	O que realmente está sendo avaliado	A avaliação corresponde a uma configuração específica, que inclui dados, modelo, inference, agent, sandbox e parâmetros.
10:01	Escolha do benchmark	O apresentador explica a seleção do Terminal-Bench e a importância de manter a versão escolhida para preservar comparações.
12:39	Harness de avaliação e sandboxes	A palestra compara opções de harness, recomenda fixar versões e demonstra a instalação do Harbor e a escolha de sandboxes isolados.
16:46	Escolha do agent, do modelo e dos parâmetros	Ravenwolf percorre agents, provedores e configurações que influenciam a avaliação, incluindo context window, system prompt e recursos do sandbox.
21:27	Timeouts, concorrência e sampling	O apresentador discute limites de tempo, paralelismo, retries, temperature, top P, quantidade de tokens e seeds.
25:38	Configuração e execução de uma avaliação	A demonstração reúne as escolhas das camadas da avaliação e inicia uma execução com Harbor, Terminal-Bench e um sandbox.
30:21	Resultados e toolkit do WolfBench	O apresentador mostra a execução de uma tarefa e como o WolfBench coleta, organiza e transforma resultados em arquivos e gráficos.
37:07	Como interpretar o leaderboard	A demonstração explica como comparar consistência, média, variação e teto de desempenho nos gráficos interativos.
41:20	Custo, tokens e comportamentos inesperados	Ravenwolf compara custos entre modelos e agents e mostra casos em que recusas ou overthinking afetam os resultados.
47:36	Inspeção de traces e recomendações finais	O apresentador inspeciona traces para investigar tarefas e encerra com recomendações para publicar benchmarks reproduzíveis e transparentes.

Citações

Um score não basta, porque o desempenho é uma distribuição, não um ponto. — 04:20

Você não está avaliando um modelo; está avaliando uma configuração específica. — 07:25

O leaderboard não é uma resposta: ele ajuda você a encontrar uma pergunta melhor. — 37:38

A barra é uma afirmação; o trace é a evidência. — 47:36

Execute configurações de benchmark reproduzíveis. Compartilhe os resultados. — 50:41

Conceitos e entidades

• WolfBench (ferramenta): Framework de código aberto apresentado por Wolfram Ravenwolf para organizar, analisar e visualizar resultados de avaliações de modelos e agentes.
• Wolfram Ravenwolf (pessoa): Apresentador da palestra e criador do WolfBench.
• Weights & Biases (empresa): Empresa em cujo contexto o apresentador trabalha e cujas ferramentas são mencionadas na demonstração.
• Terminal-Bench (benchmark): Benchmark agentic escolhido para avaliar tarefas práticas executadas em ambientes de terminal.
• Harbor (ferramenta): Framework usado na demonstração para executar avaliações do Terminal-Bench.
• Terminus 2 (ferramenta): Agent padrão mencionado para executar tarefas do Terminal-Bench por meio do Harbor.
• CoreWeave (empresa): Provedor cujos serverless sandboxes são usados na demonstração para isolar tarefas.
• Daytona (empresa): Provedor de sandboxes que apoiou o apresentador em avaliações anteriores.
• Weave (ferramenta): Plataforma mencionada para armazenar e inspecionar traces das execuções.
• OpenRouter (ferramenta): Provedor de acesso a modelos citado como alternativa para executar a avaliação.
• GLM-5.2 (modelo): Modelo de open weights usado como exemplo na demonstração prática.
• GPT-5.5 (modelo): Modelo comparado a outros na análise de desempenho, tokens e custo.
• Gemini 3.5 Flash (modelo): Modelo apresentado como exemplo de desempenho próximo ao GPT 5.5, mas com maior uso de tokens e custo na avaliação.
• Claude Code (ferramenta): Agent citado entre os sistemas avaliados pelo apresentador.
• Codex (ferramenta): Agent comparado com outros na avaliação, incluindo em combinação com diferentes modelos.
• Hermes Agent (ferramenta): Agent mencionado como exemplo de sistema cuja configuração e system prompt podem influenciar os resultados.
• Terminal-Bench 2.0 (benchmark): Versão do benchmark usada pelo apresentador para preservar a comparabilidade com resultados anteriores.
• Terminal-Bench 2.1 (benchmark): Versão mais recente que o apresentador recomenda a quem estiver começando uma avaliação nova.
• MMLU (benchmark): Benchmark citado como opção para avaliações relacionadas a capacidades multilíngues.
• MMU-Pro (benchmark): Benchmark citado como opção para avaliações multimodais.

Tradução completa (pt-BR)

00:12 Antes de começarmos, se quiser acompanhar — embora este seja um workshop prático, então vejo que há muitos notebooks por aí, ótimo. Se quiser acompanhar exatamente o que estou fazendo, você precisa ter uma conta na W&B, ou Weights & Biases. Se não tiver uma, pode se cadastrar e criar uma gratuita. Também damos créditos de inference, então você pode fazer uma avaliação dessa forma, e o acesso ao sandbox também está incluído. E, se quiser usar outra coisa, como o OpenRouter, também pode. Ou até um provedor diferente,

00:43 o que você quiser usar. Vou usar isto como exemplo no workshop. E, se você tiver um agente de IA, pode simplesmente dizer a ele para mudar alguma coisa e fazer funcionar com a minha configuração. Então, vamos lá. Um pouco sobre mim. Sou Wolfram Ravenwolf. E meu slogan é: avalio modelos no café da manhã, construo agents à noite e prego sobre IA o dia inteiro. Faço isso como evangelista de IA na Corvus e na Weights & Biases. E também sou coapresentador do podcast Thursday AI.

01:15 Alex também está aqui. Ele é o cara principal. E, se tiver algum problema técnico durante o workshop, você pode falar com ele. Ele vai ajudar para que não sejamos interrompidos. Ele é a pessoa certa. Obrigado pela ajuda, Alex. E, sim, você pode me acompanhar no X ou no LinkedIn, e no WolfBench, em wolfbench.ai. Fácil de lembrar. Mas este workshop não é só sobre o WolfBench. É sobre por que e como eu o construí, para que você possa criar sua própria avaliação de modelos e agents, do zero até o leaderboard. Bem, minha história, basicamente, é que eu

01:47 comecei ainda criança e amava IA desde o início. Depois que o ChatGPT surgiu, decidi que queria focar minha carreira nisso. Se alguém se lembra dos bons e velhos tempos do LocalLlama, quando o TheBloke quantizava modelos, eu testava os modelos — foi assim que comecei. Muitas pessoas me pediam ajuda com inference e coisas do tipo. Então, virei consultor. E, sim, no ano passado me dediquei integralmente a uma startup alemã de IA e, neste ano, entrei na Qorvo.

02:17 E estou no podcast há bastante tempo, certo, Alex? Mas isto é sobre vocês. Então, sobre o workshop: quem são vocês e por que estão aqui? Acho que há diferentes tipos de pessoas, e quero saber em qual categoria vocês acham que se encaixam. Por exemplo, quem constrói agents. Há pessoas aqui construindo agents que querem avaliá-los? Alguém aqui? Alguém ali? Algumas pessoas. E iniciantes em evals. Há pessoas que querem fazer avaliações significativas, mas ainda não

02:47 fazem ideia do que estão fazendo e querem aprender? Certo, há mais gente nessa categoria. E avaliadores de modelos. Quem está interessado em saber em qual modelo e agent deve confiar? Qual é o que quer usar? Alguém está especificamente interessado nisso? Ali e ali. Ótimo. Líderes de plataforma e de evals. Pessoas que querem avaliações comparáveis e reproduzíveis. Alguém aqui? Algumas pessoas aqui. Ótimo. Depuradores de traces. São as pessoas que analisam os traces de fato e tentam descobrir o que deu errado e como melhorar.

03:18 Ali. Ótimo. E os céticos. Quem não confia nos leaderboards? Quer dizer, não… todas as mãos deveriam estar levantadas, certo? >> [risos] >> Mas por que isso acontece e como podemos mudar? Isso faz parte do que vamos discutir, assim como a forma de vocês criarem o próprio. Mas, primeiro, meus princípios orientadores são: mentalidade é mais importante que conjunto de habilidades, que é mais importante que conjunto de ferramentas. O conjunto de ferramentas é aquilo que usamos, e isso muda na IA quase toda semana, todo mês. Surge algo novo e tudo muda o tempo todo.

03:50 Então, conjunto de habilidades é a maneira como usamos as ferramentas que temos. Isso se aplica a diferentes ferramentas. Se você tem uma boa habilidade, sabe usar as ferramentas e consegue mudar para outras. Mas a mentalidade é o mais importante, porque é o mais difícil de mudar ou melhorar. E, especificamente para avaliação, isso determina por que fazemos benchmark e a que devemos prestar atenção. O conjunto de habilidades é apenas como usar as ferramentas. E, quanto aos conjuntos de ferramentas, vou mostrar alguns, e você pode criar o seu próprio dessa maneira, como fiz com o WolfBench.

04:20 E a premissa é que uma única pontuação não basta, porque o desempenho é uma distribuição, não um ponto. O que eu não gostava nos leaderboards e em muitas avaliações que vi é que você vê umas barras bonitas e alguns números — uma média, um agregado — e isso não diz muita coisa. É por isso que as pessoas sempre dizem, ou dizem com frequência: “Não confio nisso; minha experiência é diferente.” E há coisas escondidas por trás dos números que podemos descobrir e analisar. Porque

04:50 o modelo é realmente bom? Teve uma execução de sorte? Quais são os trade-offs ocultos? Coisas assim. E foi por isso que construí o WolfBench: eu queria saber quais modelos posso usar com quais agents. O agent muda com o tempo. Em janeiro, era o OpenClaw. Em fevereiro, era o Hermes Agent. E agora estou usando muito o Codex. Antes, era o Claude Code. E ainda quero saber quais modelos funcionam melhor com quais configurações. E, como eu disse, a maioria dos resultados de avaliação acaba reduzida a uma única pontuação. E a maioria dos leaderboards classifica os modelos.

05:20 Você nem vê os sistemas agênticos por trás deles. Ou, então, as diferentes versões e configurações — e, às vezes, nem dá para ver quais configurações foram usadas. Elas variam muito: você vê algumas pontuações e outra pessoa relata o mesmo benchmark, mas usa configurações diferentes. Então, será que é mesmo possível compará-las? E existe uma maneira de inspecionar os resultados que essas pessoas obtiveram? O WolfBench é um framework. Tem gráficos, dashboards e leaderboard. É open source, aliás, e também tem uma metodologia, que é o que mais quero discutir. Assim, você pode usar essa

05:52 metodologia com suas próprias ferramentas. E, no WolfBench, uma coisa que se aplica a todos os benchmarks é que você precisa decidir quais métricas são importantes para você. Quer analisar uma média? Quer ver as pontuações mais baixas e mais altas? Quer ver qual porcentagem dos benchmarks ele consegue resolver? E com que consistência? E também o custo. Isso é algo que nem todo mundo leva em conta. Quantos tokens ele consumiu? Quanto custou? E pode acontecer de um modelo

06:23 mais barato e mais rápido demorar mais e custar mais do que um dos modelos maiores, simplesmente porque usou tantos tokens. Condições uniformes também são muito importantes. Então, você precisa usar a mesma configuração todas as vezes, porque, se mudar apenas uma das muitas variáveis que existem — e vamos ver várias delas —, isso basicamente passa a ser um novo benchmark. E, se quiser testar vários agents, quais deles você vai analisar? E sempre faça várias execuções. Uma única execução é uma loteria de benchmark. É um resultado aleatório, apenas uma estimativa aproximada

06:55 do resultado. Então, você precisa fazer várias execuções. No WolfBench, faço cinco, mas você pode fazer mais se tiver dinheiro, é claro. É sempre uma questão de trade-off. A transparência também é muito importante para mim, porque publico todos os resultados, e as pessoas podem analisá-los. Então, não mostro apenas uma pontuação e digo que este é o meu modelo número um e aquele é o número dois. Envio tudo, e você pode inspecionar, conferir e pedir para seu agent analisar também, o que faz muito sentido com todos os dados que coletamos. Então, basicamente, primeiro acerte o raciocínio, e depois as ferramentas se tornam

07:25 intercambiáveis. E acho que a coisa mais importante que as pessoas precisam entender é que você não está classificando um modelo. Se estiver fazendo o benchmark de um modelo, é este modelo, mas, na verdade, você está fazendo o benchmark de uma configuração específica. Então, você usa um conjunto de dados e, se mudar o conjunto de dados, terá um novo benchmark. Você tem o modelo e, por trás dele, o mecanismo de inference e tudo o que acontece no endpoint, coisas que muitas vezes você não pode controlar. Mas, se eles atualizarem o software de inference, isso pode mudar os resultados de novo, e você não tem como perceber isso. A menos que a inference seja feita por você, no seu próprio sistema. O agent harness. Além disso, o agent harness

07:58 também: se eu testar o Claude Code ou o Codex, será uma versão diferente se eu testar na semana que vem e fizer a atualização. Então, também é importante ter isso em mente. E o mesmo vale para o sandbox. Mesmo que você use um provedor de sandbox, se eles mudarem algo no backend, talvez você nem perceba, mas isso pode ter um efeito. O mesmo vale para todas as configurações que você escolhe. Então, se mudar qualquer parte, será um experimento diferente. Você precisa ter isso em mente. Tudo bem, aqui está um glossário. Vocês receberão a apresentação, então não vou passar por tudo isso. A maioria de vocês já

08:28 está bem familiarizada com isso, e vou explicar o que for necessário no momento. Estamos analisando um conjunto específico de ferramentas porque se trata de um workshop prático. Esta é uma forma de montar esse conjunto, não a única, e vou mostrar as diferentes maneiras para que vocês possam escolher o que preferirem. Para acompanhar, vocês devem ter um laptop e um terminal. Python, UV e Git são recomendados. Temos arquivos para baixar, então, se não forem acompanhar, podem baixar os resultados, importá-los e usar o conjunto de ferramentas mesmo assim. Não precisam acompanhar tudo, mas, se quiserem,

08:59 podem fazer isso e usar os próprios resultados dessa forma. Sim, vocês devem ter Wi-Fi, e uma chave de API é opcional. Mostrei isso no começo. Vou mostrar de novo daqui a pouco. Assim, vocês podem acessar. Então, tirem uma captura de tela. Leiam o QR code. É aqui que vocês podem acessar um formulário para obter créditos gratuitos de inference durante a conferência AI Engineer e, para isso, precisam de uma conta gratuita da Weights & Biases. Podem se cadastrar aqui, caso ainda não tenham uma. Quem já tem uma conta?

09:30 Alguém aqui usa a Weights & Biases? Bastante gente. Ótimo. E, quanto aos sandboxes, estou usando os sandboxes serverless da CoreWeave que vocês oferecem, nos quais há uma caixa isolada para cada tarefa. Isso é muito importante, porque, caso contrário, cada execução de avaliação alteraria o próprio sistema, deixando os resultados ainda mais aleatórios. Tudo bem, vamos analisar seis camadas intercambiáveis e escolher cada uma delas; vocês podem fazer o mesmo. Este é o conjunto de habilidades para fazer isso e a mentalidade por

10:01 trás. Agora, vamos escolher as diferentes ferramentas para o kit de ferramentas que estamos montando. Precisamos de um benchmark, que é um conjunto de dados. Precisamos de um harness de avaliação para executar o conjunto de dados e a avaliação e, sim, orquestrar tudo isso e executar nos sandboxes, para que não rode no seu sistema. Também precisamos de um agent harness. Que agent queremos usar? E o modelo e o serviço. Essa costuma ser, claro, a parte que mais interessa às pessoas: como esse modelo se sai? E a questão é que você não está usando apenas

10:33 um modelo; está sempre usando um endpoint. Ele está sempre em um provedor. Se for o OpenRouter, ele encaminha as solicitações para outros provedores. Há muitos provedores e, se for OpenAI, Google, xAI ou qualquer outro, cada um tem sua própria configuração, e, de certa forma, você também está avaliando isso. E todas as configurações que pode escolher. Então, a primeira coisa é: que benchmark vamos usar? Você pode começar pelo benchmark. Fiz assim porque queria testar o uso agêntico com diferentes harnesses, então decidi que queria um benchmark que fizesse isso. Por isso, analisei todos os benchmarks que haviam sido

11:04 usados pelos laboratórios de ponta e vi que o Terminal Bench estava presente em praticamente todos. É um benchmark agêntico. Não é um benchmark de programação; é um benchmark agêntico, com tarefas como consertar um repositório Git, descobrir uma senha, reparar um banco de dados, coisas que você pediria ao seu agent no uso normal, por exemplo. Foi por isso que escolhi o Terminal Bench. Mas, se você tiver interesse em questões multilíngues, MMLU é uma opção. Ou, se tiver interesse em questões multimodais, MMU Pro é uma opção. Se você tiver

11:36 interesse no uso de agents de GUI, escolheria outro benchmark. Se tiver interesse em matemática, programação ou qualquer outra coisa, existe um benchmark para isso. A questão é encontrar o benchmark que seja, sim, mais interessante para você e que permita comparações. Você também pode criar o seu próprio, claro. Pode criar seu próprio conjunto de dados. Quanto ao Terminal Bench, ele é agêntico, por isso o escolhi para fazer o benchmark de agents. Existem as versões 2.0 e 2.1, e a 3.0 está sendo desenvolvida agora. Escolhi a 2.0 porque a 2.1 não estava

12:08 disponível quando comecei. Se você está começando agora, escolha a versão mais recente, a 2.1, mas estou usando a 2.0 porque escolher uma nova versão significaria ter um novo benchmark, e eu já não poderia comparar as pontuações. Na verdade, ela corrige apenas 28 dos 89 testes, mas ainda seria um benchmark diferente para todos os modelos. Eu teria que testar de novo tudo o que já fiz. E fiz muita coisa — nunca é o suficiente —, mas fiz bastante, então não quero criar agora uma nova versão do Wolf Bench. Vou fazer isso mais adiante, talvez com a versão 3.0

12:39 ou se houver um grande salto nas capacidades e precisarmos de um benchmark diferente. Harness de avaliação. Você já escolheu qual benchmark e qual conjunto de dados quer usar. Agora, precisa de algo para executar a avaliação. O Harbor é uma estrutura padrão para o Terminal Bench. Existem outras. O Inspector é uma ótima estrutura, criada pelo UK AI Security Institute, que permite usar muitos benchmarks diferentes. Também é muito popular. O LM Evaluation Harness, que usei há anos, existe há muito tempo

13:10 e a OpenAI tem suas próprias ferramentas de eval. Você pode criar seu próprio executor ou usar um dos outros. Escolha o que quiser. Algumas pessoas também… Algumas começam escolhendo o executor e, depois, selecionam um dos benchmarks compatíveis com ele. Essa também é uma maneira válida. E agora, para a primeira etapa prática, vamos instalar o Harbor. Neste caso, estou usando a versão atual. Estava atual ontem. Não sei se ainda está atual agora. Muda bastante, mas fixo a versão, e recomendo muito que as pessoas usem uma única versão

13:41 porque, sempre que você muda uma das variáveis, se isso afeta a avaliação — e muitas variáveis afetam —, então, sim, você já está mudando uma variável, e a comparabilidade fica comprometida. Mesmo que haja um bug, pelo menos você está testando todos os modelos com o mesmo bug. Mas, claro, isso é uma forma de pensar bastante teórica, porque às vezes é preciso atualizar. Se uma nova versão do harness de avaliação der suporte a um agent ou provedor diferente, talvez você seja obrigado a atualizar. O que recomendo para quem leva isso realmente a sério é fazer um fork do repositório,

14:12 manter o próprio fork e simplesmente fazer backport do que for necessário. E, para instalar, é… Falta uma quebra de linha aqui. O comando é uv tool install harbor. Assim, a instalação é feita em um ambiente UV, sem afetar o sistema, e você pode desinstalar tudo de forma limpa. Depois, você deve ter esta versão. A próxima etapa: os agents precisam de um sandbox, porque, se você executar tudo localmente no seu próprio sistema, o segundo agent encontrará um sistema que já foi alterado e interferirá no seu sistema. Então, eu

14:43 não recomendo isso. Você pode usar Docker. Isso é muito comum, mas é muito difícil paralelizar, dependendo do sistema que você está usando. Então, você precisa de muitos recursos. Por isso existem provedores de nuvem, e preciso fazer um agradecimento especial à Daytona. Eles me apoiaram no começo, antes de a Qualif ter seus próprios sandboxes, e eu queria começar com isso. Então, eles realmente me apoiaram muito, e fiz muitas das avaliações que tenho com a Daytona. Agora, temos nossa própria oferta, então estou usando-a para testar, e é por isso que há duas opções aqui

15:14 que recomendo. Os sandboxes da Qualif são para quem usa o serviço Kubernetes, e o dourado aqui é o Qualif serverless sandboxes. Você só precisa da sua conta Vent B. >> E quanto ao… Ah, certo. Também temos um… Eu… Você pode… Desativei o Slack, então ele não está sendo compartilhado aqui. Se alguém quiser obter o PDF agora mesmo, basta acessar Alex. Provavelmente, essa é a maneira mais fácil neste momento.

15:44 Certo. Depois de instalar isso, o Harbor estará instalado. Agora, precisamos de um cliente de sandbox que faz parte do Harbor. Neste caso, há algumas coisas envolvidas. Aqui está o QR code da apresentação. Isso. Ótimo. O comando UV tool install Harbor entre colchetes instala o provedor para usar os sandboxes, e você

16:16 não precisa fazer nada. Depois de instalado, basta ter sua API key. Você configura isso em um arquivo YAML, e aqui está apenas a próxima etapa. Não precisa copiar isso. Há um link e uma URL simples que você pode acessar, com a configuração completa, alguns slides adiante. Então, só para você… Isso é só para você ver. Mas, se estiver acompanhando, basta digitar o comando UV tool install para instalar o provedor Harbor, se estiver usando isso.

16:46 Vamos continuar. Próxima etapa: o agent. Esta é a parte mais divertida para mim, porque há muitos agents, e quero testar como esse agent se sai com este modelo. Aqui está uma lista de alguns dos agents. Estes são todos os agents, e há ainda mais compatíveis com o framework Harbor. Temos Cursor, Claude, Klein, Codex, Open Claude Hermes agent e Terminus 2, que é o agent padrão do Terminal Bench e do framework Harbor. E este não é um agent de verdade. Você não pode

17:19 usá-lo para suas tarefas de programação, ou não deveria. É mais como simular um ambiente CLI para o modelo em si: ele envia pressionamentos de teclas, e o agent os executa. É uma maneira de fazer isso. Então, o Simple Agent, que é o agent padrão, é o que você verá nos resultados do Terminal Bench, a menos que alguém diga que foi testado com um agent diferente. Esse é o agent usado. E então, qual modelo você quer testar? Você precisa escolher um modelo e um provedor. Se estiver usando GPT 5.5, usará OpenAI.

17:49 Se estiver usando Claude, Fable — se tiver sorte de poder usá-lo —, usará Anthropic. O Google também fornece alguns dos modelos da Anthropic. E estes são apenas alguns deles. OpenRouter fornece quase todos, provavelmente todos, inclusive com DDR ativado, então você não envia nenhum dado aos fornecedores dos modelos. E também temos nosso próprio núcleo de inference, com inference sem servidor, onde você também pode escolher entre modelos open source. Neste caso, o que eu queria

18:20 testar era o GLM 5.2, que foi o modelo mais recente que testei e também o melhor modelo open source, de pesos abertos. Então, escolhi este para a demonstração. Você poderia escolher qualquer outro, é claro. E agora vem a questão das configurações. Há muitas configurações. Algumas são bem conhecidas, outras talvez nem tanto. O tamanho da context window também é muito importante, porque você sempre vê que este modelo tem este tamanho de context window, mas cada provedor tem… Sim, alguns provedores escolhem oferecer um tamanho

18:52 diferente, menor, por motivos de desempenho. Por exemplo, nossa própria inference também não oferece o milhão completo de tokens do GLM 5.2, apenas 256K, mas assim podemos atendê-lo mais rapidamente, e a qualidade do modelo se deteriora depois de certa quantidade de tokens. Então, basicamente, metade da context window já faz uma diferença muito perceptível. E o problema é que custa muito quando você chega sempre ao

19:22 milhão e depois compacta. Então, pessoalmente, acho que 256K é o ideal; foi por isso que recomendei à nossa equipe de inference que usasse esse valor nessa situação. Também uso o mesmo com Codex. Basicamente, neste momento, isso oferece a melhor qualidade pelo melhor custo-benefício e velocidade. Esforços de pensamento e raciocínio. Esse é um fator importante, e fiz diferentes avaliações com diferentes modos de pensamento. Eles têm um grande efeito no modelo e, às vezes, um efeito muito surpreendente: quando você aumenta o nível de pensamento, o desempenho cai. Mas vou falar

19:54 sobre isso quando chegarmos ao slide. Então, o system prompt. Nem sempre você pode alterar o system prompt ou sequer inspecioná-lo, mas ele é um fator muito importante. E, se pensar em um agent como o Open Law Hermes agent, você tem o arquivo sole MD, onde pode incluir muitas instruções. Agora, imagine que você está usando isso com o benchmark. Se der a instrução “você é um assistente prestativo”, o resultado será bem diferente de dar a instrução de que ele é um agent autônomo que executa tarefas. Já vi resultados em que

20:26 o modelo ou o benchmark apresentou um resultado ruim porque o modelo tentou perguntar ao usuário, mas não havia usuário e ele não sabia disso. Então, se eu alterar o system prompt e disser que ele não pode perguntar ao usuário, ele se comportaria de outra forma e obteria uma pontuação melhor, tenho quase certeza. E isso mudaria completamente o que estou testando. Então, há muitas variáveis aqui. Também há a configuração de ferramentas. Se você der ao agent acesso à web, já vi um modelo pesquisar a solução do benchmark, porque Terminal Bench é um benchmark público.

20:56 E você precisa olhar os traces para ver o que aconteceu. Não é realmente… Nem sequer é algo ruim, se você quer um agent, ele deve ser inteligente. E, se existe uma solução para o problema, por que deveria tentar descobri-la por conta própria, se já há uma solução publicada? Então, depende do que você realmente quer medir e se quer dar esse acesso ou não. E nem todos fazem isso, ou não o fazem sempre. Recursos do sandbox, todas essas coisas. Se você der menos CPU ou memória, pode faltar recursos ou ele pode ficar mais lento, levar mais tempo para fazer algo ou até travar; nesse caso, você obtém

21:27 um resultado ruim. E a culpa não é do modelo, mas da configuração do sandbox. Tempo limite da tarefa: cada tarefa tem um tempo limite. Por padrão, acho que varia de 5 a 15 minutos até mais de 3 horas. Uma dura 3 horas e pouco, e outra, umas 2 horas. Isso significa que você precisa decidir quanto tempo quer investir. Quando comecei com o Wolf Bench, dei a cada tarefa um limite fixo de 2 horas porque não queria basicamente prejudicar os modelos de pesos abertos

21:57 que muitas vezes são executados em endpoints de inference menos potentes do que os grandes modelos de fronteira SOTA dos laboratórios. Então, se você executa o DeepSeek em um sistema local, geralmente ele não é tão rápido quanto o GPT nos sistemas da OpenAI. E isso distorceria a pontuação se você não desse tempo ilimitado. Mas percebi, quando usei 2 horas, que, se o modelo não consegue realizar a tarefa, às vezes ele fica andando em círculos, tentando e tentando e tentando, e falhando e falhando e falhando. Então, ficava muito caro e demorava muito, porque, se eu reservar 2 horas por tarefa e houver 89 tarefas, e eu

22:29 paralelizá-los dependendo do nível de concorrência que estou usando, que é o próximo ponto. Isso leva muito tempo. Leva muito tempo, custa muito e você não obtém resultado, porque simplesmente não consegue executar a tarefa. Então, percebi que uma hora é um bom limite. Se você usar a duração de teste padrão do Terminal Bench, o tempo do teste vai aumentar. Concorrência, era isso que eu queria dizer. Você não quer esperar 8 ou 9 horas, nem o dobro disso. Você quer usar concorrência, para ter vários

22:59 testes acontecendo ao mesmo tempo. Mas então você precisa decidir até que nível pode aumentar. Se eu usar concorrência 89, posso executar todas as 89 tarefas do Terminal Bench de uma vez. Mas, se meu endpoint de inference não for rápido o suficiente e eu sofrer limitação de taxa, vou obter pontuações ruins ou até mesmo nenhuma pontuação no final. O mesmo vale para os sandboxes. Se eu tiver um provedor de sandbox, recebo recursos e, se usar 8 GB por sandbox, isso se acumula rapidamente e talvez você ultrapasse o limite permitido. Política de novas tentativas: com que frequência repetir

23:31 algo. Isso também importa: se eu não repetir uma tarefa e ela falhar porque um sandbox travou, o modelo recebe uma pontuação ruim. Mas não foi culpa do modelo. Então, há erros que você deve tentar novamente e há erros que não deve. Por exemplo, se o modelo causar uma falha por conta própria ao fazer algo estúpido, isso é uma falha que você quer medir. Temperature, as coisas de sempre. Isso é algo difícil para um benchmark, porque que temperature você deve usar? Alguns provedores de modelos informam a temperature recomendada para usar com o modelo deles.

24:02 Outros não. Alguns agents têm um padrão. Alguns agents decidem com base no modelo. E há tantas combinações que você precisa decidir: quer procurar a recomendação para cada modelo? Se não houver uma, qual você usa? Como garantir que as pessoas que estão fazendo o mesmo benchmark usem a mesma configuração que você escolheu? É difícil. E o top P também. Você usa 0,95, usa 1 ou usa qualquer valor? É só uma configuração, e há tantas outras. E o máximo de tokens novos: quantos

24:33 tokens o modelo pode gerar? Você precisa decidir isso, porque há recomendações dos provedores e limitações dos hosts. Você precisa escolher algo e, normalmente, configurar isso. E, se puder, também pode definir uma seed para reduzir a aleatoriedade. Quando comecei a fazer benchmarks, usei temperature zero para haver menos aleatoriedade. Nunca houve ausência total de aleatoriedade. E já vi coisas tão pequenas quanto uma atualização do driver de tráfego alterarem os resultados que obtive. Mesmo quando tudo era determinístico ou parecia ser.

25:05 Porque temos erros de arredondamento de ponto flutuante, otimizações de desempenho e muitos efeitos que alteram o resultado, mesmo que você use temperature zero. E, hoje em dia, quando o modelo recomenda temperature 1, você não deve definir zero, é claro. Caso contrário, estaria contrariando a recomendação. Nesse caso, você poderia definir uma seed, mas, mesmo que escolha uma seed como 42, que é muito popular — você sabe por quê —, a questão é que alguns modelos podem ter mais sorte com essa seed, enquanto outros podem ter menos sorte. São todas escolhas que você precisa fazer.

25:38 Agora, para essa escolha de qual inference queremos usar, à esquerda tenho o núcleo de inference normal com inference serverless. Se quiser acompanhar e usar o OpenRouter, porque não passou pelo processo de obter sua própria chave aqui, também pode usar o OpenRouter. Em ambos os casos, basta usar um arquivo .env e inserir a variável aqui embaixo. Basta inserir a variável, a chave, no arquivo .env, e então vamos usá-la com o agent. Se usar o OpenRouter, você precisa

26:10 definir algumas configurações especiais para usar nosso provedor, o provedor One API. Isso é muito importante se você estiver usando o OpenRouter para fazer o benchmark de um modelo. Há muitos provedores e, por padrão, você recebe um deles. Eles decidem qual é o melhor naquele momento. Então, se você executar uma única rodada do benchmark com 89 tarefas, talvez metade das tarefas use este provedor e a outra metade use outro. Portanto, você definitivamente precisa definir qual quer usar. E, depois de tudo isso, você escolheu uma opção para cada uma das seis camadas pelas quais passamos.

26:42 Escolhemos o Terminal Bench para nossa avaliação, escolhemos o Harbor e uma versão específica dele, escolhemos nossos sandboxes, escolhemos o Terminus 2 como agent, o GLM 5.2 e configurações específicas. Se estiver fazendo uma avaliação, você fará o mesmo. Seja qual for o framework ou o modelo que usar, terá que fazer escolhas e deve deixar muito claro o que está usando. Isso é importante quando você publica seus resultados, para que outras pessoas saibam o que você realmente usou e mediu. Então, aqui está outro código QR. Ele fornece

27:15 a configuração completa, para que você não precise copiar as coisas dos slides. E aqui está uma formatação que ficou um pouco bagunçada. Desculpem. Se você baixar essa configuração, vou mostrar no próximo slide como executá-la, e levará cerca de 5 minutos para obter os resultados neste caso. Também vou fazer o mesmo. Então, se quiser baixar a configuração, aqui está o código QR. E vou para o próximo slide. Deixe-me não apenas mostrar, mas executá-la de fato. Então, deem uma olhada. O que

27:46 estamos fazendo é carregar o arquivo .env para obter a chave de API que encontramos dois slides atrás e, em seguida, executar o comando UV run harbor run config com a configuração que você baixou ou criou. Aí, podemos obter os resultados. Vou fazer isso agora no shell. Primeiro, instalando o framework Harbor. Executando o comando. Vou ampliar um pouco.

28:17 Então, se meu Wi-Fi estiver funcionando como deveria, está tudo certo. Certo. Vamos deixar isso rodando. Volto em um minuto. Enquanto isso, vou continuar a apresentação. Estamos executando a tarefa, e ela fará apenas um teste. Não quis usar 89 testes, senão ficaríamos aqui uma hora a mais. E esse é apenas o tempo que dou para cada teste; depois disso, o verificador precisa executar e conferir se está

28:48 correto. Isso também leva algum tempo, então demora ainda mais. Mas o Harbor busca as tarefas, o conjunto de dados do Terminal Bench 2.0, usando o que está na configuração. Esta é a parte em que a configuração especifica o Terminal Bench versão 2.0. Depois, inicia os sandboxes usando o provedor que estamos usando. Então, cria um sandbox por tarefa, dependendo da concorrência, de quantos usa. Em seguida, executa o agent. Ele entra no sandbox e instala

29:18 o agent e executa a tarefa. Dá a ele um prompt de sistema para o usuário, basicamente dizendo: “É isso que você precisa fazer”. O agent faz a tarefa. Depois, coleta os resultados do sandbox antes que ele seja destruído. E obtém as trajetórias, ou seja, o que o agent está fazendo. Assim, você recebe muitas informações. Esta tarefa pequena é uma das menores: é apenas um repositório Git em que algo foi perdido, e ele deve encontrar isso na árvore do Git e restaurar.

29:49 Isso leva cerca de 3 a 5 minutos. Vamos ver em que ponto estamos. Já foi instalado. Agora instalamos nosso cliente One B. No próximo passo, neste caso, vou apenas pegar minha chave de API no One Password. Depois, vou escrever a configuração aqui. Esta é a que vocês podem baixar. Só estou usando cat para gravá-la em um arquivo.

30:21 E carregando o arquivo .env. Agora, a chave de API está nas minhas variáveis de ambiente, e eu vou… Este é o comando de execução. Executar a avaliação. Agora está começando a se conectar, iniciar os sandboxes, instalar o agent e executá-lo. Tudo isso está acontecendo aqui. Enquanto isso, vou voltar à apresentação. Próxima parte: executar como evidência, não apenas como uma pontuação. A

30:52 A formatação está totalmente bagunçada aqui. Vou corrigir a apresentação e vamos fazer o upload. Este é apenas o diretório do que está na pasta de avaliação. Podemos criar isso ao vivo assim que terminar. Claro, deve levar uns cinco minutos. Agora, está iniciando o ambiente, o que está criando os sandboxes. Então, vou deixar rodando. Ah. Ainda é cedo demais. E, quando tivermos isso, teremos uma tarefa, que será pontuada. Ela ou…

31:24 …recebe uma pontuação de um ou zero. Foi bem-sucedida ou falhou? Se você fizer isso para as 89 tarefas, terá uma quantidade que indica quantas tarefas o modelo realizou. Depois, você repete isso em cinco execuções, por exemplo, e obtém uma porcentagem, que mostra quantos por cento do Terminal Bench o modelo alcançou. E essa costuma ser a pontuação divulgada pelos laboratórios. A maioria das pessoas divulga apenas a média de cinco execuções. E esta é a instalação do Wolf Bench Toolkit. Antes, usamos todo o framework Harbor e o Terminal Bench, e isto é o que eu…

31:54 …programei, o que criei. O Wolf Bench Toolkit é uma forma de trabalhar com esses dados, porque, caso contrário, você fica com alguns arquivos e uma pontuação, mas como faz para analisá-los? Então, isto é um coletor, é o que o Wolf Bench faz, e eu… É melhor eu mostrar quando abrir o programa. Então, vou voltar aqui. Enquanto isso acontece, vou iniciá-lo em um novo shell. E vamos cloná-lo e entrar nele.

32:26 Então, é open source, sob a licença Apache 2. Você pode usar nos seus próprios projetos. Claro, terá que adaptá-lo se estiver usando algo diferente do Terminal Bench, mas hoje em dia é fácil fazer isso. É só pedir ao seu agent. Uma pergunta rápida: quem está usando agents para coisas assim? Nem todo mundo? Ah, estou surpreso. Ainda vejo muitos notebooks, aliás. Porque algumas pessoas agora simplesmente pegam o celular, fazem uma captura de tela e dizem: “Certo, agent, pode começar. Faça o que ele estiver mostrando no palco.”

32:58 No ano que vem. Certo, está baixando, e também estou baixando todos os resultados de todas as execuções que fiz até agora. Então, um pequeno spoiler: fiz 430 execuções até agora. Onde está? Foram 430 execuções. Enfim, estes são os agents que testei até agora: Cloud code, Hermes agent, open clock cursor, Codex. Klein ainda não foi publicado…

33:29 …ainda. Isso está na minha lista, assim como alguns outros agents. Se você está criando um agent, entre em contato comigo se quiser que ele apareça também. E alguns modelos que testei — muitos deles na W&B — foram executados na nossa própria inference. Então, infelizmente, o custo final não foi tão alto quanto aparece aqui, quase 40 mil. Parte disso foi executada na nossa própria inference, mas usei os preços que foram publicados. Vamos ver em que ponto estamos. Terminou o download. Então, os 13 megabytes são os…

34:00 …resultados. Se quiser ver todas as trajetórias, elas foram enviadas para o Weave e você pode inspecioná-las. Você não precisa baixar gigabytes de dados. Agora, se quiser usar o Wolf Bench, pode definir algumas variáveis. Ele também faz uploads, mas vou mostrar isso se eu simplesmente iniciá-lo. Ele usa um notebook Remeo para fornecer um dashboard, uma maneira fácil de lidar com todos os dados de avaliação. Então, deve aparecer a qualquer momento. Aí está.

34:31 Este é um dashboard. Você pode inserir suas informações e indicar onde quer fazer o upload dos traces, caso tenha os dados do We. Depois, pode descobrir VMs se estiver usando XE dev ou Hetzner; ele encontrará todas as suas VMs e você poderá filtrar quais nomes de VM correspondem a VMs de avaliação. Porque normalmente não executo o framework Harbor no meu próprio laptop. Eu o executo em uma VM, para poder desligar o laptop ou evitar que o Wi-Fi caia e a conexão com os sandboxes falhe, pois isso também poderia afetar alguma coisa. Neste caso, tudo é local…

35:03 …assim que eu baixar os arquivos, o que já fiz. Então, posso simplesmente examinar meu diretório local e ele encontrará todos os dados de execução que já produzi. Aqui estão as 443 execuções únicas. Ele mostra um filtro: toda execução que tem uma pontuação é considerada válida. Ela precisa incluir todos os testes. Se alguns testes não tiverem sido executados, não é uma execução válida. Foi apenas uma execução de teste. Também não deve haver muitos erros ou timeouts. Então, recebo uma lista de tudo isso e posso escolher quais modelos quero usar para criar…

35:35 …um gráfico bonito. Neste caso, vou usar todos eles. Você também pode simplesmente mudar os nomes dos modelos e, às vezes, precisa mudar o modo de raciocínio, porque o parâmetro que você fornece pode ser alterado pelo agent. Por exemplo, se estiver usando um nível de raciocínio extra high ou quiser usar um modo de raciocínio max, mas seu agent não for compatível, talvez isso tenha outro nome. Então, você precisa ajustá-lo para que reflita de fato o que foi usado.

36:05 Agora, depois que tudo isso estiver pronto, posso simplesmente criar meu arquivo de resultados. Você pode fazer upload para o Weave, se tiver a chave. Eu não configurei a chave, então, no momento, não tenho o botão. Agora, crio um arquivo para salvar, que é um único arquivo JSON contendo todos os resultados. Você pode compartilhá-lo com outras pessoas. E, por fim, gero um gráfico, que é um artefato que eu crio. Então, com todos os resultados que obtive, gero um novo gráfico. E este é o mesmo que, na próxima etapa, posso enviar usando o uploader que também tenho.

36:36 Depois que o gráfico é gerado, faço o upload para wolfbenchmark.ai, e ele é atualizado. Se eu ativar esta opção para substituir o index.html, ele fica online imediatamente. Voltando à apresentação… Ah, vamos ver como está a execução do benchmark. Ah, terminou. Vejam, terminou. Trials: um; pontuação média: 1.0. Então, havia uma tarefa, e ele resolveu a tarefa. Funcionou. Terminou e corrigiu o repositório Git.

37:07 E agora essa tarefa está no meu diretório, e eu poderia importá-la, mas não é uma execução completa, então não aparece por padrão. Depois que fizermos isso e enviarmos os dados, podemos ver o que o Wolf benchmark oferece. Isso também se relaciona à questão da mentalidade: o que queremos observar? Neste caso, foi isso que acabamos de fazer. Mostrei o dashboard. Agora precisamos analisar o leaderboard e o que ele significa, porque…

37:38 …o leaderboard em si, seja qual for o resultado que ele gera, não é simplesmente uma resposta; ele ajuda você a encontrar uma pergunta melhor. Por exemplo: o que você está analisando? Você se importa com a capacidade de um modelo ou com a confiabilidade dele? Vou mostrar o que isso significa acessando wolfbenchmark.ai. E o caso é que vou diminuir um pouco o tamanho. Então, eles estão ordenados da esquerda para a direita, e tenho todas as informações aqui. A maioria dos benchmarks que você vê simplesmente…

38:10 …mostra a pontuação do Terminal Bench e apenas a média. Esta é uma página interativa, usada não só para exibir resultados, mas também para criar gráficos que você pode copiar e colar em outro lugar. Há um ícone de captura de tela, então posso mostrar coisas no X, por exemplo. Se eu quiser mostrar o desempenho deste modelo, basta selecioná-lo. Posso remover algumas barras ou reordená-las. É interativo, então posso criar meu relatório dessa forma. E ele também inclui isso na URL. Assim, qualquer pessoa pode…

38:42 …ver a mesma coisa que você tinha na tela se você compartilhar a URL. Vou mudar para cá. Às vezes, parece um pouco confuso, porque há muitas informações — muitas informações na mesma barra. Como eu disse, você pode filtrar as informações para deixar a barra mais simples, mas gosto de ver isso porque a parte mais escura, na parte inferior, mostra a porcentagem de todo o benchmark que um modelo resolveu em cada uma das cinco execuções…

39:14 fez. Então, é isso que chamo de consistência. Esse modelo e esse agent resolveram a tarefa em 60% de todo o benchmark em todas as vezes. Isso significa que, se essa for uma pontuação muito alta, o modelo é muito confiável, porque, se resolve a tarefa, você pode esperar que a resolva sempre. Já a pontuação amarela é a média, a pontuação que costuma ser informada. As setas para cima e para baixo ao redor dela indicam as melhores e as piores pontuações em uma das cinco execuções. Então, se estiverem muito próximas umas das outras, isso significa que há

39:45 pouca variância. Assim, você pode esperar a mesma pontuação. Se estiverem muito distantes, como vemos aqui, de 79% a 60%, isso significa que há muita variância. E isso é um sinal de que há muita aleatoriedade envolvida na resposta do modelo. Não dá para confiar muito que ele execute a tarefa. Mesmo que tenha uma pontuação alta, é um pouco aleatório se ele consegue ou não. E a marca mais alta é a estrela; ela indica o teto. Qual porcentagem do benchmark ele conseguiu resolver, pelo menos uma vez? A quantidade de tarefas mostra quanto

40:18 Sim, em um caso ideal, essa seria a pontuação que o modelo deveria obter sempre, se fosse perfeito e executasse a tarefa corretamente todas as vezes. Embora isso também fosse um indício de que ele provavelmente foi ajustado para esse benchmark. Mas isso mostra até onde ele pode chegar. Então, o que você quer é um teto muito, muito alto, uma média bem estável e uma base sólida muito alta. E, se dois modelos têm a mesma pontuação e elas são quase iguais, ainda dá para ver que a base sólida é diferente. Nesse caso, eu escolheria o que tem uma base sólida mais alta

40:49 . Como aqui: 73% contra 74%. É quase a mesma coisa. Se você olhar apenas a pontuação média, é praticamente igual. Pode ser uma questão de variância, só variância. Mas aqui a diferença é maior: são 6 pontos percentuais, uma diferença perceptível. Então, você vê que o nível de pensamento extra é melhor do que o nível médio, como esperávamos. Mas, se estivermos olhando para… Isso também é muito interessante. Vou mostrar na apresentação. Deixe-me mudar para a apresentação.

41:20 Então, essas eram as diferentes maneiras de visualizar o modelo. Ah, tolerância a risco e custo. Preciso mostrar isso porque é algo… Se você olhar para o segundo melhor modelo na minha avaliação, foi o Gemini 3.5 Flash. Esse modelo Flash é quase tão bom quanto o GPT 5.5. Então, como assim? Se eu olhar apenas para o Terminus, para não termos tantas barras, também posso dizer que quero comparar apenas esses dois. E, sim, o Gemini 3.5 Flash é um ótimo modelo. Mas, se eu olhar como ele conseguiu esse resultado, tenho uma visualização 3D que

41:52 mostra quantos tokens ele usou para chegar a essa pontuação. Foram bilhões de tokens para obter esse resultado, enquanto o GPT 5.5 usou muito menos. Deixe-me ampliar. Foram 136 milhões de tokens para o GPT 5.5, comparados a 1,65 bilhão de tokens para o Gemini 3.5 Flash. E o que acontece é que, se também olharmos para o preço, que é outra visualização 3D, temos o custo. E posso até mostrar os dois ao

42:23 mesmo tempo. Agora, o custo aparece como uma sombra. Você vê o custo aqui. Ele está sobreposto porque o modelo usou muitos tokens, mas isso mostra que o Gemini 3.5 Flash está muito próximo do GPT 5.5, só que usou tantos tokens que, é claro, custou ainda mais do que o GPT 5.5. Nesse caso, custou US$ 620, comparados a US$ 497. Então, de US$ 500 para mais de US$ 600. Portanto, não é que você… Sim, precisa pensar nisso. Você quer usar um modelo rápido e barato?

42:54 Mas você precisa comparar: ele é mesmo mais rápido e mais barato? Porque todos esses tokens também levam tempo. Essa é uma coisa. Voltando à apresentação: isso é uma superfície de decisão, não apenas um gráfico. Você carrega seu snapshot e pode adicionar o seu próprio, se tiver executado a avaliação; quando executar o código, ele aparecerá. Depois, pode filtrar as diferentes métricas e os modelos, como mostrei. Pode reordenar as barras e exportar a sua própria visualização. E então pode mostrá-la e fazer uma publicação nas redes sociais

43:25 sobre isso ou escrever um artigo, o que quiser. Você pode fazer isso. Neste caso, eu estava analisando qual é o melhor modelo nesse benchmark. Então, meu número um agora é o GPT 5.5 com Codex. Ele é ainda melhor que o Fable. Se você está se perguntando o que aconteceu com o Fable, também é muito interessante dar uma olhada. Se eu incluir o Fable aqui, ele teve 13 recusas. Ou seja, recusou. E, se você olhar para o custo, ele foi muito alto. Foi meu benchmark mais caro.

43:56 Não conte a ninguém, porque custou US$ 11.000 só para testar o Fable, e ele falhou porque recusou muitos testes. Opa. E isso também é algo que você precisa decidir. É aí que as pessoas dizem: “Ah, não confio nesse benchmark; esse modelo está em primeiro lugar.” Olhe o que aconteceu aqui. O benchmark precisa ser transparente para que você possa examinar os traces e ver o que aconteceu. Aí, de repente, tudo faz sentido. Certo. Voltando, como eu disse, o melhor modelo foi o Codex com GPT 5.5, mas, como você

44:29 pode ver, foi bem caro. Vamos ampliar. Custou quase mil dólares. Já o Cursor com o mesmo modelo custou apenas US$ 282. Foi bem barato em comparação com o outro, e usou um pouco menos de tokens. Mas, sim, você poderia dizer: “Certo, esta é a melhor combinação”, embora talvez a outra seja melhor em termos de preço e desempenho.

44:59 E o Terminus também teve o teto mais alto, mas, se as pontuações estiverem muito próximas, isso pode ser aleatório. Você teria que fazer 10 execuções ou até mais para ter bastante certeza, mas em algum momento precisa escolher e seguir com uma opção. Essa também foi a comparação que acabei de mostrar: Gemini 3.5 Flash contra GPT 5.5, com pontuação mais baixa e uma conta maior. Nesse caso, faria mais sentido usar o outro modelo. E isso também foi muito interessante e

45:29 me surpreendeu bastante quando testei o Opus 4.6. Na época, aumentei o nível de pensamento para o máximo, e a pontuação caiu. Ele realmente piorou. Fiz a mesma coisa com o Claude Code, porque também usei o Titanus, e vi o mesmo efeito. Quando faço isso com o GPT, se aumento de pensamento desligado para extra alto, ou de médio para extra alto, o modelo fica mais inteligente, como seria de esperar. Então, por que o desempenho do Opus piorou? Isso me surpreendeu. E a diferença, se… Se você olhar para os

46:00 traces, vai ver que o modelo pensa demais. Ele fica pensando em excesso. Isso significa que eu dou uma hora para ele. Se o modelo pensa por um ou dois minutos e depois decide executar um comando, mas esse comando ainda não existe na máquina, ele passa mais dois ou três minutos pensando: “Como instalo isso?”. Enquanto isso, um agent que nem sequer está pensando fica simplesmente fazendo as coisas. O primeiro impulso é: executo este comando, recebo uma mensagem de erro; executo este comando, recebo uma mensagem de erro; instalo, recebo uma mensagem de erro e corrijo. E ele ganha mais turnos. Assim, consegue fazer mais. Essa

46:32 é a diferença entre pensar por uma hora sem fazer nada e simplesmente tentar, tentar e tentar, por tentativa e erro. E o interessante é que, por padrão, os modelos GPT não pareciam tão inteligentes quanto o Opus. O Opus é muito capaz desde o início. Mesmo com o pensamento desligado, já obteve uma ótima pontuação. Se você comparar aqui, com o pensamento desligado ele já foi melhor do que o nível médio do GPT 5.5. E até a base sólida foi mais alta. Então, ele realizou mais tarefas em todas as execuções.

47:04 Sim. Então, são coisas que você precisa observar. E, se algo for surpreendente, examine os traces para descobrir o que está acontecendo. O modelo está pensando demais. Também vi o mesmo acontecer com Fable, aliás, em que o modelo era muito inteligente e parecia saber que era tão inteligente. Então, o que ele fez foi decidir seguir nesta direção. E, mesmo que o benchmark dissesse que deveria ser feito daquela maneira, ele dizia: “Não, eu sei melhor. Vou fazer do meu jeito.” Aí, no final, o verificador executou os testes, e o modelo falhou. Então, em alguns casos, o modelo era inteligente demais para o próprio bem.

47:36 E este também é um recurso importante que preciso mostrar a vocês. A barra é uma afirmação; o trace é uma evidência. Estou falando de traces o tempo todo. Temos as barras, que é o que vemos no Wolf Bench. As barras são bem legais. E o interessante é que você pode clicar em qualquer uma delas. Basta clicar. E você será levado à nossa página One, onde temos o Weave, que permite inspecionar todos os traces. Neste caso, cliquei em uma barra e estou vendo as cinco execuções que compuseram aquela pontuação.

48:07 Agora posso escolher qualquer uma das execuções, entrar aqui — e isto eu deveria remover. Vou mostrar isso mais tarde. Saia daí. Então, temos 89 itens. São as 89 tarefas que venho fazendo, e vocês podem ver todos os traces aqui. São muitos, então está carregando um pouco. Depois, você pode abrir qualquer um deles e ver o nome da tarefa, a recompensa, se teve sucesso ou não, e todas as etapas. Você vê a

48:38 solicitação inicial, a mensagem do usuário que diz: “Você é um assistente. Sua tarefa é fazer isto.” Depois, você vê o que o LLM fez como primeiro comando, que análise fez e o que pretende fazer; em seguida, o comando que envia, e assim por diante. Você pode inspecionar de verdade tudo o que aconteceu e analisar. Ou usar seu agent e pedir que ele faça isso. Temos um novo recurso, que também é um agent integrado à plataforma. Então, você tem um agent dentro do Weave e pode simplesmente pedir que ele faça isso. Meu

49:09 colega Tim Sweeney vai falar sobre isso no dia 1º de julho. Vocês podem conferir. Uso agents com frequência, porque ler todos os traces demora muito. E, se o agent der um link do Weave e você verificar que o que ele diz é verdade, isso também é muito bom. Então, recapitulando: há muitas variáveis relevantes para os benchmarks. Há a versão do benchmark, o OneBench 2.0, 2.1, a versão do agent, o serviço e a rota do modelo; até atualizações no endpoint de inference podem mudar os resultados e as configurações.

49:39 Recursos do sandbox: como eu disse, se o agent ficar sem recursos, vai falhar, e aí o modelo recebe uma pontuação ruim, embora a culpa não tenha sido dele. Amostragem, temperatura, tudo o que discutimos. Configurações padrão de raciocínio, como não aumentar o máximo quando ele demora muito para pensar; um agent menor e mais rápido pode funcionar melhor. Política de tempo limite, política de novas tentativas. Se você não tentar de novo e tiver ocorrido um erro de infraestrutura, receberá uma pontuação ruim. Então, depois de cada execução, reviso todos os erros e falhas e verifico se houve problemas de inference.

50:10 Você pode descobrir isso se houver caracteres repetidos ou se tokens do template de prompt vazarem para a resposta propriamente dita; aí você sabe que há um problema com o tokenizer ou com o servidor de inference. E isso é especialmente importante com modelos novos. Se você faz benchmark de modelos assim que são lançados, eles são tão novos que talvez o mecanismo de inference ainda não tenha o melhor suporte. Já fiz avaliações em que o modelo novo não era lá essas coisas. Uma semana depois, fiz a mesma avaliação, com tudo igual, e ele teve um desempenho melhor porque o mecanismo de inference havia

50:41 sido aprimorado. Isso também faz parte do processo. Então, sigam a mensagem: tragam tudo de vocês. Vocês têm os blocos de construção; confiram a apresentação e pensem no que querem fazer, em qual avaliação usar, qual agent usar e qual modelo testar. Agora vocês têm a mentalidade necessária para saber o que observar e aplicar isso para criar leaderboards, gráficos e avaliações mais confiáveis do que simplesmente executar algo e publicar uma pontuação. Portanto, executem suas próprias configurações reproduzíveis de benchmark. Compartilhem os resultados.

51:12 Se quiserem trabalhar com o Wolf Bench, entrem em contato comigo. Se quiserem executar alguns modelos, seria ótimo. Poderíamos colaborar e publicar os resultados, assim não preciso executar tudo. E, se quiserem criar uma derivação, também será ótimo. Usem outro framework, o que quiserem. E, se estiverem desenvolvendo modelos ou agents, fiquem à vontade para entrar em contato comigo para que eu possa avaliá-los com benchmark. Já trabalho com alguns criadores de agents e publicarei os resultados em breve. Sim, basicamente é isso para a apresentação. Espero que tenham conseguido

51:42 tirar algo dela. E, se tiverem perguntas, esta é a hora. Caso contrário, podem me encontrar no estande. E um grande agradecimento ao Alex pela ajuda. O podcast Thursday I é toda quinta-feira, de manhã, no fuso horário de onde estou — um fuso horário diferente. Às 8h30, horário do Pacífico. Toda semana, porque é muito difícil acompanhar o que está acontecendo, e também é difícil para nós; então somos obrigados a fazer isso para poder informar vocês. Certo, obrigado.

52:27 >> [música]

Transcrição original

[00:12] Before we get started, if you want to follow along, though this is a practical workshop, so I see a lot of notebooks out there, great. Um if you if you want to follow along exactly as I’m going, you should have a wand B account or weights and biases account. If you don’t have one, you can register and get a free one. And we also give you inference credits, so you can do an evaluation that way, and sandbox access is also included. And um if you want to use something else like like open router, you can do that as well. Or even a different provider,

[00:43] whatever you want to use. I will just use this as the example in the workshop. And if you have an AI agent, you can just tell it change something and make it work with my setup. So, let’s go. Quick about me. I’m Wolfram Reimann Oh. And my slogan is I have evaluate models for breakfast, build agents at night, and preach AI all day long. I do that as an AI evangelist at Corvus and weights and biases. And um I’m also a co-host on Thursday AI, the podcast.

[01:15] Alex is also here. He’s a the main guy. And if you have technical issues during the workshop, you can contact him. He will help you out so we don’t get interrupted. But he’s your man. Thanks, Alex, for the help. And yeah, you can follow me on X or LinkedIn, and Wolf Benches wolfbench.ai. Easy to remember. Um but this workshop isn’t just about Wolf Bench. It’s why and how I built it, so you can stand up your own model and agent evil from zero to leaderboard. Um yeah, my backstory basically I

[01:47] started as a little child loved AI from the beginning. Then when ChatGPT happened, I decided I want to focus my career on this. Um if anyone knows the old good old times in local llama when the block was quantizing models, I was testing the models or I started that way. Was asked a lot about helping with inference and stuff. So, I became a consultant. And yeah, last year I went full in in a German AI startup and this year I joined Qorvo.

[02:17] And I’ve been on the podcast for a long time, right Alex? So, but this is about you. So, the workshop, who you are and why you are here. I think there are different kinds of people and I’m interested in which category you think you belong to. So, for instance, the agent builders. Are people building agents here that want to evaluate their agents? Someone here, someone here, a couple. And evil newcomers. Any people who want to do meaningful evaluations but have no

[02:47] idea what they are doing yet and want to learn this? Okay, those are more. And model evaluators. Who is interested in which model and agent should I trust? Which is the one I want to use? Anyone interested in that specifically? Over there and over there. Great. Platform and evil leads. The people who want to do comparable and reproducible evaluations. Someone here. A couple here. Great. Trace debuggers. Those are the people who are looking at the actual traces and trying to find out what went wrong and how to improve this.

[03:18] Over here. Great. And skeptics. Who does not trust the leaderboards? I mean No, every hand should go up, right? >> [laughter] >> But why is that and how can we change that? And that is part of what we are talking about and how you can build your own. But first, my my guiding principles are mindset is greater than skill set greater than tool set. So, the tool set is what we are using and that changes in AI changes almost every week, every month. Something new comes out and it changes all the time.

[03:50] So, skill set is how we are using tools that we have. That applies to different tools. So, if you have a great skill, uh, you know how to use the tools, you can switch to other tools. But, the mindset is the most important thing because that is the hardest to change or to improve. And for evaluation specifically, that is why we benchmark and what to watch out for. And skill set is just how to use the tools. And tool sets, I will show you a couple of tool sets and you can build your own that way like I did with Wolf Bench.

[04:20] And the premise is one score is not enough because performance is a distribution, not a point. The thing I disliked about the leaderboards and a lot of evaluations I have seen is you see some nice bars and you see some numbers and it’s an average, an aggregate, and it doesn’t really tell you very much. And that’s why people always say or often say, “I don’t trust this and I have a different experience.” And there are things hidden behind the numbers that we can find out and look at. Because

[04:50] is it a really a good model? Did it have a lucky run? What are the hidden trade-offs? Stuff like that. And that’s why I built Wolf Bench because I wanted to know which models can I use with which agents. The agent changed over time. In January, it was Open Claw. In February, it was Hermes Agent. And uh, I’m using a lot of Codex now. It was Cloud Code before. And I still want to know which models work the best with which settings. And yeah, like I said, most evaluation results collapse into just one score. And most leaderboards rank the models.

[05:20] You don’t even see the agentic systems behind it. Or yeah, different versions, settings, even if you even see what uh, settings they have used for this. And they vary a lot, so you see some scores and somebody else reports the same benchmark, but they use different settings. So, can you really compare them? And is there a way to inspect the results to those people got? So, Wolf Bench is a framework. It has charts, dashboards, leaderboard. It’s open source, by the way, and there’s also methodology, and that is what I want to talk about most. So, you can use that

[05:52] methodology with your own tools. And for WolfBench, one thing that is that is applicable to all the benchmarks is you have to decide which metrics are interested to you. Do you want to look at an average? Do you want to look at the worst and best scores? Do you want to look at how many percent of the benchmarks it can solve at all? And how much does it consistently and also cost. That is also something that not everybody takes into account. How many tokens has it burned? How much did it cost? And it can happen that a

[06:23] cheaper and faster model takes longer and costs more than one of the bigger models because it just used so many tokens. Also very important are uniform conditions. So, you have the same setup every time because if you change just the variable, one of the many that are there, and we will look at a bunch of those, if you change it, it is basically a new benchmark now. And also multi-agent, if you want to do different agents, which ones do you look at? And always do multiple runs. A single run is benchmark lottery. It is a random result, and it is just a ballpark

[06:55] number. So, you have to do multiple runs. I do five with WolfBench, but you could do more if you have the money, of course. It’s always a trade-off. Uh transparency is also super important to me because I publish all the results, and people can look at that. So, I don’t just show a score and say this is why this is my number one model, number two model. I upload everything and you can inspect it and check it out, and have your agent check it out, which makes a lot of sense with all the data we’ve collected. So, basically get the thinking right, and then the tools become

[07:25] interchangeable. And the most important thing I I think that people need to realize is you’re not ranking a model. If you’re benchmarking a model, it’s this model, but you are actually benchmarking a specific configuration. So, you use a data set, and if you change the data set, it’s a new benchmark. You have the model, and behind the model you have the inference engine and whatever is happening on the endpoint that you often can’t control. But if they do an update for the inference software, it can change the results again and you you have no way to actually see that. Unless it’s your own inference on your own system. Agent orange. Also the agent

[07:58] orange, if I test blood code or code X, it is a different version if I test it next week and I do the update. So that is also important to keep in mind. And same thing with the sandbox. Even if you are using a sandbox provider and they change something in their back end, you may not even notice and it could have an effect and all the settings you choose yourself. So change any part and it’s a different experiment. You have to keep that in mind. Um okay, here’s a glossary. You will get the presentation, so I’m not going through all of this. Most of you are

[08:28] very familiar with this and I will explain whatever is needed at the moment. So we are looking at a specific tool set because it’s a practical workshop and this is one way to build it, not the only way and will show you the different ways and you can pick your own stuff. So to follow along, you should have your laptop and your terminal, Python, UV and Git are recommended. We have files to download, so if you are not following, you can download the results and import them and use the tool set anyway. So you don’t have to follow along everything, but if you want to,

[08:59] you can do it and use your own results that way. Um yeah, you should have the Wi-Fi and an API key is optional. I showed it in the beginning. I’ll show it in a minute again. So you can get this. So here again, take a screenshot. Scan the QR code. This is where you can get you get to a form where you can get free inference credits for the duration of the AI engineer conference and to do that you need a free One B account. There you can sign up if you don’t have already. If you don’t already have one. Who has an account already?

[09:30] Does anyone here use One B? Bunch of people. Great. Okay, and also the sandboxes, I’m using the core weave serverless sandboxes in your offering where you have an isolated box for each task, which is super important because otherwise you would change your own system with every evaluation run and then it would be even more random. Okay, we are looking at six swappable layers and we’ll choose each one and you can do the same. So this is the skill set how to do it and the mindset in the

[10:01] background and now we choose the different tools for this toolkit that we are building. So we need a benchmark, which is a data set. We need an evaluation harness to run the data set and the evaluation and yeah, to orchestrate all of this and to run it in sandboxes so it doesn’t run on your system. And also we need an agent harness. What which agent do we want to use? And the model and service. That is of course usually the thing that people are most interested in. How does this model do? And the thing is you are not just using

[10:33] a model, you’re always using an endpoint. It’s always on a provider if it’s open router, they are routing to other providers. They are a lot and if it’s open AI or Google or XAI or whatever it is, they have their own setup and you are also evaluating that in a way. And all the settings you can choose. So the first thing is which benchmark do we use? You can start with the benchmark. I did it that way because I wanted to test agentic use with different harnesses so I decided I want a benchmark that does that. So I looked at all the benchmarks that have been

[11:04] used by the frontier labs and I saw terminal bench was on pretty much everyone. And it’s an agentic benchmark. It’s not a coding benchmark, not just it’s a agentic benchmark where there are tasks like like fix the git repository, crack a password, repair a database, stuff you would ask your agent in normal use as an example. And that’s why I picked terminal bench. But you could if you are interested in multilingual stuff, MMLU is one thing. or if you are interested in multimodal stuff, MMU Pro is something. If you are

[11:36] used interested in GUI agent use, then you would book pick a different benchmark. If you are interested in mathematics, coding, whatever it is, there’s a benchmark for it and the thing is find the benchmark that is yeah, most interesting to you and that is comparable. You could also make your own, of course. You can make your own data set. And regarding Terminal Bench, that is a gentic, so that’s why I chose it to benchmark agents. There are versions 2.0 and 2.1 and 3.0 is in the making right now. I chose 2.0 because 2.1 wasn’t

[12:08] available when I started. If you are starting now, choose the latest version 2.1, but I’m using 2.0 because choosing a new version would be a new benchmark and I could not compare the scores anymore. It actually fixes only 28 of the 89 tests, but it would be a different benchmark for all the models. I would have to retest everything I already did. And I did a lot and never enough, but I did a lot, so I don’t want to make a new version of Wolf Bench right now. I will do that at a later point, maybe with 3.0

[12:39] or if a big new jump in capabilities happens and we need a different benchmark. Evaluation harness. This is you have chosen which benchmark you want to use, which data set to use. Now you need something to actually run the evaluation and Harbor is a default framework that is for Terminal Bench. There are others. Inspector is a great framework by the UK AI Security Institute, which has a lot of different benchmarks you can use. It’s also very popular. The LM Evaluation harness, I used that years ago, so it’s been around forever

[13:10] and OpenAI has their own eval stuff. You can build your own runner or one of the others. You pick what you want. Some people can also Some people start with picking their runner and then they pick one of the benchmarks it supports. That is also a valid way. And now for the first practical step, let’s install Harbor. In this case, I’m using the current version. It was current yesterday. I’m not sure if it’s current right now. It changes a lot, but I pin it to the to the version, and I highly recommend people stick to one version

[13:41] because anytime you change one of the variables, if it has an effect on the evaluation, and many have, then, yeah, you are changing already a variable, and the comparison comparability is suffering. Even if it has a bug, you are at least testing all the models with the same bug. But, it’s a visual thinking, of course, because sometimes you have to update if a new version of the harness of the evaluation harness supports a different agent or provider, then you may be forced to update. What I recommend for the people who are really serious about this, fork the repository,

[14:12] maintain your own fork, and just backport whatever you need. And if you install it, this is There’s a line break missing. It’s UV tool install Harbor. So, it’s installing in a UV environment, so it doesn’t affect your system, and you can cleanly uninstall it again. Then, you should have this version. The next step, agents need a sandbox because if you just run it locally on your own system, then second agent running, it would find a system that has already been changed, and it would interfere with your system, so I would

[14:43] not recommend that. You can use Docker. That is very common, but it’s very hard to parallelize that depending on what system you are using. So, you need a lot of resources. So, that’s why there are cloud providers, and I have to give a big shout out to Daytona. They supported me in the beginning before Qualif had their own sandboxes, and I wanted to start with this. So, they really supported me a lot, and I have done a lot of the evaluations I have with Daytona. Now, we have our own offering, so I’m dogfooding it, and um that’s why there are two options here

[15:14] that I recommend. The Qualif sandboxes are for those using the Kubernetes service, and the the golden one here is the Qualif serverless sandboxes. You just need your Vent B account. >> What about the Ah, okay. We also have a Um, I Can you uh I I turned off Slack, so it’s not shared here. If anyone wants to get the PDF right away, just go to Alex. This is probably the easiest way right now.

[15:44] Um, okay. So, after you’ve installed this, uh Harbor is installed. Now, we need a sandbox client that is part of Harbor. And in this case, there’s a part of a couple of things. Here’s the QR code for the presentation. Yeah. Good. Um, UV tool install Harbor in square brackets won’t be installs the provider to use the sandboxes, and you

[16:16] don’t have to do anything. Once it’s installed, you just have to have your API key. And you configure this in a YAML file, and here’s just the next step. You don’t have to copy this. There is a link and an easy URL you can just enter with the full configuration a couple of slides ahead. So, just so you This is just so you see it. But, if you are following along, you should just type the UV tool install command to install the Harbor won’t be provider if you are using this.

[16:46] Let’s continue. Next step, agent. This is the most fun part for me because there are so many agents, and I want to test how does this agent do with this model? And here’s a list of some of the agents. These are all the agents, and there are even more that are supported by the Harbor framework. So, we have Cursor, we have Claude, we have Klein, we have Codex, Open Claude Hermes agent, um, and Terminus 2 is the default agent for the terminal bench and Harbor framework. And this is not a real agent. You can’t

[17:19] use it for your coding stuff, or you shouldn’t. It’s more like simulating CLI environment to the actual model, and it sends keystrokes, and the agent executes them. It’s one way to do this. So, in simple agent, which is a default if you are seeing Terminal Bench scores somewhere, and nobody said it’s tested with a different agent, that is the agent they used. And then, which model do you want to test? You have to pick a model, and you have to pick a provider. If you are just using GPT 5.5, you will be using OpenAI.

[17:49] If you are using Claude, Fable, lucky if you are to use it, then you will be using Anthropic. Also, Google also provides some of the Anthropic models. And these are the just some of those. OpenRouter provides almost all of them, probably all of them, even with DDR enabled, so you are not sending any data to the model vendors. And we also have our own inference core, with serverless inference, where you also get selection of open-source models. And in this case, what I wanted

[18:20] to test is GLM 5.2, which was the latest model I tested, and also the best open-source model, open-weights model. So, I just picked this for the demonstration. You could choose any other, of course. And now the thing is the settings. There are a lot of settings. Some are very familiar to people, some maybe not as much. So, the context window size is also very important, because you always see this model has this context window size, but every provider has the Yeah, some providers choose to deliver a

[18:52] different size, a smaller size, for performance performance reasons. Like our own inference also doesn’t offer the full 1 million of G GLM 5.2, only 256K, but that way we can serve it faster, and the quality of the model de- degrades after a certain amount of tokens. So, basically, half context is already very um very much noticeable. And the thing is it costs a lot if you always go to the

[19:22] million and then you compact. So, I personally think 256K, that’s why I recommended it to our inference team to use this in that situation. Um I also use the same with Codex. Um basically, right now that gives you the best quality at the best price performance and speed. Thinking and reasoning efforts. This is a big factor and I have done different evaluations with different thinking modes and they really have a big effect on the model and sometimes a very surprising effect where if you raise the thinking, it goes down, but I will tell

[19:54] about this when we get to the slide. So, system prompt. You don’t always have the ability to change the system prompt or even inspect it, but it is a very important factor. And if you think about an agent like Open Law Hermes agent, you have the sole MD where and put a lot of instructions. And now imagine you are using this with the benchmark. And if you give the instruction you are helpful assistant, it will be very different if you give it an instruction it is an autonomous agent doing stuff. I have seen results where

[20:26] the model or the benchmark delivered a bad result because the model tried to ask the user, but there was no user and it didn’t know. So, if I change the system prompt and tell it you can’t ask the user, it would behave differently and it would get a better score, I’m pretty sure. And that would be completely changing what I’m testing. So, there are so many variables here. Also, tool config. If you give the agent web access, I’ve seen where a model went out and looked up the solution for the benchmark because Terminal Bench is a public benchmark.

[20:56] And you have to look in the traces to see what happened here. It It’s not really It’s not even a bad thing if you want an agent, it should be smart. And if there’s a solution for the problem, why should it try to think of it if it there is a published solution? So, it depends what you really want to measure and if you want to give it access or not. And not all of those do that. Or not every time. Sandbox resources, all the thing. If you give it less CPU or memory, it may run out or it be maybe slower, so it takes longer to do something or even crash and then you get

[21:27] a bad result. And it’s not the model’s fault, it’s because of the sandbox configuration. Task timeout, every task gets a timeout. By default, they range from I think 5 minutes 15 minutes to over 3 hours. One is 3 hours something and another one is 2 hours or so. And that means you have to decide how much time you want to invest. When I started with Wolf Bench, I gave every task a fixed 2 hours because I didn’t want to basically handicap open weights models

[21:57] which are often running on less powerful inference endpoints than the big SOTA frontier lab models. So, if you are running DeepSeek on a local system, it’s usually not as fast as GPT on OpenAI systems. And that would skew the score if you don’t give it unlimited time. But I noticed when I was going with 2 hours that if the model can’t do the task, it sometimes just goes in circles and tries and tries and tries and fails and fails and fails. So, it was very expensive and took a long time because if I do 2 hours per task and there are 89 tasks and I

[22:29] parallelize them depending on how much concurrency I’m using, which is the next point, it takes so long. It takes so long and it costs so much and you don’t get a result because it just can’t do the task. So, I noticed 1 hour is a good mark. If you use the default terminal bench the test duration will rise. Concurrency, that is what I meant. You don’t want to wait 98 89 hours or even twice the amount of time. You want to do concurrency, so you have multiple

[22:59] trials happening at the same time. But then you have to decide how high can I go? If If I go concurrency 89, I can do all the 89 tasks of terminal bench at once. But, if my inference endpoint is not fast enough and I get rate limited, then I will get bad scores or even no scores at the the end. The same with the sandboxes. If I have sandbox provider, I get resources and if I use 8 GB per sandbox, yeah, it sums up quickly and maybe you get over the limit you are allowed. Retry policy, how often to retry

[23:31] something. That is also something if I don’t retry a task and it fails because a sandbox crashed, I get a bad score for the model. But, it wasn’t the model’s fault. So, if there are errors that you should retry and there are errors you should not retry. Like if the model causes a crash on its own by doing something stupid, that is actually a fail you want to measure. Temperature, the usual stuff. Um that is a difficult thing for a benchmark because which temperature do you use? Some model providers they give you the recommended temperature to use with their model.

[24:02] Some don’t. And some agents have a default. Some agents decide based on the model. And there are so many combinations that you have to decide, do you want to look for every model what is the recommended one? If there is none, which do you use? How do you make sure that people who are doing the same benchmark are using the same setting you chose? It’s difficult. And top P as well. Do you use 0.95 or do you use one or do you any value? It’s just one setting and there are so many others. And max new tokens, how

[24:33] many tokens is the model allowed to generate? You have to decide on this because there are recommendations by the providers, there are limitations by the by the the hosters. You have to choose something and usually you have to configure it. And if you can, you can also set a seed so the randomness is reduced. We I when I started benchmark, I used temperature zero so there was less randomness. There was never no randomness. And I’ve seen things as small as a traffic driver update to change the actual results I got. Even if everything was uh deterministic or looked like that.

[25:05] Because we have floating point rounding errors, we have performance optimization, so many effects that change the result even if you use a temperature zero. And nowadays, when the model is recommending temperature one, then you should not set zero, of course. Otherwise, you would be going against the recommendation. In that case, you could set a seed, but even if you choose a seed like 42, it’s very popular. You know why. And the thing is, some model may be more have more luck with that seed than others have less luck with that seed. It’s all choices you have to make.

[25:38] Now, for this choice, which inference we want to use, I have on the left side the normal inference core with serverless inference. If you want to follow along and you want to use open router because you don’t didn’t go through the getting your own key here, you could use open router as well. In either case, you just use an end file and put in the variable at the bottom here. You just put the variable, the key in the end file, and then we will use that with the agent. Um if you use open router, you have to

[26:10] set some special settings to use our provider, the One API provider. This is very important if you are using open router and benchmarking a model. There are so many providers, and by default, you get one of these. They decide which is the best at the moment. So, if you are running a single benchmark run 89 tasks, you may get half the task with this provider and half the task with the other provider. So, you definitely have to set which one you want to use. And after all this, you have chosen one part for each of the six layers we went

[26:42] through. We have chosen Terminal Bench for our evaluation, we have chosen Harbor and a specific version of that, we have chosen our sandboxes, we have chosen Terminus 2 as the agent. GLM 5.2 and we have specific settings. If you are doing evaluation, you will do the same. Whatever framework you use, whatever model you use, you have to make choices and you should be very clear what you are using. This is important when you are publishing your results, so others know what you have actually used and measured. So, here is another QR code. This gives

[27:15] you the full configuration, so you don’t have to copy stuff from the slides and here’s a formatting that has been messed up a little. Excuse this. Um If you download this configuration, I will show you in the next slide how to run it and it will take about 5 minutes to actually get the results in this case. And I will also do the same. So, if you want to download the config, here’s the QR code. And I will go to the next one. So, let me just not just show it, but actually run it. So, take a look at this. What we

[27:46] are doing, we are sourcing the end file to get the API key we find two slides back and then we are running it with the UV run harbor run config command and giving it the configuration you downloaded or created and then we can actually get the results. I will do this right now in the shell. So, the first thing, installing the harbor framework. Executing the command. I will zoom in a bit.

[28:17] So, if my Wi-Fi is working the way it should, it’s full. Okay. We are letting this run. I will go back in a minute. So, continuing with the presentation. So, we are running the thing and it will do just one test. I didn’t want to use 89 tests for this, otherwise we would be sitting an hour overtime. And that is only the time I give every test, so afterwards the verifier has to run and check if it’s

[28:48] correct. That takes also some time, so it takes even longer. But, um Harbor pulls the tasks, the Terminal Bench 2.0 data set, it uses that from the configuration. So, this is the part where it has Terminal Bench version 2.0 in the config. Then, it starts the sandboxes using a provider we are using. So, it creates a sandbox per task, depending on the concurrency, how many it uses. Then, it runs the agent. It actually goes in the sandbox, installs

[29:18] the agent, and executes the task. Give it Give it a system user prompt, basically, saying here, “That is what you have to do.” The agent does it. And afterwards, it collects the results from the sandbox before it is destroyed. And it gets the trajectories, really, what is the agent doing? You get a lot of information that way. And this small task, it’s one of the smallest, it’s just a Git repository where something has been lost, and it should be find it in the Git tree and restore it.

[29:49] This takes about 3 to 5 minutes. Let’s see how far we are here. It’s installed now. Then, we install our One B client. And the next step, in this case, I’m just getting my API key from the One Password. And then, I’m writing the configuration here. This is the one you can download. I’m just catting it into a file.

[30:21] And loading the end file. Now, the API key is in my environment variables, and I will just This is the run command. Run the evaluation. So, now it’s starting to go out, starts the sandboxes, install the agent, run it. And this is all happening here. And while it’s doing that, I will go back to the presentation. Next part. Run as evidence, not only a score. The

[30:52] formatting is totally messed up here. I will fix the presentation and we will upload it. This is just the directory of what is in the in the evaluation folder. We can create this live as soon as it’s done. Of course, it will take about 5 minutes should it take. Right now, it’s starting the environment, which is creating the sandboxes. So, just letting it run. Oh. This is too early. And when we have that, we get one task and it is scored. It either It

[31:24] gets a score of one or zero. Did it succeed or did it fail? If you do that for the 89 tasks, you get an amount how many tasks it did and then you do that over five runs, for instance, and then you get a percentage and you know how many percent of Terminal Bench did the model get. And then this is usually the score that the labs report. Most people just report the average across five runs. And this is the installation of the Wolf Bench Toolkit. What we have done before, it was all the Harbor framework and Terminal Bench and this is what I

[31:54] programmed, what I created. The Wolf Bench Toolkit is a way to work with this data because otherwise you now have a couple of files and you have some score, but how do you analyze it? So, this is a collector, what Wolf Bench does and I will It’s best if I show it when I open the program. So, let me go back here. While this is happening, I will just start it in a new shell. And we just clone it and go in there.

[32:26] So, it’s open source, Apache 2 license. You can use it for your own projects. Of course, you have to adapt it if you are using something else than Terminal Bench, but it’s easy to adapt nowadays. Just tell your agent. Quick question. Who’s using agents for stuff like that? Not everybody? Oh, I’m surprised. I still I still see a lot of notebooks, by the way. Because some people now just pull out their phone, take a screenshot, and say, “Okay, agent, go. Do whatever he is showing on the stage.”

[32:58] Next year. Okay, so it’s downloading and I’m also downloading all the results I did with all the runs I did so far. So, quick spoiler, I did uh 430 runs right now across um where is it? Uh it was 430 runs. But anyway, here are the agents I tested so far. Cloud code, Hermes agent, open clock cursor, Codex, Klein is not published

[33:29] yet. That is on my list and some other agents. If you are making an agent, contact me if you want to appear as well. And some models I tested, many on those W&B, that was on our own inference. So, the the final cost was unfortunately not as high as it is displayed, almost 40K here. So, this is some of this is on our own inference, but I just use the prices that have been published. So, let’s see where we are here. It’s downloaded. So, the 13 megabytes, those are the

[34:00] results. If you want to see all the trajectories, those have been uploaded to weave and you can just inspect them. You uh um don’t have to um download gigabytes of data. Now, if you want to use the Wolf Bench, you can set some variables, so it is also an uploader, but I will show you if I just start it. And this uses a Remeo notebook to um provide a dashboard, an easy way to handle all the evaluation data. So, any moment now. There it is.

[34:31] So, this is a dashboard. You can enter your information where you want to upload the traces if you have the We stuff. Then you can discover VMs if you are using XE dev or Hetzner, it will find all your VMs on there and you can filter which VM names are evaluation VMs. Because I don’t run the Harbor Framework on my own laptop usually. I run it in a VM so I can turn off my laptop or my Wi-Fi doesn’t go off and the connection to the sandboxes fails because that could also affect something. Um in this case, everything is local as

[35:03] soon as I download the stuff which I did. So, I can just scan my local directory and it will find all the run data I already did. So, here are the 443 unique runs. And it shows you here a filter so I every run that has a score is is measured. It has to have all the tests. If some tests have not been run, it’s not a valid res a run. It was just a test run. It shouldn’t have too many errors or timeouts. And then I get a list of all of this stuff and I can choose which models I want to create um

[35:35] uh nice chart for. In this case, I will just use all of them. Then you can also just change the names of the models and sometimes you also have to change the thinking because the parameter you give can be changed by the agent. Like if you are using a thinking extra high or if you want to use a thinking max mode and your agent doesn’t support it, maybe it is called a different way. And then you have to change it so it’s really reflecting what has been used actually.

[36:05] Now, after all of this is done, I can just create my results file. You can upload to We view if you have the key. I do not have set the key so I right now don’t have the button. Now, I create a save file and this is one JSON file that contains all the results. You can share that with other people. And in the end, I generate a chart which is a artifact I generate. So, now from all the results I did, I get a new chart. And this is the same that I then in the next step, I have an uploader as well.

[36:36] After the chart is generated, I just upload it to wolfbenchmark.ai and it’s updated. If I activate this option to replace the index.html and it is online immediately. So, going back to the present Oh, let’s just check how far the benchmark run. Oh, it’s done. See, it’s done. Trials one, mean score 1.0. So, it had one task, it solved the task. So, it worked. It finished and it fixed the Git repository.

[37:07] And this task is now in my directory and I could import it, but it’s not a full run, so it is not displayed by default. And once we have done that and uploaded this, we can look at what Wolf benchmark provides. This is also the mindset thing again, what do we want to look at? And in this case, this is what we just did. I showed you the dashboard. And now we have to take a look at the leaderboard and what it means, because

[37:38] the leaderboard itself, whatever it generates, it is not just an answer, it helps you to find a better question. Like, what are you looking at? Do you care about the capability of a model or the reliability of a model? And I will show you what that means by going to wolfbenchmark.ai. And the thing is, I will just make it a little smaller. So, they are sorted from left to right and I have all of the information here. Most benchmarks you look at, they just

[38:10] show the terminal’s two score and they only show the average. So, this is an interactive page, which is used not only to display results, but to create charts that you can then copy and paste and put somewhere else. There’s a screenshot symbol so I can show stuff on X for instance. So if I want to show how did this model do, I can just mark it. I can remove some of the bars or reorder the bars. So it’s interactive. So I can create my report that way. And what it also has it in the URL. So everybody can

[38:42] if you give the URL to this, they see the same thing you had on your screen. So I’m switching over here. And it looks a bit overwhelming sometimes because there are so many information so so many information on the same bar. Like I said, you can filter to different information to make it a simple bar, but I like to see this because the darker part at the bottom, that percentage is how many percent of the whole benchmark has a model solved in every run of the five runs runs I

[39:14] did. So that is what I call consistency. This model and this agent, they have solved the task 60% of the whole benchmark every time. And this means if that is a very high score, the model is very reliable because if it solves the task, you can expect it to solve the task all the time. While the yellow score is the average, the one score that usually is reported. And the up and down arrows around it, those are the best and the worst scores in one of the five runs. So if those are very close to each other, then there’s

[39:45] not a high variance. So you can expect the same score. If they are very far apart like we see here from 79% to 60%, that means there’s a lot of variance. And that is a sign that the model there’s a lot of randomness involved here. You can’t really trust it to execute the the task. Even if it has a high score, it’s a bit random if it does it. And the highest mark is the star, that is the ceiling. How many percent of the benchmark has it solved at all, at least once. The amount of task that tells you how

[40:18] Yeah, in an ideal case, that would be the score the model should get all the time if it’s perfect and always doing it. Although, that would also be an indicator that it is probably benchmarked for this. Um but it shows you how far it can go. So, what you want is a very very high ceiling, a very stable average, and a very high solid base. And if a model has the same score and they are almost the same, you can still see that the solid base is different. And then in that case, I would pick one that has a higher solid

[40:49] base. Like here, it’s 73% to 74%. It’s almost the same. If you just look at the average score, it’s almost exactly the same thing. Could be a variance, just variance. But this is a bigger difference. It’s 6% points, and that is a noticeable gap. So, you see the extra high thinking is better than the medium thinking, as we expected. But if we are looking at um This is also very interesting. I will show it in the presentation. Let me switch to the presentation.

[41:20] So, these were the different ways to imagine the model. Ah, risk and cost tolerance. I have to show you this because this is something If you look at the second best model on my evaluation, it was Gemini 3.5 Flash. So, this model, a flash model, is almost as good as GPT 5.5. So, what gives? If I just look at terminus, so we don’t have so many bars, and I can also say I just want to compare these two. And yeah, it’s a great model, Gemini 3.5 Flash. But if I look at how did it achieve that, I have a 3D view, which

[41:52] shows you how many tokens it used to achieve that. And it has been billions of tokens to get that score, while GPT 5.5 used much less. Let me zoom in. So, 136 million tokens for GPT 5.5, compared to 1.65 billion tokens for Gemini 3.5 Flash. And the thing is, if we also look at the price, which is another 3D view, this is the cost. And I can even show both at

[42:23] the same time. The cost is now a shadow. You see that the cost is over here. It’s overlap because it used so many tokens, but this shows that Gemini 3.5 Flash is very close to GBD 5.5, but it used so many tokens that it cost even more than GBD 5.5 of course. So, it costs in this case $620 compared to $497. So, 500 to over 600. So, it’s not that you Yeah, you have to think about this. Do you want to use a fast and cheap model?

[42:54] But you have to compare is it really faster and cheaper because all those tokens also take time. That is one thing. Going back to the presentation. And it’s a decision surface. It’s not just a chart. So, you load your snapshot and you can add your own if you did it and you execute the code, you would see them. And then you can filter like I showed you different metrics and models. You can reorder the bars and export your own. And then you can show this and make a social post

[43:25] about this or write an article, whatever you do. Um you can do this. In this case, I was looking at which is the best model on this benchmark. So, my number one right now is GBD 5.5 with Codex. It is even better than Fable because if you are asking what happened to Fable, that is also very interesting to take a look at. If I put Fable in here, it’s had 13 refusals. So, it refused. And if you take a look at the cost, it goes so far. It was my most expensive benchmark.

[43:56] Don’t tell anyone because it cost 11,000 just to test Fable and it failed because it refused so many tests. Whoops. And that is also something of course you have to decide. That is when people say oh I don’t trust this benchmark this model is in the first place. Look at what happened here and the benchmark has to be transparent so you can look at the traces and see what has happened then it makes sense suddenly. Okay. Going back and yeah like I said the best model was Codex with GPT 5.5 but as you

[44:29] can see it was pretty very expensive. Let’s zoom in. It cost almost a thousand bucks. While Cursor with the same model cost only 282. So that was very cheap compared to the other one and it used a little less tokens here. But yeah that’s you could say okay this is the best combination but maybe the other one is from a price and performance perspective the better one.

[44:59] And Terminus also had the highest ceiling but if the scores are very close to each other that could be random. You have would have to do 10 runs or even more to be very sure but you have to make a choice sometime and pick one and go with it. This was also the thing that I just showed Gemini 3.5 Flash compared to GPT 5.5 lower score bigger bill so in that case it would make more sense to use the other model. And this was also super interesting and

[45:29] surprised me a lot when I tested Opus 4.6 at the time I raised the thinking to max and the score decreased. It really got worse and I did the same with Claude Code because I used Titanus as well and there I saw the same effect. When I do that with GPT if I increase from thinking off to extra high or from medium to extra high if I raise the thinking level the model gets smarter as you would expect. So why did it get worse with Opus? That was surprising to me and the difference if If look at the

[46:00] traces is that you see the model it thinks too much. It’s overthinking. And that means I give it 1 hour. And if the model thinks for a minute or two and then decides I want to execute this command and the command doesn’t exist on the machine yet, then it thinks another two or three minutes. And how do I install this? While an agent that is not even thinking, it’s just doing stuff. So the first impulse is I run this command, get an error message. I run this command, get an error message. I install it, get an error message, fix it. And it gets more turns. So it can do more. That

[46:32] is the difference between thinking for an hour and not doing anything or just trying, trying, trying, trial and error. And the interesting stuff is that the GPT models, they are by default they appeared not as smart as Opus. Opus is very capable out of the box. Even with thinking off, it already got a great score. If you compare that here, it is already with off better than medium here on GPT 5.5. And even the solid base was higher. So it did more tasks in every run.

[47:04] Yeah. So that is stuff you have to look at. And if it’s surprising, take a look at the traces to find out what is happening here. Model overthinking. I also saw the same with Fable, by the way, where the model was very smart and it seemed to know it was so smart. So what it did is it decided to go this direction. And even if the benchmark said it should be done that way, said, “No, I know better. I will do it my way.” And then the verifier at the end, it ran, tested, and failed. So the model was too smart for its own good in some cases.

[47:36] And this is also an important feature I have to show you. The bar is a claim, the trace is evidence. I’m talking about traces all the time. So we have the bar, which is what we see on Wolf Bench. You have the nice bars. And the thing is you can click any of the bars, any of these. You just click it. And you get taken to our One page, where we have weave, which allows you to inspect all the traces. In this case, I just clicked one bar, and I’m seeing all the five runs that composed that score.

[48:07] And I can now pick any of the runs, go in here, and uh this I should remove. I’ll show this later. Uh go away. So, we have 89 chords. That are the 89 tasks that I have been doing, and you can see all of the traces here. It’s a lot, so it’s loading a bit. And then you can go into any of these, and you see the task name, and you see the reward, did it succeed or not, and you see all the steps. You see the

[48:38] initial request, the user message that says, “You are an assistant. You are tasked to do with this.” Then you see what the LLM did as a first command, what analysis it did, and what it wants to do, and then the command it sends, and so on. And you can really inspect all of this what has happened, and look at it. Or use your agent, and have this done. And we have a new feature, which is also an agent built into the platform. So, you have an agent inside of weave, and you can just tell it to do this. There’s a talk about this by my

[49:09] colleague, Tim Sweeney is doing it on July 1. There you can check it out. I use agents a lot, because reading all the traces takes a long time. And if the agent gives you a link to weave, and you see that it’s true what it says, that is also very good. So, to recap, there are so many variables relevant to benchmarks. You have the benchmark version, the OneBench 2.0, 2.1, the agent version, the model service and route, even updates to the infer- inference endpoint can change the results and the settings.

[49:39] Sandbox resources, like I said, if the if the agent runs out of resources, it will fail, and then you get a bad score for the model, although it wasn’t the model’s fault. Sampling, temperature, all things we discussed. Thinking defaults, like maximum not being higher if it thinks too long and a smaller, faster agent reaction could work better. Time out policy, retry policy. If you don’t retry and there has been infrastructure error, you would get a bad score. So, after every run I go through all of the errors and mistakes and check if there have been inference

[50:10] issues. You can find that out if there are repeated characters or if prompt template um tokens leak into the actual response, then you know there’s a tokenizer issue, an inference server issue. And especially with new models, that is a big thing. If you are benchmarking models as they come out, they are so new that the inference engine maybe has not the best support yet. So, I have done evaluations where the new model wasn’t that great. A week later I did the same, everything was the same, and it was better because the inference engine has

[50:41] been improved. That is also part of this. So, use the message, bring your own everything. You have the building blocks, check out the presentation, think about what you want to do, which evaluation to use, which agent to use, which model to test. You have the mindset now to know what to look out for and apply this to make uh leaderboards and charts and evaluations that are more reliable than if you just run something and publish a score. So, run your own reproducible benchmark configurations. Share the results.

[51:12] If you want to work with Wolf Bench, contact me. If you want to run some models, that would be great. We could collaborate and publish the results so I don’t have to run everything. And uh if you want to make an off-spin, that’s also great. Use another framework, whatever you want. And if you are building models or agents, feel free to contact me so I can benchmark them. I work with some of the agent uh creators already and will publish results soon. Yeah, that’s basically the end of the presentation. I hope you could get

[51:42] something out of it. And if you have some questions, now is the time. Otherwise, you can catch me at the booth and uh big shout out to Alex for the help. The podcast Thursday I is every Thursday and in the morning the time zone I’m from another time zone. 8:30 um Pacific time. Every week because it’s so hard to keep track of what’s happening and it’s hard for us as well so we are forced to do it so we can report it to you. Okay, thank you.

[52:27] >> [music]