Mimo V2.6 Pro e Flash (testados por completo): são mesmo open weights!?

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: Mimo V2.6 Pro & Flash (Fully Tested): This is OPEN WEIGHTS!? · Canal: AICodeKing · 11:37 · Assistir no YouTube

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

Resumo

O vídeo compara Mimo V2.6 Pro e Mimo V2.6 Flash em oito tarefas de programação e resolução de problemas no OpenCode, usando o KingBench 3. Flash custa cerca de 68% menos que Pro para tokens de entrada e saída e teve desempenho geral ligeiramente superior nos testes originais: 58 de 80, contra 55,5 de 80. Os dois modelos obtiveram nota máxima na tarefa de fine-tuning local, mas apresentaram falhas em outras tarefas, como geometria 3D, estado da simulação e tratamento de entradas. Em um reteste separado de matemática com um limite maior de saída, Flash recebeu crédito parcial e chegou a 64 de 80, enquanto Pro não entregou uma resposta utilizável. O apresentador considera Flash a opção de melhor custo-benefício, mas recomenda verificar cuidadosamente os resultados gerados.

Pontos-chave

Os dois modelos têm open weights sob a licença MIT e uma context window de pouco mais de um milhão de tokens.
Na configuração testada, Flash custa cerca de 68% menos que Pro para tokens comuns de entrada e saída.
Flash superou Pro no total original, com 58 de 80 contra 55,5 de 80.
Ambos receberam nota máxima na tarefa de gerar dados, fazer fine-tuning de Gemma 2B e criar um aplicativo local de geração de fatos sobre pandas.
Flash teve resultados melhores na simulação de elevadores, na ilustração SVG e no jogo de arco e flecha; Pro foi melhor no relógio 3D.
As tarefas 3D revelaram problemas de geometria e movimento, apesar de as interfaces e interações parecerem funcionais.
As tentativas originais da tarefa de matemática não produziram uma resposta utilizável; no reteste com maior limite de saída, Flash apresentou um método parcial, mas não forneceu o número final.
O apresentador recomenda experimentar Flash primeiro para protótipos econômicos e inspecionar cuidadosamente os resultados.

Capítulos

Início	Capítulo	Resumo
00:02	Modelos, preços e configuração dos testes	O vídeo apresenta Mimo V2.6 Pro e Flash, suas características e preços, além da configuração usada no OpenCode.
02:07	Simulações, objetos 3D e ilustração	Os modelos são avaliados em tarefas de elevador, estojo de lentes, mesa dobrável e ilustração SVG de um panda com um hambúrguer.
05:47	Jogo, problema de matemática e fine-tuning local	O apresentador testa um jogo de arco e flecha, retesta a tarefa de matemática com um limite maior de saída e compara os resultados de fine-tuning local.
08:27	Relógio 3D e pontuações finais	O vídeo avalia o relógio 3D, apresenta as pontuações dos testes e discute o custo-benefício de Flash em relação a Pro.
11:04	Conclusão e recomendações	O apresentador recomenda experimentar Flash para protótipos econômicos, lembrando que os resultados precisam ser inspecionados.

Citações

Para entrada e saída comuns, Flash é cerca de 68% mais barato. — 01:35

Mantive esses resultados separados, para não substituir discretamente uma tentativa que falhou por outra com aparência melhor. — 07:23

Flash é a opção de melhor custo-benefício mais interessante para mim com base nesses resultados. — 10:33

Eu experimentaria Flash primeiro para protótipos baratos e verificaria o resultado com cuidado. — 11:04

Conceitos e entidades

MiMo-V2.6 Pro (modelo): Modelo da Xiaomi testado em oito tarefas de programação e resolução de problemas.
MiMo-V2.6 Flash (modelo): Modelo da Xiaomi com preço mais baixo que Pro e melhor pontuação geral nos testes originais do vídeo.
Xiaomi (empresa): Empresa que lançou Mimo V2.6 Pro e Mimo V2.6 Flash.
OpenRouter (ferramenta): Provedor usado para acessar os modelos e consultar seus preços.
OpenCode (ferramenta): Ferramenta usada para executar as tarefas de benchmark com os dois modelos.
KingBench 3 (conceito): Benchmark composto por oito tarefas usado para comparar o desempenho dos modelos.
Gemma 2B (modelo): Modelo usado na tarefa de fine-tuning local e geração de fatos sobre pandas.
MIT License (conceito): Licença indicada no vídeo para os pesos dos dois modelos.

Tradução completa (pt-BR)

00:02 [música] >> Oi. Bem-vindos a mais um vídeo. A Xiaomi lançou o Mimo V2.6 Pro e o Mimo V2.6 Flash, e os preços chamaram minha atenção imediatamente. Os dois estão disponíveis pelo OpenRouter. Ambos têm pesos abertos, e o Flash custa cerca de um terço do preço do Pro para tokens comuns de entrada e saída. Mas eu queria ver o que essa diferença realmente representa quando pedimos que eles criem coisas. Neste vídeo, testei os dois modelos no OpenCode com todas as oito tarefas do KingBench 3. Temos uma simulação de elevadores,

00:33 um objeto 3D interativo, uma ilustração em SVG, um jogo, um problema de matemática, uma tarefa real de fine-tuning local e um relógio de pulso 3D funcional. Analisei os arquivos gerados, abri os projetos visuais e verifiquei o comportamento antes de dar uma nota de 0 a 10 para cada resultado. E há algumas diferenças bem interessantes. Nesta rodada, o Flash se saiu melhor em várias tarefas práticas. Às vezes, o Pro demorou muito mais e ainda assim deixou problemas básicos no resultado. Então, vamos direto ao assunto. Primeiro, um pouco de contexto. O OpenRouter lista a data de lançamento dos dois modelos como 21 de setembro. E o anúncio da Xiaomi foi atualizado em 22 de setembro. Estou testando-os em 24 de setembro. O Pro tem cerca de 1,02 trilhão de parâmetros no total, com 42 bilhões ativos por token. O Flash tem 309 bilhões no total, com 15 bilhões ativos. Esses modelos usam mistura de especialistas, então a contagem de parâmetros ativos corresponde à parte que realiza o trabalho para cada token. Os dois têm uma context window de pouco mais de um milhão de tokens. A página dos modelos informa suporte a entradas de texto, imagem, áudio e vídeo, com saída de texto, e os pesos foram lançados sob a licença MIT. É bom ver isso. O benchmark de hoje se concentra no comportamento de programação e resolução de problemas deles pelo OpenCode e pelo OpenRouter.

01:04 O anúncio foi atualizado em 22 de setembro. Estou testando-os em 24 de setembro. O Pro tem cerca de 1,02 trilhão de parâmetros no total, com 42 bilhões ativos por token. O Flash tem 309 bilhões no total, com 15 bilhões ativos. Esses modelos usam mistura de especialistas, então a contagem de parâmetros ativos corresponde à parte que realiza o trabalho para cada token. Os dois têm uma context window de pouco mais de um milhão de tokens. A página dos modelos informa suporte a entradas de texto, imagem, áudio e vídeo, com saída de texto, e os pesos foram lançados sob a licença MIT. É bom ver isso. O benchmark de hoje se concentra no comportamento de programação e resolução de problemas deles pelo OpenCode e pelo OpenRouter.

01:35 Agora, os preços são bem agressivos. No momento deste teste, o OpenRouter lista o Pro a 43,5 centavos por milhão de tokens de entrada e 87 centavos por milhão de tokens de saída. O Flash custa 14 centavos para entrada e 28 centavos para saída. A entrada em cache tem uma tarifa separada, mais baixa. Então, para entrada e saída comuns, o Flash é cerca de 68% mais barato. O valor final da sua conta ainda depende de quanto o agent pensa, de quantas chamadas de ferramenta faz e de quanto do contexto é reutilizado. Para a configuração dos testes, usei a versão

02:07 1.18.32 do OpenCode, com o OpenRouter como provedor. Cada tarefa teve uma sessão e uma pasta novas. Os dois modelos receberam o mesmo prompt, com raciocínio ativado. Cada tarefa recebe uma nota de 0 a 10. Também vou mostrar um novo teste de matemática, separado, com um limite de saída maior, porque isso fez diferença no resultado do Flash. A primeira tarefa é a simulação de elevadores. Precisamos de três elevadores, cada um levando apenas uma pessoa. Deve ser possível criar pessoas em andares diferentes, fazê-las esperar pelo próximo elevador disponível e ver o destino delas em uma dica de ferramenta. O Pro nos dá uma simulação reconhecível

02:38 com os controles básicos certos e elevadores animados. Mas, quando comecei a testar a contagem de passageiros, tudo desandou. Em uma rodada, 16 pessoas foram criadas, mas o contador de pessoas atendidas acabou chegando a 21. O código de despacho trata uma reserva para o elevador zero como se não houvesse reserva, permitindo que o mesmo passageiro seja atendido mais de uma vez. A opção de reiniciar também tem um problema. Uma viagem que já estava em andamento podia terminar depois da reinicialização e adicionar um passageiro ao contador zerado. Então, a interface parece funcionar, mas o estado interno não é confiável. Vou dar 7 de 10 ao Pro aqui.

03:09 O Flash se sai muito melhor. Removi os passageiros iniciais, criei 12 e todos os 12 foram levados. Também coloquei cinco pessoas na fila do mesmo andar, e elas esperaram e foram buscadas corretamente. A dica de ferramenta do destino também funciona. Ainda há callbacks atrasados que não são totalmente cancelados ao limpar a simulação, então não diria que ela é totalmente robusta, mas o comportamento principal que testei funciona, e o Flash recebe 9 de 10. Agora, a segunda tarefa é um estojo para lentes de contato em Three.js, com rótulos claros de esquerda e direita e tampas que abrem quando você

03:40 clica nelas. Os dois modelos criam cenas 3D interativas, e ambos permitem abrir as tampas independentemente. Mas é aqui que observar um objeto de ângulos diferentes faz diferença. As tampas fechadas do Pro ficam parcialmente dentro do corpo do estojo, então o estojo não parece realmente vedado quando está fechado. Os rótulos e o formato também são menos convincentes do que deveriam. Recebe 7 de 10. O Flash tem uma interação um pouco melhor, mas a geometria por baixo continua errada. Há material sólido onde deveriam ficar os compartimentos das lentes, e as letras estão parcialmente enterradas nas tampas. Abrir uma tampa deveria revelar um pequeno recipiente utilizável, e essa ilusão não se sustenta aqui. O Flash recebe 7,5 de 10. A terceira tarefa é uma mesa dobrável em Three.js. Mova o controle deslizante para a direita e ela deve se desdobrar. Mova-o para a esquerda e ela deve se dobrar, com um movimento suave por todo o intervalo. Os dois modelos fazem a interação principal funcionar. Verifico as posições extremas e várias posições intermediárias, depois movo o controle deslizante de volta. A mesa se move suavemente, e você pode girar a visualização para inspecioná-la, mas os dois modelos têm problemas mecânicos no meio da animação. As pernas do Pro atravessam o chão enquanto a mesa se dobra. As pernas internas do Flash se cruzam, e a mesa não parece ter um apoio convincente.

04:12 A mesa não parece ter um apoio convincente. Então, dá para demonstrar a ideia, mas o movimento precisa ser melhorado para parecer fisicamente plausível. Vou dar 8 de 10 para os dois. Em seguida, temos o SVG de um panda comendo um hambúrguer. Parece simples, mas testa se o modelo entende a relação entre os objetos, em vez de apenas colocar um panda e um hambúrguer na mesma imagem. O Flash cria uma ilustração limpa e reconhecível. Tanto o panda quanto o hambúrguer ficaram bons, mas o hambúrguer está ao lado da boca, com um espaço visível entre eles. Parece mais que ele está segurando a comida do que

04:44 dando uma mordida. Isso vale 8 de 10. O Pro acrescenta mais sombras e detalhes, mas o hambúrguer vira uma pilha enorme, com espaços flutuantes entre os ingredientes. Também esconde a boca, o que enfraquece a pose de quem está comendo. Prefiro o resultado do Flash aqui. O Pro recebe 7 de 10. Um SVG estático poderia ter recebido a nota máxima. A animação não era necessária. Também há uma grande diferença de tempo nesta tarefa específica. O Flash terminou em cerca de 34 segundos, enquanto o Pro levou cerca de 10 minutos. Esse é o tempo total dessas execuções do agent, incluindo o trabalho e o uso de ferramentas. Não é uma medição da velocidade bruta de geração de tokens, e eu não presumiria

05:15 que a mesma diferença apareça em todos os prompts. A quinta tarefa é o jogo de arco e flecha. Deve haver quatro alvos, e concluir o desafio mais rápido deve colocar você em uma posição mais alta na tabela de classificação. Os dois modelos produzem jogos com aparência jogável, com mira, flechas, alvos e cronômetro. O Flash responde a um arrasto no navegador, dispara uma flecha e registra um acerto no alvo. O Pro tem uma apresentação mais elaborada, embora o cronômetro no cabeçalho possa congelar enquanto o cronômetro desenhado dentro do jogo continua avançando. Também verifiquei a lógica original do jogo com simulações de controle. Esses testes acertaram os quatro alvos, testaram erros e acertos repetidos e confirmaram que tempos menores de conclusão ficam acima dos maiores na classificação.

05:47 Tem um problema mais sério que os dois modelos compartilham. A tecla R reinicia o jogo mesmo quando você está digitando o nome de um jogador, então inserir um nome com essa letra pode descartar uma partida concluída antes de você salvá-la. É um pequeno trecho de código com um efeito bem irritante para quem está jogando. Vou dar 8,5 de 10 ao Pro e 9 de 10 ao Flash. Os dois têm uma base sólida aqui, com um bug corrigível no tratamento das teclas. O Flash também mantém o cronômetro visível funcionando de forma mais consistente na versão que testei. Agora, a sexta tarefa é o problema de contagem de permutações.

06:21 O problema de contagem de permutações. A resposta correta é 20.460, e verifiquei isso de forma independente com um programa exaustivo. Nenhum dos modelos recebeu a resposta ou o código de verificação. As primeiras tentativas não entregaram uma resposta. O Flash usou quase 32 mil tokens de raciocínio e parou ao atingir o limite de saída. O Pro chegou ao limite de 20 minutos sem retornar uma resposta utilizável. Portanto, as duas tentativas originais recebem zero nesta tarefa. Isso significa que não entregaram uma resposta nessas condições, e não que tenham dado um número específico errado. Há um detalhe importante na configuração. O OpenCode tinha um limite padrão de saída de

06:51 32 mil tokens, embora esses modelos anunciem suporte a até 131.072 tokens de saída. Por isso, dei a cada modelo uma nova tentativa, em uma sessão separada, com esse limite maior, o mesmo prompt e o mesmo limite de 20 minutos. Mantive esses resultados separados, para não substituir discretamente uma tentativa malsucedida por outra com aparência melhor. Nessa nova tentativa, o Pro continuou sem entregar nada antes do tempo limite. O Flash escreveu um programa de contagem válido, e as verificações em versões menores corroboram o método, mas ele nunca executou o programa nem forneceu o número final. Isso vale 6 de 10 por desempenho parcial.

07:23 —

07:53 crédito no reteste. A tentativa original continua valendo zero, e vou mostrar separadamente o efeito de substituir essa pontuação. A sétima tarefa é a tarefa de fine-tuning local. Gerar um conjunto de dados com fatos sobre pandas, fazer fine-tuning do Gemma 2B e criar uma página da web local que gere um fato sobre pandas sempre que você atualizá-la. Testei as duas implementações, e elas funcionam perfeitamente. Ambas lidam com o workflow de fine-tuning e entregam o aplicativo local de geração de fatos solicitado pelo prompt. Atualize a página e você verá um fato sobre pandas gerado pelo modelo. Então, os dois passam com nota máxima. O Pro tira 10 de 10, e o Flash tira 10 de 10. Esse é um bom resultado porque a tarefa

08:27 vai além de criar uma interface. Ela inclui preparar os dados, treinar o modelo e conectá-lo a um aplicativo local funcional. Os dois modelos dão conta do recado aqui. Por fim, temos o relógio de pulso 3D funcional, com ponteiros suaves e dois fusos horários. O relógio do Pro abre e funciona. Os valores dos fusos horários estão corretos, os ponteiros mostram a hora certa, e você pode trocar os fusos. Ele também modela a caixa, a pulseira e um pulso. Infelizmente, as marcações do mostrador ficam escondidas sob a geometria sólida da caixa. Dá para ver os ponteiros se movendo sobre o que parece ser um mostrador de metal em branco. O ponteiro dos segundos se move

08:58 suavemente, mas os ponteiros dos minutos e das horas avançam em pequenos saltos. O Pro tira oito de 10. À primeira vista, o Flash parece mais completo, com um mostrador detalhado e um submostrador para o segundo fuso. Mas as leituras digitais e os ponteiros analógicos não coincidem. O código já inclui frações de minutos e horas e, depois, soma essas frações novamente ao posicionar os ponteiros. O ponteiro das horas fica visivelmente adiantado, e as fórmulas também causam saltos para trás nas viradas do horário. Os fusos horários digitais estão corretos, e o ponteiro dos segundos se move suavemente, mas ponteiros precisos são essenciais para um relógio funcional, e parte

09:28 da pulseira inferior também desaparece pelo chão. O Flash tira seis e meio de 10. Este é um bom exemplo de por que verifico o comportamento depois da primeira captura de tela. Então, este é o gráfico final atualizado. O Pro tira 55 e meio de 80, o que dá cerca de 6,94 de 10 no total. O Flash tira 58 de 80, o que dá 7,25 de 10. Se usarmos separadamente esse reteste de matemática com orçamento maior, o Pro continua em cerca de 6,94, enquanto o Flash sobe para 64 de 80, ou 8 de 10. As pontuações totais dos dois incluem nota máxima na tarefa de fine-tuning. Agora, em termos de porcentagem,

10:01 o Mimo V2.6 Pro marca 69,38%, e o Flash marca 72,5%, à frente de GPT-5.6, Soul e Muse Spark 1.3, com 71,25%, mas abaixo de GLM-5.2, com 75%. Com o reteste de matemática com orçamento maior, o Flash chega a 80%. Isso iguala a pontuação anterior do Opus-4.8, coloca-o acima do GLM-5.3, Flash, com 78,75%, e deixa-o logo abaixo do DeepSeek V4.1,

10:33 Flash, com 81,25%. Então, o resultado do reteste do Flash o coloca numa posição bem mais forte na tabela, enquanto o Pro permanece em 69,38%. Junto com o preço mais baixo do Flash, isso faz dele o resultado mais interessante para mim aqui. Os dois modelos recebem nota máxima no fine-tuning local. O Flash assume a liderança geral graças ao melhor desempenho na simulação do elevador, na ilustração e no jogo, enquanto o Pro se sai melhor no relógio. Na minha opinião, o Flash é a opção com melhor custo-benefício entre esses resultados. Seus preços por token são muito mais baixos, e eu preferi a simulação do elevador, a ilustração de pandas

11:04 e o jogo do Flash. O Pro se saiu melhor na marcação do tempo do relógio, então há diferenças reais, em vez de um modelo vencer todas as tarefas. Pessoalmente, eu experimentaria primeiro o Flash para protótipos baratos e examinaria o resultado com cuidado. Esta avaliação não me dá um motivo forte para pagar mais pelo Pro por padrão. Os dois podem produzir pontos de partida úteis, mas os bugs de geometria, os bugs de estado e os resultados de matemática ainda precisam de atenção. No geral, é bem legal. Enfim, me contem o que acharam nos comentários. Se gostaram [música] deste vídeo, considerem fazer uma doação pela opção Super Thanks ou se tornar membro

11:37 clicando no botão Join. Além disso, [música] curtam este vídeo e se inscrevam no meu canal. Vejo vocês no próximo. Até lá, tchau. >> [música]

Transcrição original

[00:02] [music] >> Hi. Welcome to another video. So, Xiaomi has released Mimo V2.6 Pro and Mimo V2.6 Flash, and the pricing immediately caught my attention. Both are available through OpenRouter. Both have open weights, and Flash costs about a third of Pro for regular input and output tokens. But, I wanted to see what that difference actually gets you when you ask them to build things. For this video, I ran both models through OpenCode on all eight tasks in KingBench 3. We have an elevator simulation,

[00:33] interactive 3D object, an SVG illustration, a game, a math problem, an actual local fine-tuning task, and a working 3D wristwatch. I reviewed the generated files, opened the visual projects, and checked the behavior before giving each result a score out of 10. And there are some pretty interesting differences here. Flash handled several of the practical tasks better in this run. Pro sometimes spent much longer and still left basic problems in the result. So, let’s get right into it. First, a little context. OpenRouter lists both models with a September 21 release date. And Xiaomi’s

[01:04] announcement was updated on September 22. I’m testing them on September 24th. Pro has about 1.02 trillion total parameters with 42 billion active per token. Flash has 309 billion total with 15 billion active. These are mixture of experts models, so the active count is the portion doing the work for each token. Both have a context window of just over a million tokens. Their listing support text, image, audio, and video input with text output, and the weights are released under the MIT license. That’s good to see. Today’s benchmark focuses on their coding and problem-solving behavior through

[01:35] OpenCode and OpenRouter. Now, the pricing is pretty aggressive. At the time of this test, OpenRouter lists Pro at 43.5 cents per million input tokens and 87 cents per million output tokens. Flash is 14 cents for input and 28 cents for output. Cached input has a separate lower rate. So, for ordinary input and output, Flash is about 68% cheaper. Your final bill still depends on how much the agent thinks, how many tool calls it makes, and how much context gets reused. For the testing setup, I used Open Code version

[02:07] 1.18.32 with Open Router as the provider. Each task had its own fresh session and folder. Both models received the same prompt with reasoning enabled. Each task gets a score out of 10. I’ll also show a separate math retest with a larger output budget because that made a difference to Flash’s result. The first task is the elevator simulation. We need three elevators, each taking only one person. You should be able to spawn people on different floors, have them wait for the next available elevator, and see their destination in a tooltip. Pro gives us a recognizable simulation

[02:38] with the right basic controls and animated elevators. But, once I started testing the passenger counts, it broke down. In one run, 16 people had been created, yet the completed counter eventually reached 21. The dispatch code treats a reservation for elevator zero as if there is no reservation, which allows duplicate handling of the same passenger. Reset also has a problem. A trip that was already running could finish after the reset and add a passenger to the cleared counter. So, the interface looks like it is working, but the underlying state isn’t reliable. I’m giving Pro seven out of 10 here.

[03:09] Flash does much better. I cleared the initial passengers, spawned 12, and all 12 were delivered. I also queued five people on the same floor, and they waited and got picked up properly. The destination tooltip works, too. There are still delayed callbacks that aren’t fully canceled when clearing the simulation, so I wouldn’t call it completely robust, but the main behavior I tested works, and Flash gets nine out of 10. Now, the second task is a 3.js contact lens case with clear left and right labels and caps that open when you

[03:40] click them. Both models create interactive 3D scenes, and both let you open the caps independently. But, this is where looking at an object from different angles makes a difference. Pro’s closed caps are positioned partly inside the body, so the closed state doesn’t really look sealed. The labels and the shape are also less convincing than they should be. It gets seven out of 10. Flash has a slightly better interaction, but the geometry underneath is still wrong. There’s solid material where the lens wells should be, and the letters are partly buried in the caps. Opening a cap should reveal a usable

[04:12] little container, and that illusion doesn’t hold up here. Flash gets seven and a half out of 10. The third task is a folding table in 3 JS. Move the slider right and it should unfold. Move it left and it should fold with smooth movement through the whole range. Both models get the main interaction working. I check the end points and several positions in between, then move the slider back again. The table changes smoothly, and you can rotate the view to inspect it, but both have mechanical problems in the middle of the animation. Pro’s legs pass through the floor as the table folds. Flash’s inner legs intersect, and the

[04:44] table doesn’t stay convincingly supported. So, you can demonstrate the idea, but the motion needs work before it looks physically believable. I’m giving both eight out of 10. Next is the SVG of a panda eating a burger. This sounds simple, but it checks whether the model understands the relationship between the objects, rather than just putting a panda and a burger in the same picture. Flash makes a clean recognizable illustration. The panda and burger both look good, but the burger sits beside the mouth with a visible gap. It looks more like holding food than

[05:15] taking a bite. That’s eight out of 10. Pro adds more shading and detail, but the burger becomes an oversized stack with floating gaps between the ingredients. It also hides the mouth, which weakens the eating pose. I prefer Flash’s result here. Pro gets seven out of 10. A static SVG could have earned full marks. Animation wasn’t required. There’s also a big timing difference on this particular task. Flash finished in about 34 seconds, while Pro took about 10 minutes. That’s the total time for those agent runs, including their work and tool use. It isn’t a measurement of raw token speed, and I wouldn’t assume

[05:47] the same gap will happen on every prompt. The fifth task is the bow and arrow game. There should be four targets, and completing the challenge faster should move you higher on the leaderboard. Both models produce playable-looking games with aiming, arrows, targets, and a timer. Flash responds to a browser drag, fires an arrow, and registers a target hit. Pro has a more elaborate presentation, although its header timer can freeze while the timer drawn inside the game keeps moving. I also checked the original game logic with control simulations. Those checks completed all four targets, tested misses and repeated hits, and verified that lower completion

[06:21] times rank above higher ones. The more serious problem is one both models share. The R key restarts the game even when you’re typing a player name, so entering a name with that letter can throw away a finished run before you save it. It’s a small piece of code with a pretty annoying effect for the person playing. I’m giving Pro eight and a half out of 10, and Flash nine out of 10. Both have a solid core here with a fixable input handling bug. Flash also keeps the visible timer behaving more consistently in the version I tested. Now, the sixth task is the permutation

[06:51] counting problem. The correct answer is 20,460, and I independently checked that with an exhaustive program. Neither model received the answer or the checking code. The first runs didn’t deliver an answer. Flash used almost 32,000 reasoning tokens and stopped because it hit the output limit. Pro reached the 20-minute time limit without returning a usable response. So, both original attempts get zero for this task. That means no delivered answer under these conditions, rather than a specific wrong number. There is an important setup detail here. Open code had a default

[07:23] output cap of 32,000 tokens, even though these models advertise support for up to 131,072 output tokens. I therefore gave both models one fresh retest with that larger cap, the same prompt, and the same 20-minute time limit. I kept those results separate, so we’re not quietly replacing a failed attempt with a better-looking one. In that retest, Pro still delivered nothing before timeout. Flash wrote a valid counting program and checks on smaller versions support its method, but it never ran the program or gave the final number. That earns six out of 10 in partial

[07:53] credit on the retest. Its original attempt remains zero, and I’ll show the effect of replacing that score separately. The seventh task is the local fine-tuning task. Generate a panda fact dataset, fine-tune Gemma 2B, and build a local webpage that generates a panda fact whenever you refresh it. I’ve tried both implementations, and they work flawlessly. Both handle the fine-tuning workflow and deliver the local fact generation app the prompt asks for. Refresh the page and you get a panda fact from the model. So, this is a full pass for both. Pro gets 10 out of 10, and Flash gets 10 out of 10. This is a good result because the task

[08:27] goes beyond making an interface. It includes preparing the data, training the model, and connecting it to a working local app. Both models get the job done here. Finally, we have the working 3D wrist watch with smooth hands and two time zones. Pro’s watch opens and runs. The time zone values are correct, the hands show the right time, and you can swap the zones. It also models the case, strap, and a wrist. Unfortunately, the dial markings are hidden under solid case geometry. You can see the hands moving over what looks like a blank metal face. The second hand sweeps

[08:58] smoothly, but the minute and hour hands advance in small steps. Pro gets eight out of 10. Flash initially looks more complete with a detailed face and a second zone subdial. But, the digital readouts and analog hands don’t agree. Its code already includes fractional minutes and hours, then adds those fractions again when positioning the hands. The hour hand runs visibly ahead, and the formulas also produce backward jumps at time boundaries. The digital zones themselves are correct, and the second hand moves smoothly, but accurate hands are central to a working watch, and part

[09:28] of the lower strap also disappears through the floor. Flash gets six and a half out of 10. This is a good example of why I check the behavior after the first screenshot. So, this is the updated final chart. Pro gets 55 and 1/2 out of 80, which is about 6.94 out of 10 overall. Flash gets 58 out of 80, which is 7.25 out of 10. If we use this separately labeled larger budget math retest, Pro stays at about 6.94, while Flash rises to 64 out of 80 or 8 out of 10. Both totals include full marks for the fine-tuning task. Now, in percentage

[10:01] terms, Mimo V2.6 Pro scores 69.38% and Flash scores 72.5% ahead of GPT-5.6, Soul and Muse Spark 1.3 at 71.25% but below GLM-5.2 at 75% With the larger budget math retest, Flash reaches 80%. That matches the previous Opus-4.8 score, puts it above GLM-5.3, Flash at 78.75% and leaves it just below DeepSeek V4.1,

[10:33] Flash at 81.25%. So, Flash’s retest result moves it into a much stronger part of the table, while Pro remains at 69.38%. Combined with Flash’s lower pricing, that makes it the more interesting result for me here. Both models earn full marks on local fine-tuning. Flash takes the overall lead through its stronger elevator simulation, illustration, and game, while Pro does better on the watch. If you ask me, Flash is the more interesting value option from these results. It has much lower token prices and I preferred its elevator simulation, panda

[11:04] illustration, and game. Pro did better on the watch’s timekeeping, so there are real differences rather than one model winning every task. Personally, I’d try Flash first for inexpensive prototypes and inspect the result carefully. This run doesn’t give me a strong reason to pay extra for Pro by default. Both can produce useful starting points, but the geometry bugs, state bugs, and math results still need attention. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. If you like [music] this video, consider donating through the Super Thanks option or becoming a member

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