Pretty neat that you can just install it and start using it (at a Sonnet 4.6-level model) without needing to sign in or pay.
Typically, Chinese websites are a big pain to log in or sign up because they require a +86 phone number due to legal reasons. Being able to use it without having to make an account is amazing for friction reduction. I could probably even just install it onto new machines to help with set up.
I wonder how they are gonna detect and block abuse though?
MiMo v2.5.0-Pro is honestly the first Chinese model that I've tried where I really though why should I use Claude Sonnet when I can get the same results for a fraction of the cost. There was always something off about Chinese models that made it apparent that it couldn't fully compete with GPT, Claude, Gemini, etc. but this was the first model where I was like, this feels like Sonnet.
I can't prove it, but I think they trained heavily on Claude output. From my perspective I don't care since Anthropic trained on my data.
Using them also works well for North Americans as our peak hours is not theirs.
If I had one complaint, the v2.5.0-Pro model thinks too much.
GLM 5.1 is stronger than Sonnet 4.6 in my opinion, but while they have a coding plan that is a good value MiMo beats it on price. I haven't used MiMo much yet but it felt pretty similar.
They won't be giving this away, at least not for some years. It almost certainly has distillation data embedded in it, and that would be a smoking gun.
So funny I have noticed how terrible the signup is on all these Chinese models, companies etc. Always wonder why it is such an easy process. Like QQ, Tencent etc demos Ive seen past year
Mildly annoying how almost everything strips out EXIF data nowadays, in part due to security concerns like this, and then I can't find out what camera, lens, and settings were used to take photos.
My static site generator strips out exif data from images and I would expect all sensible sites would do the same. There is a lot of personal information jammed in there - if you post a picture of your dog making a funny face to social media you don’t want the exact GPS coordinates of your house plastered over the internet.
You have to be selective though, some of the EXIF data specifies things like color spaces and orientation that is used by browsers for displaying the image properly.
For my personal website I have a lot of photography-oriented blog posts [1], but I have special code to strip out GPS info from the location if it's close to my home [2].
EDIT: my vibe-coding slop agent put my home GPS lat long in the example config in the README lol. Please don't rob my house; I'll go run git-filter-repo later.
Yeah, if I take a dense grid of photos near my house, it would reveal a 500 m circle. But in practice I don't take _that_ many photos in the neighborhood. Also, the circle isn't perfectly centered on my home.
A lot of prompt engineering goes out of date quickly. Nobody nowadays goes "you are an expert software engineer. make no mistakes" lol.
As a personal anecdote, I find that a lot of big prompts and skills use up context window budget and in many cases agents will eagerly try to use a skill even if it isn't super relevant or necessary for the current task. So when I have too many skills I have to spend a bunch of time toggling the checkboxes to figure out which ones are needed for the task at hand before starting...
I can't find the link now, but Anthropic has a post about using either a light model call or other logic (regex etc) to dynamically decide what tools to expose per incoming request.
I've run into the same issue and I still end up manually curtailing what's exposed to the model, limiting to the task at hand, but I like the idea of another (smaller I hope) model doing 70% of the clipping instead, automagically.
> Anthropic has a post about using either a light model call or other logic (regex etc) to dynamically decide what tools to expose per incoming request.
How? Using the agent SDK or Claude Code? If the latter, it'd be nice if they figured that out. There's a huge amount of quality of life things missing from Claude Code. It's a pretty raw frontend to the backend models. And either Claude Code or the backend models get convinced they don't need skills they've been asked to read or even built-in capabilities like reading PDFs.
Much like agents, I can tell myself I'm a senior infrastructure/security engineer doing a thorough, adversarial code review, but that doesn't change the results much.
Nice. In the US, it cost us $35k to install 7.6 kW panels + 13 kWh battery. But our PG&E electricity prices in the Bay Area are also several times more expensive than in Europe ($0.50 per kWh) so it will also pay off in 8-10 years.
$35k and $0.50 per kWh is quite pricy. My brother is in US (Kansas) and he told me that for the time being, it doesn't make sense for him to get solar, as the utility price is something like $0.07/kWh and he uses a low amount of electricity and install cost would be somewhere around $20k-25k. I think the math works?
We also did the math for ourselves with 8-10 years at current electricity prices: 30 eurocents/kWh (which got 3x more expensive in the last 10 years). So we might be lucky and break even even sooner.
!35K, I just payed $11K for the same in Europe. But here in Spain it is not financially worth it, but insurers against frequent brownouts and 3 outages a year
Lots of comments are expressing skepticism about compatibility but it's pretty cool how Nvidia has the clout to convince a bunch of game publishers and creative apps to release Arm versions. Popular games like League of Legends as well as stuff like Adobe Photoshop and Premiere are getting native Arm ports.
> Over 100 Windows software providers such as Adobe, Blackmagic Design, Blender, CapCut, ComfyUI and OTOY, and game developers such as KRAFTON, NetEase, Remedy Entertainment, Riot Games and XBOX are embracing the new RTX Spark platform. [...] NVIDIA is partnering with Adobe to rearchitect Adobe Premiere and Photoshop for RTX Spark. [0]
> Gaming on Arm is finally coming of age thanks to the NVIDIA partnership. Native anti-cheat solutions from Epic and BattlEye are fully supported on the RTX Spark platform. Major developers are jumping on board, with Riot Games bringing League of Legends and Valorant natively to the architecture, alongside KRAFTON bringing PUBG Battlegrounds. [1]
Also, Nintento Switch is an Nvidia/Arm gaming device so many game publishers already have some experience with the combo.
Quite a few of those already have arm ports for windows, and have since the 1st gen Snapdragon X Elite. I have the surface laptop 7 with that chip, and I remember it being made a big deal when photoshop & lightroom were ported. I believe Blender also had an arm build for windows a while ago too as did Davinci Resolve (as of 2024 I believe).
The big news is more so on the games side, which is probably where Nvidia had some pull.
I'm curious what "rearchitect for RTS Spark" means in practice though. Sounds like its less convincing them to make an arm build for windows, but they are maybe taking advantage of some hardware specific features? If so, what does that mean for the Snapdragon X series I wonder?
This thread is almost 1:1 identical to when Apple released their own silicon. This has the potential to be a worthy competitor for the Windows ecosystem, precisely because of NVidia’s moat as the grandparent pointed out.
Microsoft pulls in their weight as well, so this seems like it has a decent chance of getting industry support.
If you can get desktop RTX 5070 performance, oodles of (v)RAM, and minimal power usage out of a thin and light mobile device it's a win. This is change. If you can afford it.
Yes, there is a chance but it could also turn into another Itanium. Just because it is a superior product and backed by giants, doesn't necessarily guarantee success.
Itanium was arguably not superior. The assumption behind it (that the compiler can bring order to the chaos) was wrong, making it slower, more expensive, and less efficient than x86 in real-world scenarios.
That said, Apple still deserves a lot of credit. They had a 5+ year edge, especially around the vision of tightly integrating the NPU and unified memory.
I think they have a longer lead, considering how long they’ve been making iPhone A-style processors. Migrating the desktop ecosystem to it was only the logical next step.
Like gaming consoles they calculated that unified memory will be cheaper for them in the long run. The funny thing is that while it gave them a unintended edge on local A.I, the "cheaper" calculation, didn't work out so well for them.
Yeah but like, Apple put Rosetta 2 out and it was damn good.
Vendors didn’t have to do shit to support the platform, they just got better performance if they did (like factorio).
There is something of a difference between “all your stuff will still work, at comparable performance” and arm windows which (as evidenced by all the vendor promises) you can’t really currently say with prism.
I would describe prism as “surprisingly rubbish considering they had an example of how to do it right” and “your app probably doesn’t run because of drivers or some ??? compatibility thing”.
Am I misremembering? I remember being blown away by Rosetta.
Prism… yeah. Toggle the settings. Disable jit. Disable FP. …bin laptop. Get an intel laptop.
I think a lot of it is down to Windows, not Prism itself.
For decades, Windows made it too easy for games and even some application to install drivers. Windows games use drivers for anti-cheat (and historically for copy protection too). Neither Apple Rosetta nor Microsoft Prism can translate/emulate drivers, but since drivers have been much more prevalent on Windows, now Windows has a much biggest compatibility problem.
Don't read too much into the marketing speak. "Embracing" does not necessarily mean most of these companies are actually doing anything other than providing a marketing statement about how their product already works on ARM64 Windows. E.g. Photoshop has had an ARM64 version on Windows since 2020, EAC & BattlEye since 2024 & 2025 respectively. And, even then, it'd be a lot more exciting if e.g. Fortnite would actually enable ARM64 support in EAC rather than it just be supported by EAC.
Only the ones which explicitly list something like the Riot Games mention are really related to the device/Nvidia. The thing which really pushes this along is user adoption/market share, not big names. This device will help that, especially in the gaming space, but it's easy to get over eager as it being from Nvidia means everyone else who has been waiting will just now jump on board too because of that.
Well, linux already runs perfectly fine on ARM chips, so it probably won't matter much. The real bottleneck is getting game studios to build arm releases of their code, which by itself is easy in normal circumstances but they often have third party code that doesn't have ports or are abandoned or hidden behind NDA's (networking code, sound processing, custom tooling etc). So ARM and Linux are not the blocking factor at all and I'm willing to bet most of the engineers working on game engines have ported them to linux/arm for fun already, they just can't release for various reasons above.
So if anything, we need to push more game studios to use open source dependencies which will make porting easier.
Linux is terrible on ARM, I don't agree that it runs perfectly fine at all. Try loading Ubuntu onto a Snapdragon laptop for example. It works but lots of issues eg sound, webcam quality, etc
I think you're referring to a specific SoC that's used on recent laptops which happens to have driver issues, something not specific to ARM at all. Other (usually embedded) ARM devices have been running just fine on Linux for over 20 years now.
GNU/Linux has trouble, but thanks to Android (and ChromeOS), we know Linux itself specifically on ARM does actually work. Freeing those drivers is another matter, unfortunately.
Those are specific firmwares for those devices that are either closed-source binary blobs, open-source hackjobs/reverse engineered attempts, or just plain missing firmwares. The fault is not on Linux but rather on Qualcomm not releasing things for that specific SoC. Some SoC's have better support than others. ARM cpu's themselves works perfectly fine on linux.
Intel has closed things down: some wifi and webcam firmwares are poop and a massive pain to get working on newer chips (if at all). Their wifi firmwares also don't respect certain kernel overrides (which is why I replaced my Intel Wifi 7 chip with a mediatek Wifi 6 one). Blame is 100% on intel and not linux. Broadcom is also pretty bad at being a team player in this regard.
I basically recommend everyone to stick with AMD chipset & GPU's where possible, because they have mainline kernel support nailed down 95% of the time.
Again, ARM works fine, their extra firmwares for extra devices on SoC's are to blame if you struggle.
> Those are specific firmwares for those devices that are either closed-source binary blobs, open-source hackjobs/reverse engineered attempts, or just plain missing firmwares
This isn't fully the reason, Linux is infamous for requiring a specific build for each SoC (and usually each board of said SoC) where as Windows on ARM uses ACPI which Linux doesn't support to the same level. Linux prefers the landfill promoting device tree for each device approach.
> Linux is infamous for requiring a specific build for each SoC
no, thats just androids problem. desktop linux like ubuntu ships all the device trees from their supported arm variants. its still more work than acpi for kernel maintainers but you dont need device specific builds.
> landfill promoting device tree for each device
whats landfill promoting about this? you dont need to keep the trees updated they only depend on the hardware and follow a stable spec. and even if the vendors dont want to support linux a community user can write their own device tree and send upstream.
reply