Bottom line up front
The open-weight models released through 2026 converge on a shape rather than a size. They are sparse mixture-of-experts models where a small fraction of a very large parameter pool is active per token, they ship with context windows of a million tokens or close to it, they are trained and documented for agent and tool use rather than chat, and they are released under permissive licences - MIT or OpenMDW - with optimised checkpoints for named hardware. The practical consequence is that self-hosting is now a licence-and-hardware question rather than a permission question, and the hardware question has a published answer for each model.
Sparse mixture-of-experts is now the default shape
Read the model cards of the open releases through 2026 and a consistent shape appears. A mobile-family model with roughly 309 billion total parameters and 15 billion active. A search-and-agent model reported at roughly 753 billion total and 40 billion active. A reasoning model at 550 billion total and 55 billion active. A coding model at 600 billion total and 27 billion active. A cost-efficient tier at 552 billion total with 8 billion active on input and 16 billion on output.
The pattern is deliberate: total parameters set the capability ceiling while active parameters set the compute bill. Analysts describe the shift as one from scale to efficiency, with sparse designs plus long context becoming the standard combination rather than an exception. For anyone estimating cost, the useful number is the active one, and it is published.
- Record total and active parameters separately for each candidate.
- Use active parameters as the cost signal.
- Note that a larger total-parameter model is not necessarily more expensive per token.
Training and documentation aim at agents
The second convergence is in what the models are built for. One reasoning model's card documents configurable inference-time reasoning budget and multi-token prediction for speculative decoding. A coding model ships two thinking levels and documents tool calling and structured output. A hybrid model is described as trained for agent harnesses, with the stated aim of more accurate tool calls and lower latency for high-volume tasks.
The documentation follows the training. Where earlier open releases documented chat capability, current ones document tool use, structured output, context length, and completion limits as first-class properties. That shift matters when you are evaluating, because the properties you need are now part of the published record rather than something you have to discover by testing.
- Check the model card for tool calling and structured output, not just chat capability.
- Record the documented completion limit alongside the context window.
- Note which runtimes the developer lists as supported, as that constrains self-hosting.
Permissive licences, but not one licence
The licence picture is permissive but not uniform. Several major 2026 releases ship under MIT, which permits commercial use, modification, and redistribution with attribution. NVIDIA's family ships under OpenMDW-1.1, which the developer states permits commercial use but which is a different document with different terms. A licence summary on a model card is not the licence.
This is the part of self-hosting that is settled and cheap to check, which makes it odd that it is so often skipped. Read the licence for the exact checkpoint you intend to run, record the version and the date you checked it, and where the commercial answer matters, take it to a qualified adviser.
- Read the licence for the specific checkpoint, not the model card's summary of it.
- Record the model version, licence, and the date you checked.
- Keep the hosted endpoint's API terms separate from the weights' licence.
The hardware question now has a published answer
The reason open weights stopped being a theoretical option is that each release now comes with a deployment story. One vendor lists a minimum of eight H100-class GPUs for its frontier model. Another publishes five checkpoints including a quantised build for inference and two draft-model variants for speculative decoding, with named target hardware. A third publishes a quantised build and a GGUF build and documents that the default context scales with available VRAM.
That turns self-hosting from a research project into a capacity check: read the documented minimum, compare it to what you operate, and decide. For teams already running the hardware, the answer is often yes. For everyone else, the published figure is the honest end of the conversation, and the hosted endpoint is the access route rather than a compromise.
- Read the documented hardware minimum before planning any deployment.
- Check which checkpoint is recommended for inference rather than for further training.
- Compare the minimum against hardware you operate, not hardware you could buy.