The Open-Model Race has Split Four Ways
Why “open” now means four different engineering trade-offs, not one model category

- Open-weight AI models now optimize for four distinct outcomes—deep transparency, hardware efficiency, modular specialization, or raw frontier capability—making "open" an inadequate descriptor for choosing what to build on.
- A model release can expose any combination of six layers (weights, license, architecture, training code, training data, and logs/checkpoints), and two models can both claim to be "open" while revealing completely different information.
- Efficiency-first models use mixture-of-experts designs to reduce compute per token, but active parameter count and memory footprint are separate properties that rarely move together, meaning low compute cost does not equal small hardware requirements.
- Frontier-first releases like Kimi K3 (2.8T parameters) and DeepSeek V4 Pro (1.6T parameters) match closed-model capability but are practically undeployable on standard hardware despite being freely downloadable.
- Aggregate benchmark leaderboards collapse four incompatible goals into one number; the correct selection process is to start from the task, then verify license terms, real hardware fit, benchmark conditions, operational maintainability, and upgrade path before committing to any release.
We are no longer moving toward one universally "best" open model. Labs now optimize for four different outcomes: deep transparency, hardware efficiency, modular specialization, or raw frontier capability.
That distinction matters because it changes what you should build on. A model tuned for reproducibility solves a different problem than one built for single-box deployment, and confusing the two costs real engineering time.
Recent releases make the split clear.
Moonshot released the weights for Kimi K3, a 2.8-trillion-parameter model with a million-token context window.

Around the same time more than 80 companies (like Google, Nvidia, GitHub) signed an open letter "Open Weights and American AI Leadership." Nvidia CEO Jensen Huang wrote in sharing it that the world needs both frontier closed models and frontier open models. The letter ties open weights to access, competition, and user control.
But each of those benefits depends on a different part of the release.
Consider what "open" is actually doing here. A model can be built to be reproduced by researchers or it can be built to top a benchmark. Both models are shipped for different reasons but both arrive under an "open" label.
The more accurate picture is that open-model labs now optimize for four different outcomes, and each release is mostly a bet on one.
Some projects publish the full training pipeline so others can inspect and reproduce it. Some squeeze maximum capability into the tightest hardware budget. Some ship the model as swappable parts rather than one fixed endpoint. Others release the strongest checkpoint they can, even when few teams can host it.
These approaches aren't rigid, and a few models sit in two at once, but the outcome a release emphasizes tells you far more than the license attached to it.
A weight file cannot tell you what kind of open model you have
The word "open" has quietly stopped describing a license and started describing a stack. A modern release can expose any combination of six layers, and where a project draws the line is the whole story.

At the shallowest layer are the weights you download and run. Above that sits the license, which governs what you're allowed to do with them. An MIT model and a "community license" model can ship identical weights and grant very different freedoms.
Then comes the architecture and inference code, the definition of how the model is wired, and the training code and recipes needed to rebuild the model rather than merely execute it.
Below that is the training data that determines what the model learned, and at the deepest layer the checkpoints, logs, and evaluations that let someone trace how the final model came to behave as it does.
Two releases can both call themselves open while exposing completely different layers.
One might publish only weights and a license; another the full data and recipe behind a weaker model. Neither fact appears in a benchmark score.
This is why the four approaches are worth separating, each places most of its value in a different layer. Transparency-first releases invest in the deepest layers; efficiency-first in architecture and inference; specialization-first in composition. Frontier-first releases put most of their value in the checkpoint's capability, even when the surrounding training process stays closed.