Gemini 4 Argon: os benchmarks de código não coincidem
Argon lidera no DeepSWE, mas fica atrás noutros testes de código. Comparo os benchmarks, o milhão de tokens de saída e o acesso ainda limitado.

Nesta página
- O que mostram os benchmarks de código do Gemini 4 Argon?
- Porque dão os benchmarks de código resultados diferentes?
- O Gemini 4 Argon tem uma janela de contexto de um milhão de tokens?
- Quem pode usar o Gemini 4 Argon no lançamento?
- Quanto vai custar o Gemini 4 Argon?
- O que testaria quando o acesso fosse mais amplo?
A Google anunciou o Gemini 4 Argon a 30 de setembro de 2026, e os resultados de programação dão-me motivos para o testar antes de mudar de modelo. Argon lidera a comparação da Google no DeepSWE, mas fica atrás de Astra e Opus noutros testes. O limite de saída também sobe para um milhão de tokens, com acesso inicial através de um programa restrito de ciberdefesa. [1] [2]
O que mostram os benchmarks de código do Gemini 4 Argon?
Argon ganha a comparação no DeepSWE, mas a tabela de lançamento da Google mostra que o primeiro lugar muda consoante a tarefa. Consideraria Argon para trabalhar em repositórios, sem o tratar como substituto automático de Astra ou Opus. Estas três linhas explicam porquê. [2]
Comparação de lançamento da Google DeepMind, consultada a 1 de outubro de 2026. As percentagens vêm de benchmarks e condições diferentes; compare os modelos na mesma linha, não as linhas entre si. [2, 3]
| Benchmark de código | Gemini 4 Argon | GPT-6 Astra | Claude Opus 5.5 |
|---|---|---|---|
| DeepSWE v1.1 | 77,9 % | 74,1 % | 74,2 % |
| FrontierSWE v2 | 55,0 % | 65,5 % | 62,3 % |
| Terminal-bench 4.0 | 57,4 % | 58,2 % | 66,4 % |
No DeepSWE v1.1, Argon atinge 77,9 %, à frente dos 74,1 % de Astra e dos 74,2 % de Opus 5.5. É um resultado útil para desenvolvimento de software. Porém, o FrontierSWE v2 coloca Astra nos 65,5 %, contra os 55,0 % de Argon, enquanto o Terminal-bench 4.0 dá 66,4 % a Opus, contra 57,4 % a Argon. São diferenças de 10,5 e 9,0 pontos percentuais, calculadas a partir dos valores publicados. [2]
A diferença importa porque «o melhor a programar» seria uma conclusão demasiado ampla para esta tabela. Resolver um problema delimitado e concluir um trabalho longo podem exigir capacidades diferentes a um agente. Os resultados sugerem que a tarefa deve determinar o modelo que testo primeiro. É a mesma distinção prática que explico em porque os benchmarks de IA não refletem toda a qualidade de um modelo.
Os bons resultados de Argon também surgem fora da programação. A Google publica 51,3 % para Argon em High no AutomationBench, face aos 41,4 % de Astra em Max e aos 42,5 % de Opus 5.5 em Max com fallbacks predefinidos. Na avaliação da Zapier, um passo recusado é encaminhado para o modelo de reserva predefinido do fornecedor. Isso justifica testar processos automatizados, mas o resultado não elimina as fraquezas visíveis nas linhas de código. [2] [11]
Porque dão os benchmarks de código resultados diferentes?
Os benchmarks medem trabalhos diferentes, e a Google combina também resultados obtidos com métodos distintos. O modelo é apenas parte do sistema avaliado: as instruções, as ferramentas e o tempo disponível podem alterar o resultado. O relatório de avaliação da Google apresenta os detalhes necessários para ler a tabela. [3]
No DeepSWE, a Google avaliou Argon com o harness mini-swe, o software que fornece ferramentas ao modelo e executa a tarefa. Os valores dos concorrentes vêm da classificação do benchmark ou das fichas de sistema dos fornecedores. A Google publica geralmente os seus resultados com o nível de raciocínio mais alto; pass@1 mede o sucesso numa única tentativa, sem votação por maioria entre respostas geradas em paralelo. Esta regra tem exceções, pelo que não se aplica a todas as linhas. [3]
A qualidade dos testes do DeepSWE também merece atenção. Na auditoria de 7 de setembro de 2026, a Epoch AI encontrou erros em pelo menos 23 das 113 tarefas, nas quais soluções válidas podiam ser classificadas como falhas. A auditoria não demonstra que a pontuação de Argon esteja errada, mas dá-me um motivo para tratar a diferença exata com cuidado, em vez de presumir que todas as tarefas eram testes fiáveis. [10]
O FrontierSWE é uma exceção importante. A classificação pública da Proximal apresenta a média de cinco tentativas em cada uma das 34 tarefas, com até 20 horas por tentativa no seu ambiente de agentes proximus. Mostra ainda o pior e o melhor resultado. Esta é uma medida diferente da taxa de sucesso numa tentativa; as execuções longas ajudam a perceber se um agente consegue continuar a trabalhar num pedido exigente. [4]
Existe também uma verificação independente das capacidades gerais. Nos dados de 1 de outubro do Intelligence Index v4.3.2, a Artificial Analysis atribui a Argon em High uma pontuação arredondada de 53, tal como a Astra em Max. Opus 5.5 em Max com fallback predefinido obtém 58. As configurações diferem e o índice combina dez avaliações, sobretudo com texto em inglês; não é uma percentagem de tarefas de repositório concluídas. É outro motivo para testar Argon sem perder de vista os resultados individuais de programação. [5] [7] [8]
É por isso que olho para a configuração completa ao comparar Claude e Codex em funcionalidades grandes. Se uma execução tiver mais tempo ou ferramentas diferentes, o resultado pode continuar a ser útil. Responde, porém, a uma pergunta diferente de um teste em que muda apenas o modelo.
O Gemini 4 Argon tem uma janela de contexto de um milhão de tokens?
O anúncio do milhão de tokens diz respeito à saída. A Google afirma que Argon aumenta o limite de saída de 64 000 para um milhão de tokens, permitindo respostas muito mais longas. Isso estabelece quanto o modelo pode produzir, mas não anuncia uma nova janela de contexto de entrada. [1]
A distinção tem consequências práticas. A janela de contexto limita o material com que o modelo pode trabalhar num pedido; o limite de saída determina quanto pode gerar. Uma saída mais longa poderá ajudar quando o trabalho exige bastante código ou um relatório detalhado, mas não estabelece, por si só, quanto de um repositório pode ser fornecido como entrada.
O novo limite é cerca de 15,6 vezes o anterior de 64 000 tokens. É um cálculo feito a partir dos valores da Google, não uma afirmação de que a tarefa dura 15,6 vezes mais ou se torna igualmente mais fiável. O limite indica onde a geração tem de parar, não se vale a pena guardar tudo o que foi produzido até esse ponto.
Interessam-me primeiro os trabalhos que antes paravam sem produzir um resultado completo. Manteria a gestão de contexto para agentes de programação, porque um orçamento de geração maior não justifica retirar as instruções e as informações do repositório que tornam a tarefa compreensível. A avaliação continuaria a procurar uma alteração que possa rever, não um número de tokens.
Quem pode usar o Gemini 4 Argon no lançamento?
O acesso começa com equipas de ciberdefesa de confiança no programa Fairwind da Google. A empresa anuncia uma disponibilidade mais ampla depois, começando pelos clientes pagantes da API e pelos subscritores do Google AI Ultra, mas não indica uma data para essa fase. A 1 de outubro de 2026, o acesso está a ser alargado por fases e ainda não está aberto a todos os programadores. [1]
A Google DeepMind descreve Fairwind como um programa de acesso antecipado para organizações aprovadas que trabalham em segurança defensiva e investigação. Os parceiros podem incluir governos e responsáveis por infraestruturas críticas, sujeitos a controlos de acesso e restrições de utilização. O programa exige uma aprovação separada: uma conta paga normal não garante acesso à distribuição inicial de Argon. [6]
A ênfase do lançamento na cibersegurança tem um benchmark a apoiá-la. A tabela da Google dá 68,0 % a Argon no CWE-bench v1, igual a Astra e ligeiramente acima dos 67,0 % de Opus 5.5. O CWE-bench testa a auditoria e correção de vulnerabilidades: Argon usa Antigravity, Astra usa Codex e Opus usa Claude Code. As pontuações comparam modelos com as ferramentas dos agentes. Sustentam, portanto, um bom resultado do sistema Argon testado, não uma vantagem do modelo isolado. [2] [9]
Para um programador que escolhe ferramentas agora, a restrição de acesso importa tanto como uma pontuação promissora. Posso preparar uma tarefa de comparação, mas ainda não incorporar um anúncio no trabalho em produção. Esperaria pela via de acesso documentada e pela configuração do modelo antes de alterar uma integração.
Quanto vai custar o Gemini 4 Argon?
A Google anuncia preços iniciais da API de 2 dólares por milhão de tokens de entrada e 10 por milhão de saída. Depois passam para 4 e 20 dólares. A entrada em cache recebe um desconto de 95 %. São preços anunciados para a próxima abertura mais ampla; a Google não especifica a duração do período inicial. [1]
Preços da API anunciados. Os preços da entrada em cache são calculados com o desconto de 95 % indicado pela Google. Não foi anunciada uma data de fim do período inicial. [1]
| USD por milhão de tokens | Preço inicial | Preço posterior |
|---|---|---|
| Entrada sem cache | 2,00 | 4,00 |
| Entrada em cache | 0,10 | 0,20 |
| Saída | 10,00 | 20,00 |
Os preços normais por token serão o dobro dos iniciais, pelo que faria o orçamento do trabalho recorrente com 4 e 20 dólares. Um pedido hipotético com 100 000 tokens de entrada sem cache e 10 000 de saída custaria 0,30 dólares no início e 0,60 depois. São cálculos da cobrança de tokens, não custos medidos por tarefa.
O limite de um milhão de tokens de saída torna essa parte da fatura mais visível. Gerar um milhão de tokens de saída faturados custaria 10 dólares ao preço inicial ou 20 depois, antes dos custos de entrada. O modelo não precisa de atingir o limite em cada pedido. Definiria um orçamento de geração adequado à tarefa, em vez de preferir a resposta mais longa permitida.
Esta é a distinção por detrás do menor custo medido por tarefa do GPT-6.1 Sol: o preço por token e o custo do trabalho concluído são medidas diferentes. O preço de Argon será mais útil quando uma avaliação registar os tokens necessários para produzir um resultado aceite.
O que testaria quando o acesso fosse mais amplo?
Testaria uma tarefa suficientemente longa para revelar as diferenças entre os benchmarks de programação e mediria o trabalho necessário para aceitar o resultado. A pontuação de Argon no DeepSWE justifica esse teste; os resultados inferiores no FrontierSWE e no Terminal-bench indicam-me que devo observar a execução continuada, em vez de avaliar só a primeira resposta.
A comparação partiria do mesmo commit do repositório, com as mesmas instruções, ferramentas e verificações de aceitação. Incluiria uma correção delimitada e uma alteração maior com vários passos, repetiria as execuções e manteria as falhas nos resultados. O tempo de revisão contaria a par do custo da API: um patch barato que exige muitas reparações não é trabalho concluído a baixo custo.
Separaria também a conclusão da tarefa da quantidade produzida. Uma resposta mais longa ajuda se entregar a parte que faltava do trabalho; se acrescentar código alheio à tarefa, cria mais esforço de revisão. Quero saber se Argon consegue terminar a alteração maior com menos correções ao preço normal. É a comparação que prepararia enquanto o acesso se alarga.





