I consider myself an advanced industry representative in these things and would also borrow some time for detailed investigation. I'd happily contribute some valuable assets (tacos with cheese dip) into the matter, straight out of my personal drawers.
I use cachyos as my daily driver for a long time now. I play quite a few games. Only league of legends forces me to dual boot into windows every once in a week or so - fuck the anticheat cartel
I'm approaching a year now on CachyOS and it has been a wonderful experience. All the games that I play run just fine, maybe a few FPS drop compared to Windows, but it's not a big deal for me. I also don't play any competitive online games that require 3rd party anti-cheat spyware. Biggest positives, I got very comfortable with terminal and CLI work. My development work has definitely improved.
Yeah that must be it. OpenAI doesn't want to disclose internal reasoning, that's why thats typically encrypted_content in OpenAI codex session ledgers etc.; leveraging responses API preserves reasoning server side all the way till a final answer is made; so that's very impressive and to me the score that matters.
If watermarking of any kind were actually going to prevent ai-generated “fraud” (or even ai being used as part of a scam), it would have more support on HN.
This kind of metadata injection increases surveillance without providing a meaningful deterrent.
Furthermore, it almost surely limits the quality of the output. At least the finterprinting of the text tokens has to, how can you otherwise constrain token output?
For example if you have 2 equally likely tokens to choose from you can pick the one specified by a key function instead of the one specified by an rng.
There are already a handful of repos doing essentially exactly this: `mlx-moe-offload`, `streamlx`, `mlx-moe`, `mlx-flash`, and `deepseek-v4-flash-mlx` - i.e. keep the resident parts of an MoE in unified memory and page/stream routed experts from SSD on Apple Silicon.
At this point I'd much rather see people collaborate on one of these implementations, benchmark against them, or upstream the useful bits into MLX/MLX-LM instead of producing yet another near-identical repo.
The local-LLM ecosystem really does not need every implementation idea rediscovered five times and wrapped in a new README. AI-assisted coding makes producing a new repo cheap; maintaining, benchmarking, and integrating one is the actually valuable part.
I see your point. As an oss defender myself, I agree, however, the spirit of this is to see how fast I can make it. I'm sharing this with the community, which I think is aligned with the original oss spirit.
It's an experiment for myself but I am committing to maintain it. I've been an oss person for a loooong time, way before AI was a thing. Think about it as a new, from-scratch take at it, not as a re-reproduction.
Hey carloslfu, kudos from the other side of the internet, don't get down on people nitpicking everything here, experimenting and discovering is part of learning so keep going!, remember this is the place that said dropbox was dumb and could be replaced by a script.
I think multiple people working on the same thing is great.
Everyone comes at it from a different point of view, and some approaches work, some don't. And when people do this themselves they learn. Existing projects have their mistakes worked out already.
Maybe one of these people is going to come up with the thing that nobody else thought of because of their experience working the problem from scratch. You may not get that from someone working from an existing project, because existing projects have their approach "baked in."
What all these projects are showing so far is that it's possible to stream from disk, but that the performance isn't ideal. But I'm sure you could take this approach with smaller models and get better performance.
In addition, it's a given that when you work with large data sets performance means organizing the data to take advantage of caches, both disk and cpu. It's not clear how that would work, exactly, given that each run is a not-quite-random walk through the data. The Big Data way is to prebuild all of that as much as possible, which is probably impossible with a big model. But what about a smaller model?
Multiple people working on the same thing is great. I'm less convinced about multiple people asking the same LLMs to redo the same project and coming up with a repo with a llm slop readme full of "Disk bites first", it's not this, it's that etc...
I don't think that this will bread any innovations.
This is one of the aspects of this year that I've been finding very grating and wasteful. Collaboration still happens among people with the ability to do so and the technical skills, but everyone else is taking their own helicopter to the top of the mountain, "putting it out there", and there's just a ton of redundant projects that do the same thing.
Also for the record, I wasn't trying to take a personal shot at you or your project—nor am I sure of how valid that would be, if that were to have been my intention—it's just a gripe I have in general what I think is somewhat degrading the trust I can have in certain types of projects, especially those that someone shits out, puts on the app store, appears on the surface to visibly look ok, but ultimately has no uniquely valuable contribution or long-term outlook and is just someone's zero to one replication of something that has an api and already exists. It is admittedly cynical, but I now scrutizinize what I pay for more aggressively as a consequence.
I'm sorry this makes it seem like I didn't do my research. I did a TON. To fix it I'll add a benchmark/comparison table. Also, I wouldn't call it market research since this is not commercial AT ALL.
I'm only joking anyway — it's more a comment on the whole AI-accelerated trend of everyone having their own version of a thing.
I do agree that, ultimately, combining your efforts with others working in this whole area is probably really worth it, but I can see how there's an ease of pushing forward on your own these days.
I do not have fast internet so I am not sure when I'll really be able to download the weights but I do have an M1 Max to try this on, so I will at some point!
I see! yes, downloading the weights part is painful. I tried a couple fixes and it is as fast as it can get downloading from HuggingFace. I think the field is heading toward smaller, more capable models soon, so you won't have to wait that long!
I mostly use Muse Glimmer, which runs quite well on my M1 Max as it is 30B but it also reasons very efficiently. I have tried the Qwen 3.8 27B which is also usable if quite slow to reason, but I guess like everyone the idea of the Flash-Next model holds some intrigue, because the 35B-A3B is pretty good.
reply