Inkling: America's Largest Open-Weight Model Ships Apache 2.0

What changed on 15 July

Thinking Machines Lab — the research company founded by former OpenAI chief technology officer Mira Murati — released Inkling on 15 July 2026. It is the lab's first production model and its first open-weights model, trained from scratch rather than adapted from anything that came before. It did not arrive as a preview, a waitlist or a promise of weights to follow: the full weights went up on Hugging Face on day one, under the Apache 2.0 licence, with same-day fine-tuning available on the company's own Tinker platform. The specifications below come from the lab's own announcement post.

• 975 billion total parameters in a mixture-of-experts architecture, with 41 billion active per token.
• One million tokens of context, multimodal, with native reasoning across text, images and audio and a controllable "thinking effort" setting.
• A reasoning model by design — trained with reinforcement learning to produce a chain of thought before it answers, over more than 30 million RL rollouts across two long continuous training runs.
• Apache 2.0 on the weights — not a bespoke community licence, not a revenue-threshold carve-out.
• Trained on 45 trillion tokens of text, images, audio and video, using NVIDIA GB300 NVL72 systems.
• A smaller sibling shipped alongside: Inkling-Small, at 276B total and 12B active parameters — and it is more interesting than a footnote suggests.
• Described as the largest American open-weights model released to date — a regional record, not a global one.

Two details in that list deserve underlining. The training-stability claim is one: 30 million reinforcement-learning rollouts sustained across two long continuous runs is an engineering result as much as a research one, because RL at that duration is notorious for collapsing partway through. The other is the small model, which the lab reports matches or exceeds its far larger sibling on many benchmarks — a claim we return to below, because it changes the affordability question this whole article is about.

What we will not do is quote a benchmark score. We have not seen verified independent evaluation figures for either model, and the lab's own comparisons are first-party claims rather than third-party measurements. What can be assessed today, precisely and without waiting for a leaderboard, is the licence and the hardware envelope. Those two things decide whether the model is usable by your team long before any benchmark does.

Open-weight is not open-source, and the difference is the whole story

The phrase "open-source model" has become a habit in AI coverage, and it is wrong often enough to be worth correcting every time. Open source, as the term is understood in software, means you receive the source — the thing from which the artefact is built — along with the freedom to study, modify and redistribute it. For a language model, the analogue of source is the training data and the training code. Inkling ships neither.

What it ships is the output of a training run: a very large tensor file, plus enough configuration to load and serve it. Apache 2.0 then governs what you may do with that artefact — and Apache 2.0 is generous. But generosity about the artefact is not the same as transparency about its construction. You can run Inkling, fine-tune it, embed it in a commercial product and redistribute your derivative. You cannot reproduce it, cannot audit what it was trained on, and cannot answer a customer or regulator who asks what data shaped a particular behaviour beyond repeating the lab's own summary of 45 trillion tokens across four modalities.

That matters commercially in at least two places. The first is auditability. If your model makes a decision that a client challenges — a rejected application, a mis-summarised medical note, a biased ranking — "we do not know what it was trained on" is a weak position, and no licence fixes it. The second is documentation. Teams selling into the European Union are working through what general-purpose AI documentation expectations mean for downstream deployers, and the general direction of travel is towards being able to describe a model's provenance and training-data characteristics. An open-weight model gives you more to say than a closed API does — you can at least inspect and evaluate the artefact directly — but it does not hand you a training-data account you did not have. Treat the weights as a strong asset and the provenance gap as an open risk you document honestly rather than paper over.

Why Apache 2.0 at frontier scale is the actual news

Most open-weight releases at this size have arrived under bespoke licences written by the lab that trained the model. These vary enormously — some are near-permissive, some attach conditions — and the common feature is that each one is a new document your legal team has to read from scratch. Apache 2.0 is the opposite: a licence that has been in the world since 2004, that your organisation almost certainly already depends on somewhere in its dependency tree, and that a lawyer can clear in an afternoon because they have cleared it before.

Concretely, here is what a permissive licence buys you that a bespoke community licence may not:

• Commercial use with no threshold. No monthly-active-user ceiling above which your rights change, no revenue trigger, no separate agreement required if the product succeeds. For a startup, this removes a genuinely awkward planning problem: you are not building on terms that get worse precisely when things go well.
• No acceptable-use annex that can drift. Bespoke licences often reference a policy document that the licensor may revise. Apache 2.0 has no such attachment. What you agreed to is what stays agreed.
• Redistribution of derivatives. You may fine-tune, quantise, distil into a smaller student and ship the result — including to customers, including as part of an on-premises deployment on their hardware. That single freedom is what makes a regulated-sector product buildable.
• No reporting obligations. No per-seat counts, no usage disclosures, no attribution requirement on your product surface beyond the standard notice file.
• An explicit patent grant. Apache 2.0 includes one; many bespoke model licences are silent on patents, which is a gap your counsel will notice.

None of this is exotic. It is simply the difference between adopting a well-understood legal instrument and adopting a novel one. At 975 billion parameters, that ordinariness is the surprise.

The small model is the story inside the story

Buried under the 975-billion-parameter headline is the finding that should actually change what you deploy. Thinking Machines Lab reports that Inkling-Small — 276 billion total parameters, 12 billion active — matches or exceeds its far larger sibling on many benchmarks. The lab attributes this to improvements in the pre-training data and recipe used for the smaller model, rather than to any architectural trick.

State the provenance plainly: this is the lab's own claim about its own models, not an independent evaluation, and we have no third-party figures to corroborate it. Treat it as a hypothesis to test rather than a settled result. But it is a hypothesis worth testing urgently, because if it survives contact with your evaluation set, the economics of this release invert completely.

Consider what the two models ask of you. The 975B model needs more than two terabytes of GPU memory at native precision — roughly eight NVIDIA B300 accelerators or sixteen H200s, which is a procurement project. The 276B model with 12 billion active parameters sits in a different universe of cost entirely: a small multi-GPU node rather than a cluster, and an active-parameter count low enough that per-token latency is genuinely comfortable for interactive products. Same licence, same one-million-token context, same day of release. If the capability gap is as narrow as the lab suggests on the tasks you care about, serving the large model would be paying an order of magnitude more for a difference your users cannot perceive.

This is also a useful corrective to how open-weight releases get read. The instinct is to treat the biggest number as the product and the smaller sibling as a consolation prize for teams who cannot afford the real thing. That instinct has been wrong more than once, and it is expensive when it is wrong. The disciplined move is to benchmark the small model first, on your own tasks, and make the large model justify its memory bill against a real baseline rather than against nothing.

How Inkling sits against the current open-weight field

Inkling did not land in isolation. July 2026 has been the busiest month for open weights on record, and the useful comparison is not "which model is best" — nobody can answer that for your workload from a table — but which combination of scale, sparsity and licence terms fits the constraints you actually have.

Two readings of that table are worth holding at once. Inkling is the largest American open-weights release to date — a meaningful marker for teams with procurement rules or customer expectations that favour a US-headquartered lab. It is not the largest open-weight release overall: Kimi K3's weights, scheduled to publish on Hugging Face at 00:00 UTC on 27 July 2026, take that title. Mistral, as we reported, has confirmed a new open-weight model entering early access in July 2026 with research, government and industry partners, but has not disclosed parameter count, benchmarks or licence terms, so it sits in the table as a placeholder rather than a comparison.

The precision detail in the Kimi row is not trivia, and it sets up the next section. Moonshot shipped K3 at roughly 1.4 terabytes using MXFP4 four-bit weights, against roughly 5.6 terabytes at 16-bit — a four-fold reduction achieved through quantisation-aware training from the supervised fine-tuning stage onward, with MXFP4 weights and MXFP8 activations chosen for broad hardware compatibility. In other words, the largest open-weight model in the world is distributed in a four-bit format by design, not as a community afterthought. That is the clearest signal yet about where this class of model is heading.

The real gate is memory, not compute

More than two terabytes at native precision

Here is the number that decides whether you can use Inkling at all. At native 16-bit precision, the model requires more than two terabytes of GPU memory to hold. Practical configurations cited at release are roughly eight NVIDIA B300 accelerators, or sixteen NVIDIA H200 accelerators. That is a rack-adjacent proposition: a high-density single node at the top end, or a small multi-node cluster.

For a well-funded lab in Cambridge or a GPU-rich enterprise in Hyderabad, that is a procurement conversation. For a twelve-person startup in Pune or Manchester, it is not. Renting that configuration by the hour is possible, but the economics only work if your utilisation is high and steady — an idle eight-GPU B300 node is one of the more expensive ways to hold a file. The honest framing is that native-precision Inkling is not a small-team option, and pretending otherwise wastes a quarter.

# Sketch only — check the model card for the exact repo path,
# revision, and any recommended serving flags before you copy this.

# 1. Pull the weights
hf download <org>/<repo> --local-dir ./inkling

# 2. Serve across eight accelerators with tensor parallelism
vllm serve ./inkling \
  --tensor-parallel-size 8 \
  --max-model-len 1000000 \
  --gpu-memory-utilization 0.92

# 3. For a realistic budget, serve a quantised checkpoint instead
#    and measure quality loss on YOUR eval set, not a public one.

Quantisation is the practical route for almost everyone, and the field has moved far enough that this is no longer a compromise you apologise for. The Kimi K3 contrast makes the point better than any argument: 1.4 terabytes at four-bit against 5.6 terabytes at sixteen-bit, on a model with nearly three times Inkling's parameter count. At this scale, precision is the whole ballgame. Inkling itself shipped at bf16, and we have not seen verified figures for what a four-bit Inkling checkpoint weighs or how it holds up, so we are not going to invent one — but the direction of travel is not ambiguous.

The discipline that matters is measuring what you lose. Quantise, then run your own evaluation set against both the native and the reduced checkpoint, and decide with numbers rather than vibes. Note too that Kimi's approach — quantisation-aware training rather than post-hoc conversion — tends to preserve quality better than quantising a bf16 checkpoint after the fact, which is a reason to be careful about assuming a community four-bit build of Inkling will behave like a first-party one. Our guide to cutting self-hosted serving costs through quantisation, batching and speculation covers the mechanics, and the vLLM production playbook covers the serving side once you have picked a precision.

41B active out of 975B: what sparsity changes, and what it does not

Mixture-of-experts architectures are frequently described as if they make a large model behave like a small one. They do, in exactly one dimension, and it is worth being precise about which.

What sparsity changes. Inkling activates 41 billion parameters per token out of 975 billion total. The compute cost of generating a token — the arithmetic actually performed — scales with the active count, not the total. That means per-token latency and per-token compute economics resemble a 41B dense model far more than a 975B dense one. If you were comparing Inkling against a hypothetical dense model of similar quality, the serving compute would be dramatically cheaper. This is the entire reason frontier labs have converged on sparse designs: capability scales with total parameters, cost scales closer to active ones.

What sparsity does not change. You still have to hold or page the full weight set. Every expert must be reachable, because routing is decided per token and you cannot know in advance which experts a request will need. Two terabytes of memory is two terabytes of memory whether 4% of it is doing arithmetic on any given token or all of it. Expert offloading to CPU memory or NVMe is possible, and it trades a serious latency penalty for a smaller GPU bill; it is a legitimate choice for batch workloads and a poor one for interactive ones.

The practical consequence is that MoE moves your bottleneck from compute to memory capacity and memory bandwidth. If you are sizing a deployment, size it against total parameters and measured throughput on your own traffic shape — never against the active-parameter figure, which describes the arithmetic and not the accommodation. Teams that get this wrong tend to discover it after the hardware has been ordered.

The sovereignty case is now genuinely different

For a large class of teams across India and the UK, the binding constraint on model choice has never been capability. It has been data residency. A healthcare group in Leeds, a public-sector supplier in Delhi, a bank's internal tooling team in either country — all of them have had the same conversation, in which the best available model is a US API and the answer is therefore no.

A permissively licensed, frontier-class base changes the shape of that conversation in a way that was not true a year ago. Apache 2.0 weights can be deployed inside a private VPC, on-premises, or on national compute, with no call leaving the perimeter and no contractual dependency on a foreign vendor's continued goodwill. The model can be fine-tuned on data that could never be sent to a third party. The derivative can be shipped to a customer to run on their own hardware. None of that is possible with an API, and much of it is complicated by a bespoke community licence.

Both markets have been building the compute side of this in parallel. India's IndiaAI Mission has been assembling subsidised GPU capacity aimed precisely at teams that cannot or will not use foreign APIs — our breakdown of the mission's compute pool and what it costs builders is the practical reference. The UK has its own sovereign-model and sovereign-compute programmes pursuing a similar goal through different instruments. Neither is a solved problem, and neither makes an eight-GPU B300 node appear on your desk. But the combination — subsidised domestic compute plus a permissively licensed frontier-class base — is a materially better starting position than the one teams had twelve months ago, when the open-weight tier was both further behind and more legally encumbered.

The caveat is worth stating plainly: sovereignty is an operational commitment, not a licence checkbox. Running your own frontier model means owning the uptime, the security patching, the evaluation regression suite and the capacity planning. That is a real team, not a side project.

What to do this quarter

1. Start with Inkling-Small, not Inkling. At 276B total and 12B active it fits an ordinary GPU budget, carries the same licence posture, and forces you to build the serving and evaluation pipeline you will need regardless. The lab's own claim that it matches or exceeds the 975B model on many benchmarks is untested by anyone else — so test it, on your tasks. If it holds, you have saved an order of magnitude.
2. Clear the licence formally, then use that as leverage. Get Apache 2.0 signed off in writing for model weights specifically. Once it is on the approved list, every future Apache-licensed release is a technical decision rather than a legal one — which is a compounding advantage.
3. Build the eval set before you build the deployment. Fifty to two hundred tasks drawn from your actual product, scored consistently. Without it you cannot judge a quantised checkpoint against a native one, and quantisation is the decision that determines your bill.
4. Price the memory, not the compute. Size against total parameters. Treat the 41B active figure as a statement about latency and arithmetic, never about capacity.
5. Document the provenance gap. Write down, now, that training data and training code are not published, and what that means for any auditability or documentation commitment you make to customers. Doing this early is cheap; doing it under a client's due-diligence questionnaire is not.
6. Fine-tune deliberately, not reflexively. Same-day fine-tuning availability makes it tempting. Establish whether prompting and retrieval get you there first, and if not, follow an eval-driven approach rather than a hopeful one.

The bottom line

Inkling is a significant release for a reason that has almost nothing to do with 975 billion. Thinking Machines Lab shipped a frontier-scale reasoning model on day one, with the weights actually available, under a licence that a small company's solicitor can clear without a bespoke review — and it shipped a smaller sibling alongside that, by the lab's own account, gives up little or nothing on many tasks. That is a good pattern, and it deserves to become the norm rather than the exception.

It is still open-weight and not open-source, the training data and training code remain undisclosed, the memory bill at native precision rules the large model out for most readers of this piece, and every capability claim so far is first-party. Hold all of that alongside the good news. The right posture for a builder in Bengaluru, Bristol or anywhere else is the unglamorous one: clear the licence, download the small model, build the eval harness, measure the quantisation loss on your own tasks, and let evidence rather than a parameter count decide what goes into production.

Primary source: Thinking Machines Lab's Introducing Inkling. Corroborating coverage from MarkTechPost, gHacks, Simon Willison's blog, TechTimes, technology.org and Latent Space. Kimi K3 figures from Moonshot's technical blog. We will update this piece when independent evaluations we can verify are published.