I'm using DSH with my local models (4x sparks running GLM53F, trying them on DS41F this morning). DSH is better than opencode IMO. It's a little barebones out of the box but I guess that's the point. I had to have an agent add support for attachments to make it more useful for multi-modal work.

The PTC mode is pretty nice. Feels like models are still learning how to navigate it.

I ran the preview model around 2,126,605,070 tokens for $22.04 USD for the last couple of days. Kind of shocked.

It did a decent job refactoring https://github.com/mmastrac/diffgemma to create a CUDA support backbone, it's struggling a bit to port metal kernels to CUDA unattended (it hasn't managed to get numbers to match over >1 layer).

It successfully ported a root exploit to an older Android phone that GLM5.3Flash and DSv4Flash were struggling a bit on, though I didn't start it from scratch and it picked up some of their work.

FWIW it feels like a slightly-north of Opus 4.8 model, not quite Opus 5, not fable. It thinks in circles far less than DSv4F. The API version is insanely fast - was getting ~400 tok/s at times.

Thanks for providing some real feedback on using it.

Which harness are you using?

Not him, but ds is really good in prime-agent

I've been trying out the 4.1 flash preview for some bulk tasks: it did a pretty good job refactoring a bunch of .metal kernels to .cu. It needed less steering than Opus on refactoring, IMO, and writes better comments. It failed to port a root exploit from modern Android to an older Pixel 3, but I suspect part of that might have been harness configuration (it asked me to give it a longer timeout for tasks at some point, but I didn't have a chance to finish that).

I was getting something like 300-400 tok/s which was just insanity. It was running so much faster than the toolcalls themselves. Honestly, even if it's not quite as strong in reasoning, it just throws so much so fast that it can do a lot more than you might expect.

I'd say it was comparable with GLM5.3 Flash.

It should be possible to run on Mac via https://github.com/mmastrac/diffgemma, but I'm at rustconf right now and I can't download weights on hotel wifi easily.

let me try this out as well

https://github.com/mmastrac/diffgemma#custom-quantization has some instructions on (naively) quantizing the upstream model as well.

I've been running mine for ~4ish I think, on my third battery and might run out my fourth because it's feeling a _little_ sluggish at times.

I am waiting for the next FP model where I can use a USB-C/dp external display and then I'm all over it.

That's a lot, I usually use old phones from family members, most of them have 4 years of use by the time I get them and I get a whole day of usage from the battery.

Honestly, not sure. I use Firefox Mobile pretty heavily during the day and I suspect it's part of the drain. I'm not too concerned by it and I just try to replace the battery every ~1-1.5 years.

Me too. But I always have the screen on the lowest brightness possible and use ublock. I mostly read text based pages.

What is happening to your batteries? I'm on something like year 6 on my Redmi and my battery is fine. Am I simply lucky?

I also never had battery issues with my fp4, except it sometimes starts draining really fast. Fix is too charge while phone is shutdown.

The comparisons with other models here are odd.. the other models change depending on the task. It would be far more useful to at least compare against the more recent open models (DS4Flash/GLM53Flash/Qwen38).

They are trying to keep the models within the same quant class, which is tough to do since a lot of models aren't distilled to lower quants.

There is, for example, no Qwen3.8 7B.

It is odd to me, though, that they didn't run the same benchmark suite for the various quants.

Any idea what size this is?

Mark Zuckerberg said that they will release soon Muse Spark as open weights, in which case we will see the size.

However, the statement did not include any details, so it is not clear if the open weights variant will be the same that they are hosting now, or some scaled down version.

Do you have a source for more info? That seems odd to me - LLMs are particularly resilient to bitflips, so if anything the demand would pull on DDR5 in general, not on ECC specifically.

What's missing from these discussions is the real weakness of diffusion models: you can have two positions where two tokens need to be coordinated, but both spots are teetering between two valid states. They don't always collapse to the matching pair.

I only learned this the hard way reimplementing diffusiongemma. I had ideas on how to fix it but no cluster to train and experiment, hah.

have u seen the dspark paper, they add a morkov head for light weight dependency, not sure whether it can be extended to multi step refining

Is there a lookup that gives you a title to blob mapping?