O artigo de lançamento do Gemini 4 Argon publicado pelo Google apresenta uma tabela de benchmarks de 19 linhas e, pela nossa contagem, o Argon lidera 13 linhas isoladamente e empata em uma. As cinco linhas em que ele perde não são por acaso. O GPT-6 Astra leva o FrontierSWE v2, o Terminal-Bench Science e o OSWorld-2.0; o Claude Opus 5.5 leva o Terminal-bench 4.0 e o PostTrainBench. Trata-se de ambas as linhas do Terminal-Bench, uma linha de codificação agêntica, a linha de engenharia de ML e uma das duas linhas de uso de computador: justamente a maior parte do trabalho na qual uma equipe de codificação realmente gasta suas execuções. E a questão não é mais hipotética. Desde 13 de outubro de 2026, o Argon está disponível para o público geral na API paga do Gemini como gemini-4-argon.
Portanto, a pergunta “qual modelo vence?” tem três respostas diferentes dependendo da linha analisada — e, para uma equipe que opera múltiplos agentes de codificação, isso não é um detalhe irrelevante. Se todos os Agentes do painel rodarem no mesmo Runtime, a equipe herda as derrotas de um laboratório junto com suas vitórias, e cada novo lançamento reabre a discussão. Qual agente está em qual tarefa, o que foi concluído, o que precisa de revisão: nada disso deveria depender de quem liderou uma tabela esta semana.
TL;DR
Nenhum laboratório de fronteira domina todas as linhas, nem mesmo em sua própria tabela. Encare cada lançamento como evidência para roteamento, e não como um motivo para migração: mantenha mais de um Runtime conectado, documente a regra de roteamento (um padrão, as condições que direcionam uma Task a um Agente diferente e quem faz a revisão) e teste-a em três Tasks da sua própria base de código. O Astra roda pelo Codex, o Opus 5.5 pelo Claude Code, e os modelos Gemini pelo Gemini CLI com uma chave paga. O Google não afirmou expressamente que o Gemini CLI suporta o Argon, portanto faça um teste de fumaça (smoke test) com gemini-4-argon antes de atribuir Tasks reais a ele.
O que a tabela do Google diz, por tipo de tarefa
As linhas que realmente importam para agentes de codificação, agrupadas pelas próprias categorias do Google:
| Tipo de tarefa (categoria do Google) | Linha | Líder na tabela do Google | Ressalva |
|---|---|---|---|
| Codificação agêntica | DeepSWE v1.1 | Argon 77,9% (Opus 5.5 74,2%, Astra 74,1%) | Calculado pelo próprio Google (Argon) |
| Codificação agêntica | FrontierSWE v2 | Astra 65,5% (Opus 5.5 62,3%, Argon 55,0%) | Leaderboard do Proximal |
| Codificação agêntica | Terminal-bench 4.0 | Opus 5.5 66,4% (Astra 58,2%, Argon 57,4%) | Calculado pelo próprio Google (Argon) |
| Codificação agêntica | Vibe Code Bench | Argon 91,9% (Opus 5.5 90,3%, Astra 89,6%) | 2,3 pontos separam todos os quatro modelos |
| Engenharia de ML | PostTrainBench | Opus 5.5 49,3% (Argon 45,3%, Astra 44,3%) | Calculado pelo Google para todos os modelos |
| Ciência e matemática | Terminal-Bench Science 0.1 | Astra 68,1% (Opus 5.5 63,3%, Argon 57,6%) | Argon executado com timeout do verificador 6x maior |
| Uso de computador | OSWorld-2.0, offline subset | Astra 72,6% (Argon 69,2%) | Sem linha para o Opus 5.5 |
| Uso de computador | Agent’s Last Exam | Argon 39,5% (Opus 5.5 38,2%, Astra 34,2%) | Calculado pelo próprio Google (Argon) |
| Contexto longo | GraphWalks 256K to 1M | Argon 84,2% (Astra 71,8%, Opus 5.5 66,8%) | Calculado pelo Google para todos os modelos |
Apenas a categoria de codificação agêntica conta com quatro linhas e três líderes distintos. A vitória absoluta do Argon ocorre em trabalho de conhecimento, contexto longo e linhas multimodais — fatores de menor impacto para uma equipe cujas Tasks terminam em um diff.
Analise esses números com um certo desconto: esta é a tabela do Google. O próprio Google executou o Argon em várias linhas, os números dos concorrentes são, em sua maioria, autorreportados ou extraídos de leaderboards públicos, e os ambientes de teste diferem. A metodologia de avaliação detalha a fonte de cada célula. Resultados independentes divulgados desde o lançamento também divergem entre si: o Humanity’s Sixth Sense da Scale AI coloca o Argon em primeiro com 55,4% contra 53,6% do GPT-6 Astra; o Cursor o avalia no mesmo nível do Opus 5.5 em seu CursorBench; e a Artificial Analysis posiciona o Argon (High) em oitavo lugar entre 216 variantes listadas até 15 de outubro.
O preço também não encerra a questão. O Argon custa US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de saída até 30 de novembro de 2026, passando para US$ 4 e US$ 20 a partir de 1º de dezembro. Essa tarifa posterior é exatamente a mesma cobrada pelo Opus 5.5. Já o Astra tem preço de tabela fixado em US$ 10 e US$ 50.
Nenhum laboratório domina todas as linhas, portanto nenhum deve controlar todo o painel
Os dados dos próprios fornecedores sustentam esse argumento, não nós. Se a tabela do próprio Google, criada pelo Google para destacar o modelo do Google, ainda cede cinco linhas a dois concorrentes, não existe um único melhor modelo para agentes de codificação. Existe o melhor modelo para determinado tipo de Task, neste trimestre, no harness de alguém.
Isso altera a dinâmica no dia de um lançamento. A decisão tentadora é migrar: trocar o Runtime padrão, refazer toda a configuração e mudar os hábitos da equipe. O caminho mais econômico é tratar o novo modelo como mais um candidato para as Tasks em que seus resultados são fortes, deixando o restante do painel intacto. Já argumentamos que o melhor agente de codificação importa menos do que a forma como você gerencia o trabalho; uma tabela em que três modelos vencem em pontos diferentes é esse argumento traduzido em números.
O dilema real de decisão se resume a:
- Mantenha um único Runtime padrão se a maioria das suas Tasks tiver escopo similar e apenas uma pessoa revisar tudo. Um segundo Runtime significa uma segunda configuração para manter, uma segunda fatura e um segundo conjunto de possíveis modos de falha.
- Utilize dois ou três Runtimes se as suas Tasks se dividirem entre operações intensivas em terminal, verificação de interface gráfica (UI) e leitura de grandes bases de código — pois é exatamente aí que a tabela também se divide.
Documente a regra de roteamento
Uma regra de roteamento que existe apenas na cabeça de um engenheiro é um mero hábito, e hábitos não sobrevivem à chegada de novos membros ou à semana de um lançamento. Registre-a onde toda a equipe possa ler:
Routing rule v1 (re-test after every frontier launch)
Default
The Agent on your current default Runtime, until your own
comparison says otherwise.
Send the Task to the Claude Code Agent (Opus 5.5 set in Claude Code) when
- most of the work happens in a terminal: builds, CI repair, setup [Terminal-bench 4.0]
- it is training or evaluation plumbing for a model pipeline [PostTrainBench]
Send the Task to the Codex Agent (GPT-6 Astra set in Codex) when
- the change has to be verified by driving a desktop or browser UI [OSWorld-2.0]
- it is scientific or data work done mostly in a terminal [Terminal-Bench Science]
Send the Task to the Gemini CLI Agent (gemini-4-argon) when
- it needs a very large codebase or log read in one pass [GraphWalks]
- note: the 1M window is shared by input, thinking and output, and
Gemini CLI support is unverified. Smoke-test before this line routes work.
Escalate
If a run fails its acceptance checks twice, reassign the Task to the next
Agent in this rule. The failed runs stay on the Task as evidence.
Review
An Agent on a different Runtime from the author reads the diff and the
evidence. A person accepts the result.
Cada condição cita a linha do benchmark que a fundamenta e um perfil de Task que você reconhece facilmente no dia a dia. A diretriz de revisão é a mais crucial: um modelo analisando um diff que ele próprio não gerou atua como uma segunda opinião de baixo custo, mantendo a aprovação final sob a responsabilidade de uma pessoa.
Onde essa regra deve residir depende de quem faz o roteamento. Se pessoas escolhem o Responsável (Assignee), ela pertence às convenções documentadas do Space. Se um líder de Crew faz o roteamento, ela deve constar nas instruções da Crew. De qualquer forma, o resultado retorna para a mesma Task, preservando o histórico comparativo em um único lugar. O artigo Qual modelo para qual tarefa de codificação aprofunda essa correspondência entre tipos de tarefa e papéis de modelo.
Teste a regra na sua própria base de código antes de confiar nela
Uma linha de benchmark credencia um tipo de Task na lista de opções; a sua base de código decide o padrão. O método descrito em como comparar agentes de codificação na sua própria base de código se alinha perfeitamente a esta tabela, pois ela já aponta quais três Tasks selecionar:
- Uma Task com foco intenso em terminal, como uma pipeline de CI com falha.
- Uma Task cuja modificação precise ser verificada por meio de uma interface (UI).
- Uma questão técnica que exija carregar grande parte do repositório no contexto.
Forneça a cada Agente a mesma descrição de Task e os mesmos critérios de aceitação, utilizando o modo Criar diretório temporário para que cada execução disponha de sua própria worktree. Em seguida, pontue com base no que retorna para a Task, e não nas alegações do agente: o diff gerado, as checagens e seus resultados, as perguntas feitas e o tempo que uma pessoa levou para aprovar a entrega.
O Argon pode ser incluído nessa comparação imediatamente, assim que um smoke prompt de uma linha com gemini-4-argon for validado no seu Gemini CLI. Execute as mesmas três Tasks nele antes de fazer qualquer outra alteração. O comparativo Opus 5.5 vs. GPT-6 Sol como runtime padrão aborda a ótica de custo por tarefa concluída dessa mesma decisão.
Onde cada modelo roda, em 15 de outubro de 2026
| Modelo | Runtime | O que é necessário em um Computer | Preço de tabela por 1M de tokens (entrada / saída) |
|---|---|---|---|
| GPT-6 Astra | Codex | Codex configurado com o Astra e uma conta ou chave que tenha acesso | US$ 10 / US$ 50 |
| Claude Opus 5.5 | Claude Code | Claude Code configurado com o Opus 5.5 e uma conta ou chave que tenha acesso | US$ 4 / US$ 20 |
| Gemini 4 Argon | Gemini CLI, não confirmado | Uma chave paga da API do Gemini, gemini-4-argon como modelo e um smoke prompt bem-sucedido |
US$ 2 / US$ 10 até 30 de nov., depois US$ 4 / US$ 20 |
| Outros modelos Gemini | Gemini CLI | Uma chave paga da API do Gemini, uma chave da Gemini Enterprise Agent Platform ou uma licença do Code Assist Standard ou Enterprise | Varia conforme o modelo |
As linhas do Gemini guardam uma pegadinha. Desde 18 de junho de 2026, o Gemini CLI não oferece mais suporte a contas Google AI Pro, Ultra ou individuais gratuitas do Code Assist, segundo o aviso de transição do Google. Os planos Pro e Ultra incluem o Argon no aplicativo do Gemini, mas uma assinatura não equivale a uma chave de API, e o Argon não conta com um plano gratuito de API.
O Sharkly não impõe modelos. A documentação de Agentes expressa isso com clareza: “O Agente segue o modelo padrão do Runtime. Ele não garante nem exibe o nome de um modelo específico.” Você define o modelo por meio dos Argumentos personalizados no Agente ou no Runtime, ou nas configurações da própria ferramenta no Computer. Portanto, “o Agente do Codex” na regra de roteamento refere-se a um Agente em um Runtime Codex configurado para utilizar o Astra.
Os procedimentos de configuração estão detalhados em GPT-6 Astra no Sharkly, Claude Opus 5.5 no Sharkly e, para a configuração do Gemini CLI e a transição para o Argon, em Gemini 4 Argon para agentes de codificação.
A tabela muda; o painel não deveria
O próximo lançamento irá redesenhar essa tabela. O que deve permanecer estável é tudo aquilo que cerca o modelo: a regra de roteamento, as Tasks, as evidências que cada execução devolve e a pessoa responsável por aprovar o resultado. Agentes pesquisam, executam, testam e reportam. Pessoas definem o direcionamento, concedem autoridade e validam a entrega final.
Se você deseja continuar trabalhando com múltiplos agentes de codificação em vez de se prender a um único ecossistema, é exatamente em torno desse desafio que o Sharkly foi projetado.



