RunMat Turns One: What We Built and What Comes Next

One year ago, we published RunMat v0.0.1 with a clear goal: give MATLAB-syntax code a fast, open runtime built for modern hardware. The first release was a command-line runtime with 87 built-in functions, basic 2D plotting, and a basic JIT compiler. Its launch benchmarks focused on GNU Octave.

RunMat now has more than 1,200 built-in functions, automatic GPU acceleration, and interactive 2D and 3D plotting. It runs in the CLI, in a zero-install browser sandbox, in persistent RunMat Cloud projects, and as a native Desktop app. Cloud projects are multiplayer, with real-time collaboration, version history, snapshots, and prior runs. RunMat is designed for agent in the loop engineering, where LLM agents can run scripts, inspect variables and figures, and use compiler diagnostics before returning changes for review.

Today, more than 1,000 people use RunMat per month, having run more than 55,000 scripts in the first 6 months of this year.

Last week, we released RunMat v0.6.0. The first year followed a deliberate approach: systematically implement MATLAB-language semantics in a modern compiler pipeline written in Rust, while extending the language and product where doing so does not break compatible behavior. We are now deepening compatibility and booting more established codebases, alongside shipping new capabilities that deepen the runtime's capabilities.

What the first year taught us

People want a true alternative, not a new language to learn

The first lesson we learned was that familiar syntax was not enough. Engineers wanted the MATLAB language their existing work already uses, with the same syntax, call forms, and language grammar / semantics. They wanted a true alternative to what they already knew, rather than a language that only looked similar. A language that only looked similar would still leave teams rewriting and revalidating years of engineering work; a language that looked only similar would not match what textbooks they had learned in school.

One team evaluating RunMat described a MATLAB codebase developed over 17 years and spanning more than a million lines. Their test for an alternative is straightforward: can we replace the runtime, run the existing regression suite, and change as little source as possible, while providing all of the performance, portability and execution benefits of RunMat? Engineers in other fields described similar constraints: internal codebases, teams that had validated routines, or existing staff that had learned MATLAB. Continuity, and a practical second option, were of paramount importance.

People are tired of AI tools that don't offer a specific value proposition

We always believed that agent in the loop engineering would be a key use case for RunMat. Once the cat was out of the bag for people to use LLMs for writing code, we knew that LLMs and humans will be inseparable for engineering work as time progresses. In 2025, 1 billion GitHub commits were written. In 2026, GitHub is on pace to hit 14 billion commits. The world is changing, and going forward, we believe most code will be written by LLMs, and most code will be reviewed by humans.

As we experimented with providing a good agent-in-the loop experience for RunMat, one of the first experiments we did was to make a prompt box the primary way to interact with RunMat.

To our surprise, usage volume plummeted, referrals plummeted, and the overall usage of RunMat dropped. We since evolved the Agent to be a more integrated part of the product, removed it from being front and center, and usage growth has gone back to a steep incline.

Now, LLMs in RunMat are a key part of the product, but not the center of attention. People come to RunMat for a great math and physics runtime environment, not yet another generic AI tool.

Agents are contextual to projects, and can run scripts, inspect variables and figures, and use compiler diagnostics before returning changes for review. Every runtime error can dispatch background root cause analysis agents to help engineers understand the issue and propose a fix. Edits are atomic collections of changes that can be reviewed, applied, and reverted as needed.

We believe LLMs will be a key part of the engineering workflow, and will continue to design RunMat to work well with them.

Performance pays back in many ways

We wrote the compiler in Rust, and it keeps one implementation core across native builds and WebAssembly. We use Cranelift and wgpu as proven foundations for native compilation and cross-platform GPU access.

RunMat Accelerate estimates when suitable array work should move to the GPU, fuses compatible operations into fewer GPU dispatches, and keeps intermediate values resident when later operations can reuse them. Engineers continue writing MATLAB-syntax array code, and the runtime figures out when computation size warrants GPU acceleration, and accelerates it automatically.

Plotting followed the same performance model. Since data would already be resident in GPU memory, we could allow plots to be rendered without moving the full dataset back to the CPU. RunMat grew from basic 2D charts into an interactive GPU-accelerated plotting engine with more than 30 plot types across 2D and 3D. We modeled the renderer on a video-game engine. Supported plots can reuse GPU buffers instead of moving the full dataset back to the CPU, while camera changes redraw the prepared scene. This keeps large surfaces and point clouds responsive during interaction.

See the benchmarks here for more details. In short, in building RunMat, we prioritized performance, and we're realizing performance pays back in many ways for our users. Performance is not just about speed; it allows for scaling up physics models by 10x, or 100x in resolution on the same hardware. Performance allows for a codebase that runs on 100,000 computers with CPU cores to run through parallel execution on a fraction of that hardware using GPU cores. Performance allows you to do things that were not possible before, and it's really exciting to see people build amazing things with RunMat.

What comes next

The work between here and 1.0 is concentrated on deepening compatibility by booting real codebases, filling the built-in and language gaps they expose, and expanding the regression and parity tests that protect existing behavior. We are also extending automatic acceleration across more workloads and bringing the browser, Cloud, Desktop, and agent workflows closer together.

Alongside the core runtime, we are finishing RunMat FEA: an integrated way to bring CAD or mesh geometry into RunMat, define and solve physics studies, and post-process the results using the same MATLAB-syntax environment. It extends the runtime from math on arrays to math on geometry.

Our goal with RunMat is not to reproduce an old computing environment one feature at a time. It is to preserve the code and expertise teams already have, while giving that work a faster, more portable, and more collaborative execution layer underneath it.

Our mission remains to help engineers push the frontier of math and physics.

It has been exciting to see people carry established work into RunMat and tell us what it needs next. We're excited for the next year ahead.

To mark RunMat's first birthday, we're making RunMat Pro free for students and educators. If you study or teach, request academic access here for a free version of RunMat Pro. RunMat Pro includes collaborative projects, allowing students to work together on projects, and educators to create assignments and projects for their students.

Things to try next to explore RunMat:

• Bring an existing project to the browser sandbox
• Download RunMat Desktop
• Contact us link