Opus + Sol em equipe orquestrada: supera todos os modelos de IA agora? (Testado)

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: Opus + Sol Orchestrated Team: This BEATS every AI MODEL right now! (Tested) · Canal: AICodeKing · 13:55 · Assistir no YouTube

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

Resumo

O vídeo compara cinco equipes de modelos, cada uma com um modelo líder e até três workers, em seis tarefas de programação. Opus com Sol obtém a maior pontuação total entre os resultados apresentados, enquanto equipes diferentes se destacam em tarefas específicas, como emulação, editores visuais e jogos. O apresentador também destaca falhas de planejamento, interrupções por limites de uso e diferenças de custo e consumo de tokens. Como os testes não tiveram orçamentos computacionais equivalentes e vários registros de uso estão incompletos, o vídeo ressalta que as conclusões sobre capacidade, confiabilidade e custo ainda são limitadas.

Pontos-chave

O teste compara cinco equipes de modelos em seis projetos, com um modelo líder que planeja e revisa o trabalho dos workers.
Opus com Sol obteve 44,2 de 60 pontos, a maior pontuação total registrada.
Opus com Sonnet teve o melhor resultado na tarefa de emulação, enquanto Astra com Sonnet liderou as tarefas de designer de ambientes e jogo de Pokémon.
Planos que omitem funcionalidades obrigatórias podem limitar o resultado de toda a equipe, mesmo quando o trabalho executado é bem feito.
Interrupções por cotas e erros de limite de uso afetaram algumas tarefas e impedem uma comparação completa da capacidade das equipes.
Os testes indicaram falhas em integrações, importação de dados, salvamento e outras jornadas de uso, mesmo nos aplicativos com bons resultados.
O total registrado foi de cerca de 936,11 milhões de tokens, mas a maior parte da entrada era contexto repetido e as contagens não medem diretamente código útil.
Os custos finais de todas as equipes permanecem desconhecidos; apenas oito das 30 tarefas tiveram registros de uso completos.
O apresentador recomenda conferir se cada funcionalidade necessária tem um responsável antes de iniciar o trabalho dos workers.

Capítulos

Início	Capítulo	Resumo
00:02	Configuração do teste e emulação	O vídeo apresenta as equipes e os critérios de comparação, depois avalia os resultados na tarefa de emulação.
03:20	Designer de ambientes e configurador de teclado	A comparação aborda a qualidade dos aplicativos visuais e verifica se as equipes conseguem enviar configurações a um teclado virtual.
06:00	Jogo de Pokémon e aplicativo Fitbit	O apresentador examina a jogabilidade e o salvamento do jogo, além de integrações, dados e cálculos nos aplicativos de saúde.
09:42	Resultados gerais, tokens e custos	O vídeo resume as pontuações e detalha as limitações dos registros de uso, do consumo de tokens e das estimativas de custo.
12:21	Recomendação e próximos passos	O apresentador escolhe uma configuração inicial, aponta ressalvas nas comparações e recomenda conferir os responsáveis por cada funcionalidade.

Citações

Um modelo planeja o trabalho e verifica os resultados, enquanto outro cuida das atribuições. — 00:02

Esse é o tipo de ciclo de revisão que eu quero de uma equipe. — 03:20

A lição maior é incluir a conexão com o dispositivo antes de investir mais na aparência. — 05:27

Eu verificaria se cada funcionalidade obrigatória tem um responsável antes de os workers começarem. — 13:24

Conceitos e entidades

Opus 5.5 (modelo): Modelo usado como líder ou worker em várias das equipes comparadas.
Sonnet 5.5 (modelo): Modelo que participou de equipes com Opus e Astra e obteve destaque na emulação.
GPT-6.1 (modelo): Modelo citado entre os modelos considerados no vídeo.
GPT-6 (modelo): Modelo citado entre os modelos considerados no vídeo.
Astra (modelo): Modelo que liderou equipes avaliadas em tarefas como designer de ambientes e jogo de Pokémon.
Sol (modelo): Modelo usado como worker em equipes lideradas por Opus ou Astra.
Muse Wonderful 1 (modelo): Modelo citado entre os participantes do teste; algumas de suas execuções foram afetadas por interrupções de cota.
Bambood (ferramenta): Ferramenta pela qual as equipes executaram os trabalhos, segundo a transcrição.
Claude Code (ferramenta): Ferramenta usada para executar os trabalhos das equipes.
Codex (ferramenta): Ferramenta usada para executar os trabalhos das equipes.
Muse CLI (ferramenta): CLI nativa do Muse usada nas execuções mencionadas.
orquestração (conceito): Organização do trabalho em que um modelo líder planeja e verifica tarefas atribuídas a outros modelos.
AICodeKing (empresa): Canal do YouTube que publicou o vídeo.

Tradução completa (pt-BR)

00:02 Olá. Bem-vindos a mais um vídeo. Testei cinco equipes de IA para descobrir qual configuração de líder e trabalhador eu realmente usaria em um projeto de programação. Um modelo planeja o trabalho e verifica os resultados, enquanto outro cuida das tarefas. Isso é orquestração, e as decisões do líder podem moldar o aplicativo inteiro. Acompanhei as conversas entre eles e testei os aplicativos. Então, vamos ver onde o trabalho em equipe ajudou e onde falhou. Os modelos são Opus 5.5, GPT 6.1, Sol, GPT 6, Astra, Sonnet 5.5 e Muse Wonderful 1. Os cinco pares são Opus

00:37 com Sol, Astra com Sonnet, Opus com Sonnet, Astra com Sol e Opus com Museful. O primeiro modelo é sempre o líder. Tudo foi executado pelo Bambood usando Claude Code, Codex e o Muse CLI nativo. Cada equipe teve até três trabalhadores simultâneos, 20 rodadas do líder e 50 tarefas, sem limite de tempo adicional. As seis tarefas foram um emulador, uma alternativa ao Docker, um designer de ambientes, um configurador de teclado, uma abertura de Pokémon e um aplicativo desktop para Fitbit. Cada tarefa valia 10 pontos. Cada par recebeu uma execução de alto esforço por tarefa em uma máquina compartilhada, sem orçamentos computacionais iguais

01:10 entre as equipes. Não há testes individuais comparáveis nem inversão dos papéis, então esta comparação não isola o quanto a delegação em si ajuda. O emulador pede suporte a Game Boy, DS e 3DS em Rust, incluindo salvamento e recursos normais de reprodução. As duas equipes lideradas por Astra planejaram a execução de Game Boy, mas apenas a inspeção de arquivos para DS e 3DS, deixando esses caminhos de execução ausentes. Astra com Sonnet recebe 1,9 de 10, e Astra com Sol recebe 2,2. Mas melhorar o suporte a Game Boy não faz um inspetor de arquivos de DS executar jogos de DS. Opus com Sol recebe 6,2, com caminhos de execução conectados para os três

01:43 sistemas. Os exemplos de DS e 3DS demonstram a renderização, com verificações de entrada separadas para 3DS. Opus com Sonnet recebe 7,1, a maior pontuação no emulador. Ele passa em todos os oito diagnósticos compartilhados de Game Boy, e o City Builder de Game Boy Color oferece controles úteis e salvamento. Os exemplos de DS e 3DS também avançam mais, embora esses pequenos testes de homebrew não provem que a maioria dos jogos comerciais funcione. Opus com Museful recebe 5,8, com algum resultado nos três sistemas, mas resultados em branco ou incompletos em exemplos mais abrangentes.

02:16 Erros de cota do provedor interrompem os trabalhadores, e o líder conclui uma parte maior do trabalho. Assim, Opus com Sonnet produz o emulador mais forte aqui. Já as equipes Astra mostram como um plano incompleto limita tudo o que vem depois. Para a alternativa ao Docker, importar uma imagem é apenas parte do trabalho. Também são necessários isolamento de processos e controles de recursos, e essas avaliações hospedadas em macOS não comprovaram que havia isolamento funcional pelos caminhos de Linux entregues. Isso limita as pontuações a cinco, mesmo quando as ferramentas de imagem funcionam. Opus com

02:47 Sol, Opus com Sonnet e Astra com Sonnet recebem 5,0. Astra com Sol recebe 4,7, com fluxos de trabalho funcionais para o registro e para salvar imagens do Docker, mas sem importação do formato padrão de arquivo OCI. Nenhuma das equipes demonstra a vantagem de eficiência solicitada em relação ao Docker. Opus com Museful recebe 3,0 após um teste de extração que altera as permissões de dois diretórios próprios fora do caminho de extração pretendido. O conteúdo deles permanece inalterado, e ambos continuam dentro do diretório pai de armazenamento do aplicativo. Isso não demonstra que um convidado tenha escapado do Linux nem que tenha sobrescrito arquivos arbitrários do host.

03:20 Essa execução também sofre interrupções por cota, e nenhum desses resultados comprova uma substituição completa do Docker. O designer de ambientes produz aplicativos muito mais utilizáveis. No projeto de Opus e Sol, um testador percebe que selecionar uma cadeira faz a área de visualização ficar em branco. O líder suspeita de um problema antigo com a captura de tela do construtor, mas o testador reproduz a falha. Um trabalhador corrige o destaque da seleção, e o líder verifica o aplicativo reconstruído. Esse é o tipo de ciclo de revisão que quero de uma equipe. Opus com Sol recebe 8,9, enquanto Opus com Sonnet e Astra com

03:52 Sol recebem 9,0. A versão de Opus e Sonnet ainda permite que móveis grandes demais ultrapassem os limites de um cômodo menor. Opus com Museful recebe 8,9, com formas personalizadas, iluminação colorida e restauração funcional de projetos. Alterações de cor deixam três texturas extras retidas, embora edições normais seguidas de desfazer permaneçam estáveis. Essa execução termina sem nenhuma falha de cota observada, embora ainda haja lacunas nos registros de uso. Astra com Sonnet recebe 9,3, a maior pontuação no designer de ambientes. O líder atribui responsáveis separados ao modelo do ambiente, ao editor

04:23 e ao renderizador e, então, envia correções específicas conforme essas partes se conectam. A edição e a restauração de projetos funcionam, e adicionar e remover objetos repetidamente retorna as contagens de recursos aos valores originais. Um objeto muito fino pode ultrapassar ligeiramente a parede, mas, com base nesses resultados, eu escolheria este designer de ambientes. A tarefa do teclado pede uma alternativa com tema amarelo ao VA que configure teclados QMK. Um editor bonito não basta se o teclado nunca recebe as alterações. Verifiquei as mensagens de configuração e o estado resultante por meio de um teclado virtual controlado de forma independente. Isso é uma evidência limitada de compatibilidade, não uma prova de suporte a todos os teclados físicos ou versões de firmware.

04:54 Opus com Sol recebe 7,8, e Opus com Sonnet recebe 7,4. Ambos enviam mensagens de configuração que alteram o estado do dispositivo testado, mas as limitações de edição, compatibilidade e backup reduzem suas pontuações. As duas versões lideradas por Astra recebem 2,8, e as tarefas atribuídas explicam o motivo. Astra com Sol atribui a seleção e os metadados, enquanto Astra com Sonnet exclui explicitamente a abertura do dispositivo e o envio de mensagens de configuração. O benchmark proibia alterar hardware real conectado, mas não proibia

05:27 implementar esse caminho de comunicação. Assim, as equipes melhoram os editores locais, enquanto a conexão necessária continua ausente. Opus com Museful recebe 7,7, com códigos de tecla, macros, iluminação e restauração funcionais em um perfil novo do navegador. Ainda assim, aceita uma confirmação incompleta, e importações de macros inválidas podem alterar parcialmente a configuração. Falhas de cota também interrompem os trabalhadores antes que o líder conclua outros reparos. Opus com Sol lidera esta tarefa, e a lição mais importante é incluir a conexão com o dispositivo antes de dedicar mais trabalho à

06:00 aparência. Para Pokémon, eu queria uma abertura normal e jogável até o primeiro ginásio, com progresso que sobrevivesse ao salvamento e ao carregamento. Opus com Sol recebe 8,6, e Opus com Sonnet recebe 8,7. Ambos completam esse percurso quando o armazenamento do navegador funciona, mas mudanças nos nomes, arte mais simples e mecânicas simplificadas reduzem a fidelidade. Os testes considerados na avaliação usam jogo normal, não os grupos dos agents com níveis muito altos nem a cura automática. Opus com Museful recebe zero porque não entrega um jogo jogável.

06:30 Há um contrato e um auxiliar gráfico, mas não há ponto de entrada, batalhas pelo mundo nem salvamento. Erros de cota da assinatura afetam os seis trabalhadores usados durante a execução e, por fim, impedem até mesmo um pedido para ler uma linha e responder. Essa nota zero descreve o projeto entregue, não o que Muse poderia fazer com capacidade disponível. Astro com Sonnet recebe 9,1, a maior pontuação em Pokémon. O líder percebe que um passo a passo manda os jogadores curarem Imputer sem disponibilizar um centro de cura. Ele atribui a criação da porta, da enfermeira e do caminho de volta, que estavam faltando. O percurso independente completa a missão de entrega do pacote, captura um

07:03 Pokémon selvagem e chega até Brock atravessando a floresta. Nas derrotas normais, o jogador perde dinheiro e não ganha insígnia; ao vencer a partir de um salvamento legítimo, recebe a insígnia e o dinheiro esperado. O progresso sobrevive a outro recarregamento quando o armazenamento funciona. Ainda é um jogo reduzido, sem evolução nem limites de uso de movimentos. Uma mensagem enganosa de salvamento bem-sucedido quando o armazenamento está bloqueado também tira pontos, porque, ao recarregar, o jogador perde esse ponto de controle temporário. Astro com Sol também recebe zero, com uma pasta completamente vazia depois que um erro HTTP

07:34 429 esgota as tentativas. Os registros não permitem determinar se a causa foi a cota da conta ou outro limite de taxa. Astro com Sonnet lidera a comparação dos jogos concluídos, enquanto essas execuções interrompidas precisam de acesso funcional ao provedor antes que possamos avaliar todo o potencial delas. A tarefa do Fitbit pede um aplicativo desktop de análise com um back end em Rust. Opus com Sol recebe 7,7, enquanto Opus com Sonnet recebe 6,5. Os clientes do provedor de Sol funcionam com entradas de teste controladas que representam as respostas esperadas do provedor, enquanto a conexão externa de Sonnet recebe pontos apenas com base na inspeção do código-fonte. Nenhum dos resultados

08:06 comprova uma conexão com uma conta pessoal do Fitbit nem precisão clínica. No aplicativo de Opus e Sonnet, a carga calculada de um treino pode aparecer na visualização de detalhes, mas desaparecer do resumo diário. No aplicativo de Opus e Sol, os dados de demonstração substituem as medições diárias importadas, e limpar os dados de demonstração remove esses dias. Importar novamente o CSV sintético original restaura os valores exatos, então a perda demonstrada pode ser recuperada. Opus com Museful recebe 6,3, com cálculos substanciais em Rust, mas com botões de conexão e importação quebrados, que falham antes de chegar ao back end.

08:39 Chamadas diretas ao back end não corrigem esses botões quebrados. Essa execução também sofre interrupções por cota. Os dois aplicativos de saúde liderados por Astro recebem 7,6. Astro com Sonnet detecta que a atualização dos dados de demonstração exclui os registros do usuário. Um trabalhador também encontra uma interface antiga dentro da aba de pacotes, então o líder a reconstrói e verifica os arquivos incorporados. Um arquivo-fonte corrigido não ajuda se você iniciar um pacote antigo. O aplicativo final aceita registros de treinos e de diário, e os dados sobrevivem à exportação, importação e reinicialização, mas ele aceita apenas o próprio formato JSON, sem conexão com o Fitbit

09:10 ou o caminho real de exportação do Fitbit. O cálculo da carga considera os dias ausentes como zero, então um histórico incompleto pode gerar resultados enganosos. A Astra com Soul corrige as novas tentativas que poderiam criar treinos duplicados após uma resposta perdida. Um teste independente perde essa resposta e, em seguida, tenta novamente após reabrir a caixa de diálogo; apenas um treino permanece. O rascunho pendente ainda não sobrevive ao recarregamento do aplicativo. Esse aplicativo também depende do próprio formato JSON, em vez de uma conexão funcional com o Fitbit. Ele mostra zero passos em um dia que contém apenas um treino e exibe mil

09:42 treinos como mil linhas de tabela. As verificações de saúde da Astra usam os serviços em Rust em um navegador, então a experiência completa do aplicativo nativo para desktop continua sem ser verificada. Opus com Soul lidera esta tarefa, mas todos os resultados ainda têm lacunas em relação ao produto solicitado. Agora, aqui está o resultado geral. Opus com Soul obtém 44,2 de 60, ou 73,67%. Opus com Sonnet vem em seguida, com 43,7 ou 72,83%, em cinco tarefas afetadas por limites de uso. Astra

10:13 com Soul obtém 26,3 ou 43,83%, incluindo sua execução interrompida de Pokémon. Mantenho visíveis essas pontuações dos resultados entregues, mas as interrupções impedem uma classificação justa da capacidade entre as cinco equipes. Essas porcentagens medem os pontos obtidos, não a taxa de sucesso futura. Para tokens e custo, os totais incluem líderes, workers, correções e chamadas adicionais registradas ao modelo. A configuração e a avaliação foram excluídas. O uso retomado é contabilizado apenas uma vez, e os registros ausentes continuam desconhecidos. O total é de cerca de 936,11

10:44 milhões de tokens registrados, incluindo 926,74 milhões de tokens de entrada e 9,37 milhões de tokens de saída. A maior parte da entrada é contexto em cache repetido, e o raciocínio já está incluído na saída, então não é contado duas vezes. Opus com Sonnet registra cerca de 444,81 milhões de tokens, em comparação com 143,73 milhões para Opus com Soul. Astra com Sonnet registra 107,06 milhões, Opus com Muse full registra 155,06 milhões, e Astra com Soul registra 85,45 milhões. Essas contagens incluem contexto repetido

11:17 e não medem diretamente código útil. Usando as tarifas de API salvas, Soul e Sonnet custam cada um US$ 2 por milhão de tokens de entrada nova, US$ 0,10 por leituras em cache e US$ 10 por tokens de saída. Opus custa US$ 4,20 e US$ 20 nessas categorias, enquanto Astra custa US$ 10, US$ 1 e US$ 0,50. Portanto, Opus custa o dobro por unidade que Soul, enquanto Astra custa cinco vezes mais por tokens de entrada nova e de saída, e dez vezes mais por leituras em cache. As regras para gravação em cache e contexto longo também afetam os cálculos.

11:49 Para Muse full, usei a suposição padrão solicitada, de US$ 4 por tokens de entrada nova, US$ 0,20 por leituras em cache e US$ 20 por tokens de saída. Essa não é uma tarifa completa confirmada nem uma fatura de assinatura. E não há uma tarifa completa confirmada para gravação em cache aqui. Para os subtotais, os registros de custo nativos do Claude substituem as estimativas de tokens do Claude quando disponíveis; para os outros provedores, uso estimativas de tokens. Essas alternativas não são somadas entre si, e os registros não estabelecem todas as tarifas de serviços hospedados. Opus com Soul registra cerca de US$ 56,97,

12:21 enquanto Opus com Sonnet registra US$ 124,22. Astra com Sonnet registra US$ 68,75. Opus com Muse full registra US$ 80,22, e Astra com Soul registra US$ 75,22. Isso dá cerca de US$ 405,49 em uso de orquestração registrado, mas apenas oito das 30 tarefas têm dados de uso capturados completos. O custo final de cada equipe continua desconhecido, então esses subtotais não permitem identificar a configuração mais barata nem uma vencedora em pontuação por dólar. Um valor registrado mais baixo também pode significar

12:51 que parte do uso está faltando. Para minha configuração inicial, eu escolheria Opus liderando Soul. Ela tem o maior total comparável e continua sendo útil nas seis tarefas, com Opus liderando Sonnet como uma alternativa próxima. Eu daria preferência à equipe Sonnet para emulação, enquanto a equipe Soul obtém uma pontuação maior nos aplicativos de teclado e de saúde. Vale considerar Astra com Sonnet para o editor visual e o trabalho com jogos pequenos demonstrados aqui. Mas eu inspecionaria com cuidado as atribuições iniciais, porque os planos para o emulador e o teclado omitem trabalho obrigatório. Opus com Muse full e Astra com Soul

13:24 precisam de execuções completas antes que eu possa fazer uma comparação geral justa. No meu próximo projeto, vou verificar se cada recurso obrigatório tem um responsável antes de os workers começarem. Depois, vou reproduzir as falhas contestadas, testar o fluxo normal do usuário e conferir o pacote final. Ainda são necessárias mais execuções e custos completos antes de fazer afirmações mais amplas sobre confiabilidade ou custo-benefício. No geral, é bem legal. Enfim, me contem o que vocês acham nos comentários. Se gostaram deste vídeo, considerem fazer uma doação pela opção Super Thanks [música] ou se tornar membro clicando no botão Join. Além disso, deixem um gostei neste vídeo [música] e

13:55 inscrevam-se no meu canal. Vejo vocês no próximo. Até lá, tchau. >> [música]

Transcrição original

[00:02] Hi. Welcome to another video. So, I tested five AI teams to see which lead and worker setup I’d actually use for a coding project. One model plans the work and checks the results, while another handles the assignments. That’s orchestration, and the lead’s decisions can shape the whole application. I followed their conversations and tested the applications. So, let’s see where the teamwork helped and where it failed. The models are Opus 5.5, GPT 6.1, Soul, GPT 6, Astra, Sonnet 5.5, and Muse Wonderful 1. The five pairs are Opus

[00:37] with Soul, Astra with Sonnet, Opus with Sonnet, Astra with Soul, and Opus with Museful. The first model is always the lead. Everything ran through Bambood using Claude Code, Codex, and the native Muse CLI. Each team had up to three simultaneous workers, 20 lead rounds, and 50 assignments without an added time limit. The six tasks were an emulator, Docker alternative, Room Designer, Keyboard Configurator, Pokémon Opening, and Fitbit Desktop App. Each task was worth 10 points. Each pair gets one high-effort run per task on a shared machine without equal computation

[01:10] budgets. There are no matched solo tests or reversed roles, so this comparison doesn’t isolate how much delegation itself helps. The emulator asks for Game Boy, DS, and 3DS support in Rust, including saving and normal playback features. Both Astra-led teams planned Game Boy execution, but only file inspection for DS and 3DS, leaving those execution paths missing. Astra with Sonnet gets 1.9 out of 10, and Astra with Soul gets 2.2. But, improving Game Boy support doesn’t make a DS file inspector run DS game. Opus with Soul earns 6.2 with connected execution paths for all

[01:43] three systems. DS and 3DS examples demonstrate rendering with separate 3DS input checks. Opus with Sonnet earns 7.1, the highest emulator score. It passes all eight shared Game Boy diagnostics and the Game Boy Color City Builder supports useful controls and saving. The DS and 3DS examples also progress further, although these small homebrew tests don’t prove that most commercial games work. Opus with Muse full earns 5.8 with some output across all three systems, but blank or incomplete results in broader

[02:16] examples. Provider quota errors interrupt workers and the lead completes more of the work. So, Opus with Sonnet produces the strongest emulator here. While the Astra teams show how an incomplete plan limits everything that followed. For the Docker alternative, importing an image is only part of the job. You also need process isolation and resource controls and these macOS hosted reviews didn’t establish working isolation through the delivered Linux paths. That limits the scores to five even where the image tools work. Opus with

[02:47] Soul, Opus with Sonnet, and Astra with Sonnet all get 5.0. Astra with Soul gets 4.7 with working registry and Docker save workflows, but no import for the standard OCI archive format. None of the teams demonstrates the requested efficiency advantage over Docker. Opus with Muse full gets 3.0 after an extraction test, changes permissions on two owned directories outside the intended extraction route. Their contents stay unchanged and both remain inside the application storage parent. This doesn’t demonstrate a guest escaping Linux or overriding arbitrary host files.

[03:20] That run also suffers quota interruptions and none of these results establishes a complete Docker replacement. The room designer produces much more usable applications. In the Opus and Soul project, a tester finds that selecting a chair makes the viewport go blank. The lead suspects an old builder screenshot problem, but the tester reproduces the failure. A worker repairs the selection highlight and the lead checks the rebuilt app. That’s the kind of review loop I want from a team. Opus with Soul earns 8.9 while Opus with Sonnet and Astra with

[03:52] Soul both earn 9.0. The Opus and Sonit version still lets oversized furniture protrude from a smaller room. Opus with Muse full earns 8.9 with custom shapes, colored lighting, and working project restoration. Color changes leave three extra textures retained, although normal editions followed by undo remain stable. This run finishes without an observed quota failure, even though its usage records still have gaps. Astra with Sonit earns 9.3, the highest room score. The lead gives the room model, editor,

[04:23] and renderer separate owners, then sends specific corrections as those parts connect. Editing and project restoration work and repeated object additions and removals return to the original resource counts. A very thin object can overhang the wall slightly, but this is the room designer I’d favor from these results. The keyboard task asks for a yellow themed alternative to VA that configures QMK keyboards. A nice editor isn’t enough if the keyboard never receives the changes. I checked configuration messages and resulting state through an independently controlled virtual keyboard. That’s limited compatibility

[04:54] evidence, not proof of support for every physical keyboard or firmware version. Opus with Soul earns 7.8 and Opus with Sonit earns 7.4. Both send configuration messages that change the tested device state with editing compatibility and backup limitations reducing their scores. Both Astra lead versions earn 2.8 and their assignments explain why. Astra with Soul assigns selection and metadata, while Astra with Sonit explicitly excludes opening the device and sending configuration messages. The benchmark prohibited changing real connected hardware, but it didn’t prohibit

[05:27] implementing that communication path. So, the teams improve local editors while the required connection remains absent. Opus with Muse full earns 7.7 with working keycodes, macros, lighting, and restoration in a fresh browser profile. It still accepts an incomplete acknowledgement and invalid macro imports can partly change the configuration. Quota failures also interrupt the workers before the lead completes further repairs. Opus with Sol leads this task, and the bigger lesson is to include the device connection before spending more work on

[06:00] appearance. For Pokémon, I wanted an ordinary playable opening through the first gym with progress that survives saving and loading. Opus with Sol earns 8.6, and Opus with Sonnet earns 8.7. Both complete that route when browser storage works, but change names, simpler artwork, and simplified mechanics reduce fidelity. The credited tests use ordinary play, not the agents’ heavily leveled parties or automatic healing. Opus with Museful scores zero because it delivers no playable game.

[06:30] There is a contract and a graphics helper, but no entry point, world battles, or saving. Subscription quota errors affect all six workers used during the run, eventually blocking even a request to read one line and reply. That zero describes the delivered project, not what Muse could do with available capacity. Astro with Sonnet earns 9.1, the highest Pokémon score. The lead catches a walk-through that tells players to heal Imputer without providing a healing center. It assigns the missing door, nurse, and return route. The independent route completes the parcel quest, catches a wild

[07:03] Pokémon, and reaches Brock through the forest. Normal losses have the money and give no badge, while winning from a legitimate save awards the badge and expected money. Progress survives another reload when storage works. It’s still a reduced game without evolution or move use limits. A misleading save success message when storage is blocked also costs points because reloading loses that temporary checkpoint. Astro with Sol also scores zero with a completely empty folder after an HTTP

[07:34] 429 error exhausts retries. The logs don’t establish whether account quota or another rate limit caused it. Astro with Sonnet leads the completed game comparison, while those interrupted runs need working provider access before we can judge their full potential. The Fitbit task asks for a desktop analytics app with a Rust back end. Opus with Soul earns 7.7, while Opus with Sonnet earns 6.5. Soul’s provider clients work against controlled test inputs representing expected provider responses, while Sonnet’s external connection receives credit from source inspection only. Neither result

[08:06] establishes a personal Fitbit account connection or clinical accuracy. In the Opus and Sonnet app, a workout’s calculated load can appear in its detail view, but disappear from the daily summary. In the Opus and Soul app, demo data replaces imported daily measurements, and clearing the demo removes those days. Importing the original synthetic CSV again restores the exact values, so the demonstrated loss is recoverable. Opus with Muse full earns 6.3 with substantive Rust calculations, but broken connect and import buttons that

[08:39] fail before reaching the back end. Direct back end calls don’t fix those broken buttons. This run also suffers quota interruptions. Both Astro led health apps earn 7.6. Astro with Sonnet catches demo refresh deleting user records. A worker also finds an old interface inside the package tab, so the lead rebuilds it and checks the embedded files. A repaired source file doesn’t help if you launch an older packet. Its final app supports workout and journal entries with data surviving export, import, and restart, but it accepts only its own JSON format without a Fitbit connection

[09:10] or actual Fitbit export path. Its load calculation treats missing days as zero, so incomplete history can produce misleading results. Astro with Soul repairs retries that could create duplicate workouts after a lost response. An independent test loses that response, then retries after reopening the dialogue, and exactly one workout remains. The pending draft still doesn’t survive an application reload. That app also relies on its own JSON format rather than a working Fitbit connection. It shows zero steps on a workout only date and renders a thousand

[09:42] workouts as a thousand table rows. The Astra health checks use the rust services in a browser, so the complete native desktop experience remains unverified. Opus with Soul leads this task, but every result still has gaps against the requested product. Now, here’s the overall result. Opus with Soul earns 44.2 out of 60 or 73.67%. Opus with Sonnet follows at 43.7 or 72.83% with five quota affected tasks. Astra

[10:13] with Soul earns 26.3 or 43.83% including its interrupted Pokémon run. I keep those delivered scores visible, but the interruptions prevent a fair capability ranking across all five teams. These percentages measure earned points, not future success rate. For tokens and cost, the totals include leads, workers, corrections, and recorded additional model calls. Setup and evaluation are excluded. Resumed usage counts only once and missing records remain unknown. The total is about 936.11

[10:44] million recorded tokens including 926.74 million input and 9.37 million output. Most input is repeated cached context and reasoning already belongs to output, so it doesn’t count twice. Opus with Sonnet records about 444.81 million tokens compared with 143.73 million for Opus with Soul. Astra with Sonnet records 107.06 million, Opus with Muse full records 155.06 million, and Astra with Soul records 85.45 million. These counts include repeated context

[11:17] and don’t directly measure useful code. Using the saved API rates, Soul and Sonnet each cost $2 for fresh input, 0.10 for cached reads, and $10 for output per million tokens. Opus costs $4.20 and $20 for those categories, while Astra cost $10, $1 and $0.50. So, Opus is twice Soul’s unit price, while Astra is five times its fresh input and output price, and 10 times its cached read price. Cash write and long context rules also affect the calculations.

[11:49] For Muse full, I used the requested standard wonder assumption, $4 for fresh input, $0.20 for cached reads, and $20 for output. That isn’t a confirmed full tariff or subscription invoice. And there is no confirmed full cash rate right here. For the subtotals, native Claude cost records replace the Claude token estimates where available with token estimates for the other providers. Those alternatives don’t get added together, and the records don’t establish every hosted fee. Opus with Soul records about $56.97,

[12:21] while Opus with Sonnet records $124.22. Astra with Sonnet records $68.75. Opus with Muse full records $80.22, and Astra with Soul records $75.22. That’s about $405.49 of recorded orchestration usage, but only eight of the 30 tasks have complete captured usage. Every team’s final cost remains unknown, so these subtotals can’t identify the cheapest setup or a score per dollar winner. A lower recorded amount can also mean

[12:51] some usage is missing. For my own starting setup, I’d choose Opus leading Soul. It has the highest comparable total and stays useful across all six tasks, with Opus leading Sonnet a close alternative. I’d favor the Sonnet team for emulation, while Soul’s team scores higher on the keyboard and health applications. Astra with Sonnet is worth considering for the visual editor and small game work demonstrated here. But, I’d inspect its initial assignments carefully because its emulator and keyboard plans omit required work. Opus with Muse full and Astra with Soul

[13:24] need complete runs before I’d make a fair overall comparison. For my next project, I’d check that every required feature has an owner before the workers start. Then I’d reproduce disputed failures, test the normal user journey, and check the final package. More runs and complete costs are still needed before making broader reliability or value claims. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. If you like this video, consider donating through [music] the Super Thanks option or becoming a member by clicking the join button. Also, give this [music] video a thumbs up and

[13:55] subscribe to my channel. I’ll see you in the next one. Until then, bye. >> [music]