modular/modular: the MAX and Mojo monorepo, built through Bazel and split across two licenses

One repository for the Mojo compiler, the stdlib and the MAX stack

The repository describes itself as hosting the open-source components of the Modular Platform, which bundles the MAX Framework and the Mojo language. What makes it more than a standard library mirror is the list of components with source available, each with the date it arrived. The Mojo standard library under /Mojo/stdlib has been open since March 2024. GPU programming in Mojo under /max/mojo/max/gpu, the Mojo compute kernels in /max/kernels, the model pipelines in /max/python/max/pipelines and the inference server in /max/python/max/serve followed in May 2025. The Python model authoring framework in /max/python/max arrived in November 2025, and the Mojo compiler itself, under /Mojo, has been in the repository since August 2026.

The MAX graph compiler (/GraphCompiler), the MAX runtime (/MLRT) and the MAX driver (/max/driver) are listed as well, along with example code in /max/examples and /Mojo/examples. The top level also carries directories such as AsyncRT/, Kernels/, SDK/, Target/ and rust_kv/, which makes this a large monorepo rather than a single package. The last push to main was on 2 November 2026.

Building from source goes through bazelw, not pip

The repository is a Bazel workspace. MODULE.bazel, REPO.bazel, BUILD.bazel, .bazelrc and .bazelversion sit at the root, and the entry point for running anything is the bazelw wrapper script checked in next to them. To run the Mojo compiler on a file from the checkout:

./bazelw run //Mojo:mojo -- Mojo/examples/hello.mojo

The part before the double dash is a Bazel target, //Mojo:mojo, and everything after it is passed to the mojo binary, here the hello.mojo example. Running anything means going through Bazel and the target graph defined in BUILD.bazel and MODULE.bazel, so a working Bazel setup is a precondition for every experiment in the tree.

This path is aimed at people who want to experiment with MAX or Mojo internals. The README splits its audience in two: if you want MAX and Mojo in your own projects, it sends you to the MAX get started guide at max.modular.com and the Mojo quickstart at mojolang.org rather than to a source build. The pyproject.toml at the root, with name modular and version 0, exists for tooling and requires Python 3.10 or newer; it is not a package you install to get MAX.

The max generate example will not run without a supported GPU

The second example drives the MAX pipelines entrypoint to generate text with a model:

./bazelw run //max/python/max/_entrypoints:pipelines -- generate \
  --model Qwen/Qwen3.5-0.8B --max-batch-size 1 --max-length 10000 \
  --prompt "The sky is blue because"

The generate subcommand takes a model identifier, here Qwen/Qwen3.5-0.8B, a batch size of 1, a maximum length of 10000 and a prompt string. The README attaches a hard condition to this command: it requires a compatible GPU, and the list of compatible hardware lives on the system requirements page at max.modular.com. A laptop without one of those GPUs can build and run the Mojo hello example but cannot reproduce this one, so check the compatibility list before planning a model serving experiment around a source checkout.

The command also downloads model weights from a third party. The license section is explicit that you are entirely responsible for checking and validating the licenses of third parties such as Hugging Face for software and models that get downloaded. Running a different model with --model means checking that model's license yourself.

Mojo is Apache 2.0, but parts of MAX are under a separate license

GitHub reports the repository license as NOASSERTION, and the reason is that there is no single license. Mojo and contributions to it are under the Apache License v2.0 with LLVM Exceptions, in Licenses/APACHE_LICENSE. MAX is split: portions of the MAX source code and its binary distribution are covered by Licenses/MAX_LICENSE, and the remainder of the MAX source is under Apache 2.0 with LLVM Exceptions.

The practical consequence is that you cannot assume a file is Apache licensed because it sits in a public GitHub repository. If you plan to vendor MAX kernels, fork the inference server, or redistribute a binary you built, you need to establish which side of that split each piece falls on and read the terms of MAX_LICENSE itself. The README does not say which directories fall under MAX_LICENSE, so that mapping is work you have to do before a commercial deployment, not after. Combined with the third-party clause above, a product built on this repository has at least three sets of terms to clear: Apache 2.0 with LLVM Exceptions, the MAX license, and the license of whatever model you load.

Open source in stages: the platform is not all here yet

Modular states that it is actively open-sourcing more of the platform over time, and the dated component list reads like a timeline of that process: the standard library first in 2024, kernels and GPU programming in 2025, the compiler in 2026. The flip side is that the repository is not the whole product. It hosts the components whose source is available today, and the binary distribution of MAX is mentioned separately in the license terms.

For a reader this has two consequences. First, behaviour you see in a packaged MAX release may depend on code you cannot find in this checkout, so a bug report against the packaged build should go through the issue tracker rather than assume the cause is visible in source. Second, the date attached to each component matters: anything written before August 2026 about the Mojo compiler being unavailable as source no longer holds, while claims about other parts of the stack need checking against the current component list rather than assuming everything is now public. The list in the README is the reference for what you can build yourself.

MAX and Mojo ship together on one release line

Releases are tagged under max/ and pair a MAX version with a Mojo version. max/v26.5.0, published on 11 August 2026, was MAX 26.5 with Mojo 1.0.0. max/v26.6.0 on 17 September 2026 carried MAX 26.6 and Mojo 1.1.0, and max/v26.7.0 on 22 October 2026 carried MAX 26.7 and Mojo 1.2.0. That is roughly one release a month, with the Mojo minor version moving in step with MAX.

If you pin a toolchain, pin the pair. A Mojo version number tells you which MAX release it came with, and the tag name only mentions MAX, so searching the releases page for a Mojo version means reading the release titles. The Mojo 1.0.0 release and the arrival of the compiler source in /Mojo both date from August 2026.

The pace also matters for anyone following along from source: main received a push on 2 November 2026, after the 22 October release, so a checkout from main can be ahead of the latest tagged release, and reproducing a reported bug means checking out the matching max/ tag first.

The serve and pipelines layer is Python with vendored pieces

Above the kernels sits a Python layer. /max/python/max is the AI framework for authoring models in Python, /max/python/max/pipelines holds models built on that framework, and /max/python/max/serve is the inference server, which exposes an OpenAI-compatible endpoint. All three have been public since May 2025, except the framework itself, which followed in November 2025.

The root pyproject.toml shows how some of this code is maintained. Ruff excludes several files that are vendored verbatim and kept unformatted so a future re-vendor diffs cleanly: three files under max/python/max/_xgrammar copied from xgrammar v0.2.2, and an encoding file under pipelines/architectures/deepseekV4 taken from the DeepSeek-V4-Flash-0731 checkpoint. The OpenAI schema module in max/serve/schemas/openai.py is generated, and generated protobuf stubs are excluded as well.

For contributors, the formatting rules are strict and shared: black is configured to format .mojo files at a line length of 80, and ruff uses the same 80 column limit with a comment that the two must match. Patches touching vendored files should leave them as they are, since reformatting them defeats the reason they are excluded.

Contributions are accepted by area, with an AI tool policy at the root

Both halves of the platform take outside contributions, but through different guides. Mojo contributions follow the contributor guide on mojolang.org, and MAX contributions follow max/docs/contributing/README.md in the repository. Each side also publishes a list of contribution areas that says which kinds of changes are accepted where, so read the relevant one before writing a patch against a component that may not take outside changes. Bug reports go through the GitHub issue chooser at github.com/modular/modular/issues/new/choose.

The root contains CONTRIBUTING.md, CODE_OF_CONDUCT.md and AI_TOOL_POLICY.md, plus AGENTS.md and CLAUDE.md for coding agents working in the tree, and the ruff configuration excludes .agents and .claude directories as machine-authored agent state that is not shipped product code. Anyone using an AI assistant to prepare a contribution should read AI_TOOL_POLICY.md before opening a pull request. Pre-commit, clang-format, clang-tidy, shellcheck and buildifier configuration files are also checked in, so local checks can match what the repository expects.

Editorial conclusion

Use modular/modular if you want to read or change the Mojo compiler, the standard library, the MAX kernels or the Python model pipelines, file a precise bug, or contribute; it is built for that and it moves quickly, with three MAX and Mojo releases between August and October 2026. If you only want to write Mojo or serve a model with MAX, start from the MAX and Mojo get started guides instead of a Bazel build. Before depending on it, check whether your GPU is on the MAX compatibility list, and have someone read Licenses/MAX_LICENSE, because the repository is not under a single license.

Frequently asked questions

Official sources

1. Issues
2. modular/modular on GitHub
3. Project website
4. README
5. Releases