Mojo 1.0: A Python Superset for High-Performance AI, Now Fully Open Source

Three weeks after Qualcomm completed a roughly $3.9 billion acquisition of Modular, the company did something unexpected: it open-sourced the entire Mojo compiler. Mojo 1.0 shipped on August 11, 2026. The compiler followed on August 18, released at ModCon in San Francisco under Apache 2.0 with LLVM exceptions. The move addresses the biggest criticism leveled at the language since its 2023 introduction: developers no longer have to take the same leap of faith on a closed compiler.

Chris Lattner, who built LLVM, Clang, Swift, and MLIR, now serves as Qualcomm's executive vice president for advanced AI software. Mojo is his fourth major language project and leans on all the previous ones.

What Mojo is and why it exists

The standard AI development workflow involves prototyping in Python and then rewriting performance-critical code in C++ or CUDA. Python is readable and productive. CUDA is fast but tied to NVIDIA hardware, and writing it requires a completely separate toolchain from the rest of your application. Mojo's goal is to combine Python-like productivity with low-level performance without locking developers to CUDA.

Mojo is a superset of Python. It uses Python's syntax as a starting point and adds opt-in features: strong type annotations, var for mutable variables, let for immutable ones, and fn for functions where the compiler can apply more aggressive optimization. These additions are not mandatory for prototyping but unlock significantly better performance when you need it. Under the hood, Mojo uses MLIR (Multi-Level Intermediate Representation) rather than just LLVM, which is what allows it to target GPUs, NPUs, TPUs, and custom accelerators alongside standard CPUs. The same source compiles to whichever hardware you're targeting.

CPU performance: the Mandelbrot benchmark

The Mandelbrot set calculation is a useful benchmark because it's compute-heavy with nested loops and floating-point arithmetic, exactly where Python's interpreted overhead shows most clearly. The Python and Mojo versions are structurally identical:

def mandelbrot_kernel(c_re, c_im):
    z_re, z_im = 0.0, 0.0
    i = 0
    while i < MAX_ITER:
        if z_re*z_re + z_im*z_im > 4.0:
            break
        new_re = z_re*z_re - z_im*z_im + c_re
        new_im = 2.0*z_re*z_im + c_im
        z_re, z_im = new_re, new_im
        i += 1
    return i

fn mandelbrot_kernel(c_re: Float64, c_im: Float64) -> Int:
    var z_re: Float64 = 0.0
    var z_im: Float64 = 0.0
    var i = 0
    while i < MAX_ITER:
        if z_re*z_re + z_im*z_im > 4.0:
            break
        let new_re = z_re*z_re - z_im*z_im + c_re
        let new_im = 2.0*z_re*z_im + c_im
        z_re = new_re
        z_im = new_im
        i += 1
    return i

Running both:

python mandel.py

mojo run mandel.mojo

Python: ~0.8081 seconds. Mojo: ~0.0051 seconds. That's roughly 150x faster for nearly identical code structure. The minor checksum difference between the two outputs isn't a bug: Mojo's compiler uses fused multiply-add (FMA) instructions that produce slightly different floating-point rounding than the sequential operations Python runs.

A more realistic benchmark: on certain matrix operations, Mojo can be 1.9x faster than NumPy. NumPy is a wrapper around highly optimized C and Fortran code, so beating it demonstrates that Mojo's compiler is generating better code than pre-compiled C libraries in at least some cases, likely through better memory layout and instruction-level optimizations.

GPU programming

Mojo's more significant claim is writing GPU kernels in the same language as the rest of your code, without switching to CUDA or a vendor-specific SDK.

A vector addition kernel in Mojo is defined in the same .mojo file as the host code that orchestrates it. Building and running it:

mojo build vector_add.mojo -o vector_add

./vector_add

On a MacBook with an M4 Pro, Mojo correctly identifies the GPU via Metal and runs the kernel without any Metal-specific code in the source. The same source is meant to target NVIDIA GPUs via CUDA, AMD GPUs via ROCm, and Qualcomm's own accelerators. That's the architectural bet: write the kernel once instead of maintaining separate implementations for each hardware vendor.

What the 1.0 release actually means

1.0 is primarily a stability promise. APIs marked as stable will not break in future 1.x releases. Additive changes are expected; breaking changes to stable APIs are not. This is the guarantee that lets developers and companies build on Mojo without fear of constant migrations.

What it doesn't mean:

The fn keyword has not been removed. What changed in 26.5 is that def functions now have better type inference and optimization in many contexts, but fn remains the path to fully explicit, maximally optimized code. Code using fn from earlier Mojo versions is not broken.

Some core built-in APIs are still marked unstable. The 1.0 release shipped with warnings on certain fundamental components, indicating they may still change. The stability guarantee applies to explicitly marked stable APIs, not the entire standard library.

External compiler contributions are not yet accepted. The standard library has accepted external contributions since 2024. The compiler and toolchain target end-of-year for opening to outside patches. Source is visible but the project isn't fully open for external development yet.

There is no formal RFC process. Language decisions are made by the internal team. This may change as the project matures.

The Qualcomm context

Qualcomm closed the Modular acquisition on July 29, 2026. Three weeks later, the compiler was open-sourced. The timing was not accidental, but Modular had committed to open-sourcing the compiler as part of the 1.0 plan before the acquisition, and had been progressively opening the stack since 2024.

Qualcomm's strategic interest in Mojo is straightforward: a programming language that only runs well on one vendor's chips doesn't get adopted. A language that runs well across all hardware, including Qualcomm's Snapdragon processors and custom AI accelerators, drives demand for Qualcomm silicon across the ecosystem. AMD's presence at ModCon as a highlighted partner underscores that Mojo is positioning itself as explicitly CUDA-neutral.

The benchmark qualification that matters

Early Mojo benchmarks quoted figures like "35,000x faster than Python." These compared a fully vectorized, parallelized Mojo implementation against a naive, single-threaded Python loop that no performance-conscious developer would write for that task. The more honest comparison is Mojo versus Python with NumPy or Mojo versus Python with optimized C extensions. The 150x CPU speedup in the Mandelbrot test uses straightforward code on both sides, which is why it's a more meaningful baseline.

Who should look at Mojo now

For developers writing custom GPU kernels, performance-critical inference code, or operators for AI models, Mojo is now a genuinely open toolchain worth evaluating. The compiler is on GitHub, the language is at mojolang.org, and the Apache 2.0 license means there are no restrictions on commercial use.

The picture is different for application developers and data scientists working mostly at a high level with PyTorch, TensorFlow, or Pandas. Mojo's library ecosystem is still young, so while the language is ready for experimentation and performance-critical components, it is not yet a replacement for the broader Python data science stack. For now, the more practical approach is to introduce it selectively, using Mojo where performance matters most while keeping the rest of the application in the tools developers already rely on. with the performance-critical path, validate the toolchain there, and expand from that foundation.

Got an article suggestion? Let us know

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.