Open Weights, Licensed Hosting: Auditing Mistral Large 4's Terms for Commercial API Builders

Coverage of the Mistral Large 4 release landed across 29–30 October 2026 and converged quickly on the same shape: a 1T-parameter model, downloadable weights, coding performance described as equivalent to a closed frontier model, and a licensing caveat — hosts need a licence. This post works through that caveat from the perspective of someone shipping a commercial API: which rights the open weights actually grant you, how to audit the terms yourself in about fifteen minutes, and what to record so the answer is still checkable when the next revision lands.

That last clause is the whole story. Everything before it is a download. Everything after it is an architecture decision.

If you build products on top of large models for a living, "the weights are free" is not a fact about your project. It is a fact about a file on a CDN. Legality turns on a much narrower set of clauses: may you run the weights, redistribute them, serve them to third parties, relicense a derivative. Four separate grants. A release can hand you one of them, three, or all four.

The position I'd defend: treat an open-weights release as a distribution decision, not a permission slip. Pull the licence artifacts before you write integration code, not after, and assume the hosting-resale right is the one you don't have until the text says otherwise in plain language.

What the Mistral Large 4 coverage establishes about the licence — and what it doesn't

The source material here is four secondary pieces published over two days. That's enough to establish that a release happened and roughly what's in it. It is not enough to establish terms — and the terms are the part that governs your build.

Confirmed in the coverage

Mistral released weights for a model called Mistral Large 4, described in the coverage as a 1T-parameter model.
The weights went up on Hugging Face; one headline calls the release "Mistral Large 4 Le Chonk."
Several pieces state that hosting providers need a licence — the framing that complicates the "open" label.
The release is described as free of charge, with coding performance said to rival a closed model referred to as GPT-6.1 Terra.

That's the extent of what I can state plainly. Note what isn't on the list: the licence name, the hosting clause itself, the parameter architecture, benchmark numbers, a link to primary text.

⚠️

None of the four pieces reproduces the licence text, and I have not read it. Anything below that reads like a description of Mistral Large 4's actual terms is arithmetic, a general principle of model licensing, or explicitly marked as inference. Verify it against the licence file in the repository before you rely on it.

Unconfirmed or secondhand licence claims

"Free of charge" is a pricing statement, not a rights statement. Coverage calling the release free and coverage saying hosts need a licence don't conflict — they describe two different things. Don't let the first one overwrite the second.
"Coding performance equivalent to GPT-6.1 Terra" is a parity claim sourced to aggregators, which puts it at least two hops from a reproducible evaluation. Parity claims are the easiest thing in this industry to launder through a headline. Treat it as a hypothesis with a test attached, not a spec.
The scope of the hosting clause is unknown. "Hosting providers need a licence" doesn't say whether a single-tenant deployment for one named customer counts, whether internal-only use counts, or whether the trigger is revenue, tenancy, or public availability. Those questions decide your architecture, and the material doesn't answer them.
Whether earlier Mistral weight releases used the same terms. They haven't been uniformly permissive — some shipped under Apache 2.0, others under research-only terms — so precedent from an earlier model is not a safe reading of this one.

Why the licence-versus-pricing distinction decides the build

Because the failure mode isn't "someone read the licence and disagreed with it." The failure mode is a team saying "the weights are open, we can host it" in a planning meeting, building a multi-tenant serving layer over six weeks, and finding out on legal review that the one clause they needed was the one they skipped.

The rest of this post is the audit that prevents that, plus the controls that make the answer checkable a year from now, after the person who read the licence has moved on.

Open weights are not open source: the four grants that decide your architecture

The Open Source Initiative's Open Source AI Definition exists precisely because "downloadable weights" and "open source" kept getting conflated. In the OSI framing the freedoms attach to use, study, modify, and share — and a release can restrict any of them while still publishing a very large file.

For engineering purposes, split the grant into four questions. They're independent, and you need a specific answer to each before you design a serving layer around the model.

Grant 1: the right to run the weights

The cheapest grant, and the one almost every release gives you. Running weights on hardware you control, for internal purposes, is usually permitted — sometimes restricted to non-commercial or research use. Check whether the grant is conditioned on purpose (research only, non-commercial only) or on scale (below a revenue or user threshold). Purpose conditions are the ones that quietly break a startup the month it starts charging.

Grant 2: the right to redistribute weights or derivatives

Separate from running. Redistribution covers shipping weights inside a container image, mirroring them to your own artifact registry, bundling them in an on-prem appliance, or dropping them into a customer's cloud account. Plenty of licences that allow internal use bolt attribution and notice-preservation requirements onto redistribution — which puts your Dockerfile and your release process in scope, not just your inference server.

Grant 3: the right to serve the model to third parties

The load-bearing clause, and the one the reporting flags. "Third party" is doing a lot of work in that sentence. A hosted-API licence typically triggers on serving model outputs to people outside your legal entity, and it's often the clause that turns a permissively-licensed model into a commercial one. More on this below.

Grant 4: the right to relicense a fine-tune or derivative

The most commonly misread. A permissive licence on the base weights does not automatically give you permissive terms on your derivative — it gives you the right to create one, under conditions the base licence sets. If those conditions include notice requirements, naming restrictions, or a copyleft-style "same terms" obligation, you cannot unilaterally relicense your fine-tune as MIT and put it on a marketplace.

A way to hold it in your head:

Grant	What breaks without it	Where teams get surprised
Run	Nothing works	Research-only purpose limits
Redistribute	On-prem appliance, mirrors, CI images	Notice and attribution obligations
Serve third parties	Any multi-tenant API product	Definition of "third party"
Relicense derivative	Fine-tune marketplaces, open-weight spin-offs	Derivative terms inherit conditions

Collecting the licence artifacts before you write a line of integration code

Licence review isn't a legal-only activity and it doesn't belong at the end of the project. It's artifact collection, and it should happen in the first hour of evaluation, next to reading the model card.

The four files to pull from the model repository

Pulled at a pinned revision:

LICENSE (or LICENSE.md, LICENSE.txt) — the operative text. Everything else is commentary.
README.md — the model card, which on Hugging Face carries YAML frontmatter including a license field.
config.json — architecture metadata: layer count, hidden size, attention head configuration. You need this for the memory math later.
*.safetensors.index.json if present — the real shard count and total size, which is the difference between "1T parameters" as a headline and "1T parameters" as a bill.

Reading the model card as a contract of representations

A model card is not a licence, but it is a representation the publisher made on a date. Two things matter. The frontmatter license field is machine-readable metadata your registry should ingest — but it's a claim, not the terms, and it can be stale or wrong. If frontmatter says one thing and LICENSE says another, LICENSE wins, and you should log the discrepancy.

The card's prose often carries restrictions that never appear in the licence file: acceptable-use policies, prohibited-use lists, required disclosures for downstream deployments. Whether those bind contractually depends on whether the licence incorporates them by reference. That's a legal question; the engineering consequence is simple enough. Archive the card too, because an acceptable-use policy can change between revisions and your audit needs to reflect what you actually relied on.

Pinning the commit and archiving what you audited

An audit that references "the repo" instead of a revision is worthless. Pin to a commit SHA, store the four artifacts, record the date. Mechanics below.

A repeatable audit pass: commands and what their output tells you

Fifteen minutes, run once per model, re-run whenever the revision changes. Set REPO to the actual repository id from the vendor's Hugging Face organisation page — not one copied out of a news article.

Fetching LICENSE, README, and config metadata

REPO="<org>/<repo>"   # confirm from the vendor's HF org page, not from coverage
REV="main"

hf download "$REPO" \
  --revision "$REV" \
  --include "LICENSE*" "README.md" "config.json" "*index.json" \
  --local-dir "./audit/$REPO"

Older tooling: huggingface-cli download takes the same flags. Authenticate with a read token — some repositories are gated, and a gated repo is itself a signal that the publisher wants an attributable download.

Then read the frontmatter without opening an editor:

README="./audit/$REPO/README.md"

python - "$README" <<'PY'


text = pathlib.Path(sys.argv[1]).read_text(encoding="utf-8")
fm = text.split("---", 2)[1]
meta = yaml.safe_load(fm)
print(json.dumps({k: meta.get(k) for k in
      ("license", "license_name", "license_link", "gated")}, indent=2))
PY

The output shape is small and boring:

{
  "license": "other",
  "license_name": "…",
  "license_link": "…",
  "gated": null
}

license: "other" is the interesting value. It means the licence isn't a recognised SPDX identifier and the operative text lives entirely in the LICENSE file. In practice every custom model licence shows up this way. A recognised identifier like apache-2.0 is a strong signal; a custom name is a signal to keep reading.

Recording a hash and a date so the audit is reproducible

cd "audit/$REPO"
git rev-parse HEAD 2>/dev/null || echo "not a git clone — use the HF API revision"
sha256sum LICENSE* README.md config.json 2>/dev/null | tee SHA256SUMS
date -u +"%Y-%m-%dT%H:%M:%SZ" | tee AUDITED_AT

If you downloaded rather than cloned, pull the revision from the Hub API:

curl -sS "https://huggingface.co/api/models/$REPO" \
  | jq -r '.sha, .cardData.license, .siblings[].rfilename' | head -20

Commit SHA256SUMS, AUDITED_AT, and the revision SHA into your own repository next to the licence text. Not paranoia: in fourteen months, "we checked the licence" is unfalsifiable. A hash plus a date isn't.

Reading the result: the clause classes to look for

Read the LICENSE file for clause classes, not vibes. Five minutes per class:

Scope and definitions. Who is a "user", what is a "derivative", what is "commercial use". Definitions decide the edge cases; the operative clauses rarely do.
Grant of rights. Which of the four grants are actually enumerated. Silence is not a grant.
Conditions. Attribution, notice preservation, naming restrictions, acceptable-use incorporation, volume or revenue thresholds.
Reservation of rights. Language like "all rights not expressly granted are reserved" means anything unlisted is withheld.
Termination and change. Whether the publisher can alter terms on a new revision, and whether your existing deployment is grandfathered. This clause decides whether your archived hash is a shield or a snapshot of a deal that no longer exists.

The hosting clause is the load-bearing licensing term

Everything above is standard licence hygiene. The hosting clause is where this release diverges from a permissive drop, and where the engineering consequences get large.

Where the boundary sits between internal use and service to third parties

The useful mental model is a trust boundary, not a revenue boundary. Ask: does a person outside my legal entity receive model outputs through infrastructure I operate?

Employee using an internal chat tool → no third party. Internal.
Customer using a product feature where the model is a component → third party, in almost every reading.
Your own team running evals against your own weights → internal.
A contractor inside your Slack → depends on your definitions, and you should not be the one deciding.

The trap is that teams hear "hosting providers need a licence" and picture Together, Fireworks, and the hyperscalers. It probably does target them — but this clause class is usually written around the act of serving, not the size of the server, and your 40-customer SaaS is serving.

That's inference, not a reading of Mistral's text. It is also how this clause class is normally drafted, and it's the assumption to hold until the actual words say otherwise.

The gray zones: customer-dedicated deployments, VPC installs, and fine-tune marketplaces

Three shapes that fall between the obvious categories. Escalate these; don't guess.

Customer-dedicated deployment. One inference stack in one customer's cloud account, they pay you, only they use it. Is that hosting for a third party? Arguably yes — you are operating a service for a third party, tenancy of one notwithstanding. Single-tenant does not mean internal.

VPC install. You deploy into a customer's VPC and hand over the keys; you operate nothing. This sits closer to redistribution than to hosting, which means a different grant applies. You can satisfy one clause and violate the other in the same deployment.

Fine-tune marketplace. You publish a fine-tune of the base weights on a hub. That's redistribution and derivative relicensing at once, and it's the shape most likely to break a custom licence — the conditions attach to the derivative, and a marketplace listing is an assertion that you can relicense it.

Questions to send the vendor in writing

Email is cheap and the answer is an artifact. Ask, in this order:

Does serving model outputs to customers through our own API constitute "hosting" under the licence, and if so what licence applies?
Is a single-tenant deployment in a customer-controlled cloud account treated as internal use or as a service to a third party?
May we redistribute the weights, or a quantised build, inside a container image delivered to a customer's environment? With what notices?
May we publish a fine-tune, and under what terms may we license it?
Do the terms attach to the revision we downloaded, or can they change on a later revision?
What is the acceptable-use policy, and is it incorporated into the licence by reference?

If the answers come back as "read the licence," that's an answer too, and it tells you the vendor hasn't operationalised the clause either.

Five deployment shapes and their licence posture

Same model, five architectures, five different compliance questions. This is the table to paste into a design doc.

Shape	Grants exercised	Risk	What to do first
Internal research cluster	Run	Low	Confirm no research-only clause blocks production later
Single-tenant for one named customer	Run + serve	Medium	Written confirmation of internal-vs-hosted classification
Public multi-tenant API	Run + serve	High	Hosting licence or explicit permission
Wrap the vendor's hosted endpoint	Vendor API terms only	Medium	Read the API terms, not the weights licence
Redistribute a fine-tune	Run + redistribute + relicense	High	Derivative and notice clauses, plus marketplace terms

Internal research cluster

The easy one. Confirm the run grant isn't conditioned on non-commercial purpose, and that your organisation's definition of "internal" matches the licence's. Cheap to verify. Also cheap to get wrong the day the prototype becomes a product.

Single-tenant deployment for one named customer

The gray zone from the previous section. Low engineering effort, high contractual ambiguity. Get it in writing before the customer signs — retrofitting a licence negotiation into a live contract is how deployments freeze.

Public multi-tenant API

Assume you need the hosting licence until proven otherwise, and budget for it in the business case rather than the post-launch cleanup. If the licence is unavailable or uneconomic, this is the shape where you switch models. That's much cheaper before you have customers.

Wrapping the hosted Mistral endpoint behind your own API

The shape most teams will actually pick, for reasons the next section makes arithmetic. Watch which document governs: the weights licence is largely irrelevant here, and the API terms of service bind. Different documents, different constraints — rate limits, caching and retention rules, attribution requirements, restrictions on building a competing service.

The failure mode is specific. A team reads the licence file, concludes "we're compliant," and never opens the API terms that actually govern the product.

Redistributing a fine-tune

Highest risk. You're exercising three grants at once, and the derivative clause is the one nobody reads. Before publishing, confirm the derivative conditions, preserve every required notice, and check whether the marketplace's own terms stack a second layer of obligation on top.

The 1T-parameter reality check: memory, serving, and licence urgency

Here is where the decision reorders itself. The published coverage gives a parameter count and an architecture-free headline. Everything below is arithmetic on that one number, not a measured footprint — an order-of-magnitude filter, not a capacity plan.

Rough memory and serving math

Weights, at a few precisions:

Precision	Bytes/param (approx)	Weight memory	80 GB H100s for weights alone
BF16	2	~2 TB	~25
FP8 / INT8	1	~1 TB	~13
4-bit	0.5	~500 GB	~7

Three things the table leaves out: KV cache, activations, redundancy.

KV cache scales with batch size × context length × layers × head dimension, and at frontier scale it is not a rounding error — it's tens to hundreds of gigabytes at production concurrency.
Tensor parallelism across nodes needs fast interconnect. A single 8-GPU node gives you 640 GB at 80 GB per card, which does not cover FP8 weights at this size.
Redundancy doubles the "minimum" number if you want to survive a node failure.

So the honest framing: a 1T-parameter model is a multi-node, multi-tenant-cost-class deployment. Two nodes is a floor, not a target, and it assumes the architecture shards cleanly.

💡

The arithmetic above uses only the parameter count. With config.json in hand, replace the estimate with params × bytes_per_param plus a measured KV cache from a smaller proxy model at the same context length. Half a day of work, and closer than any published chart.

What the weight size does to the licence question

It changes which question is urgent.

If self-hosting costs five figures a month in GPU capacity before you serve a single request, then for most teams the weights licence is a procurement document, not an operational one. The API terms bind the product, because the product ships on the vendor's endpoint.

Useful reframing, and also a trap. Model size makes self-hosting unlikely, which makes teams sloppy about the weights licence — and the moment someone proposes an on-prem deal, an appliance, or a fine-tune release, the clause nobody read becomes the clause that governs. Audit it anyway. It's fifteen minutes.

Engineering controls that make compliance auditable, not aspirational

A licence conclusion living in a wiki page is not a control. Three small pieces of engineering turn it into one.

A model registry that carries licence metadata

Every model your systems can load gets a record, and the record is machine-readable:

{
  "model_id": "<org>/<repo>",
  "revision": "<commit-sha>",
  "license_spdx": "NOASSERTION",
  "license_url": "./audit/<org>/<repo>/LICENSE",
  "grants": {
    "run": true,
    "redistribute": "conditional",
    "serve_third_parties": "requires_license",
    "relicense_derivative": "prohibited_pending_review"
  },
  "audited_at": "2026-10-30T00:00:00Z",
  "audited_by": "platform-team",
  "sha256": "<hash-of-license-file>"
}

Two properties matter. The grants are enumerated, so silence can't be mistaken for permission. And the revision is pinned, so an upstream change doesn't silently alter what you audited.

A serving-layer policy gate for resale routes

Put the check where the traffic is, and fail closed.

// license-gate.js — evaluated at deploy time, not per request
const REQUIRED_GRANT = {
  internal: "run",
  single_tenant: "serve_third_parties",
  public_api: "serve_third_parties",
  on_prem_bundle: "redistribute",
  published_finetune: "relicense_derivative",
};

export function assertDeploymentAllowed(record, mode) {
  const grant = REQUIRED_GRANT[mode];
  if (!grant) throw new Error(`unknown deployment mode: ${mode}`);

  const value = record.grants?.[grant];
  if (value !== true) {
    throw new Error(
      `blocked: mode=${mode} requires grant="${grant}", registry has "${value}"`
    );
  }
  if (!record.revision || !record.audited_at) {
    throw new Error("blocked: registry record is missing revision or audit date");
  }
  return true;
}

Running this in CI against the deploy manifest is the difference between a policy and a wish. A requires_license value fails the build, which forces the conversation into planning instead of an incident channel.

Tenant attribution and request logging

If you operate under a hosting licence, your obligations may include reporting or attribution. Design the log line before you need the report: tenant id, model id, revision, route mode, per request. Then the quarterly "how much did we serve, to whom, under which grant" question is a query rather than a reconstruction.

Keep it boring and minimal — tenant id, model revision, mode. Do not log prompts and completions to satisfy a licence obligation. That's a privacy liability bought to solve a bookkeeping problem.

Performance claims deserve the same skepticism as the licence claims

The same reporting that flags the licence caveat also asserts that coding performance rivals a closed frontier model. Both claims deserve the same handling: name the source, check the method, test the part that matters to you.

Benchmark parity with a closed model, sourced to aggregators

The parity claim traces back to secondary reporting, and no evaluation harness, prompt set, or scoring rubric appears anywhere in the material. That doesn't make it false. It makes it unverified, and unverified parity claims have a specific failure profile: they tend to hold on the benchmark and not on your workload, because benchmarks reward the tasks that get published.

There's a structural asymmetry worth naming, too. A closed model's reported numbers and an open model's reported numbers are frequently produced under different scaffolding, different sampling parameters, different tool-use assumptions. "Equivalent" in a headline compares two numbers, not two systems.

How to test the claim yourself, cheaply, before committing

Skip the public benchmark. Run your own, small and executable.

Build 30–50 tasks drawn from your actual codebase: a failing test plus a file, with a known-good fix. Score on tests passing, not on a model-graded rubric. Run it against the hosted endpoint and against whatever you use today, identical prompts, temperature 0.

// eval-lite.js — functional correctness, not vibes
const tasks = loadTasks("./tasks"); // { id, prompt, repo, testCmd }

const results = [];
for (const task of tasks) {
  const out = await callModel(task.prompt, { temperature: 0 });
  const patch = extractPatch(out); // your parser, your problem
  const ok = sandboxApplyAndTest(task, patch); // containerised, no network
  results.push({ id: task.id, ok });
}

const pass = results.filter((r) => r.ok).length / results.length;
console.log(JSON.stringify({ pass, n: results.length }));

Two guardrails, both non-negotiable: run generated code in a network-isolated container, and never point the harness at a repository with real credentials in scope. I haven't run this against Mistral Large 4's endpoint — I don't have access to it — but the harness shape is the same one you'd use for any model comparison, and it takes an afternoon.

What you learn beats the parity headline: a pass rate on your code, a cost per solved task, a latency profile. Any one of those can kill the migration before the licence question comes up.

Decision guide: self-host, hosted API, or pick a different model

In the order that actually resolves:

Can you afford the compute? ~1 TB of weights at FP8 plus KV cache means a multi-node deployment. If the answer is no, self-hosting is off the table and most of this post becomes about API terms.
Does your product serve anyone outside your legal entity? If yes, you need the hosting grant. If the licence doesn't clearly give it, you need a commercial conversation, not a creative reading.
Does your product ship weights, containers, or fine-tunes to customers? That's redistribution and derivative relicensing. Both must be explicit.
Does the model beat your incumbent on your own tasks? Run the harness. A licence you can live with on a model that doesn't help you is still the wrong choice.
Can you re-audit in a year? If the answer is "only if the person who read the licence is still here," the audit isn't finished.

My position: for most commercial teams the right answer is the vendor's hosted API under the API terms, with the weights licence archived and understood for the day an on-prem or fine-tune conversation appears. Self-hosting 1T parameters is a hyperscaler-shaped decision, and the "open weights" label doesn't change the shape. What the label changes is your option — and options are worth having even when you don't exercise them today.

Conclusion

The interesting fact about Mistral Large 4 isn't that 1T parameters shipped under a downloadable licence. It's that the release forces a distinction most teams have managed to avoid: between the weights you can hold and the service you can run.

Four grants decide that, and three of them are invisible in a headline. The hosting grant is the one that bites, and it bites a product team six weeks into a build, not a legal team in a review.

The fix is cheap and unglamorous. Pull four files at a pinned revision. Hash them. Write down which grants you have in a machine-readable record. Gate your deploy modes against that record in CI. Then run your own eval, because a parity claim from aggregator coverage is a hypothesis and you have a test harness.

Open weights are a real option and worth the audit. They are not a permission, and the licence file is not paperwork. It is the architecture.

Introduction