Inkling: Thinking Machines' Open-Weights Model
On 15 July 2026, Thinking Machines Lab — Mira Murati's lab — released Inkling, its first in-house model, as open weights under Apache 2.0. It hit the front page of Hacker News overnight, and the coverage settled into two lazy shapes: "trillion-parameter open model!" and a benchmark table showing it losing.
Both miss the point. Inkling is an unusual release that is deliberately not trying to top the leaderboard, and its most interesting feature — a continuous thinking-effort dial trained into the weights — has been widely mis-described in the first wave of reporting. This page is the practical read.
- Understand what Inkling actually is: a 975B sparse MoE with 41B active, Apache 2.0, 1M context, natively multimodal across text/image/audio/video
- Learn what the thinking-effort dial really is — a continuous float trained via RL, not the discrete low/medium/high enum the API wrappers show you
- See why 'open weights' does not mean 'runs on your machine' — the real VRAM floor is ~600 GB even quantized
- Know why Inkling loses benchmarks on purpose, and the one metric where it wins that nobody put in a headline
The one-sentence version
Inkling is a Mixture-of-Experts transformer with 975B total parameters and 41B active per token, pretrained on 45 trillion tokens of text, images, audio and video, supporting a 1M-token context window, released under Apache 2.0 — positioned not as the best model available, but as the best base to customize.
That last clause is the whole strategy. Thinking Machines says so plainly: Inkling "is not the strongest overall model available today, open or closed." Shipping a model alongside that sentence is not modesty, it's positioning — and it explains every design decision below.
Four things that surprise people
1. The effort dial is a float, and the news got its range wrong
This is the headline feature and it's the most mis-reported detail of the launch. Several outlets described the effort parameter as ranging "0.2 to 0.99," or as a named enum — none | minimal | low | medium | high | xhigh.
The official Tinker documentation says something different. Effort is continuous reasoning-effort conditioning: any float from 0.0 inclusive up to, but not including, 1.0. The default is 0.9. The named levels are just recommended sweep values, not the actual interface:
| Preset | Value |
|---|---|
| none | 0.0 |
| minimal | 0.1 |
| low | 0.2 |
| medium | 0.7 |
| high | 0.9 |
| xhigh | 0.99 |
The 0.2 floor that got reported is simply the low preset — not a limit. Nothing stops you passing 0.45. Note also how non-linear the presets are: the gap from low to medium is 0.5, while high to xhigh is 0.09. The useful resolution is bunched up at the top of the range.
This matters because most people will meet Inkling through an OpenAI-compatible wrapper exposing reasoning_effort="high". That enum is a lossy adapter over a continuous knob. If you're tuning cost against quality, the enum hides most of the dial.
Set effort directly via the Tinker renderer
renderer = TmlV0Renderer(get_tokenizer("thinkingmachines/Inkling"))
messages = [Message(role="user", content="Solve this problem step by step.")]
prompt = renderer.build_generation_prompt(messages, effort=0.9)The same effort argument carries into fine-tuning, which is the part worth pausing on — you can train at a chosen effort level:
Fine-tune at a fixed effort level
model_input, weights = renderer.build_supervised_example( messages_with_assistant_response, effort=0.9, )
2. Effort isn't a prompt trick — it was trained in with a token tax
The reason the dial is continuous is that it wasn't bolted on at inference time. During reinforcement learning, the team set effort by changing the system message and adjusting the per-token cost — literally taxing the model for thinking. The model learned to spend different token budgets on different rollouts, and the dial is the residue of that training.
That's a genuinely different mechanism from "please think step by step, but briefly," and it's why the payoff is real: Thinking Machines reports Inkling matches Nemotron 3 Ultra on Terminal Bench 2.1 while using roughly one-third as many reasoning tokens.
It also explains the caveat the docs are careful to state, which you should take seriously: "Larger values generally encourage more reasoning, but do not guarantee longer responses or higher accuracy on every sample." Effort is a learned tendency, not a guarantee. Turning it to 0.99 and expecting monotonic improvement is a misread of what it is. And higher effort "may require a larger generation budget to avoid truncation" — crank effort without raising max tokens and you'll cut the model off mid-thought.
3. Open weights, but you almost certainly can't run it
"975B parameters, Apache 2.0, weights on Hugging Face" invites an assumption the hardware table demolishes:
| Numeric | Aggregated VRAM floor | Example configuration |
|---|---|---|
| BF16 | at least 2 TB | 8× NVIDIA B300, or 16× NVIDIA H200 |
| NVFP4 (W4A4) | at least 600 GB | 4× NVIDIA B300 |
| NVFP4 (W4A16) | at least 600 GB | 8× NVIDIA H200 |
Even fully quantized to 4-bit, the floor is roughly 600 GB of aggregated VRAM. This is a multi-GPU-cluster model, not a workstation model, and not remotely a laptop model. The 41B active parameters make it cheap to run a token through; they do nothing to reduce what you must hold in memory. All 975B parameters have to be resident, because the router may reach for any of them on any token.
If your interest in open weights is "run it locally," Inkling is the wrong model and running models locally with Ollama is the right page. If your interest is legal freedom to modify and commercialize — Apache 2.0, genuinely permissive — then Inkling qualifies, and you'll rent the GPUs from TogetherAI, Fireworks, Modal, Databricks or Baseten. Those are different reasons to want open weights, and this release serves only the second one.
4. It loses benchmarks on purpose — and wins the one nobody reported
The benchmark table is unflattering, and Thinking Machines published it anyway:
| Benchmark | Inkling | A stronger competitor |
|---|---|---|
| Terminal Bench 2.1 | 63.8% | GLM 5.2: 82.7% |
| SWEBench Verified | 77.6% | Kimi K2.6: 80.2% |
| SimpleQA Verified | 43.9% | DeepSeek V4 Pro: 57.0% |
| FORTRESS Adversarial | 78.0% | Nemotron 3 Ultra: 77.6% |
Three losses, one narrow win. But the interesting result isn't in that table at all — it's calibration. The team trained with reinforcement learning based on proper scoring rules, which reward a model for saying "I'm 70% sure" and being right 70% of the time, rather than for sounding confident. The model was rewarded for estimating its own uncertainty well instead of confidently producing wrong answers, and it shows up on forecasting evaluations like ForecastBench and Prophet Arena.
For anything where a wrong-but-confident answer costs more than a hedged one — triage, research, routing, extraction with a human reviewer downstream — a well-calibrated 44% is worth more than an overconfident 57%. That property doesn't fit in a leaderboard column, which is roughly why nobody led with it.
The architecture, briefly
The pieces worth knowing, beyond the parameter count:
- A 66-layer decoder-only transformer. Each layer holds 256 routed experts plus 2 shared experts, with 6 routed experts active per token. The shared experts always fire — they carry general capability — while the router picks specialists per token.
- A deliberate departure from the near-universal default. The stated reason is better extrapolation to longer sequences, which is how a 1M-token context window is meant to hold up rather than degrade at the tail.
- Sliding-window and global layers mixed at a 5:1 ratio with 8 KV heads, plus short convolutions applied at the attention inputs. Five cheap local layers per one expensive global layer is what makes 1M context affordable.
- Images enter as 40×40 pixel patches through a four-layer hMLP; audio as dMel spectrograms. Both pass through a lightweight embedding layer and are processed jointly with text tokens — one stream, not a bolted-on vision encoder. Output is UTF-8 text only.
- Muon for large matrix weights, Adam for everything else — an unusual choice at this scale, and consistent with the lab's public research interest in optimizer behavior.
What it's for, honestly
Reach for Inkling when:
- You need to own and modify a capable multimodal model. Apache 2.0 plus real multimodality plus first-class fine-tuning support on Tinker is a rare combination. This is the intended use.
- Cost per task matters more than peak score. The effort dial at one-third the reasoning tokens is a real lever, and you can tune it continuously rather than in three steps.
- Calibration matters. If your pipeline can act on "the model isn't sure," this is unusually well-suited.
Don't reach for it when you want the strongest coding agent (the table says GLM 5.2 and Kimi K2.6 beat it), when you want to self-host on your own hardware (see the VRAM floor), or when you want maximum factual recall (SimpleQA 43.9% is not competitive).
One safety note that the model card states directly: Inkling has a residual "occasional tendency to comply with role-play and indirectly framed prompts concerning harmful topics," and the card explicitly recommends layering external moderation — it names Llama Guard — rather than relying on built-in refusals. VentureBeat framed the model's posture as "resistance to censorship"; read the model card's own language as the operative guidance instead, and budget for a moderation layer if you deploy this. The card also lists the usual residual limits: hallucination, imperfect instruction-following, and degraded performance in long multi-turn conversations.
Check yourself
0/4Where it sits next to what you know
If you already read Kimi K2 for Claude users, the shape is familiar — a trillion-ish-parameter sparse MoE with permissive licensing — but the intent differs. Kimi K2 optimizes for long agentic tool chains. Inkling optimizes for being reshaped: multimodal input, a tunable effort budget, and fine-tuning as a first-class path.
For the broader picture, see choosing a model, DeepSeek and Qwen open models for the rest of the open-weights field, and what AI costs across providers for the economics the effort dial is aimed at.
Sources & further reading
- Inkling: Our open-weights model — Thinking Machines Lab's announcement: architecture, training, benchmarks, positioning.
- Inkling model card — license, hardware requirements, known limitations, safety guidance.
- Thinking effort — Tinker docs — the authoritative reference for the effort parameter's range, default, and presets.
- Inkling cookbook — Tinker docs — renderers, multimodal input, fine-tuning entry points.
- tinker-cookbook on GitHub — runnable recipes, including
sample_reasoning.pyfor comparing effort values. - thinkingmachines/inkling on Hugging Face — weights, deployment recipes for SGLang, vLLM, TokenSpeed, Unsloth and Transformers.
- Together AI: Inkling on day 0 — hosted access and the OpenAI-compatible
reasoning_effortsurface. - TechCrunch and VentureBeat — launch coverage and strategic framing.