Artificial Analysis Coding Agent Index Coloca Claude em Primeiro, mas o Custo Reordena os Líderes
A Artificial Analysis colocou Claude Sonnet 5.5 em primeiro, com 68 pontos, mas seus novos resultados sobre agentes de programação revelam uma história de custos bem menos confortável.
O Artificial Analysis Coding Agent Index posiciona Claude Code com Sonnet 5.5 em esforço máximo à frente de Gemini 4 Argon e GPT-6.1 Sol. Ainda assim, o vencedor consome muito mais tempo, tokens e gastos de API por tarefa do que seus novos rivais mais próximos.
Essa diferença muda a decisão prática para equipes de desenvolvimento. Claude lidera o benchmark composto, enquanto Codex com GPT-6.1 Sol oferece resultados quase comparáveis usando uma fração dos recursos medidos. Gemini 4 Argon fica entre os dois, combinando uma pontuação agregada forte com uma vantagem notável em tarefas de software de longo horizonte.
A publicação original do benchmark apresenta os três lançamentos como novos líderes. Os resultados subjacentes sustentam sua importância, mas não um pódio simples de três posições. Outras configurações, incluindo Claude Opus 5.5, também aparecem perto do topo.
Mais importante, cada resultado pertence a um modelo, uma configuração de raciocínio e um harness de agente. O ranking não testa apenas a inteligência abstrata do modelo. Ele testa sistemas completos de programação, como Claude Code, Codex e Antigravity CLI.
Essa distinção está no centro da história. As equipes já não escolhem apenas o modelo com a pontuação mais alta. Elas escolhem quanto tempo adicional e computação vale um ponto extra no benchmark.
O Que Mudou no Artificial Analysis Coding Agent Index
Os resultados mais recentes separam a liderança em benchmarks da eficiência operacional com mais clareza do que comparações anteriores de modelos.
A Artificial Analysis avalia agentes de programação em trabalho de ponta a ponta, em vez de questões isoladas de conclusão de código. Seu índice combina modificação de repositórios, operação de terminal e compreensão de bases de código em uma única pontuação.
Claude Code executando Sonnet 5.5 em esforço máximo lidera com 68 pontos. Seus resultados por componente são 72 por cento no DeepSWE v1.1, 66 por cento no Terminal-Bench 4.0 e 67 por cento no SWE-Atlas-QnA.
Antigravity CLI executando Gemini 4 Argon marca 64. Ele alcança 79 por cento no DeepSWE, 56 por cento no Terminal-Bench e 56 por cento em perguntas sobre repositórios.
Codex com GPT-6.1 Sol em esforço xhigh marca 63. Essa configuração registra 73 por cento no DeepSWE, 55 por cento no Terminal-Bench e 61 por cento no SWE-Atlas-QnA.
Esses totais deixam apenas cinco pontos entre Claude e Sol. No entanto, a Artificial Analysis mediu a configuração de Claude usando cerca de 8,7 vezes mais tokens por tarefa. Ela também foi executada por quase seis vezes mais tempo.
O custo medido de API mostra uma diferença ainda maior. A configuração de Claude em esforço máximo custa cerca de 13,6 vezes mais por tarefa do que Sol em xhigh no Codex.
Gemini 4 Argon fica entre esses extremos. Seu custo medido é aproximadamente 5,6 vezes o de Sol, enquanto sua vantagem no índice é de um ponto. Ele consome cerca de 4,3 vezes mais tokens e leva mais do que o dobro do tempo.
A comparação do benchmark conta, portanto, duas histórias. Claude tem a maior pontuação composta, enquanto Sol oferece a relação mais forte entre pontuação medida e custo entre essas três configurações.
A Artificial Analysis também informa várias configurações de esforço para Sonnet 5.5. Esse detalhe importa porque esforço máximo não é a configuração padrão de Claude Code.
Sonnet 5.5 em esforço xhigh marca 63, igualando a pontuação de destaque de Sol. Ele usa mais que o dobro dos tokens de Sol e tem um custo medido mais de três vezes maior.
Em esforço high, Sonnet marca 55. Em esforço medium, o padrão no Claude Code, marca 46. Esses resultados demonstram o quanto o orçamento de raciocínio muda o produto que está sendo avaliado.
O mesmo padrão aparece nos resultados de Sol. GPT-6.1 Sol em esforço medium marca 61, apenas dois pontos abaixo de sua configuração xhigh. Seu custo medido e tempo de execução também caem substancialmente.
Raciocínio máximo não produz automaticamente o melhor resultado. O resultado xhigh de Sol supera seu resultado em esforço máximo por três pontos na avaliação publicada.
Esse resultado contraintuitivo lembra que benchmarks de agentes contêm variância. Mais tempo de inferência pode ajudar, mas também pode criar trajetórias mais longas, chamadas de ferramentas desnecessárias ou reconsideração improdutiva.
O vencedor da manchete continua sendo Claude Code com Sonnet 5.5 em esforço máximo. A mudança mais consequente é que os compradores agora podem ver quão caro é obter seus últimos cinco pontos.
O Benchmark Mede Sistemas, Não Apenas Modelos
A pontuação de um agente de programação reflete a interação entre um modelo, seu harness, suas ferramentas e seu orçamento de raciocínio.
O Coding Agent Index v1.5 usa três componentes com pesos iguais. De acordo com a metodologia publicada do índice, cada componente testa uma parte diferente do trabalho de software.
DeepSWE v1.1 contém 113 tarefas de longo horizonte. Os agentes devem modificar repositórios existentes, enquanto ambientes verificadores separados avaliam se seus patches enviados passam.
Terminal-Bench 4.0 contém 66 tarefas que abrangem áreas como engenharia de software, aprendizado de máquina, segurança e administração de sistemas. Os agentes trabalham em ambientes de linha de comando, e então suítes de testes avaliam seus resultados.
SWE-Atlas-QnA contém 124 perguntas sobre repositórios. Essas tarefas medem se um agente consegue rastrear código desconhecido e explicar com precisão seu comportamento.
Cada tarefa recebe três tentativas. A Artificial Analysis calcula resultados de pass-at-one para cada componente e, em seguida, atribui peso igual aos três componentes no índice composto.
Essa estrutura é mais ampla do que um teste convencional de geração de código. Ela recompensa agentes que conseguem inspecionar repositórios, escolher ferramentas, operar terminais, manter contexto e se recuperar de erros.
Ela também torna o harness importante. Um harness é a camada de software que conecta um modelo a arquivos, terminais, instruções, gerenciamento de contexto e execução de ferramentas.
Claude Code, Codex e Antigravity CLI não oferecem fluxos de trabalho idênticos. Eles podem empacotar o contexto de modo diferente, incentivar padrões distintos de uso de ferramentas ou impor limites diferentes.
Consequentemente, o benchmark não pode estabelecer que Sonnet 5.5 é sempre um modelo de programação melhor do que GPT-6.1 Sol. Ele estabelece que uma configuração testada de Claude Code teve pontuação superior a uma configuração testada de Codex.
A distinção fica visível nas pontuações dos componentes. Gemini 4 Argon lidera o trio no DeepSWE com 79 por cento, apesar de ficar abaixo de Claude no geral.
Sol supera por pouco Sonnet em esforço máximo no DeepSWE. Claude constrói sua liderança geral por meio do Terminal-Bench e do SWE-Atlas-QnA, onde obtém margens maiores.
Os resultados, portanto, descrevem perfis de capacidade diferentes. Gemini parece mais forte nas alterações de repositório de longo horizonte do benchmark. Claude parece mais equilibrado entre trabalho de terminal e compreensão de repositórios.
Sol continua competitivo nos três, usando menos recursos medidos. Ele não vence nenhum componente incluído contra os dois rivais, mas evita uma fraqueza grave.
Esse equilíbrio importa no uso em produção. Uma equipe que mantém um repositório grande pode valorizar mais a conclusão de patches do que respostas a perguntas sobre repositórios. Outra equipe pode precisar de trabalho confiável de terminal em ambientes variados.
O número único do índice ajuda os leitores a examinar o cenário. Ele não deve substituir os resultados por componente ao selecionar uma ferramenta para uma carga de trabalho definida.
A Artificial Analysis também agrega dados de tokens, custo e tempo em todo o mesmo conjunto de benchmarks. Telemetria ausente é excluída da média relevante, em vez de ser tratada como zero.
Seu cálculo de custo considera tokens de entrada comuns, entrada em cache, gravações em cache, raciocínio e saída quando os provedores precificam essas categorias separadamente. Ele representa o custo de API pago por token, não o preço de assinaturas.
O custo informado também exclui várias despesas operacionais. Ele não inclui integração de engenharia, revisão humana, configuração de ambiente, controles de segurança ou as consequências de um patch defeituoso.
Essas exclusões não enfraquecem a comparação. Elas definem o que ela pode responder: quanto uso de modelo os agentes avaliados consumiram sob esse teste.
Elas também explicam por que a execução mais barata no benchmark nem sempre produzirá o pull request aceito mais barato. Um resultado mais fraco pode criar custos adicionais de revisão, correção e nova execução.
Portanto, as equipes devem avaliar tanto o custo direto de inferência quanto o custo por resultado bem-sucedido. O índice publicado fornece ingredientes úteis, mas não calcula essa medida completa de negócio.
Claude Sonnet 5.5 Vence em Desempenho com um Alto Prêmio de Eficiência
A liderança de Claude é real dentro deste benchmark, mas o esforço máximo transforma uma vantagem modesta de pontuação em um grande compromisso de recursos.
A Anthropic lançou Sonnet 5.5 em 28 de setembro de 2026. A empresa o posiciona como um complemento mais rápido e de menor custo ao Opus 5.5 para tarefas diárias delimitadas, depuração e criação de documentos.
Os detalhes do lançamento do modelo da Anthropic enfatizam o esforço ajustável. Configurações menores priorizam velocidade e economia, enquanto configurações maiores dão ao modelo mais tempo para raciocinar e verificar seu trabalho.
Os resultados da Artificial Analysis mostram os dois lados desse design. Elevar Sonnet de esforço medium para máximo aumenta seu índice de 46 para 68.
Essa melhoria de 22 pontos é substancial. Ela vem acompanhada de aproximadamente 21 vezes mais tokens, mais de dez vezes o tempo de execução e quase 23 vezes o custo medido de API.
O esforço máximo também produz trajetórias de agente muito longas. A Artificial Analysis registra cerca de 266 turnos por tarefa e 27,7 milhões de tokens totais para a configuração líder.
Esses números não significam que toda tarefa real consumirá os mesmos recursos. Eles mostram o comportamento médio em um exigente conjunto de benchmarks com centenas de tentativas de tarefas.
Eles também esclarecem como o modelo vence. A configuração de melhor desempenho não está apenas produzindo uma resposta mais inteligente com o mesmo orçamento. Ela está passando muito mais tempo interagindo com seu ambiente.
Essa estratégia compensa na pontuação composta. Claude lidera Gemini por quatro pontos e Sol por cinco. Ele também registra os melhores resultados do trio em dois dos três benchmarks de componentes.
O prêmio fica mais difícil de justificar quando as configurações de menor esforço de Claude entram na comparação. Sonnet em xhigh iguala a pontuação de 63 pontos de Sol, mas consome mais tokens, tempo e gastos medidos.
Em esforço high, Claude fica oito pontos atrás de Sol xhigh. Seu uso de recursos é mais próximo ao de Sol, mas a diferença de desempenho se torna significativa.
Em esforço medium, Claude se torna muito mais barato e rápido do que sua configuração máxima. No entanto, sua pontuação fica 17 pontos abaixo de Sol xhigh e 18 pontos abaixo de Gemini.
Não há contradição entre esses resultados. A Anthropic permite que usuários comprem mais raciocínio em tempo de teste, e o benchmark mostra que esse raciocínio adicional pode elevar a conclusão de tarefas.
A troca envolve escala. Um desenvolvedor individual pode aceitar uma execução longa e cara para uma migração difícil. Uma empresa que processa milhares de mudanças rotineiras enfrenta um cálculo diferente.
A melhor configuração também pode variar durante um único fluxo de trabalho. Uma equipe pode usar esforço medium para exploração, esforço high para implementação e esforço máximo apenas para falhas persistentes.
Essa estratégia de roteamento preservaria o acesso à capacidade máxima do Claude sem aplicar seu maior orçamento de recursos a todos os tickets. Ela exige medição e regras claras de escalonamento.
A vitória do Claude no benchmark é, portanto, mais relevante para tarefas em que a qualidade da conclusão supera todas as outras restrições. Os exemplos incluem correções difíceis entre repositórios, migrações frágeis ou incidentes com alto custo de falha.
Ela é menos decisiva para manutenção de alto volume. Atualizações de dependências, pequenas refatorações, geração de testes e correções rotineiras de bugs geralmente favorecem qualidade aceitável a custo previsível.
É por isso que o Artificial Analysis Coding Agent Index não deve se tornar um atalho de compra. O resultado de 68 pontos representa uma configuração de teto, não um padrão automático.
GPT-6.1 Sol e Gemini 4 Argon pressionam Claude por direções diferentes
Sol desafia Claude em eficiência, enquanto Argon o desafia no trabalho de repositório de longo prazo.
A OpenAI apresentou o GPT-6.1 Sol em 29 de setembro, um dia após a Anthropic lançar o Sonnet 5.5. O Google veio em seguida com o Gemini 4 Argon em 30 de setembro.
O momento deu ao Artificial Analysis três novas configurações de ponta para comparar em poucos dias. Suas posições no benchmark revelam mais diferenciação do que suas descrições de lançamento sugerem.
A OpenAI descreve o Sol como um modelo quase flagship para programação, uso de computador e trabalho profissional a menor custo. Seu cartão de modelo do Sol oferece cinco configurações de raciocínio, de baixa a máxima.
No Coding Agent Index, xhigh é a melhor configuração testada do Sol. Ela obtém 63 pontos, enquanto o esforço máximo obtém 60.
Esse resultado enfraquece a suposição de que o maior orçamento de raciocínio é sempre o mais seguro. Ele sugere que as equipes devem avaliar as configurações de esforço em benchmarks, em vez de selecionar o rótulo mais alto por padrão.
A principal vantagem do Sol é a consistência por unidade de recurso. A configuração xhigh conclui uma tarefa média em cerca de 15,5 minutos e consome 3,2 milhões de tokens.
O Claude com esforço máximo precisa de cerca de 90 minutos e 27,7 milhões de tokens. O Gemini precisa de cerca de 34,5 minutos e 13,7 milhões de tokens.
O Sol também tem desempenho competitivo em cada componente. Seu resultado de 73 por cento no DeepSWE supera os 72 por cento do Claude, embora fique atrás dos 79 por cento do Gemini.
Suas pontuações no Terminal-Bench e em perguntas sobre repositórios permanecem abaixo das do Claude. Essas desvantagens criam a diferença de cinco pontos no resultado composto.
Para muitas organizações, essa diferença será aceitável. O menor uso de recursos do Sol permite mais tentativas, adoção mais ampla ou verificação adicional dentro do mesmo orçamento.
A comparação não estabelece que o Sol seja universalmente mais econômico. Os preços dos provedores podem mudar, os padrões de cache diferem e as cargas de trabalho internas podem produzir distribuições de tokens diferentes.
Ela estabelece, porém, uma hipótese forte que vale a pena testar. Se as tarefas de uma equipe se assemelharem ao benchmark, o Codex com Sol pode oferecer uma relação custo-desempenho melhor do que o Claude com esforço máximo.
O Gemini 4 Argon cria um tipo diferente de pressão. O Google apresentou o Argon como um modelo para raciocínio sustentado em fluxos de trabalho profissionais complexos.
O anúncio do Argon do Google descreve usos internos envolvendo migração de código, otimização de memória, pesquisa e cibersegurança. Esses exemplos permanecem alegações da empresa, a menos que sejam reproduzidos de forma independente.
O Coding Agent Index acrescenta evidência de terceiros para uma parte dessa narrativa. O resultado de 79 por cento do Argon no DeepSWE é o mais forte entre os três sistemas destacados.
Esse resultado se alinha ao foco do Google em trabalho de longo prazo. Ele sugere que o Argon merece atenção para alterações extensas em repositórios, embora o Claude lidere o índice geral.
A pontuação mais fraca do Argon em perguntas sobre repositórios reduz seu resultado composto. Seu resultado de 56 por cento fica cinco pontos atrás do Sol e onze atrás do Claude.
O modelo também não tem a eficiência medida do Sol. O Argon ganha um ponto agregado sobre o Sol enquanto exige mais de quatro vezes mais tokens por tarefa.
Isso não torna a configuração irracional. Uma taxa mais alta de conclusão no DeepSWE pode superar o uso de recursos para organizações que enfrentam trabalho de implementação difícil.
A questão importante é a adequação à carga de trabalho. O Sol parece atraente como um generalista eficiente, enquanto o Argon oferece um sinal mais forte para modificação de repositórios de longa duração.
O Claude continua sendo o líder de desempenho equilibrado em sua configuração mais agressiva. A pressão do mercado vem de rivais que tornam diferentes partes dessa liderança menos valiosas.
Esse é um quadro competitivo mais saudável do que um ranking universal. Ele oferece às equipes de engenharia opções distintas, em vez de três marcas de modelos quase intercambiáveis.
Também aumenta a importância de manter fluxos de trabalho portáteis. As equipes devem evitar vincular prompts, práticas de revisão e preparação de contexto a um único modelo, a menos que o benefício seja mensurável.
Um registro pesquisável de requisitos, decisões e alterações anteriores pode tornar essas comparações mais consistentes. As equipes podem usar uma base de conhecimento de engenharia para preservar esse contexto entre testes com agentes.
O objetivo não é trocar de modelo toda semana. É tornar possível a troca e a avaliação quando a fronteira de desempenho se move.
O que os números não comprovam
Uma liderança de cinco pontos em um benchmark não garante código melhor, implantação mais segura ou menor custo total de engenharia dentro de uma organização real.
O Artificial Analysis publica mais detalhes metodológicos do que muitos operadores de rankings. Suas tarefas componentes, contagens de tentativas, métodos de pontuação e definições de eficiência são documentados.
Ainda assim, um benchmark continua sendo uma amostra. Ele não pode representar todas as linguagens, formatos de repositório, ambientes de dependências, políticas de segurança ou padrões de revisão.
O índice atribui pesos iguais a seus três componentes. Uma empresa real raramente valoriza perguntas sobre repositórios, operações de terminal e conclusão de patches em proporções exatamente iguais.
Uma organização pode passar a maior parte do tempo em serviços TypeScript com testes extensos. Outra pode manter código C embarcado, pipelines de dados ou sistemas financeiros regulados.
Sua classificação interna pode diferir do ranking público. Um modelo que se destaca no DeepSWE ainda pode ter dificuldades com frameworks proprietários ou código legado pouco documentado.
A pontuação pass-at-one também comprime diferenças importantes de qualidade. Dois patches podem passar em um verificador automatizado, embora difiram em manutenção, segurança, legibilidade ou adequação arquitetural.
O inverso também pode acontecer. Uma solução parcial útil pode falhar em uma condição do verificador e receber o mesmo resultado binário de uma tentativa inutilizável.
O SWE-Atlas-QnA introduz outra dependência. O Artificial Analysis usa um juiz automatizado para decidir se as respostas sobre repositórios atendem a todos os critérios exigidos.
A avaliação automatizada permite realizar testes em escala. Ainda assim, ela pode herdar ambiguidades, viés do modelo ou erros de correção, sobretudo em explicações com várias formulações válidas.
As médias agrupadas do benchmark também ocultam a dispersão. O custo médio não revela se a maioria das tarefas é previsível enquanto um pequeno grupo cria trajetórias extremamente longas.
Essa variância importa para o orçamento. Um serviço pode tolerar uma média moderada e, ainda assim, sofrer com execuções individuais que consomem tokens excessivos ou ocupam ambientes por horas.
O comportamento dos agentes também pode mudar após atualizações de produto. A seleção de ferramentas, a compressão de contexto, a lógica de repetição e instruções ocultas do sistema podem mudar sem um novo nome público de modelo.
Por esse motivo, o benchmark deve ser tratado como uma medição datada. Ele não é uma propriedade permanente do Claude Code, Codex, Antigravity CLI ou de seus modelos subjacentes.
O Claude com esforço máximo ilustra o risco de interpretar um resultado de teto como uma experiência padrão. A configuração avaliada no benchmark consome muito mais recursos do que o padrão médio do Claude Code.
O índice também compara gastos de API por token. Limites de assinatura, tarifas empresariais negociadas, processamento regional e infraestrutura interna podem alterar a economia real de uma equipe.
Os custos humanos também estão ausentes. Um agente mais lento pode ser aceitável se trabalhar de forma assíncrona. Um agente mais rápido pode ser mais valioso quando um desenvolvedor espera por feedback.
A carga de revisão é outra variável ainda não resolvida. Um patch barato que exige inspeção extensa pode custar mais no total do que um patch caro aceito após uma revisão curta.
A segurança merece cautela semelhante. Nenhuma das pontuações de destaque, por si só, estabelece que um agente siga acesso de privilégio mínimo, resista a instruções maliciosas em repositórios ou evite vazar contexto sensível.
O Google limitou a disponibilidade inicial do Argon enquanto realiza trabalho de segurança em etapas. Esse lançamento significa que a evidência de seu uso público pode continuar mais limitada do que a atenção do benchmark sugere.
As alegações dos fornecedores também exigem atribuição cuidadosa. Anthropic, OpenAI e Google destacam, cada uma, resultados favoráveis de avaliação em diferentes suítes e configurações.
Esses resultados podem ser precisos sem serem diretamente comparáveis. Diferentes harnesses, conjuntos de tarefas, orçamentos e regras de pontuação frequentemente produzem líderes diferentes.
O benchmark do Artificial Analysis melhora a comparabilidade ao executar as configurações em uma única estrutura. Ele não pode eliminar todas as diferenças introduzidas por agentes proprietários e interfaces de modelos.
Líderes de engenharia devem reproduzir um pequeno teste interno antes de padronizar. Um conjunto de testes útil inclui tickets concluídos, casos de falha conhecidos e restrições representativas de repositórios.
Os revisores devem avaliar correção, alterações desnecessárias, segurança, cobertura de testes, qualidade da explicação e tempo até a aceitação. O gasto de tokens deve ser registrado ao lado desses resultados.
A métrica resultante deve ser trabalho aceito por dólar ou trabalho aceito por hora de engenheiro. Uma pontuação composta pública pode orientar a seleção de candidatos, mas não pode substituir essa medição.
Três sinais decidirão se a liderança do Claude importa
A próxima fase será decidida pelo desempenho em configurações padrão, pela economia de alterações aceitas e pela estabilidade do benchmark entre atualizações.
O primeiro sinal é o desempenho em configurações práticas de esforço. As configurações máximas atraem manchetes, mas os padrões moldam a maior parte do uso diário.
O Sonnet 5.5 com esforço médio obtém uma pontuação muito abaixo de seu resultado máximo. O Sol perde apenas dois pontos ao passar de xhigh para médio nos dados publicados.
Se a Anthropic reduzir essa diferença nas configurações padrão, o teto de 68 pontos do Claude se tornará mais relevante para equipes comuns. Se a diferença persistir, o argumento de eficiência do Sol se fortalecerá.
O segundo sinal é o custo por alteração aceita. Os benchmarks públicos atualmente medem o gasto de API por tarefa, não todo o caminho da solicitação ao código integrado.
As equipes devem acompanhar se fornecedores ou avaliadores independentes publicam resultados ajustados pela revisão. Eles devem incluir novas execuções, tempo de correção humana e regressões descobertas após a verificação.
O prêmio do Claude fica mais fácil de defender se seus patches exigirem menos revisão. A vantagem do Sol se fortalece se seu menor uso de inferência não criar trabalho adicional de correção.
O Argon pode liderar essa medida em alterações complexas de repositórios se sua força no DeepSWE se transferir para a produção. Sua pontuação agregada, por si só, não pode responder a essa pergunta.
O terceiro sinal é a estabilidade do ranking. Agentes de programação mudam por meio de atualizações de modelos, revisões de harnesses, políticas de ferramentas e melhorias na gestão de contexto.
Um líder estável deve manter sua posição em execuções repetidas e versões do benchmark. Grandes mudanças após pequenas atualizações do sistema reduziriam a confiança em diferenças estreitas de pontuação.
O Artificial Analysis já publica resultados por componente, métricas de eficiência e revisões metodológicas. Futuras reexecuções mostrarão se a diferença de cinco pontos representa uma separação duradoura ou efeitos temporários de configuração.
As equipes de desenvolvimento não precisam esperar por um benchmark perfeito. Elas podem tomar uma decisão delimitada agora.
Comece com um conjunto representativo de tarefas internas. Compare o Claude em mais de um nível de esforço com Sol e Argon, onde o acesso permitir.
Mantenha consistentes as permissões do agente, o snapshot do repositório e os critérios de sucesso. Registre o tempo de execução, os tokens, as falhas, o tempo de revisão e se a alteração final foi aceita.
Use uma configuração de alto esforço somente quando a tarefa justificar a escalada. O trabalho rotineiro deve começar com a configuração menos dispendiosa que atenda ao limiar de aceitação da equipe.
Reavalie a comparação após grandes atualizações de modelos ou do harness. O Artificial Analysis Coding Agent Index é útil justamente porque a fronteira está em movimento.
Por enquanto, sua mensagem é clara. O Claude Sonnet 5.5 detém a maior pontuação publicada entre as três novas configurações, mas não lidera em todas as definições práticas de primeiro lugar.
O GPT-6.1 Sol oferece um perfil de eficiência atraente, enquanto o Gemini 4 Argon lidera o trio em trabalhos de repositório de longo prazo. A escolha certa depende de qual resultado uma equipe valoriza.
Sua organização pagaria um grande prêmio de recursos por cinco pontos adicionais no índice ou financiaria mais tentativas e verificações com Sol? Teste essa questão em relação ao seu próprio trabalho integrado antes de escolher uma opção padrão.
