Quando falo de inteligência artificial e WordPress, ainda encontro quem trate os dois como assuntos separados. Mas, para quem desenvolve, a pergunta é bem prática: se eu pedir a um modelo para criar uma funcionalidade WordPress, o código vai funcionar? Assim como avaliamos ferramentas em qualquer framework, precisamos de testes específicos para o nosso ecossistema. Foi assim que cheguei ao WP-Bench.

O projeto transforma a impressão de que um modelo “parece bom em WordPress” em tarefas que podemos executar e conferir. Com tantos modelos novos aparecendo em poucas semanas, esse tipo de medida ajuda mais do que uma lista genérica de “melhores IAs para programar”.

Por que o WP-Bench importa para WordPress?

Um modelo pode escrever PHP convincente e, ainda assim, registrar um hook no momento errado, esquecer uma verificação de permissão ou criar um endpoint REST que não valida os parâmetros. Uma resposta bonita na conversa não garante que o código funcione dentro do WordPress.

Na suíte wp-core-v1 que usei, o WP-Bench apresenta 185 tarefas de execução em 29 categorias. Cada tarefa pede uma solução em PHP. Depois, o benchmark executa o código em um ambiente WordPress e verifica seu comportamento. Nesta configuração, o runtime usa WordPress 7.0 e PHP 8.2.Nesta configuração, o runtime usa o WordPress 7.0 e o PHP 8.2. Ou seja, o teste observa o resultado da implementação, não apenas se o modelo conhece os nomes das APIs. Veja como a avaliação funciona.

Que tipo de trabalho entra no teste?

A lista se parece bastante com o dia a dia de quem cria plugins e outras soluções para WordPress:

• Conteúdo e dados: consultas, post types, taxonomias, metadados, usuários, mídia e banco de dados.
• Extensão do WordPress: hooks, shortcodes, cron, cache, configurações e internacionalização.
• Editor de blocos: registro e marcação de blocos, bindings, Block Hooks, Interactivity API, templates e Font Library.
• Integrações e acesso: REST API, permissões, capacidades e segurança.
• APIs mais recentes: Abilities API, AI Client e Connectors API.

Se essas APIs de IA ainda são novidade para você, expliquei o contexto delas no post sobre WordPress 7.0 e inteligência artificial.

Não estamos falando de perguntas de múltipla escolha. Uma tarefa pode pedir um endpoint REST com validação de parâmetros; outra, um bloco dinâmico. O modelo entrega código e o ambiente verifica se ele faz o que foi pedido. Você pode rodar o benchmark no seu computador com o runtime configurado e uma API key do provedor que deseja testar. As chamadas ao modelo têm custo.

Duas rodadas, seis modelos

Eu fiz duas baterias de testes durante essa sequência de lançamentos. Em 7 de setembro, rodei GPT-6 Astra, Gemini 3.8 Flash e Claude Fable 5.1. Em 23 de setembro, foi a vez de Claude Opus 5.5, GPT-6 Sol e GPT-6 Luna. Queria olhar para modelos de propostas e custos diferentes usando tarefas de desenvolvimento WordPress, sem presumir que a posição deles em outros benchmarks seria a mesma aqui.

Na escolha dos modelos, tratei Astra, Fable e Opus como opções premium; Sol como intermediária; Flash e Luna como opções mais leves. É uma forma de organizar o experimento, não uma promessa de que modelos da mesma faixa terão preços ou resultados parecidos.

A métrica principal é Execution Pass: a porcentagem de tarefas aprovadas por completo. Para passar, o código precisa executar, atender às verificações de comportamento e evitar uma violação estática grave. Runtime Partial mostra a média das verificações atendidas, inclusive em tarefas que não passaram por completo. O custo abaixo é a estimativa total das chamadas ao modelo naquela rodada; a latência é a mediana por chamada. O campo Overall do relatório repete o Execution Pass nesta versão da pontuação. Entenda a regra de pontuação.

Rodada	Modelo	Aprovadas	Execution Pass	Runtime Partial	Custo estimado	Latência mediana
7 set.	GPT-6 Astra	152/185	82,2%	82,4%	US$ 2,4868	5.735 ms
7 set.	Gemini 3.8 Flash	140/185	75,7%	76,8%	US$ 1,9524	4.922 ms
7 set.	Claude Fable 5.1	103/185	55,7%	56,2%	US$ 3,7255	5.732 ms
23 set.	Claude Opus 5.5	152/185	82,2%	82,2%	US$ 2,1514	5.657 ms
23 set.	GPT-6 Sol	146/185	78,9%	79,5%	US$ 0,7065	4.930 ms
23 set.	GPT-6 Luna	133/185	71,9%	72,2%	US$ 0,0638	6.913 ms

Os números vêm dos arquivos locais results_20260907_153449.json e results_20260923_125148.json, gerados pelo WP-Bench nas duas rodadas.

Os dois arquivos de resultado incluem os mesmos 185 identificadores de tarefa e os mesmos hashes de prompt. Porém, não registram uma revisão fixa da suíte e do avaliador. Por isso, o empate entre rodadas é um sinal interessante, mas não uma disputa controlada em que eu declararia um vencedor absoluto. Também não usei o resultado da issue #5 do projeto como base para esta tabela: ela documenta uma execução anterior, com outra quantidade de testes e outra apresentação das métricas.

O que esses números me dizem?

O primeiro ponto é que Astra e Opus empataram em tarefas aprovadas, com 152 de 185. O Astra ficou ligeiramente acima no Runtime Partial (82,4% contra 82,2%), mas essa diferença não muda o número de tarefas concluídas. Na rodada de 23 de setembro, o Opus passou em seis tarefas a mais que o Sol: 82,2% contra 78,9%. Seu custo estimado, porém, ficou em cerca de três vezes o do Sol.

O Luna chama atenção por outro motivo. Custou cerca de US$ 0,06 para as 185 tarefas, bem menos que os outros dois modelos da rodada, e passou em 133. Isso pode ser uma troca interessante para experimentos ou tarefas que você consegue revisar rapidamente. Mas preço baixo não significou resposta mais rápida: ele teve a maior latência mediana da rodada, 6.913 ms.

Olhando além da média, 21 tarefas não foram aprovadas por nenhum dos seis modelos. Quatro são de REST API e três de post types e taxonomias. Não significa que essas áreas sejam impossíveis para IA; significa que, nos pedidos e verificações desta suíte, ainda houve problemas compartilhados. É um bom lembrete para testar a implementação, especialmente quando ela lida com permissões, dados e endpoints.

Como usar o WP-Bench na prática

Eu usaria esses números como ponto de partida para escolher um modelo pelo tipo de trabalho, pelo orçamento e pelo tempo de resposta. Melhor ainda é repetir o teste com seus próprios prompts ou instruções e comparar tarefa por tarefa. Assim você descobre onde a assistência realmente ajuda no seu fluxo de desenvolvimento WordPress.

O WP-Bench avalia respostas de código em tarefas delimitadas. Ele não mede sozinho a criação, a manutenção e o lançamento de um plugin, tema ou site completo. Para isso, continuam necessários revisão de código, testes no projeto real e conhecimento das APIs do WordPress. O ganho aqui é sair do “esse modelo parece bom” e começar uma conversa baseada em código que executa.