TechScriptsNepal
Blog

Mistral Large 4 is open-weight, but 'open' comes with a hosting clause

TechScripts Nepal · Kathmandu · October 30, 2026 · 5 min read

Mistral released the weights of Mistral Large 4, nicknamed "Le Chonk," in late October, after first offering it through its API earlier in the month. It's a 1-trillion-parameter model, and the weights are on Hugging Face for anyone to download. That's a notable moment for open-weight AI. It also comes with a license term that decides whether it's usable for some companies, and Mistral's own announcement doesn't spell that term out.

What was released

From Mistral's announcement and the Hugging Face model card:

  • Size and design. About 1 trillion parameters in a mixture-of-experts design, with a separate vision encoder. It accepts text and images and outputs text, with three reasoning-effort settings (low, medium, and high, which is the default). Mistral says it's fluent in more than 160 languages.
  • Where to get it. Weights are on Hugging Face, with official FP8 and NVFP4 checkpoints plus community quantized versions. The model is also available through Mistral's API and through several partner platforms, including OpenRouter, NVIDIA-hosted endpoints, and Microsoft Foundry.
  • API pricing, as listed by Mistral. $0.70 per million input tokens, $0.07 per million cached input tokens, and $2.10 per million output tokens.

Mistral also publishes benchmark results, including strong coding-agent and security-related scores. Those are the company's own numbers, so treat them as a starting point for your own testing, not as a verdict.

The license, and the part nobody defined

Mistral calls the license the Mistral Ecosystem Open-Weight License and describes it as a modified MIT license. The announcement summarizes the terms this way: you're free to use, modify, fine-tune, and commercialize the model, with one condition. Businesses that operate a model-as-a-service offering must get a separate commercial license from Mistral before using the model commercially.

That one condition is where the real questions are, and the announcement doesn't answer them:

  • "Model-as-a-service" is not defined. The announcement doesn't say where the line sits between building a product that uses the model and selling access to the model itself.
  • The "modified" parts aren't described. The announcement doesn't list how this differs from standard MIT, and the model card says only that there are "limitations for model-as-a-service offerings."
  • No thresholds or attribution rules are stated in the announcement. That may mean there are none, or it may mean they're in the license text.

We were not able to review the full license text while preparing this, so the points above reflect what Mistral's own announcement and the model card say, not the legal document. If you're deciding whether to build on this model, read the license itself.

How the ambiguity plays out

Using the plain reading of Mistral's summary, here is how different uses would likely fall. These are not legal conclusions.

  • Running it internally for your own staff or your own product features: this looks like ordinary commercial use, and it's the case the license appears designed to allow.
  • Fine-tuning it for your own products: likewise permitted according to the announcement.
  • Selling API access to the model, or to a lightly wrapped version of it: this is the case the model-as-a-service condition appears aimed at, and it would need a separate deal.
  • Building a product where AI is one feature among many: probably fine, but the exact boundary isn't defined, so it's the case most worth confirming in writing.

If your business model is anywhere near the middle of that list, ask Mistral or your lawyer before you commit engineering time.

Can you even run it?

A trillion-parameter model is not a laptop project. The model card says the NVFP4 checkpoint needs NVIDIA Blackwell GPUs for the vLLM serving route, and reported setups include a single high-memory Apple Silicon machine running a heavily compressed 2-bit version, four workstation-class GPUs, and an eight-GPU datacenter configuration. Minimum requirements for the full FP8 weights aren't stated.

The model card also has a couple of inconsistencies worth knowing about. It gives the active parameter count as 49 billion while the repository name says 52, and it describes a 1-million-token context window while its serving examples use 131,000. Check the numbers that matter to your use case rather than relying on the headline.

Self-hosting versus the API

For most companies, the practical question isn't whether the weights are available. It's whether hosting them yourself beats paying per token. A fair comparison looks at:

  1. Volume. Self-hosting has large fixed costs, and it only wins when usage is high and steady.
  2. Data control. If prompts contain regulated or sensitive data that can't leave your environment, self-hosting may be a requirement rather than a preference.
  3. Operations. Running a model of this size means GPUs, serving infrastructure, monitoring, and someone on call. Count that cost honestly.
  4. Capacity. As we described in our post on the data center capacity crunch, compute isn't always available when you want it, and that applies to leasing GPUs too.
  5. Fit. A smaller model that you can run cheaply may do the job. Test before assuming the biggest model is the right one.

Why this decision is worth getting help with

The expensive mistakes here come early and look cheap at the time. A team picks the biggest model because it tops a leaderboard, or commits to self-hosting without pricing the GPUs and the person on call, or builds on a license term nobody read closely. Each is a few days of checking that saves months later, and few small teams have someone who has run these comparisons before.

That comparison is a normal piece of work for us at TechScripts Nepal. We test candidate models against your real tasks, price self-hosting against an API at your expected volume, list the license questions your lawyer should answer, and then build and hand over whatever you choose, including training for the team that will own it (how an embedded engineer fits in). If you're weighing this now, tell us what you're building.