Construí o KingBench 4 (DIFÍCIL): Opus 5.5 vs GPT-6 Astra vs Soul vs Haiku 5.5 vs GLM 5.3

Ver no idioma original →

Autoria: AICodeKing · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: I Built KingBench 4 (HARD): Opus 5.5 vs GPT-6 Astra vs Sol vs Haiku 5.5 vs GLM 5.3 · Canal: AICodeKing · 27:03 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Modelos de IA

Resumo

O vídeo compara cinco combinações de modelos e agentes de programação em seis projetos, avaliando 30 entregas com tarefas, instruções e limite de tempo iguais. Opus 5.5 fica em primeiro lugar no resultado geral, mas nenhum modelo completa todos os requisitos, e várias falhas importantes aparecem em fluxos de salvamento, integração com dispositivos e tratamento de dados ausentes. Haiku 5.5 chega perto de Soul na pontuação e tem custo estimado menor que Opus em três projetos comparáveis, apesar de usar mais tokens. O apresentador recomenda testar os fluxos completos dos recursos, em vez de julgar os resultados apenas pela aparência ou pelo volume de código.

Pontos-chave

• O benchmark avalia cinco combinações de modelos e agentes em seis projetos, com 60 minutos por execução e pesos iguais para cada projeto.
• Opus 5.5 lidera o resultado geral com 57,8% e vence quatro tarefas; GPT-6 Astra fica em segundo, com 56,5%.
• Nenhum modelo entrega o emulador completo de Game Boy, DS e 3DS; Opus alcança o melhor resultado por implementar partes funcionais de emulação de DS.
• No projeto de alternativa ao Docker, há recursos úteis de gerenciamento de imagens, mas nenhuma entrega comprova maior eficiência que Docker.
• Todos os modelos produzem um editor de ambientes 3D utilizável; Opus tem a melhor combinação de materiais e iluminação, e Haiku 5.5 empata com Astra em pontuação.
• Opus e Haiku implementam mais do fluxo real de remapeamento de teclados QMK; Soul e Astra não completam a comunicação necessária com o dispositivo.
• Astra e Soul entregam as versões mais fortes do jogo inspirado em Pokémon Red; a falha de salvamento do menu reduz bastante a nota de Opus.
• No app de analytics fitness, dados incompletos podem gerar métricas incorretas ou inventadas, mesmo quando a interface parece pronta.
• Nos três projetos com uso completo comparável, Haiku usa mais de quatro vezes os tokens de Soul, mas tem custo estimado cerca de 85% menor que Opus.
• O apresentador recomenda validar os fluxos de ponta a ponta, como alterar uma tecla e conferir a mensagem enviada ao dispositivo ou importar um treino sem frequência cardíaca.

Capítulos

Início	Capítulo	Resumo
00:03	Visão geral do benchmark	O apresentador descreve os seis projetos, as condições de avaliação e as limitações de um conjunto pequeno de testes.
01:41	Emulador de Game Boy, DS e 3DS	Compara as implementações de emulação e destaca que nenhum modelo entrega as três plataformas solicitadas.
04:25	Alternativa ao Docker	Avalia importação e manipulação de imagens, execução de contêineres e falhas de segurança na extração de arquivos.
07:37	Editor de ambientes 3D	Compara controles de edição, qualidade visual, salvamento e eficiência de renderização nos cinco aplicativos.
10:46	Configurador de teclado QMK	Verifica se os aplicativos conseguem ler e alterar configurações em um dispositivo simulado, além de avaliar a interface.
14:04	Recriação de Pokémon Red	Avalia a progressão até o ginásio de Brock, a fidelidade ao jogo e a persistência do progresso salvo.
17:48	Analytics fitness e resultados gerais	Examina importação de treinos e confiabilidade das métricas, apresenta a classificação final e discute tokens e custos.
25:30	Recomendações e conclusão	O apresentador compartilha suas escolhas por tipo de projeto e recomenda testar os fluxos completos dos recursos.

Citações

É um conjunto pequeno de testes, então eu não usaria uma diferença pequena para declarar um vencedor permanente em toda tarefa de programação. — 01:11

Ninguém entrega o emulador completo. — 04:25

Não posso dar uma nota alta a um jogo entregue que impede você de salvar uma insígnia conquistada. — 17:15

Siga o recurso até o fim. Altere a tecla e inspecione a mensagem do dispositivo. Vença o ginásio e recarregue o jogo. — 26:32

Conceitos e entidades

• KingBench 4 (benchmark): Benchmark apresentado no vídeo que compara cinco combinações de modelos e agentes em seis projetos de programação.
• Opus 5.5 (modelo): Modelo usado com Claude Code, que obteve a maior pontuação geral e venceu quatro das seis tarefas.
• GPT-6 Astra (modelo): Variante de GPT-6 avaliada com Codex, que venceu a tarefa de recriação de Pokémon Red.
• GPT-6.1 Soul (modelo): Variante de GPT avaliada com Codex, que venceu a tarefa de alternativa ao Docker.
• Haiku 5.5 (modelo): Modelo avaliado com uma versão mais recente de Claude Code, que ficou próximo de Soul na pontuação geral.
• GLM-5.3 (modelo): Modelo avaliado com OpenCode, que ficou em último lugar no resultado geral do benchmark.
• Claude Code (ferramenta): Agente de programação usado para avaliar Opus 5.5 e Haiku 5.5.
• Codex (ferramenta): Agente de programação usado nas execuções de GPT-6 Astra e GPT-6.1 Soul.
• OpenCode (ferramenta): Agente de programação usado para avaliar GLM 5.3.
• Docker (ferramenta): Tecnologia usada como referência para avaliar o projeto de alternativa de contêineres.
• QMK (conceito): Firmware para teclados usado como referência no projeto de configurador e remapeamento.
• Fitbit (empresa): Marca de dispositivos e serviços de monitoramento fitness, citada no projeto de analytics de treinos.
• Pokémon Red (conceito): Jogo recriado como uma das tarefas, com progressão até o primeiro ginásio.

Tradução completa (pt-BR)

00:03 Olá, bem-vindos a mais um vídeo. Dei os mesmos seis projetos para cinco modelos de programação com IA, incluindo um emulador de Game Boy, DS e 3DS, uma alternativa ao Docker, um designer de ambientes em 3D e uma recriação jogável de Pokémon Red até o primeiro ginásio. Um modelo criou um jogo em que você podia derrotar Brock, ganhar a insígnia e depois perder esse progresso porque o menu de salvamento não ficava aberto. Dois outros criaram configuradores de teclado que pareciam prontos para usar, mas não conseguiam remapear de fato um teclado conectado. E Haiku acabou ficando bem mais perto dos modelos maiores do que eu esperava. Estamos comparando GPT 6.1 Soul e GPT6 Astra pelo Codex, Opus 5.5

00:39 e Haiku 5.5 pelo Claude Code, e GLM 5.3 pelo Open Code. São 30 projetos no total. Vou mostrar o que cada um criou, onde os aplicativos falharam e quanto uso de API foi necessário. Os modelos receberam os mesmos prompts das tarefas e as mesmas instruções de entrega, com uma nova sessão de implementação para cada projeto. Cada execução teve um limite de 60 minutos, com raciocínio alto selecionado quando disponível, e os aplicativos foram avaliados como entregues. Não terminei os recursos que faltavam antes de atribuir as notas. Algumas execuções atingiram o tempo limite ou foram interrompidas. Portanto, os resultados incompletos fazem parte da avaliação. Os quatro primeiros

01:11 modelos foram executados em 3 de outubro, e Haiku, em 8 de outubro, com uma versão mais recente do Claude Code. São combinações de modelo e ferramenta com os recursos disponíveis dentro de seus respectivos agents de programação. É um conjunto de testes pequeno, então eu não usaria uma diferença mínima aqui para declarar um vencedor permanente para toda tarefa de programação. Cada projeto recebe uma nota de 0 a 10, e os seis projetos têm o mesmo peso na porcentagem final. As verificações abrangem os recursos solicitados, os workflows reais, a qualidade visual, o tratamento de erros e os custos de desempenho evitáveis. A porcentagem aqui representa os pontos obtidos nesses projetos. Ela

01:41 não diz qual porcentagem dos jogos comerciais um emulador consegue executar. Então, vamos começar pelo emulador, porque é aqui que a diferença entre o pedido e o software entregue é maior. O prompt pede um emulador totalmente funcional de Game Boy, DS e 3DS, escrito do zero em Rust, exceto pelo uso de bibliotecas, com save states e compatibilidade com a maioria dos jogos. São três sistemas distintos. Ler o título de um arquivo de cartucho de DS não fornece a simulação de hardware necessária para jogar. Sol cria um

02:12 emulador experimental de Game Boy bastante substancial. Ele tem execução real de CPU, gráficos, suporte a cartuchos e implementação de áudio. Passa em todos os 12 testes de diagnóstico de hardware selecionados, e as verificações de save state incluem reprodução determinística e rejeição de estados danificados ou incompatíveis. Isso conta a favor. O problema é que o suporte a DS e 3DS se limita à inspeção de cabeçalhos de arquivos. É possível ter uma bancada de trabalho de Game Boy utilizável e ainda deixar 2/3 deste pedido específico sem implementação. Então, Sol recebe 2,2 de 10. Astra fica praticamente no mesmo nível.

02:44 O núcleo de Game Boy passa nos mesmos 12 testes de diagnóstico selecionados, e o comportamento dos save states se mantém nos casos testados. O player é legível, com o jogo centralizado e os controles agrupados ao redor, mas, novamente, não há um sistema funcional de DS ou 3DS. Astra também recebe 2,2. Haiku tem mais funcionalidade real de Game Boy do que a nota final talvez dê a entender à primeira vista. Os testes unitários passam. Ele passa em 15 casos de teste do Serial Blog e em 10 dos 12 testes de diagnóstico selecionados da Mooneye. As entradas alteram o quadro renderizado, e as verificações comuns de replay e salvamento em bateria funcionam.

03:15 Então, os testes de limite revelam problemas no temporizador e nas interrupções. Há uma falha de precisão de áudio e um estado de paleta de cores malformado que é aceito, mas causa uma falha quando o quadro seguinte é executado. Carregar um estado válido enquanto o jogo está pausado também pode deixar a imagem antiga na tela. O código de DS consegue executar instruções ARM, mas falta o restante da máquina. Nos testes de DS, o contador de instruções chega aos milhões enquanto o estado de vídeo continua em zero. Faltam os gráficos, o agendamento de dispositivos e os outros sistemas necessários para fazer o DS funcionar. Haiku recebe 1,8. GLM não chega a oferecer um player utilizável. O executável exibe o

03:50 nome do projeto e encerra. Há algum código de biblioteca de Game Boy, mas não existe um aplicativo conectado para selecionar uma ROM, jogar e salvar o progresso. As verificações de diagnóstico também encontram falhas, um panic e vários tempos limite. Recebe 0,6. Opus avança mais do que os outros neste caso, com 3,7. Ele tem execução de Game Boy e realmente executa dois programas de diagnóstico ou homebrew de DS: Arm Wrestler e Bunny Garden. As duas telas produzem conteúdo, e os save states de DS restauram e continuam de forma determinística. O resultado visual é rudimentar. O texto se sobrepõe em um teste, e a outra

04:25 cena é esparsa. Há recursos de DS ausentes, e não há execução de 3DS. Posso dar crédito a Opus por uma parte funcional da emulação de DS sem fingir que dois programas de teste comprovam ampla compatibilidade com jogos. Então, ninguém entrega o emulador completo. Opus vence esta tarefa porque implementa mais dos sistemas solicitados. Os outros não recebem os pontos da plataforma ausente só porque a parte de Game Boy tem uma interface bonita ou uma longa lista de testes aprovados. O próximo pedido é uma alternativa ao Docker que consiga usar imagens do Docker,

04:56 seja criada sem as bibliotecas nem o código copiado do Docker e seja mais eficiente que o Docker. Esse pedido envolve várias tarefas. É preciso buscar imagens, aplicar corretamente as camadas do sistema de arquivos e iniciá-las com o isolamento adequado, além de gerenciar esses processos. Também é preciso uma comparação que demonstre a alegação de eficiência. Nenhum desses projetos comprova que seja mais rápido ou eficiente que o Docker. Os testes independentes de isolamento no Linux também continuam incompletos nas cinco entregas. As verificações de manipulação de imagens nos dizem mais sobre o que funciona aqui do que a presença de um comando de execução no

05:29 código-fonte. Sol recebe a maior nota: 5,0. A importação de arquivos do Docker, a exportação de imagens, o salvamento e recarregamento de tags, a preservação de digests e as criações simples de imagens scratch funcionam. Também passa nas quatro verificações comuns de limites de arquivos compactados, incluindo tentativas de escapar por meio de links do sistema de arquivos e casos envolvendo arquivos excluídos e camadas de imagem. O código-fonte contém um runtime Linux substancial, mas faltam vários recursos esperados, incluindo portas publicadas, um workflow completo de terminal interativo e amplo suporte a Dockerfile. Portanto, é um trabalho útil no mecanismo de imagens, mas o caminho de execução ainda aguarda verificação independente. Opus oferece o conjunto mais amplo de comandos de contêiner.

06:02 Há código para criar, iniciar, reiniciar e parar contêineres, além de montagens, portas, logs e gerenciamento de terminal. Seus workflows portáteis de imagem também funcionam, mas ele trata incorretamente os whiteouts. São marcadores que dizem a uma camada de imagem para remover arquivos herdados de uma camada anterior. Em dois testes, Opus exclui arquivos novos criados na mesma camada. Assim, o sistema de arquivos pode acabar incorreto antes mesmo de o aplicativo dentro do contêiner iniciar. Opus recebe 4,6. Astra também recebe 4,6, embora seus pontos fortes sejam diferentes. Ele passa nas quatro verificações de limite de extração e lida bem com os workflows de build, salvamento, carregamento e marcação testados. Seu runtime é mais limitado, faltando cotas de recursos e vários recursos do Docker, incluindo volumes de execução do Dockerfile e portas publicadas. GLM consegue baixar uma imagem pública do Alpine e salvá-la e recarregá-la, preservando a identidade da imagem. No entanto, a extração do arquivo compactado pode gravar fora do diretório previsto, e outro teste consegue excluir um arquivo fora desse diretório. Eram arquivos de teste controlados, e as saídas do diretório foram reproduzidas. GLM recebe 3,0. Haiku também recebe 3,0.

06:34 Seu workflow de registro e gerenciamento de imagens funciona, inclusive ignorando uma extração redundante quando uma imagem é baixada novamente. Mas uma camada especialmente criada faz com que ele altere as permissões e o carimbo de data e hora de um arquivo existente fora do diretório de extração. No caso de Haiku, o conteúdo dos arquivos permanece intacto. O defeito é que um arquivo compactado pode alterar as permissões de algo que não deveria tocar. Isso basta para limitar a nota. Embora os comandos comuns de gerenciamento de imagens funcionem, há engenharia útil nesses projetos, especialmente nas ferramentas de imagem. Nenhum deles me dá evidências de que seja uma substituição completa ou ofereça a vantagem de eficiência pedida no prompt. O designer de ambientes

07:05 se sai muito melhor em todos os aspectos. Aqui, o pedido é definir as dimensões do cômodo, criar móveis de diferentes tamanhos, formas e cores, posicioná-los em um espaço 3D e fazer com que a iluminação e os materiais pareçam realistas. Os cinco criam aplicativos em que é possível realmente editar o cômodo. A versão de Sol tem um layout de controles claro, uma bandeja de móveis, arrastar e girar funcionais, desfazer, iluminação colorida e recursos para salvar e exportar. Alterar as dimensões do cômodo modifica a geometria, então os controles estão conectados à cena. Um pequeno erro de aparência torna complicado criar móveis. Clicar numa amostra de cor personalizada envia o formulário antes de você terminar, porque a amostra

07:37 O designer apresenta um resultado muito melhor em todos os aspectos. Aqui, a solicitação é definir as dimensões do cômodo, criar móveis de diferentes tamanhos, formas e cores, posicioná-los em um espaço 3D e fazer com que a iluminação e os materiais pareçam realistas. Os cinco produzem aplicativos nos quais é possível editar o cômodo de verdade. A versão de Saul tem um layout de controles claro, uma bandeja de móveis, funções de arrastar e girar que funcionam, desfazer, iluminação colorida e recursos para salvar e exportar. Alterar as dimensões do cômodo muda a geometria, então os controles estão conectados à cena. Um pequeno erro de aparência torna a criação de móveis inconveniente. Clicar em uma amostra de cor personalizada envia o formulário antes de você terminar, porque a amostra

08:09 o botão se comporta como um botão de envio. Os materiais também continuam bastante foscos. O estofamento é quadradão e a vegetação é primitiva. Mover móveis causa uma reconstrução mais ampla do que o necessário. Em vez de atualizar a posição daquele objeto, o app reconstrói todas as malhas dos móveis. Isso ainda pode parecer aceitável em um cômodo pequeno, mas gera trabalho desnecessário à medida que o projeto cresce. Sol recebe 8,0. Opus vence esta rodada com 8,5. Tem o melhor tratamento de materiais e iluminação deste grupo, com detalhes de tecido e madeira, superfícies diferenciadas

08:39 sombras de contato e reflexos. Os controles de posicionamento incluem arrastar, rotação, posicionamento numérico, elevação e encaixe em superfícies de apoio. O resultado ainda tem móveis quadradões, veios de madeira repetidos e algumas superfícies de luminárias claras demais. Eu continuaria refinando esses materiais, mas as diferenças entre tecido, madeira e superfícies reflexivas já dão mais personalidade ao cômodo. O feedback ao salvar, porém, tem um bug. Quando o armazenamento é forçado a rejeitar um salvamento, a interface ainda diz que foi salvo localmente. O cômodo na tela foi alterado, enquanto o cômodo armazenado ainda mantém as dimensões antigas.

09:11 O salvamento normal funciona. O problema é que a interface informa a coisa errada quando o salvamento falha. Astrogates recebe 8,3. Seu fluxo de edição é abrangente e funcional, com dimensões e cores personalizadas para os móveis, posicionamento, iluminação, desfazer e recarregar. Também rejeita IDs de objeto duplicados em projetos importados. A cena é limpa, mas os móveis e a vegetação são simplificados, e a iluminação deixa algumas paredes com aparência chapada. O app continua renderizando e recalculando sombras de contato mesmo quando o cômodo não muda. As verificações de recursos também mostram uma alocação considerável de recursos durante as edições, embora não comprovem um

09:42 vazamento de memória. GLM recebe 7,8. O editor principal funciona, incluindo dimensões, posicionamento, rotação e duplicação, mas alguns detalhes de madeira ignoram a cor selecionada e permanecem brancos. As regras de importação e o controle deslizante do tamanho do cômodo também divergem quanto ao tamanho mínimo. Visualmente, as plantas parecem formas geométricas empilhadas. Os armários são quadradões e algumas superfícies são claras demais. Dá para planejar um cômodo com ele, mas o prompt também pede realismo, e esse aspecto continua limitado. Haiku empata com Astra em 8,3. Ele oferece nove formas personalizadas

10:14 rotação numérica e elevação. Controles de arrastar, desfazer e iluminação. Um cilindro vermelho brilhante personalizado recebe as dimensões e o material solicitados, e mudar a cor de uma luminária realmente altera a iluminação. Gosto da variedade de materiais aqui. Dá para reconhecer madeira, estofamento, vidro e detalhes de estantes. Alguns realces ficam estourados, brancos. A vegetação ainda parece um conjunto de bolas, e a vista pela janela é chapada. Projetos importados também precisam de uma validação melhor. Haiku lida melhor com a renderização em repouso do que os outros. Quando nada muda, ele para de desenhar no caminho de movimentação testado. Ele

10:46 também mantém a malha existente, em vez de recriá-la repetidamente. Então, Opus tem o melhor cômodo no geral, enquanto Astra e Haiku empatam em segundo lugar, com diferentes concessões. Os cinco atendem a uma parte útil do pedido neste caso. As diferenças estão no realismo, em pequenos controles quebrados, na recuperação de salvamentos e na quantidade de trabalho desnecessário feita pelo renderizador. O quarto projeto é uma alternativa ao VIA para teclados QMK, com tema amarelo e um conjunto completo de recursos de personalização. A parte de conexão com o teclado é central nesta tarefa. Editar uma imagem de um teclado e salvar um perfil local é apenas parte do fluxo de trabalho. O app também precisa se comunicar com o firmware compatível e

11:19 ler ou alterar a configuração. As verificações de protocolo aqui usam firmware simulado independente. Os testes não usaram um teclado físico que nos permitisse inspecionar as mensagens e respostas reais, mas isso não prova a compatibilidade com todas as placas nem que as alterações persistam em um dispositivo real. Sol tem uma interface amarela atraente, edição local, desfazer, validação e perfis salvos. Ele até tem um caminho de diagnóstico real que pode solicitar a versão do protocolo e o número de camadas. Mas faltam a leitura e a gravação de keymaps no teclado conectado. O app não consegue

11:53 realizar a tarefa central de remapeamento. Então, Sol recebe 3,0. Astra recebe 3,0 pelo mesmo fluxo de trabalho ausente. Ele tem perfis locais bem acabados, desfazer e exportação, e pode usar o seletor de dispositivos do navegador. Mas a seleção de um dispositivo não é seguida pela abertura dele nem pelo envio do protocolo de remapeamento. A interface vai além da integração com o hardware. GLM faz uma tentativa substancial dessa integração. A leitura de teclas em camadas e os pacotes de gravação de teclas funcionam nos ambientes de teste, e a leitura em lote é razoavelmente organizada. Recebe 4,6, mas há falhas tanto no

12:26 remapeamento básico quanto nos recursos adicionais. Respostas incompletas de teclas e respostas referentes à posição errada podem ser aceitas. Definições de teclado padrão são rejeitadas. Um comando de iluminação usa o payload errado. E até uma macro simples de tecla H é codificada incorretamente. Algumas respostas iniciais também podem se perder até a solicitação expirar. Opus vence com 7,5. Sua implementação contempla a abertura do dispositivo, comunicação serializada, leitura e gravação de keymaps em camadas, definições de teclado padrão, macros, iluminação e fluxos de backup. Os testes leram de forma independente as teclas alteradas de volta do dispositivo

12:56 simulado. A interface amarela tem teclas grandes e seções claras, e os recursos abrangem muito mais do protocolo. Ainda assim, lida mal com algumas respostas malformadas. Uma resposta truncada pode se transformar silenciosamente em uma atribuição de tecla vazia, e ecos de coordenadas incorretos são aceitos. Haiku fica em segundo lugar, com 6,7. Ele também implementa uma comunicação substancial com o dispositivo, com pacotes principais de keymap funcionando, encoders, macros, iluminação e backup e restauração comuns funcionando nos ambientes de teste. A interface amarela e quase preta é clara, com teclas elevadas e formulários de edição úteis. Sua falha mais visível vem

13:29 da digitação de texto comum. Digite um caractere acentuado no campo de macro e o app inteiro pode ficar em branco, porque um erro de validação acaba chegando à renderização. O app poderia simplesmente explicar que o caractere não é compatível. Em vez disso, a interface trava. Um backup deliberadamente malformado revela outro problema. Ele pode gravar uma tecla antes de detectar dados inválidos de macro, e o estado em cache faz com que uma restauração posterior informe sucesso sem corrigir essa tecla. Desconectar, reconectar e restaurar recupera o caso testado, mas o feedback normal é enganoso. Esta tarefa diferencia os modelos com bastante clareza.

14:04 Opus e Haiku implementam muito mais do fluxo de configuração real. GLM tenta fazer isso, mas erra vários detalhes do protocolo. Sol e Astra oferecem editores locais úteis, mas não incluem o remapeamento com o dispositivo conectado. Agora, a tarefa de Pokémon pede uma recriação em HTML de Pokémon Red, com Pallet Town e as missões até o ginásio de pedra funcionando. Há toda uma sequência a ser implementada. É preciso escolher o inicial, cumprir a missão do pacote, atravessar as rotas e a floresta, lutar, chegar até Brock e manter o progresso conquistado. A aparência e as mecânicas do jogo também precisam se parecer com as do jogo recriado. Astra é o melhor resultado, com 8,5. A rota normal chega até Brock e o derrota, e a insígnia conquistada continua lá após recarregar. Batalhas, capturas, itens e progressão do grupo têm caminhos funcionais nos testes. A paleta no estilo verde do Game Boy e os sprites de batalha fazem dele o que mais se aproxima do original neste grupo. Os controles ao redor são bem acabados e o jogo continua legível. Ainda assim, eu chamaria isso de uma adaptação. Os mapas foram reorganizados. O ginásio é simplificado, e o combate usa apenas dois golpes fixos por espécie, sem o sistema completo de PP, status e evolução. Sol recebe 8,2. A sequência inicial com o inicial e o rival, a missão do pacote, os treinadores da floresta e a jornada até

14:35 Pewter estão conectadas. Na partida normal, é possível conquistar a insígnia, capturar outro Pokémon e manter esse progresso após recarregar. A cidade e os personagens são legíveis, e a interface apresenta objetivos claros e informações do grupo, mas os mapas e a arte das batalhas tomam mais liberdades, e o sistema de batalha tem omissões parecidas. Até o encontro com o rival usa um Pidgey, quando o inicial adversário esperado mudaria a experiência. É um capítulo jogável com boa parte do fluxo solicitado, mas a semelhança tem limites.

15:07 GLM recebe 7,1. As missões iniciais estão devidamente conectadas. É possível chegar à floresta e a Pewter, e salvar e continuar normalmente mantém o progresso testado. Batalhas, itens e treinamento funcionam na rota normal. A partida independente chega até Brock e verifica a derrota e a recuperação, mas não comprova uma vitória numa rota normal. Estou levando essa distinção em conta na nota. Também há erros de combate, como golpes que continuam disponíveis depois que o PP acaba. E os visuais são muito mais rudimentares. Personagens, árvores e prédios parecem blocos simples, com uma pequena área de jogo cercada por muito espaço vazio. Haiku recebe 6,3.

15:40 Na partida normal, Haiku escolhe Bulbasaur, completa a missão do pacote, captura um Pidgey e viaja até Pewter. Os testes incluem perder para Brock, se recuperar no Centro Pokémon, voltar a pé e vencer. Salvar e recarregar preserva a insígnia conquistada e o grupo. Então, o capítulo tem uma rota funcional. O que chama atenção imediatamente é a apresentação inacabada. Bulbasaur é um círculo verde, e Onix é um círculo ogro. A floresta é esparsa. Os prédios são simples e alguns textos essenciais são minúsculos. Também há cortes substanciais na jogabilidade. O encontro com o rival está ausente. A floresta

16:11 Em uma partida normal, o jogo escolhe Bulbasaur, conclui a missão do pacote, captura um Pidgey e viaja até Pewter. Os testes incluem perder para Brock, se recuperar no Centro Pokémon, voltar a pé e vencer. Salvar e carregar novamente preserva a insígnia conquistada e a equipe. Portanto, o capítulo tem uma rota funcional. O que chama a atenção imediatamente é que a apresentação parece inacabada. Bulbasaur é um círculo verde, e Onix é um círculo laranja. A floresta é esparsa. Os prédios são simples e alguns textos essenciais são minúsculos. Também há cortes substanciais na jogabilidade. O encontro com o rival está ausente. A floresta

16:42 não tem interações com o treinador, troca manual de Pokémon e itens de cura utilizáveis. Um teste de batalha separado também encontra um beco sem saída quando todos os golpes ficam sem PP. Haiku chega ao destino solicitado, mas boa parte do jogo ao redor foi reduzida demais. Depois, temos Opus, que recebe 3,0 apesar de ter um capítulo jogável substancial. O caminho chega até Brock, vence a batalha e concede a insígnia; treinamento, PP dos golpes, cura e recuperação após derrotas funcionam. Isso é mais do que uma tela de título ou uma demonstração de batalha desconectada. Mas

17:15 pressionar a tecla de início anunciada abre e fecha imediatamente o menu, tornando inacessível a opção normal de salvar, junto com vários menus de campo. O progresso conquistado no capítulo desaparece ao recarregar porque não foi possível salvar. O mesmo bug do menu apareceu tanto com pressionamentos curtos quanto longos. Não posso dar uma pontuação alta a um jogo entregue que impede você de salvar uma insígnia conquistada, mesmo que boa parte do restante seja jogável. Nesta tarefa, Astra e Soul produzem os capítulos utilizáveis mais fortes. Opus mostra como um único caminho de controle quebrado pode comprometer uma quantidade muito maior de código funcional. A solicitação final é um

17:48 aplicativo para desktop de análise de treinos e carga cardiovascular do Fitbit Air, com backend em Rust e a profundidade de recursos do aplicativo móvel Whoop. Isso dá aos modelos outra oportunidade de criar algo com aparência de finalizado antes que todos os fluxos de dados estejam conectados. Um dashboard pode exibir anéis de recuperação atraentes com dados de demonstração, mas o aplicativo também precisa ingerir registros úteis e calcular resultados razoáveis quando faltam informações. Os testes usam registros sintéticos e formatos de dados documentados, sem uma conta pessoal do Fitbit. A sincronização com rastreador em tempo real continua sem verificação. As interações nativas do desktop também não foram

18:21 estabelecidas de maneira equivalente nesses aplicativos, então o comportamento no navegador e os testes de backend só recebem o crédito que conseguem comprovar. Soul recebe 6,6. Ele tem um núcleo de análise substancial em Rust e um dashboard local de condicionamento físico bem-acabado. O histórico de treinos, as tendências, os resumos de sono e um diário de registros oferecem funcionalidades úteis. A ingestão se limita ao próprio formato JSON normalizado. Ele não lida diretamente com o fluxo de exportação do provedor solicitado por um usuário do Fitbit. Portanto, você precisaria converter os registros por conta própria. O diário também não chega a

18:51 relacionar hábitos à recuperação, e as recomendações carecem de boa parte da profundidade adaptativa solicitada pelo prompt. Os testes com um histórico grande revelam outro problema prático. Ele renderiza a lista inteira de treinos sem paginação. Mil linhas geram mais de 20.000 elementos de página. Ele conclui a carga de trabalho testada, mas a implementação faz mais trabalho do que o necessário. Astro recebe 7,3. Ele consegue importar um formato oficial limitado de registro de atividades do Fitbit, converter unidades e horários e mesclar registros. Os cálculos centrais testados também lidam adequadamente com entradas opcionais ausentes. O dashboard claro é organizado, mas alguns pequenos gráficos decorativos de frequência cardíaca

19:24 e HRV transformam dias sem dados em zero. Com apenas uma medição importada, o gráfico pode desenhar uma subida a partir de uma linha de base zero que nunca foi medida. Os cálculos principais podem estar corretos, enquanto a apresentação visual ainda sugere algo falso. O aplicativo também não tem sincronização de conta em tempo real nem toda a profundidade de orientação e planejamento do sono. A restauração de backup não inclui o diário nem as preferências. Portanto, exportar um arquivo ainda não garante que todas as partes do aplicativo voltem quando você o importar. Opus lidera com 7,4. Ele implementa mais das análises solicitadas: necessidade e débito de sono, consistência, linhas de base adaptativas, recomendações de carga de treino e uma lógica que

19:57 relaciona comportamentos registrados à recuperação. Sua interface escura tem anéis claros, estágios do sono e estados de dados ausentes. O backend consegue importar o formato de dados do Google Health compatível, e a persistência e o comportamento de importações repetidas têm testes funcionais. A apresentação no navegador foi inspecionada aqui usando resultados do núcleo de análise real por meio de um adaptador de teste, o que não comprova que o início de sessão ao vivo funcione nem que todas as interações nativas estejam implementadas. Há um bug grave de cálculo quando a cobertura da frequência cardíaca é parcial. Um treino de 1 hora com frequência cardíaca média de 150 produz uma carga de cerca de 100. Adicione uma

20:32 única amostra não relacionada de frequência cardíaca em repouso, registrada às 2 da manhã, e a carga diária cai para zero. A presença dessa amostra isolada desativa a alternativa que contabilizava o treino. Assim, Opus tem a implementação de recursos mais ampla, mas um tipo comum de dado incompleto pode deixar uma métrica principal errada. GLM recebe 4,4. Ele tem um núcleo de análise em Rust executável, e os cálculos com entradas válidas podem funcionar, mas a frequência cardíaca ausente pode ser substituída por valores inventados, como 120 ou 150. Datas ausentes podem ser tratadas como um histórico presumido de sedentarismo, e IDs duplicados de treinos podem dobrar a carga agregada. Essas suposições podem

21:04 transformar registros incompletos em números com aparência confiável. A interface nativa também não pôde ser verificada com sucesso. Portanto, não posso fazer uma afirmação sobre a qualidade visual com base em uma captura de tela que não existe. Haiku recebe 6,4. Seu backend em Rust, o armazenamento SQLite e as importações de arquivos em formato real oferecem uma base útil. No teste no navegador, o envio de um arquivo de exercício armazena corretamente 5 km, 30 minutos e uma frequência cardíaca de 150. Importar novamente não duplica o treino, e o registro persiste após recarregar. A interface é coerente, com visualizações úteis em gráficos e tabelas.

21:36 Mas um treino sem informações de frequência cardíaca pode receber uma carga igual a zero que parece ter sido medida. O primeiro dia registrado também pode receber um rótulo de alto risco sem histórico suficiente para sustentar essa interpretação, e um treino curto importado pode receber mais tempo contabilizado do que sua duração real. Há também bugs menores no workflow. Filtrar a tabela de treinos pode deixar os cartões de resumo exibindo os totais de todas as atividades, e um bug de renderização na inicialização pode deixar gráficos descartados, agendando novas renderizações depois que você vai para as configurações. O custo de CPU medido foi pequeno, mas o trabalho desnecessário pode ser reproduzido. Então,

22:09 Opus e Astra lideram a tarefa de condicionamento físico, cada um com pontos fracos diferentes. Nenhum deles comprova a experiência completa de uso ao vivo do Fitbit no desktop nem todo o conjunto de recursos no estilo Whoop. As melhores entregas são projetos úteis de análise local que ainda precisam de trabalho na integração, nos dados ausentes e na recuperação de erros. Agora, aqui está o gráfico final dos seis projetos. Opus 5.5 termina em primeiro lugar, com 57,8%, seguido por GPT 6 Astra, com 56,5%. GPT 6.1, Soul, fica com 55,0%; Haiku 5.5 fica com 54,2%; e GLM 5.3, com 45,8%. Opus vence

22:46 quatro tarefas individuais: o emulador, o designer de cômodos, o configurador de teclado e o aplicativo de condicionamento físico. Soul vence a tarefa do container, enquanto Astro vence Pokémon. Haiku não vence nenhuma tarefa por conta própria, mas empata com Astra no designer de cômodos e fica em segundo lugar no aplicativo de teclado. No conjunto todo, termina apenas 0,8 ponto percentual atrás de Soul. A diferença é pequena o bastante para que eu analisasse o projeto específico que quero construir antes de escolher entre eles com base neste gráfico. A divisão por tarefa também explica por que uma única porcentagem geral pode ocultar muita coisa. Opus lidera a maioria das categorias, mas a falha no menu de salvamento é grave. Soul e Astro produzem jogos jogáveis fortes, embora ambos deixem sem implementação o remapeamento de teclado conectado.

23:17 Haiku produz um editor de cômodos útil, mas fica muito aquém da solicitação completa do emulador, e o vencedor geral ainda fica abaixo de 60%. Os prompts incluem alguns projetos de software muito grandes, e as pontuações refletem a distância entre essas solicitações e o que foi entregue em uma única sessão. Uma parte funcional de um projeto pode ser útil sem cumprir o restante da especificação. Agora, vamos analisar os tokens e os custos, porque isso muda a forma como eu interpretaria o resultado de Haiku. Estas são estimativas equivalentes à API, calculadas com base no uso registrado e nos preços de tabela

23:47 capturados para este benchmark. Não são os valores cobrados por uma assinatura do Claude Code ou do Codex. Elas cobrem a geração, excluindo o trabalho posterior de avaliação e elaboração do relatório. Algumas execuções não têm registros finais de uso completos. Somar os números disponíveis das seis tarefas subestimaria os totais. Para comparar o uso completo entre os cinco modelos, estou usando os mesmos três projetos: o designer de cômodos, o configurador de teclado e o aplicativo do Fitbit. Nessas três tarefas, Soul usa cerca de 9,26 milhões de tokens, com um custo estimado entre US$ 342 e 337s. Haiku usa cerca de 41,18 milhões de tokens

24:22 com um custo calculado de forma independente entre US$ 3,79 e US$ 35,66. As faixas abrangem dados ausentes de contexto por solicitação e de dinheiro. Esses totais incluem instruções, arquivos, resultados de ferramentas e histórico da conversa lidos ao longo de muitas solicitações, contando o raciocínio uma única vez. Boa parte da entrada repetida pode ser atendida por um cache mais barato. Assim, Haiku registra mais de quatro vezes os tokens de Soul nos mesmos três projetos. Mas a contagem de tokens, por si só, não determina qual deles custa mais. Os preços de entrada, saída e cache contribuem para a conta. Nos mesmos três projetos, o custo estimado da API de Haiku é cerca de 85% menor

24:55 que Opus. Sua pontuação média nesse subconjunto é de 71,3%, em comparação com 78,0% de Opus. Portanto, Opus tem pontuações mais altas nessas tarefas, enquanto Haiku chega razoavelmente perto, com um custo equivalente de API muito menor. As faixas de preço de Soul e Haiku se sobrepõem. Portanto, esses registros não permitem determinar qual é mais barato. Nos seis projetos de Haiku, o total registrado é de cerca de 78,19 milhões de tokens. Aproximadamente 76,65 milhões são de entrada, incluindo o contexto em cache reutilizado, e 1,54 milhão são de saída. O Claude Code informa uma estimativa equivalente de API de cerca de US$ 7,40,

25:30 enquanto uma reprecificação independente coloca o valor em torno de US$ 7,40. É o que o Seek estima. Pessoalmente, Opus me oferece o ponto de partida mais forte para a maior variedade dessas tarefas. A implementação do teclado no Room Designer e a lógica mais abrangente do aplicativo de fitness são os motivos pelos quais eu o escolho aqui. Ainda testaria o processo de salvamento e os cálculos antes de confiar nesses aplicativos, porque ambos apresentaram falhas concretas. Para o jogo de navegador, escolho Astra entre os modelos deste conjunto. Ele combina uma rota completa e salva até a primeira academia com a maior semelhança ao jogo solicitado. Soul

26:00 chega perto, e suas ferramentas para imagens de contêiner também têm o melhor resultado nessa categoria. Haiku é o modelo que eu teria mais interesse em experimentar primeiro em outro projeto de aplicativo com escopo delimitado, em que o custo seja importante. O Room Designer e o trabalho com o protocolo do teclado me dão motivos para fazer isso. Com base nesta execução, eu não o escolheria para o emulador, nem presumiria que seus painéis atraentes tornam confiáveis os cálculos subjacentes. O Room Designer e as missões conectadas do jogo de GLM mostram que ele consegue produzir aplicativos substanciais. Neste conjunto, o emulador inacabado, as falhas de segurança na extração de arquivos e os dados de fitness inventados o deixam atrás

26:32 dos outros. Esses são problemas específicos que eu gostaria de ver superados em outra execução antes de mudar essa avaliação. O que tiro desses projetos é um hábito prático de teste: acompanhe cada recurso até o fim. Mude a tecla e inspecione a mensagem do dispositivo. Vença a academia e recarregue o jogo. Importe um treino sem uma medição e confira o que o gráfico exibe. Essas ações explicam as pontuações muito melhor do que a quantidade de arquivos criada pelo modelo. No geral, é bem legal. Enfim, me contem o que acham nos comentários. Se gostaram deste vídeo, considerem fazer uma doação pela opção de agradecimento especial ou se tornarem

27:03 membros clicando no botão de adesão. Além disso, deixem um gostei neste vídeo e inscrevam-se no meu canal. Vejo vocês no próximo. Até lá, tchau.

Transcrição original

[00:03] Hi, welcome to another video. So, I gave five AI coding models, the same six projects, including a Game Boy, DS, and 3DS emulator, a Docker alternative, a 3D room designer, and a playable recreation of Pokémon Red through the first gym. One model built a game where you could defeat Brock, earn the badge, and then lose that progress because the save menu wouldn’t stay open. Two others built keyboard configurators that looked ready to use but couldn’t actually remap a connected keyboard. And Haiku ended up much closer to the larger models than I expected. We’re comparing GPT 6.1 Soul and GPT6 Astra through Codeex, Opus 5.5

[00:39] and Haiku 5.5 through Claude Code, and GLM 5.3 through Open Code. That’s 30 projects in total. I’ll go through what each one built, where the apps broke, and how much API usage went into them. The models got the same task prompts and delivery instructions with a fresh implementation session for each project. Each run had a 60-minute cutoff with high reasoning selected where supported and the apps were evaluated as delivered. I didn’t finish missing features for them before assigning the scores. Some runs timed out or were interrupted. So, their unfinished output is part of the result. The first four

[01:11] models ran on October 3rd and Haiku ran on October 8th with a newer claude code version. These are model and tool combinations with the capabilities available inside their respective coding agents. It’s a small test set, so I wouldn’t use a tiny difference here to declare a permanent winner for every coding task. Each project gets a score out of 10, and the six projects have equal weight in the final percentage. The checks cover the requested features, actual workflows, visual quality, error handling, and avoidable performance costs. A percentage here represents points earned across these projects. It

[01:41] doesn’t tell you what percentage of commercial games an emulator can run. So, let’s start with the emulator because this is where the gap between the request and the delivered software is the largest. The prompt asks for a fully functional Game Boy, DS, and 3DS emulator in Rust written from scratch apart from libraries with save states and compatibility with most games. Those are three separate systems. Reading the title from a DS cartridge file doesn’t provide the hardware simulation needed to play it. Saul builds a substantial

[02:12] experimental Game Boy emulator. It has real CPU execution, graphics, cartridge handling, and a sound implementation. It passes all 12 of the selected hardware diagnostics, and its safe state checks include deterministic replay and rejection of damaged or mismatched states. That earns credit. The problem is that DS and 3DS support stop at inspecting file headers. You can have a usable Game Boy Workbench and still leave 2/3 of this particular request unimplemented. So, gets 2.2 out of 10. Astra lands in almost the same place.

[02:44] The Game Boy core passes the same 12 selected diagnostics and its safe state behavior holds up in the tested cases. The player is readable with the game centered and controls grouped around it, but again, there is no working DS or 3DS system. Astra also gets 2.2. Haiku has more actual Game Boy than its final score might initially suggest. Its unit tests pass. It clears 15 serial blog test cases and it passes 10 of the 12 selected Mooneyi diagnostics. input changes the rendered frame and ordinary replay and battery save checks work.

[03:15] Then the boundary tests expose timer and interrupt problems. A sound accuracy failure and a malformed color pallet state that is accepted but crashes when the next frame runs. Loading a valid state while paused can also leave the old image on screen. Its DS code can execute ARM instructions, but the surrounding machine is missing. In the DS fixtures, the instruction counter runs into the millions while the video state stays at zero. graphics, device scheduling, and the other systems needed to produce a working DS are absent. Haiku gets 1.8. GLM doesn’t reach a usable player. The executable prints the

[03:50] project name, and exits. There is some Game Boy library code, but no connected application for selecting a ROM, playing it, and saving progress. The diagnostic checks also find failures, a panic, and several timeouts. It gets 0.6. Opus makes the most progress here at 3.7. It has Game Boy execution and actually runs two DS diagnostic or homebrew programs, Arm Wrestler and Bunny Garden. Both screens produce output and DS save states restore and continue deterministically. The output is rough. Text overlaps in one test and the other

[04:25] scene is sparse. There are missing DS features and 3DS execution is absent. I can give Opus credit for a functioning piece of DS emulation without pretending that two test programs establish broad game compatibility. So, nobody delivers the complete emulator. Opus wins this task because it implements more of the requested systems. The others don’t get the missing platform points just because their Game Boy portion has a nice interface or a long list of passing tests. The next request is a Docker alternative that can use Docker images,

[04:56] is built without Docker’s libraries or copied code, and is more efficient than Docker. There are several jobs inside that request. You need to retrieve images, apply their fall system layers correctly, start processes with the right isolation, and manage those processes. You also need a comparison that demonstrates the efficiency claim. None of these projects proves that it’s faster or more efficient than Docker. Independent Linux isolation testing also remains incomplete across the five submissions. The image handling checks tell us more about what works here than the presence of a run command in the

[05:29] source. Soul gets the highest score at 5.0. Docker archive import, image export, and reload tags, digest preservation, and simple scratch image builds work. It also passes the four common archive boundary checks, including attempts to escape through file system links and cases involving deleted files and image layers. The source contains a substantial Linux runtime, but several expected features are missing, including published ports, a full interactive terminal workflow, and broad Docker file support. So, this is useful image engine work with an execution path still awaiting independent verification. Opus exposes the broadest set of container commands.

[06:02] There is code for creating, starting, restarting, and stopping containers, plus mounts, ports, logs, and terminal handling. Its portable image workflows work, too, but it mishandles white outs. These are markers that tell an image layer to remove files inherited from an earlier layer. In two tests, Opus deletes new files created within the same layer. You can end up with the wrong file system before the application inside the container even starts. Opus gets 4.6. Astra also gets 4.6, although its strengths are different. It passes those four extraction boundary checks and handles

[06:34] the tested build, save, load, and tagging workflows. Its runtime is narrower with missing resource quotas and several Docker features including Docker file run volumes and publish ports. GLM can pull a public Alpine image and save and reload it while preserving the image identity. However, its archive extraction can write outside the intended directory and another test can delete a file outside that directory. Those were controlled test files and the escapes were reproduced. GLM gets three. Haiku gets 30 O as well.

[07:05] Its registry and image management workflow works, including skipping redundant extraction when an image is pulled again. But a crafted layer makes it change the permissions and timestamp of an existing file outside the extraction directory. The files contents stay intact in Haiku’s case. The defect is that an archive can change permissions on something it shouldn’t be touching. That is enough to cap the result. Even though the ordinary image management commands work, there is useful engineering in these projects, especially the image tooling. None of them gives me evidence for the full replacement or the efficiency advantage that the prompt asks for. The room

[07:37] designer is a much better showing across the board. Here the request is to set room dimensions, create furniture with different sizes, shapes, and colors, place it in a 3D space, and make the lighting and materials look realistic. All five produce applications where you can actually edit the room. Saul’s version has a clear control layout, a furniture tray, working dragging and rotation, undo, colored lighting, and save and export features. Changing the room dimensions changes the geometry, so the controls are connected to the scene. One small looking mistake makes furniture creation awkward. Clicking a custom color swatch submits the form before you finished because the swatch

[08:09] button behaves like a submit button. The materials also remain fairly matte. The upholstery is blocky and the foliage is primitive. Moving furniture causes broader rebuilding than necessary. Instead of updating that object’s position, the app rebuilds all the furniture meshes. that can still feel fine in a small room, but it creates unnecessary work as the project grows. Soul gets 8.0. Opus wins this one at 8.5. It has the strongest material and lighting treatment in this set with fabric and wood detail, differentiated

[08:39] surfaces, contact shadows, and reflections. Placement controls include dragging, rotation, numerical positioning, elevation, and support snapping. The result still has boxy furniture, repeated wood grain, and some overly bright lamp surfaces. I’d keep refining those materials, but the differences between fabric, wood, and reflective surfaces already give the room more character. The save feedback has a bug, though. When the storage is forced to reject a save, the interface still says saved locally. The room on screen has changed while the stored room still contains the old dimensions.

[09:11] Normal saving works. The failure is that the interface tells you the wrong thing when saving fails. Astrogates 8.3. Its editing workflow is broad and functional with custom furniture dimensions and colors, placement, lighting, undo and reload. It also rejects duplicate object IDs in imported projects. The scene looks clean, but the furniture and foliage are simplified, and the lighting leaves some walls looking flat. It keeps rendering and recomputing contact shadows even while the room is unchanged. The resource checks also show substantial allocation churn during edits, although they don’t establish a

[09:42] memory leak. GLM gets 7.8. The core editor works, including dimensions, placement, rotation, and duplication, but some wood accents ignore the selected color and stay white. The import rules and the room size slider also disagree about the minimum room size. Visually, the plants look like stacked geometric shapes. The cabinets are blocky and some surfaces are too bright. You can plan a room with it, but the prompt also asks for realism, and that part remains limited. Haiku ties Astra at 8.3. It supports nine custom

[10:14] shapes, numerical rotation and elevation. Dragging, undo, and lighting controls. A custom glossy red cylinder gets the requested dimensions and material, and changing a fixture color actually changes the illumination. I like the material variety here. There is recognizable wood, upholstery, glass, and bookshelf detail. Some highlights blow out to white. The foliage still looks like clusters of balls, and the window view is flat. Imported projects also need better validation. Haiku handles idle rendering better than the others. When nothing changes, it stops drawing in the tested movement path. It

[10:46] also keeps the existing mesh instead of repeatedly recreating it. So, Opus has the best room overall, while Astra and Haikutai for second with different trade-offs. All five deliver a useful part of the request here. The differences come from realism, small broken controls, save recovery, and how much work the renderer does unnecessarily. The fourth project is a VA alternative for QMK keyboards with a yellow theme and a full set of customization features. The connected keyboard part is central to this task. Editing a picture of a keyboard and saving a local profile is only part of the workflow. The app also has to communicate with compatible firmware and

[11:19] read or change the configuration. The protocol checks here use independent simulated firmware. The tests didn’t use a physical keyboard that lets us inspect the actual messages and responses, but it doesn’t prove compatibility with every board or that changes survive on a real device. Soul has an attractive yellow interface, local editing, undo, validation, and saved profiles. It even has a real diagnostic path that can request the protocol version and number of layers. But connected keymap reads and writes are missing. The app can’t

[11:53] perform the central remapping job. So, Soul gets 30A. Astra gets 30A for the same missing workflow. It has polished local profiles, undo, and export. and it can use the browser’s device picker. But selecting a device isn’t followed by opening it and sending the remapping protocol. The interface goes further than the hardware integration. GLM makes a substantive attempt at that integration. Layered key reads and key write packets work in the fixtures and bulk reading is reasonably organized. It gets 4.6, but there are failures in both

[12:26] basic remapping and the additional features. Incomplete key replies and replies for the wrong key position can be accepted. Standard keyboard definitions are rejected. A lighting command uses the wrong payload. And even a plain high macro is encoded incorrectly. Some early responses can also be lost until the request times out. Opus wins at 7.5. Its implementation covers opening the device, serialized communication, layered keymap reads and writes, standard keyboard definitions, macros, lighting, and backup workflows. The tests independently read back changed

[12:56] keys from the simulated device. The yellow interface has large keys and clear sections, and the features connect to much more of the protocol. It still handles some malformed replies badly. A truncated response can silently become an empty key assignment, and incorrect coordinate echoes are accepted. Haiku comes second at 6.7. It also implements substantial device communication with working core key map packets, encoders, macros, lighting, and ordinary backup, and restore in the fixtures. The yellow and near black interface is clear with raised key caps and useful editing forms. Its most visible failure comes

[13:29] from ordinary text entry. Type an accented character into the macro field and the whole app can go blank because a validation error escapes into rendering. The app could simply explain that the character isn’t supported. Instead, it crashes the interface. A deliberately malformed backup exposes another issue. It can write a key before discovering invalid macro data and the cached state then causes a later restore to claim success without correcting that key. Disconnecting, reconnecting, and restoring recovers the tested case, but the normal feedback is misleading. This task separates the models quite clearly.

[14:04] Opus and Haiku implement much more of the actual configuration workflow. GLM attempts it, but gets several protocol details wrong. Soul and Astra deliver useful local editors while leaving connected remapping absent. Now, the Pokemon task asks for an HTML recreation of Pokemon Red with Pallet Town and the quests through the rock gym working. There is a whole sequence to support here. You need to get your starter, handle the parcel quest, travel through the routes and forest, fight battles, reach Brock, and keep the progress you’ve earned. The game’s appearance and mechanics also need to resemble the thing being recreated. Astra is the strongest result at 8.5. The normal

[14:35] route reaches and defeats Brock, and the earned badge survives reloading. Battles, captures, items, and party progression have working paths in the testing. Its green Game Boy style palette and battle sprites give it the best resemblance of this set. The surrounding controls are polished and the game remains readable. I would still call it an adaptation. The maps are rearranged. The gym is simplified and combat uses only two fixed moves per species without the full PP status and evolution system. Soul gets 8.2. The starter and rival sequence, parcel quest, forest trainers, and journey to

[15:07] pewtor are connected. Normal play can earn the badge, catch another Pokémon, and retain that progress after reloading. The town and characters are readable, and the interface gives you clear objectives and party information, but the maps and battle art take more liberties, and the battle system has similar omissions. Even the rival encounter uses a Pidgey, where the expected counterstarter would change the experience. It’s a playable chapter with a lot of the requested flow, but the resemblance only goes so far. GLM gets 7.1. The opening quests connect properly. The forest and pewtor are

[15:40] reachable and ordinary save and continue retain the tested progress. Battles, items, and training work in the normal route. The independent playthrough reaches Brock and verifies defeat and recovery, but doesn’t establish a normal route victory. I’m keeping that distinction in the score. There are also combat mistakes such as moves remaining usable after their PP runs out. And the visuals are much crudder. Characters, trees, and buildings look like simple blocks with a small game area surrounded by a lot of empty space. Haiku gets 6.3.

[16:11] Its normal playthrough chooses Bulbasaur, completes the parcel quest, catches a Pidgey, and travels to Pewtor. The testing includes losing to Brock, recovering at the Pokémon Center, walking back, and winning. Saving and reloading keep the earned badge and party. So, the chapter has a working route. The presentation is what immediately stands out as unfinished. Bulbasaur is a green circle, and Onyx is an ogre circle. The forest is sparse. The buildings are simple and some essential text is tiny. There are substantial gameplay cuts as well. The rival encounter is absent. The forest

[16:42] has no trainer interactions and manual party switching and usable healing items are missing. A separate battle test also finds a dead end when all moves run out of PP. Haiku reaches the requested destination, but too much of the surrounding game has been reduced. Then there’s Opus, which gets 3.0 despite having a substantial playable chapter. The route reaches Brock, wins the battle, and awards the badge, training, move PP, healing, and defeat recovery work. This is more than a title screen or a disconnected battle demo. But

[17:15] pressing the advertised start key opens and immediately closes the menu that makes the normal save option unreachable along with several field menus. The earned chapter progress disappears on reload because you couldn’t save it. The same menu bug appeared with both short and long key presses. I can’t give a high score to a delivered game that prevents you from saving an earned badge, even when a lot of the rest is playable. For this task, Astra and Soul produce the strongest usable chapters. Opus shows how one broken control path can undermine a much larger amount of working code. The final request is a

[17:48] desktop app for Fitbit Air workout analytics and cardio load with a Rust backend and the feature depth of the Whoop mobile app. This gives the models another opportunity to build something that looks finished before all the data paths are connected. A dashboard can display attractive recovery rings with demo data, but the app also has to ingest useful records and calculate sensible results when information is missing. The checks use synthetic records and documented data formats without a personal Fitbit account. Live tracker sync remains unverified. The native desktop interactions also weren’t

[18:21] established equally across these apps, so browser behavior and back-end tests only earn the credit they can support. Soul gets 6.6. It has a substantive Rust analytics core and a polished local fitness dashboard. Workout history, trends, sleep summaries, and a save journal provide useful functionality. Its ingestion is limited to its own normalized JSON format. It doesn’t directly handle the provider export workflow requested by a Fitbit user. So you would need to convert the records yourself. The journal also stops short

[18:51] of relating habits to recovery and the advice lacks much of the adaptive depth the prompt asks for. The large history checks find another practical issue. It renders the entire workout list without pageionation. A thousand rows produce more than 20,000 page elements. It completes the tested workload, but the implementation does more work than it needs to. Astro gets 7.3. It can import a narrow official format Fitbit activity log, convert units and times, and merge records. Its tested core calculations also handle optional missing inputs appropriately. The light dashboard is orderly, but some small decorative heart

[19:24] rate and HRV charts turn missing days into zero. With a single imported measurement, the chart can draw a rise from a zero baseline that was never measured. The main calculations can be correct while the visual presentation still implies something false. The app also lacks live account sync and the full coaching and sleep planning depth. Its backup roundtrip misses journal and preference restoration. So exporting a file doesn’t yet guarantee that every part of the app comes back when you import it. Opus leads at 7.4. It implements more of the requested analytics, sleep need and debt, consistency, adaptive baselines, training load advice and logic that

[19:57] relates recorded behaviors to recovery. Its dark interface has clear rings, sleep stages, and missing data states. The backend can import the supported Google Health data format and its persistence and repeat import behavior have working tests. The browser presentation here was inspected using results from the actual analytics core through a test adapter that doesn’t establish working live account onboarding or every native interaction. There is a serious calculation bug in partial heart rate coverage. A 1-hour workout at an average heart rate of 150 produces a load of about 100. Add a

[20:32] single unrelated resting heart rate sample from 2 in the morning and the daily load drops to zero. The presence of that once sampled disables the fallback that was accounting for the workout. So, Opus has the broadest feature implementation, but one ordinary kind of incomplete data can make a main metric wrong. GLM gets 4.4. It has a runnable Rust analytics core and valid input calculations can work, but missing heart rate can be replaced with invented values such as 120 or 150. Missing dates can become assumed sedentary history and duplicate workout IDs can double the aggregate load. Those assumptions can

[21:04] turn incomplete records into confident looking numbers. Its native interface also wasn’t successfully verified. So I can’t make a visual quality claim from a screenshot that doesn’t exist. Haiku gets 6.4. Its Rust backend, SQLite storage, and actual format file imports provide a useful base. In the browser test, uploading an exercise file correctly stores 5 km, 30 minutes, and a heart rate of 150. Reimporting doesn’t duplicate the workout, and the record survives reload. The interface is coherent with useful chart and table

[21:36] views. But a workout with missing heart rate information can get a measured looking load of zero. A first recorded day can also produce a high-risisk label without enough history to support that interpretation, and a short imported workout can receive more credited time than its actual duration. There are smaller workflow bugs, too. Filtering the workout table can leave the summary cards showing totals for all activities, and a startup rendering bug can leave discarded charts, scheduling redraws after you’ve moved to settings. The measured CPU cost was small, but the unnecessary work is reproducible. So,

[22:09] Opus and Astra lead the fitness task with different weaknesses. None establishes the complete live Fitbit to Desroe experience and the full Hoop style feature set. The better submissions are useful local analytics projects that still need work on integration, missing data, and recovery from errors. Now, here’s the final chart across all six projects. Opus 5.5 finishes first at 57.8% followed by GPT 6 Astra at 56.5%. GPT 6.1, Soul gets 55.0%, haiku 5.5 gets 54.2% and GLM 5.3 gets 45.8%. Opus wins

[22:46] four individual tasks, the emulator, the room designer, the keyboard configurator, and the fitness app. Soul wins the container task, while Astro wins Pokémon. Haiku doesn’t win a task outright, but it ties Astra on the room designer and comes second on the keyboard app. Across the whole set, it finishes only 0.8 percentage points behind Soul. That is close enough that I’d look at the actual project I wanted to build before choosing between them from this chart. The task breakdown also explains why a single overall percentage can hide a lot. Opus leads most categories, but its save menu failure is severe. Soul and Astro produce strong playable games while both leave

[23:17] connected keyboard remapping unimplemented. Haiku produces a useful room editor, but doesn’t get anywhere close to the complete emulator request, and the overall winner is still below 60%. The prompts include some very large pieces of software and the scores reflect the gap between those requests and what arrived in one session. A working slice of a project can be useful without fulfilling the rest of the specification. Now, let’s look at the tokens and cost because that changes how I’d interpret Haiku’s result. These are API equivalent estimates calculated from the recorded usage and the list prices

[23:47] captured for this benchmark. They aren’t the amount charged to a clawed code or codec subscription. They covered generation with the later evaluation and reporting work excluded. Some of the runs don’t have complete final usage records. Adding the available numbers for all six tasks would understate their totals. For a comparison with complete usage across all five models, I’m using the same three projects, the room designer, the keyboard configurator, and the Fitbit app. On those three tasks, Soul uses about 9.26 million tokens with an estimated cost between $342 and 337s. Haiku uses about 41.18 million tokens

[24:22] with an independently calculated cost between $3.79 and $35.66. The ranges cover missing per request context and cash details. These totals include instructions, files, tool results, and conversation history read across many requests with reasoning counted once. Much of the repeated input can be served from a cheaper cache. So, Haiku records more than four times Souls tokens on the same three projects. But the token count alone doesn’t rank their expense. The input, output, and cash prices all contribute to the bill. For the same three projects, Haiku’s estimated API cost is about 85% lower

[24:55] than Opus’. Its average score on that subset is 71.3% compared with Opus at 78.0%. So, Opus scores higher on those tasks, while Haiku gets reasonably close at a much lower API equivalent cost. Soul and Haiku’s price ranges overlap. So, these records don’t establish which is cheaper. Across all six Hiku projects, the recorded total is about 78.19 million tokens. Roughly 76.65 million are input, including reused cached context, and 1.54 million are output. Claude Code reports an API equivalent estimate of about $7.40,

[25:30] while independent repricing puts it between $7.40. Seek thinks. Personally, Opus gives me the strongest starting point across the widest range of these tasks. The room designer keyboard implementation and broader fitness logic are the reasons I choose it here. I would still test the save path and the calculations before trusting those apps because both produced concrete failures. For the browser game, I choose Astra from this set. It combines a completed saved first gym route with the best resemblance to the requested game. Soul

[26:00] is close and its container image tooling also has the strongest result in that category. Haiku is the one I’d be most interested in trying first on another bounded app project where cost matters. Its room designer and keyboard protocol work give me reasons to do that. I wouldn’t choose it for the emulator based on this run and I wouldn’t assume its attractive dashboards make the underlying calculations reliable. GLM’s room designer and connected game quests show that it can produce substantial applications. In this set, the unfinished emulator, archive escapes, and invented fitness data pull it behind

[26:32] the others. Those are specific problems I’d want another run to overcome before changing that verdict. What I take from these projects is a practical testing habit. Follow the feature all the way through. Change the key and inspect the device message. Beat the gym and reload the game. Import a workout with a missing measurement and check what the chart displays. Those actions explain the scores far better than the number of files the model created. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. If you like this video, consider donating through the super thanks option or becoming a

[27:03] member by clicking the join button. Also, give this video a thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye.