Just tried both the Omni model and the text only model, both as mlx versions, in lm studio omlx and rapid mlx, none of them could actually fire the model up, kept saying safetensors cant be read (yes I realize Claude should hear this not this thread).
I think mlx-vlm should support both the Audio and the Omni model: https://github.com/Blaizzy/mlx-vlm/ and there should be native MLX exports for both here:
Electric semi tractors are impractical in all but drayage use cases (port to warehouse short haul). Even then, they require specialized yards and hours to charge, and they are twice as expensive as diesel tractors. Refueling a diesel truck takes minutes. Plus the electrical grid impact to supporting the charging of these trucks, keeping just 50 trucks charged annually uses as much electricity as a decent sized town.
For autonomous trucking, you’re grossly underestimating 1) how dangerous these trucks are. A small rear end accident with a car does some damage, a small rear end from a tractor with 80k pounds of cargo kills people. 2) They are hard to drive, hard to navigate in cities, require inspections constantly for roadworthiness and safety. Sure having a tractor pull a load on a few hundred miles of straight empty highway in Texas is doable today, having that same truck get to a warehouse in the center of Dallas is a nightmare even for pro drivers.
3) Plus no one knows how to legislate or regulate these things. If a robot tractor kills someone, who is at fault? The vehicle maker? The autonomy software maker? The carrier? There are already nuclear verdict lawsuits for these types of situations with human truck drivers that can be tens to hundreds of millions of dollars I.e. shut down a carrier bad. You think a bunch of octogenarians in congress know what the hell to do with any of this stuff?
I say all of this while also fully agreeing that consumer autonomy seems to have been solved or is on its way to being solved, I’d bet in 5 years it will be weird to get an uber and there’s a person actually driving. Commercial heavy duty trucking is a whole different class of problems that goes well beyond “can the software do it”.
Source: I make software for trucking carriers and drivers
There seems quite a practical electric truck system running in Australia. They use swappable batteries loaded onto the truck with a fork lift which wouldn't be a goer for cars but seems not a bad idea for heavy trucks.
> keeping just 50 trucks charged annually uses as much electricity as a decent sized town.
Doesn't fueling a diesel require the same amount of energy? What's worse, a diesel is expelling the byproducts of that energy use right where people live.
I think these fears are over blown just like they were in the lead up to having regular driverless cars in chaotic driving conditions for example in New York City. It all worked out and very quickly and the same will happen with these things.
Fully autonomous is a long ways off, but semi-automated can't get here fast enough. Drive a comma.ai equipped car over a long road trip or other advanced driving aid, and just feel how much less frazzled you are after driving for a few hours.
could we automate the predictable, tedious sections of long drives on interstates but let humans take over for the complex 'last mile' navigating through towns and to the final destination?
those drivers could spend their lives working locally (and sleepin at home), develop deep regional expertise, and be able to handle the hardest part of the job without the fatigue from a cross-country drive.
You really think there’s more than five years between now and these things being able to do last mile? I don’t think we have the luxury of imagining in lifetimes anymore like we did 20 years ago, things are changing rapidly.
we're at a point in AI-driven automation where we've seen rapid progress on the 'easy' parts of many jobs, but we don't know whether this is an exponential trajectory (progress continues to accelerate and the singularity arrive) or a sigmoid/logistic trajectory (progress decelerates and and we have to spend more and more compute/time/money to eke out smaller relative gains).
if we're on the former path, you're right. if we're on the later, there comes a point where continued work in automation isn't cost effective and we keep the humans around to handle all the hard 'edge cases' like urban driving to the final warehouse
Not the same but adjacent hobby, I’ve had good success with feeding 3mf files to Claude (usually just fable in desktop app) that I found on maker world to prompt for modifications to the model and it works damn well. Stuff like changing a functional model from press fit only to using inset m bolts and nuts. Way better than doing it by hand in a cad app
A very similar idea crossed my mind several times, but with a twist: altering LEGO CAD parts, but keeping the connectors the same.
Main idea was, if LEGO parts don't cover the needs for an agent to build a model, let it use the best it can find, and manufacture others if needed, but keeping same compatibility with the rest of the catalog.
And for that, instead of generating new parts from scratch, maybe mutating pre-existing parts into new shapes it needs, but leaving connectors as they were, or even adding new connectors but still compatible.
I’m playing with this exact concept but going down the path of a Claude code plugin that is optimized for configuring lowdefy apps because of that framework’s unique approach where you don’t write code you generate yaml configs that then drive the rendering of an app. So far it’s working pretty well, still pressure testing it. The audit control and permissions management you have is great, especially around the connectors. Nice job!
Thanks! We've actually have been experimenting with the config generation approach as well. One tradeoff we noticed was it turns the system into more of an app builder where the ceiling of what you can do is lower compared to a coding agent. But it's much faster than codegen. How dynamic have you found Lowdefy compared to codegen?
I just redid my homelab/media server (switched from an old NUC I couldn’t figure out how to stop overheating even with some decent modification work, now using an hp elitedesk with an i5 processor that is handling my stack nicely). Thinking about setting up a vm on the base ubuntu install for isolation to run Claude in. May play with dispatch, may just put raw Claude code then use Moshi app on my iPhone and iPad.
reply