Maxwell rewrites running code and formally proves every change is equivalent
Maxwell: A new kind of model that sits between code and hardware
doubleAI has built Maxwell, a code execution model that watches a program while it runs, rewrites its binaries for the exact hardware and data at hand, and formally proves each replacement semantically equivalent to the original. It runs on CPUs and GPUs, and the company reports 38× faster data pipelines, 4.25× faster AI inference kernels, and nearly twice the speed for LTX-2.5's 4K video generation. Source code stays untouched.
A CEM lives inside the running program, watching the data flow through it and reshaping the algorithms and instructions as it goes. The output is a binary, run directly on the hardware. No humans in the loop. Therefore, the model must never err.
- epsylon
There's a lot of claim and so little technical details on that page.
How was the formalization of Python accomplished? What formal proof framework do you use?
How do you reproduce the optimizations across several instances / runs of the program? (since the source code doesn't change... assuming you don't redo the same work over and over?)
What visibility, tracking and logging is there into the actual code running? Debugging is an extremely important part of building software, especially if there's a demon switching out binary code constantly underneath. Even if the recompiler is perfect (it won't be), user code never is.
Why is the superoptimization and visibility into the data not surfaced back to the level of the source code? This seems like a waste.
- gavinray
This was a lot more exciting than I expected.
The homepage does not do a very good job of explaining what we're looking at:
It appears to be a combination of two things:
1) A formalization of the Python language
2) An LLM which hooks into running programs and hot-swaps code with verifiably-equivalent behavior but better runtime performance, found via superoptimization and then verified via the formalization rules
This is brilliant, and in hindsight one of those "I can't believe nobody had thought of this yet" sort of things.
- mccoyb
Let me say that I like the idea:
- verification
- superoptimization specialized to a particular piece of hardware
- patching binaries while they are running
all great
That being said, I'm getting some weird vibes from the prose on this site. Little phrases and claims that seem intended for the purposes of marketing, but conflate things with clear technical meaning in confusing ways.
For instance: I watched the video ("a code execution model has to be right every time") which implicitly communicates something like "the model cannot hallucinate" ... of course, the agentic LM is still probabilistic, but it is wrapped with verification tools (to reason about semantic equivalence), and is likely post-trained to be good at using those tools.
This strikes me as a conflation between the model and the harness which is intended to strike a marketing point (like: "it doesn't hallucinate") but which is clearly a ridiculous claim to make (falling down the slope: any harness which does error correction for improper tool calls might also be a "model which makes no mistakes")
Also: "self-improving code"
that's not really it, is it? Self-improving code would be code that runs itself and improves itself. This is code I run, which Maxwell watches and improves ... no?
Related: I dislike the usage of the word "model" in the above discussions on the site. Do we want to call everything a "model" now? Can anyone invent a new frontier "model" by post training an agentic LM with tools?
Also, let's say […]