Metodologia da Argusic

Como a Argusic testa se um software real executa, e como pontua os AI coding agents. Toda regra aqui é pública de propósito: o objetivo é justamente que qualquer pessoa possa conferir o nosso trabalho. Qualquer mudança nestas regras entra no registro de alterações no fim da página, vale a partir do próximo ciclo de testes e nunca é aplicada retroativamente.

1. Em resumo

• Pegamos projetos reais de código aberto e pedimos que AI agents tentem

instalá-los, iniciá-los e depurá-los sem nenhuma ajuda humana, exatamente como faria um engenheiro novo no primeiro dia.

• Todo teste é gravado do início ao fim. Todo número publicado tem link para o

seu log e a sua gravação do terminal.

• Cada projeto recebe um veredito simples: executa, executa com serviços mock, ou

não foi possível verificar.

• Os agents são comparados em condições idênticas; três execuções para cada um,

o resultado do meio é o que conta, e resultados muito inconsistentes são sinalizados e deixados de lado.

• Não vendemos nenhum agent e não aceitamos dinheiro para mudar um resultado. A

Argusic é o árbitro.

• A medição é automatizada. A escrita não é: nenhum modelo escreve uma frase

neste site, todo número em uma página é um modelo de texto preenchido a partir de uma execução registrada, e uma pessoa aprova antes de qualquer publicação. Veja como este conteúdo é escrito.

2. A pergunta que isto responde

Dado um projeto real de código aberto, um AI coding agent consegue, totalmente sozinho, instalá-lo, iniciá-lo, resolver os erros e verificar que o software executa, como um engenheiro no primeiro dia, sem nenhuma ajuda humana?

3. Por que projetos novos

Benchmarks estáticos se degradam à medida que suas respostas vazam para os dados de treinamento. O SWE-rebench (Badertdinov et al., 2025) executou os mesmos agents no SWE-bench Verified e em tarefas coletadas depois que esse benchmark se tornou público, e as pontuações mudaram muito: a Tabela 2 do estudo mostra o DeepSeek-V3-0324 resolvendo 39.7% do SWE-bench Verified e 21.3% do conjunto filtrado por data, uma diferença de 18 pontos percentuais em um único modelo. A Argusic testa projetos que estão em alta nas últimas semanas, com um pool secreto renovado todo mês, então não há nada para memorizar.

4. O que é medido

Medimos exatamente uma coisa: a capacidade autônoma de fazer um software real executar. Cada agent testado é uma combinação fixa de um modelo em uma versão fixada, um harness em uma versão fixada, as instruções padrão publicadas da Argusic e limites idênticos de tempo e de recursos. Todo agent recebe exatamente as mesmas condições.

5. Agents testados

O primeiro ciclo está em andamento. A lista de agents será publicada com o primeiro ranking. Cada agent é uma configuração fixa e fixada, apresentada sob uma identidade neutra da Argusic; suas versões exatas são registradas e guardadas para que todo número do ranking leve à configuração precisa que o produziu, e um resultado pode ser reproduzido pela Argusic mediante solicitação (veja "Como reproduzir um resultado").

6. O pool de projetos

• 80% pool público: a lista e as versões exatas (hashes de commit) são

publicadas antes de cada ciclo.

• 20% pool secreto: escolhido entre projetos em alta nos últimos 30 dias,

publicado só depois que o ciclo termina e renovado todo mês. É isso que impede que os agents sejam ajustados para o teste.

• Critérios de seleção: uma licença permissiva, um README, variedade de

linguagens e de dificuldade, e a possibilidade de executar em nível básico sem contas pagas.

6a. O que pode ser um projeto testado

Um projeto testado é algo que um agent pode receber a tarefa de configurar e executar. Hoje a Argusic testa um tipo, e foi construída para acrescentar outros sem mudar nada na forma como um resultado é obtido: a rubrica de pontuação, as regras de evidências e o vocabulário dos vereditos são idênticos entre as fontes, então um número de uma fonte significa o mesmo que um número de outra.

Fonte	O que "executa" significa aqui	Estado
Repositório de código aberto	Clonar o commit fixado, instalar, iniciar e verificar que ele faz o trabalho que o próprio README descreve	Em uso. 3669 projetos testados
Modelo do Hugging Face	Baixar o modelo em uma revisão fixada e executar a inferência exatamente como o model card documenta, em um worker com GPU. Ele executa quando o trecho documentado produz saída em uma máquina limpa sem que o testador o reescreva	Em uso. 1 projeto testado
Hugging Face Space	Fazer o build e iniciar o Space a partir da própria definição, depois acessar a interface e concluir a interação que ele anuncia	Declarado, não iniciado
Pacote publicado (npm, PyPI)	Instalar a versão fixada em um projeto vazio e executar o quickstart do próprio README	Declarado, não iniciado
Ferramenta de fornecedor	Instalar e iniciar o build publicado pelo próprio fornecedor, seguindo apenas as instruções do próprio fornecedor	Declarado, não iniciado
Template de nuvem pronto	Implantar o template como a própria página dele documenta e verificar que ele inicia e serve o que anuncia, sem que o testador precise corrigi-lo antes	Declarado, não iniciado
Imagem de container	Baixar a imagem em um digest fixado e executar o comando que a própria descrição indica, depois verificar que ela faz o que essa descrição afirma	Declarado, não iniciado
MCP server	Instalar e iniciar o servidor como documentado, conectar um cliente e confirmar que ele lista e responde às tools que anuncia	Declarado, não iniciado

A coluna de estado acima não é escrita à mão. Ela é lida do banco de dados cada vez que esta página é servida: uma fonte aparece como em uso assim que um projeto publicado daquele tipo tem uma execução registrada, e mostra a contagem. É a mesma regra que todo outro número deste site segue, e significa que ninguém precisa se lembrar de atualizar esta página quando uma nova fonte produz o seu primeiro resultado.

Duas coisas tornam um projeto do Hugging Face diferente de um repositório, e as duas são registradas com a execução em vez de serem disfarçadas. Ele precisa de um worker com GPU, então o custo por tentativa é maior e o orçamento é decidido à parte. E um model card muitas vezes documenta um trecho de código e não um aplicativo, então o comportamento verificado é "o trecho documentado produziu saída", não "o produto funciona": a página da execução diz qual dos dois, com essas palavras, e a pontuação é obtida da mesma forma.

A tabela diz "não iniciado" em vez de "em breve" de propósito. Uma fonte conta como em uso no dia em que uma execução real daquele tipo é registrada com as suas evidências, e nem um dia antes. Até lá a linha é uma declaração de escopo, nunca de resultados: nenhuma página mostra um veredito, uma contagem, uma classificação ou um cartão de compartilhamento de uma fonte que ainda não executou, e esta tabela é o único lugar onde uma fonte planejada é nomeada.

7. Uma medição

1. Uma máquina limpa e descartável (seu ambiente exato é publicado). Ela não

aceita conexões de entrada e é destruída quando a execução termina. O acesso de rede de saída não é filtrado nesta edição; o que limita uma execução é a máquina descartável e as regras da chave do modelo abaixo da lista. A máquina baixa apenas o commit fixado, não o histórico do projeto, que não faz parte do teste.

2. O agent recebe uma única missão: fazer este projeto funcionar, seguindo as

instruções padrão publicadas.

3. Um limite de tempo. Toda execução recebe um de exatamente três orçamentos (a

tabela abaixo da lista), e o orçamento dado a uma execução aparece na página dela.

4. Três execuções independentes; o resultado do meio é o que conta. Se os três

resultados diferirem em mais de 30%, o conjunto é sinalizado como instável e deixado de fora do ranking daquele ciclo.

5. Toda execução guarda um log completo e uma gravação completa do terminal,

publicados com os resultados.

6. Aplicativos desktop são iniciados em uma tela virtual dentro da máquina

(desde a v1.1). "Iniciado" significa que o processo principal do aplicativo começou naquela tela e continuou de pé, ou respondeu a um comando de versão ou de ajuda. Nada é clicado; a medição é se o software sobe em uma máquina nova, a mesma pergunta feita a todos os outros projetos. O agent é instruído a não enviar imagens ao seu modelo (desde a v1.3): o modelo padrão aceita apenas texto, e uma captura de tela anexada a uma mensagem encerrou a sessão antes do relatório.

Os orçamentos de tempo do item 3:

Faixa	Orçamento
standard	90 minutos
heavy	120 minutos
gpu	120 minutos

O orçamento standard era de 45 minutos antes da v1.3: na primeira semana, 36 de 38 estouros de tempo em um único dia eram builds ainda em andamento com o orçamento inteiro usado, então ele foi dobrado. A faixa heavy existe desde a v1.2 para um projeto que o Owner marca como heavy, ou cujo repositório é maior que 500 MB segundo o GitHub, porque um jogo grande ou um aplicativo desktop precisa desse tempo para o build. Um projeto que precisa de GPU recebe os mesmos 120 minutos.

Os três números acima não são decoração. scripts/check-ttl-methodology.sh lê esta tabela e a compara com os orçamentos com que o orquestrador está de fato configurado, e make test falha se eles divergirem. Essa verificação existe porque, entre 2026-09-06 e 2026-09-11, o orçamento de GPU no sistema em funcionamento era de 240 minutos enquanto esta página dizia 120, e nada comparava os dois (ISSUE-072).

A chave do modelo. Um agent precisa de uma chave para chamar o seu modelo, e uma execução roda código de um projeto não confiável, então essa chave é a credencial que mais vale a pena limitar. Para os agents que chegam ao modelo pela camada de roteamento da Argusic, cada execução recebe a sua própria chave, criada só para ela. Limite de gasto da chave de modelo de cada execução: 3 USD. A chave é excluída quando a execução termina, é cancelada ou estoura o tempo, e uma varredura agendada exclui qualquer chave que não pertença mais a um job em andamento. Se a chave de uma execução não puder ser criada, a execução não é iniciada e é tentada de novo; uma chave compartilhada nunca é usada no lugar. Os agents que usam o serviço do próprio fabricante do modelo o chamam com uma chave compartilhada mantida pela Argusic, não com uma chave por execução; passá-los para chaves por execução está no nosso backlog. A linha do limite acima é lida por scripts/check-cost-methodology.sh, que faz make test falhar se ela divergir do valor configurado, pelo mesmo motivo dos orçamentos de tempo.

8. Pontuação, de 0 a 100

• Instalação bem-sucedida: 30
• Inicialização ou testes bem-sucedidos: 30
• Recuperação de erros: 20, na proporção dos erros encontrados que foram

corrigidos de forma válida

• Profundidade de verificação: 20 (verificado executando de verdade: 20;

verificado com serviços mock: 12; não verificado: 0)

O resultado de uma execução é um destes:

Resultado	Significado
pass_full	Executou e foi verificado de verdade
pass_mock	Executou, verificado com serviços mock
fail	Não instalou ou não iniciou
timeout	O tempo acabou

As quatro linhas de pontuação deixam alguns casos implícitos. Eles são resolvidos aqui, e não só no código, porque uma regra que ninguém consegue ler é uma regra que ninguém consegue conferir. A pontuação é um programa determinístico com testes que cobrem cada regra abaixo; nenhum modelo de IA participa da pontuação em momento algum.

• Se nada deu errado, a recuperação de erros recebe os 20 completos. Pontuar zero

penalizaria um agent porque o projeto por acaso instalou sem problemas, o que mede o projeto, não o agent.

• Caso contrário, a recuperação de erros é a parcela dos erros encontrados que

foram corrigidos, sobre 20. Uma execução nunca pode declarar mais erros corrigidos do que encontrados; uma execução assim é rejeitada.

• A inicialização exige a instalação: um agent que não instalou o software não

poderia tê-lo iniciado.

• A profundidade de verificação exige a inicialização: sem uma inicialização

bem-sucedida não há nada para verificar, então a profundidade fica com 0.

• Instalado e iniciado, mas não verificado, não é aprovação. Recebe 80 de 100 e

ainda conta como falha, porque a pergunta é se o agent verificou que o software executa, e uma inicialização não verificada não responde a ela.

• Um estouro de tempo recebe 0 em todas as linhas. Não há crédito parcial: o

agent não terminou dentro do mesmo limite que todos os outros agents tiveram.

• Uma execução sem log e gravação completos é inválida e é executada de novo.

Ela nunca é pontuada e nunca chega ao ranking.

9. De muitas execuções a uma pontuação no ranking

A pontuação avalia um par projeto e agent. O ranking precisa de um único número por agent, e a forma de combiná-los é uma escolha de metodologia, por isso é declarada aqui.

A pontuação de um agent no ranking é o valor do meio das suas pontuações do meio por projeto. Usamos de novo o valor do meio, e não uma média, pelo mesmo motivo: um projeto desastroso não deve derrubar um agent capaz, e um projeto de sorte não deve levantar um agent fraco.

Dois tipos de resultado ficam de fora desse número, e os dois continuam aparecendo no ranking para que a exclusão seja visível, não silenciosa: resultados sinalizados como instáveis (veja a próxima seção) e todos os resultados de um projeto sinalizado como em revisão (veja controle de qualidade do ambiente).

Um agent com todos os resultados excluídos não tem pontuação no ranking. Ele aparece no fim, sem pontuação, em vez de ser removido, porque um agent que foi testado e não produziu nada utilizável é em si um resultado, e escondê-lo favoreceria discretamente os demais.

A taxa de aprovação conta todas as tentativas que um agent fez no ciclo, incluindo falhas e estouros de tempo. Veja independência e nada de escolher a dedo, mais abaixo.

10. Dispersão e instabilidade

A dispersão é a amplitude das três execuções como porcentagem do valor do meio:

spread = (highest - lowest) / middle * 100

Um conjunto é sinalizado como instável quando a dispersão é estritamente maior que 30%. Exatamente 30% não passa de 30% e continua no ranking. Dois casos extremos decorrem da fórmula:

• Se o valor do meio é 0 mas alguma execução pontuou acima de 0, a dispersão é

ilimitada e o conjunto é instável: um resultado que apareceu uma vez e não nas outras duas é o resultado menos reproduzível que existe.

• Se as três execuções pontuaram 0, a fórmula divide por zero e não tem valor,

então a dispersão é definida como 0 por esta regra e o conjunto é estável. Uma falha consistente é uma medição reproduzível e pertence ao ranking como tal.

11. O veredito do projeto

O ranking classifica agents. O veredito responde a outra pergunta, sobre o próprio projeto: um recém-chegado, na forma de um AI agent, consegue fazer este software executar hoje?

O teste é adaptativo, porque as evidências são assimétricas. Uma aprovação prova que o projeto executa; uma única falha não prova nada por si só, porque pode ser do agent e não do projeto.

1. Primeiro, o agent padrão executa uma vez. Qualquer aprovação encerra o

processo: uma aprovação completa dá "executa", uma aprovação com serviços mock dá "executa com mocks". Não há motivo para continuar testando algo que já se mostrou executando.

2. Se falhou, uma nova tentativa com o mesmo agent descarta um acaso isolado.
3. Se ainda falhou, o veredito é "não foi possível verificar", nunca

"quebrado": a Argusic informa o que os agents conseguiram fazer, e declara exatamente isso (desde a v1.3: duas tentativas completas com o agent padrão decidem). Um agent mais forte pode ser executado mediante solicitação; quando isso acontece, a aprovação dele faz o projeto "executar" (o registro mostra qual agent o verificou) e a falha dele também decide "não foi possível verificar".

Uma tentativa completa é aquela cuja gravação mostra o agent trabalhando até o próprio fim ou até o limite de tempo. Uma tentativa que as ferramentas da própria Argusic interromperam (um harness que não conseguiu ler o relatório do agent, um erro de instrumentação sem relação com o projeto) é marcada como inválida com o motivo guardado na execução, continua publicada com as suas evidências e não conta.

O veredito é o melhor resultado que qualquer tentativa alcançou:

• executa: alguma tentativa executou e foi verificada de verdade.
• executa com mocks: a melhor tentativa executou, verificada com serviços

mock, normalmente porque o projeto precisa de credenciais reais de terceiros.

• não foi possível verificar: nenhuma aprovação após duas tentativas

completas (ou após o agent mais forte, quando ele foi executado). A página diz isso e tem link para o log que mostra onde cada tentativa parou.

• ainda não verificado: o teste ainda não terminou.

Toda tentativa é publicada com todas as suas evidências, seja qual for o veredito, com uma exceção: uma gravação que não pode ser comprovadamente livre de uma credencial ativa é retida, e a execução é feita de novo (seção 17, "Remoção por segurança").

12. O que a Argusic não mede

Para evitar interpretações erradas, dizemos isto com clareza. A Argusic não mede a qualidade de longo prazo do código que um agent escreve, a segurança das suas correções, nem a experiência profunda do produto no nível de funcionalidades. Ela mede uma coisa: a capacidade autônoma de fazer um software real executar.

13. Independência e nada de escolher a dedo

• A Argusic não aceita dinheiro para alterar a sua metodologia, a pontuação ou

as classificações.

• Um patrocínio de computação, se houver, compra exatamente uma coisa: o modelo

do patrocinador é acrescentado à lista de testados em condições idênticas às de todos os outros agents, com o patrocínio divulgado ao lado dos resultados.

• Toda execução de todo agent conta e é publicada. Não existe teste privado

seguido da publicação apenas do melhor resultado. Se um agent está no ranking, todas as suas tentativas do ciclo estão no registro.

14. Divulgação do harness

O harness (a estrutura, as ferramentas, as instruções e os limites em volta do modelo) é público e idêntico para todos os agents de um ciclo. Qualquer diferença de pontuação deve poder ser atribuída ao agent, não à infraestrutura. Mudanças no harness só entram entre ciclos e são registradas no registro de alterações.

15. Controle de qualidade do ambiente

Quando um projeto falha com todos os agents, ele é sinalizado automaticamente como em revisão e excluído da pontuação até que uma pessoa o verifique: a falha pode ser do ambiente ou do projeto e não dos agents. Um problema de configuração compartilhado nunca deve ser pontuado como falha de um agent.

16. Verificar significa decodificar, não sondar

Um arquivo existir não é um resultado, e ler o seu cabeçalho não é uma verificação. ffprobe -show_streams, file e uma contagem de bytes informam um contêiner e não decodificam nada: um vídeo com todos os quadros verdes passa pelos três exatamente como um vídeo bom. A regra, em vigor desde a v1.4, é que um agent informa o que decodificou, nunca o que esperava.

• Decodifique o que você produziu. ffmpeg -v error -i FILE -f null - para

vídeo e áudio, um decodificador real para uma imagem, imprimir o conteúdo para texto. Informe o comando e o que ele retornou.

• Nunca afirme o que você não observou. O prompt que você deu a um modelo não

é evidência do que saiu; o que um README promete não é evidência de que aconteceu aqui. "81 quadros decodificados sem erros" é uma constatação. "Um vídeo de dois gatos" não é.

• É a decodificação que garante a maior profundidade de verificação.

test_depth é o campo que registra até onde uma execução chegou (seção 8: tier1_real é "verificado executando de verdade" e vale 20, tier2_mock é "verificado com serviços mock" e vale 12, tier3_none é "não verificado" e vale 0). tier1_real exige uma decodificação bem-sucedida, não a capacidade de descrever uma saída.

• verified_how carrega a prova. É o campo do relatório que contém o

comando exato que o agent executou para verificar a própria saída e o que esse comando retornou. "not verified" é uma resposta aceita e útil.

• final_state é a frase final do próprio agent sobre o que aconteceu, e é

publicada literalmente nas páginas da execução e do projeto, então todo fato nela precisa ser algo que o agent observou com os próprios comandos.

17. Integridade das evidências

Duas camadas, nunca confundidas.

A camada de evidências é bruta e permanente: toda execução produz uma gravação completa do terminal da sessão real e, para aplicativos gráficos, um vídeo bruto da sessão, além dos logs completos. Cada arquivo recebe uma impressão digital (hash) na chegada e é guardado para sempre. Qualquer pessoa pode reproduzir a sessão inteira, sem edição.

A camada de apresentação é derivada: qualquer vídeo ou imagem para redes sociais é uma renderização das evidências. As edições permitidas são acelerar, cortar para ajustar a duração, legendas tiradas da linha do tempo registrada de erros e correções, e narração. As edições proibidas são reordenar eventos, juntar sessões diferentes, esconder falhas ou alterar a substância do que o agent fez. Todo vídeo publicado tem link de volta para as suas evidências.

Três transformações derivadas são aplicadas à gravação antes de ela ser servida, e nenhuma delas muda a substância do trabalho do agent:

• Remoção por segurança. Valores de credenciais ativas são removidos. Nada

impede um repositório não confiável de induzir o agent a imprimir o ambiente, que contém a única chave de que o agent precisa, então qualquer valor com cara de segredo é apagado antes de a gravação ser guardada ou servida. Uma gravação que não pode ser comprovadamente livre de uma credencial é retida, e a execução é feita de novo.

• Material de chave gerado. Alguns projetos geram chaves como a sua função

(um gerenciador de senhas, uma ferramenta de PKI), e o agent pode executá-los e imprimir o resultado. Isso é saída real do teste, não uma credencial da Argusic, então não retém a execução: a cópia servida da gravação e do log tem o corpo de qualquer chave privada desse tipo mascarado, o arquivo bruto é arquivado com a sua própria impressão digital registrada na execução, e a página da execução informa que a máscara foi aplicada. Um corpo que não pode ser comprovadamente mascarado ainda retém a execução (desde a v1.2, decisão do Owner de 2026-09-05).

• Marca neutra do agent. A gravação é apresentada na voz do Argusic Agent: o

banner de inicialização da ferramenta subjacente (que nomeia o fornecedor, o provedor e o modelo) é suprimido, do mesmo jeito que uma visualização formatada substitui a saída bruta da máquina. Isso nunca edita os comandos que o agent executou nem as alterações que fez; esses aparecem por inteiro. Também não censura nomes de fornecedores que aparecem naturalmente em caminhos de arquivo, nomes de pacotes ou no próprio código do repositório, que fazem parte do trabalho real.

Uma transformação de exibição se aplica a texto citado (decisão do Owner de 2026-09-04): quando uma página mostra a frase de estado final do próprio agent ("O que o teste encontrou") ou a descrição de um repositório no GitHub, um travessão digitado pelo autor aparece como vírgula ou ponto, para que a página siga a pontuação da casa. O relatório guardado, o registro do repositório, o log, a gravação e as imagens renderizadas a partir da gravação não são tocados; as palavras e a ordem delas nunca mudam.

Regra permanente: todo número leva a um log, e todo quadro leva a uma gravação da sessão real.

18. Como reproduzir um resultado

O lado do projeto de todo resultado é totalmente público: o commit exato testado, o ambiente publicado, as instruções padrão e o log e a gravação completos. A página de cada execução traz tudo isso. O agent é uma configuração fixa e fixada da Argusic sob uma identidade neutra; a Argusic guarda as suas versões exatas e pode executar um resultado de novo para reproduzi-lo. A lista pública de projetos e as divulgações do pool secreto são publicadas junto com o primeiro ranking.

19. Contestar um resultado

Se um mantenedor ou um laboratório acredita que um resultado está errado, pode contestá-lo. Escreva para [email protected] com o link da execução. Revisamos o log e a gravação completos em relação à alegação e respondemos. Se o resultado foi afetado por um problema de ambiente ou de configuração do nosso lado, executamos de novo e corrigimos o registro com uma nota; se as evidências sustentam o resultado original, explicamos o que a gravação mostra. As evidências originais nunca são editadas nem removidas.

20. Registro de alterações

Duas datas aparecem em uma edição e respondem a perguntas diferentes. Escrita é o dia em que a regra foi registrada neste documento. Em vigor desde é o dia em que a primeira execução foi de fato medida sob ela, lido dos registros das execuções, não deste arquivo. Normalmente coincidem. Quando não coincidem, os registros das execuções prevalecem e são impressos aqui, porque uma edição que chegou às máquinas antes de chegar a esta página é exatamente o que um registro de alterações existe para divulgar. Nenhuma edição é aplicada retroativamente: uma execução mantém as regras que estavam em vigor no dia em que foi feita.

As edições v0.2 a v1.0 foram todas registradas em 2026-08-31, no commit que criou a primeira edição pública; as datas abaixo são os dias em que as próprias regras foram decididas, antes da primeira medição.

• v0.2 (2026-08-29): declarou os casos que a rubrica de pontuação deixava

implícitos (recuperação de erros com zero erros, as dependências entre instalação e inicialização, estouros de tempo, execuções inválidas) e a fórmula exata da dispersão com os seus dois casos extremos. Escrita antes da primeira medição, então nada foi aplicado retroativamente.

• v0.3 (2026-08-30): declarou como os resultados por projeto se combinam em um

único número do ranking (o meio dos valores do meio por projeto), quais resultados são excluídos, e que um agent sem nada pontuável aparece sem pontuação em vez de ser removido.

• v0.4 (2026-08-30): acrescentou o veredito do projeto (teste adaptativo: agent

padrão, uma nova tentativa, depois um agent mais forte, parando na primeira aprovação). A pontuação do ranking não mudou.

• v1.0 (em vigor desde 2026-08-31, escrita em 2026-08-31): primeira edição

pública. Nenhuma regra mudou em relação à v0.4; esta edição reorganiza o documento, define os termos em linguagem simples e acrescenta as seções de reprodução e de contestação.

• v1.1 (em vigor desde 2026-09-04, escrita em 2026-09-04): aplicativos desktop

são iniciados em uma tela virtual dentro da máquina de teste (seção 7, item 6), para que projetos com interface gráfica possam ser medidos. A imagem da máquina também ganhou os runtimes desktop comuns e as ferramentas de build nativas; o digest da imagem é registrado em toda execução, então os resultados de antes e de depois podem ser distinguidos. Pontuação inalterada.

• v1.2 (em vigor desde 2026-09-04, escrita em 2026-09-05): a faixa heavy (seção

7, item 3): projetos grandes recebem 120 minutos na mesma classe de máquina, decididos pela marcação do Owner ou por um repositório de 500 MB, e o orçamento aparece na página da execução. A máquina baixa apenas o commit fixado. A seção 17 ganha a transformação de material de chave gerado. Pontuação inalterada. Esta edição foi registrada aqui primeiro como válida a partir de 2026-09-05; os registros das execuções mostram três projetos heavy (cataclysm-dda, veloren, supertux) já medidos com o orçamento de 120 minutos em 2026-09-04, então a data anterior é a que aparece acima.

• v1.3 (em vigor desde 2026-09-05, escrita em 2026-09-05): o veredito é decidido

após duas tentativas completas com o agent padrão (seção 11); o agent mais forte deixa de fazer parte da cadeia padrão. Tentativas interrompidas pelas ferramentas da própria Argusic são inválidas e não contam (92 execuções desse tipo de 2026-08-30 a 2026-09-05 foram marcadas assim, com o motivo em cada execução). Limite de tempo standard de 90 minutos (seção 7, item 3); nada de imagens para o modelo (item 6). Pontuação inalterada.

• v1.4 (em vigor desde 2026-09-07, escrita em 2026-09-07): verificar significa

decodificar, não sondar (seção 16). Um agent precisa decodificar o que produziu e informar o comando que usou, nunca pode afirmar algo que não observou, e só obtém tier1_real com uma decodificação bem-sucedida. Um novo campo do relatório, verified_how, carrega esse comando e o seu resultado, e "not verified" é uma resposta aceita. As primeiras execuções com verified_how foram registradas em 2026-09-07. Pontuação inalterada. Esta edição veio de um leitor, não de nós. Alguém que leu um reel publicado perguntou se tínhamos visto falhas de MP4 válido com quadros corrompidos, e o cast da sessão mostrou que o agent tinha executado exatamente a verificação de cabeçalho que não consegue detectar isso. Metade da frase relatada era verificável (codec, dimensões, número de quadros, duração, tudo lido do cabeçalho) e metade não era: a descrição do que o vídeo mostrava era o prompt do model card, reformulado como uma observação. Essa frase tinha sido publicada literalmente em um reel, em uma legenda e em uma página de projeto (ISSUE-056).

• v1.5 (em vigor desde 2026-10-08, escrita em 2026-10-08): corrige a descrição

da rede e da chave de modelo da máquina de teste na seção 7 para que corresponda ao sistema como foi construído, e corrige a numeração da lista dessa seção movendo a tabela de orçamentos de tempo para depois da lista (assim "seção 7, item 6" na v1.1 e na v1.3 volta a ser o item 6). Antes desta edição a seção 7 dizia que a máquina tinha uma "rede restrita"; o tráfego de saída da máquina não era filtrado, e esta edição diz isso. Ela também declara a chave de modelo por execução, o seu limite de gasto de 3 USD e a sua exclusão, incluindo que execuções canceladas e paradas de emergência agora também excluem a chave (antes de 2026-10-08 não excluíam), e que os agents que usam o serviço do próprio fabricante do modelo usam uma chave compartilhada. Isto é uma correção da descrição, não uma mudança em qualquer regra de pontuação ou de medição: nenhuma execução anterior é reclassificada, nada foi medido sob uma regra diferente, e a edição não é aplicada retroativamente. Pontuação inalterada.

Apêndice: estimativas de hardware, o que cabe e com que velocidade

As estimativas abaixo aparecem ao lado dos laptops e desktops para programação, IA e ciência de dados que a Argusic lista.

Este apêndice não faz parte das regras do benchmark acima e não altera nenhuma edição: ele explica as estimativas que a Argusic mostra ao lado dos laptops e desktops que lista à venda, que são aritmética sobre números publicados pelos fabricantes, nunca medições. Os números aqui são calculados por um único arquivo compartilhado (lib/hardware-estimates.ts), e nenhum deles pode mudar sem que esse arquivo e o seu teste mudem no mesmo commit.

A listagem de hardware da Argusic mostra, para cada laptop e desktop, o maior tamanho de modelo que ele comporta e um limite superior para a velocidade com que ele gera texto. Os dois são Estimados: são calculados a partir das especificações publicadas pelo fabricante com as fórmulas abaixo. A Argusic não executou nenhum modelo nessas máquinas. Quando a Argusic de fato mede uma máquina, esse número leva o rótulo Medido, tem link para o log da execução e nunca é misturado com uma estimativa.

Uma estimativa só é mostrada quando todas as entradas são conhecidas. Se o tamanho da memória, o tipo de memória ou a largura de banda do chip estiver faltando, a página diz "Desconhecido" em vez de adivinhar.

Entradas e de onde vêm

• Memória para o modelo: a memória onde um modelo pode ficar. Para uma máquina com GPU dedicada, é a VRAM da GPU. Para Apple silicon, AMD Ryzen AI Max e NVIDIA GB10, é a memória unificada compartilhada entre CPU e GPU. Lida da listagem do produto.
• Largura de banda da memória: lida da página de especificações ou da folha de dados do próprio fabricante do chip ou da GPU (Apple, NVIDIA, AMD), uma linha de referência por chip, cada uma com link para a página de onde veio. Um chip cujo fabricante não publica a largura de banda fica sem largura de banda na página. A Argusic não calcula a largura de banda a partir da largura do barramento e da velocidade da memória, e não a copia de bancos de dados de terceiros.
• Tamanho do modelo: o número de parâmetros, nas cinco classes de tamanho do filtro: 7-8B, 14B, 27-32B, 70B, 120B ou mais. Cada classe é verificada no seu tamanho máximo (8B, 14B, 32B, 70B, 120B), então um encaixe cobre a classe inteira.

Memória: qual tamanho de modelo cabe

Um modelo precisa de espaço para três coisas.

1. Pesos. A Argusic assume a quantização Q4_K_M do llama.cpp, com 4.8944 bits por peso (README do quantize do llama.cpp):

bytes de pesos = parâmetros x 4.8944 / 8. Exemplo, calculado e não medido: um modelo de 70B precisa de 42.8 GB de pesos.

2. Contexto (KV cache). Pela fórmula da NVIDIA (Mastering LLM Techniques: Inference Optimization, NVIDIA Technical Blog, 2023-11-17):

bytes de KV cache por token = 2 x camadas x (heads x dimensão do head) x bytes por valor. Os modelos modernos compartilham heads de chave/valor entre os heads de atenção (grouped-query attention), então "heads" aqui é o número de heads de chave/valor que o modelo de fato guarda em cache. A Argusic reserva 8192 tokens de contexto com precisão de 16 bits (2 bytes, o tipo de cache padrão do llama.cpp), usando a configuração publicada de um modelo denso aberto por classe: Qwen3-8B, Qwen3-14B, Qwen3-32B, Qwen2.5-72B-Instruct e Mistral-Large-Instruct-2411.

3. Sobrecarga do runtime. A Argusic reserva 1 GB para os buffers do próprio runtime de inferência.

O contexto de 8192 tokens e a sobrecarga de 1 GB são a reserva da Argusic, uma escolha de política e não uma medição. Contextos mais longos precisam de mais memória; um modelo que cabe aqui pode não caber com uma conversa muito mais longa.

Quanto da memória da máquina conta. Toda a VRAM de uma GPU dedicada conta. Da memória unificada ou do sistema, a Argusic conta 75% e deixa 25% para o sistema operacional e outros programas. Isso corresponde ao que a AMD declara para os seus próprios chips de memória unificada: até 96GB de 128GB podem ser convertidos em VRAM (AMD), e 64GB permitem até 48GB (AMD).

Os tamanhos de memória são lidos como 10^9 bytes por GB, a mesma unidade que os fabricantes usam para a largura de banda. A memória na verdade é dimensionada em unidades binárias, então isso subestima a capacidade em cerca de 7% e torna todo encaixe um pouco conservador.

O requisito resultante para cada classe, calculado a partir das regras acima:

Classe	Pesos (Q4_K_M)	Reserva de contexto	Sobrecarga	Precisa de	VRAM a partir de	Memória unificada a partir de
7-8B	4.89 GB	1.21 GB	1 GB	7.10 GB	7.10 GB	9.47 GB
14B	8.57 GB	1.34 GB	1 GB	10.91 GB	10.91 GB	14.54 GB
27-32B	19.58 GB	2.15 GB	1 GB	22.73 GB	22.73 GB	30.30 GB
70B	42.83 GB	2.68 GB	1 GB	46.51 GB	46.51 GB	62.01 GB
120B ou mais	73.42 GB	2.95 GB	1 GB	77.37 GB	77.37 GB	103.16 GB

Assim, por exemplo, uma GPU de 8GB comporta a classe 7-8B, uma GPU de 24GB a classe 27-32B, e 64GB de memória unificada a classe 70B. Uma máquina abaixo da primeira linha aparece como não comportando nenhuma das classes.

Velocidade: um limite superior, não uma previsão

Gerar cada token exige ler cada peso do modelo da memória uma vez, então a geração de texto é limitada pela largura de banda da memória (NVIDIA: "Model execution is frequently memory-bandwidth bound"). Isso dá um teto:

tokens por segundo, no máximo = largura de banda da memória / bytes de pesos.

Exemplo, calculado e não medido: um chip com 546 GB/s executando um modelo de 8B em Q4_K_M (4.89 GB de pesos) não pode passar de cerca de 111 tokens por segundo.

A velocidade real é sempre menor. O limite ignora o tempo gasto lendo o contexto, a computação e a sobrecarga do software. As medições reunidas na discussão #4167 do llama.cpp mostram a velocidade subindo com a largura de banda, mas abaixo do linear. Para o Llama 2 7B em Q4_0 no Apple silicon: M3 Max (400 GB/s) 66.31 tokens por segundo, M4 Max (546 GB/s) 83.06, M2 Ultra (800 GB/s) 94.27. Passar de 400 para 546 GB/s (1.37 vez a largura de banda) deu 1.25 vez a velocidade; dobrar para 800 GB/s deu 1.42 vez. Leia o limite como "esta máquina não pode ser mais rápida que isto", nunca como "esta máquina executa nesta velocidade".

O limite assume um modelo denso, em que cada peso é lido para cada token. Modelos mixture-of-experts leem apenas os experts ativos para cada token, então podem executar mais rápido do que o limite para o seu tamanho total sugere.

Memória para o modelo por dólar

Uma das ordenações dessa listagem é memória para o modelo por dólar: gigabytes de memória para o modelo (VRAM, ou memória unificada) divididos pelo preço atual na Amazon, com a data do preço mostrada. Ela responde a "o que comporta o maior modelo por este dinheiro". Não é uma classificação de qualidade nem de velocidade, e uma comissão nunca a altera.

O que estas estimativas não são

• Não são benchmarks. Nenhum modelo foi executado nas máquinas listadas para produzi-las.
• Não cobrem duração da bateria, calor, ruído nem desempenho sustentado sob carga.
• Assumem um usuário, uma conversa e pesos Q4_K_M no estilo do llama.cpp. Outros runtimes, outras quantizações e contextos mais longos mudam a resposta.