MiMo-V2.6-Pro has an insanely high score of 46 on AA, putting it at the head of the opensource models available. It also costs pennies. Flash is not out on AA yet, but it costs less than half on datacenter and is slightly below on Xiaomi's own benchmarks. It also fits in 192GB, which makes it the first real use case for Gorgon Halo. So I tried both models. This is not a benchmark; it's an educated impression from a senior SWE. MiMo-V2.6-Pro I gave it a security-focused task: enable a bubblewrap sandbox to do git push to github, but not git push --force or other destructive commands. Optional flag --no-git when starting the sandbox completely disables github write access. It stopped to ask me questions as it spotted unclear corner cases in the design 🥇 , then moved on to implementing. It was slow, but that's just an inference issue (~25 tok/s) that should be fixed in a few days as more providers come online. Then I read its output and I had to pick up my jaw from the floor, where it had dropped. With an extremely quick glance at the code, I immediately spotted that, in order to bypass --no-git, you would have to perform this extremely complicated and exotic command inside the sandbox: $ git push (fails) $ echo GIT_STATUS blocked $ GIT_STATUS="p0wn3d by l33t h4xx0r" git push (successful) This is 15-year-old script kiddie level. I didn't read further. I asked GLM-5.3 (full-fat) to do a security review of the change. In 3 minutes, it found NINE glaring security holes that allow bypassing git and gh restrictions. A few examples that made me want to rip my hair out: In the default restricted mode, git push works 🥇 git push --force is blocked 🥇 git push -f is blocked 🥇 git push -uf lets you happily wipe out the git remote. ☠️ git config alias.fp 'push --force --no-verify && git fp goes through too ☠️ env -u GIT_CONFIG_COUNT /usr/bin/git push --forceblasts through ☠️ Again. This is an intern-with-acne level kind of incompetence. To seal the lid on the coffin, MiMo's prose in the chat is infuriating. Not quite Opus-level infuriating, but it gets close. It hurts the eyes and it frequently takes 2 reads to understand what the hell it's saying. GLM, DeepSeek, and Qwen are much more pleasant to work with. MiMo-V2.6-Flash I asked MiMo-V2.6-Flash to do a very simple git surgery: create a new branch off master and cherry-pick a single commit from another branch. However, I didn't realise that the git worktree I pointed it to was corrupted (the branch on the main git repo was fine). A dumb model would have just returned "there's no git here, I have no idea what you're talking about" A smarter model would have noticed that there was a /worktrees/ in the path, come up with an educated guess about what happened, and gave me a hint on how to fix it A very smart model would have noticed that the only other directory existing in the sandbox was the main git repo, which had a branch with the same name as the broken worktree directory, and recovered it from there. MiMo-V2.6-Flash went on 80k tokens worth of acid trip. It first attempted to find the main git repo, failed, and then panicked and went down a rabbit hole which involved tampering with /tmp, mount --bind, and other insanity. I noticed after a while as I was wondering what the heck was wrong. I suspect that given enough time it may have nuked my main git repo and I tremble at the idea of what it could have done if not sandboxed. If you scale down Pro's intelligence on AA by comparing the available self-published benchmarks against those of Pro (which is a very crude method but gives a ballpark idea), MiMo-V2.6-Flash comes out on par with GLM-5.3-Flash (high) and Qwen3.8-Flash. Which is absolutely, categorically, not. DO NOT shell out the money for a Gorgon Halo for MiMo-V2.6-Flash. Qwen3.8-Flash on a Strix Halo is vastly better. I'm going to stick with my previous models: DSv4.1 Flash as the default GLM-5.3-Flash (high) as the dirt cheap option GLM-5.3 when the big guns are needed Qwen3.8-Flash and Qwen3.8-27B to run locally (I have a 3080 so Flash is very slow).   submitted by   /u/crusaderky [link]   [comments]