Inkling Architecture Explained: Thinking Machines Lab’s 975B Open-Weights MoE

Most frontier labs ship a model and claim a leaderboard. Thinking Machines Lab shipped one and explicitly said it isn’t the best model available, open or closed. That single sentence in the launch post tells you more about the Inkling architecture than any benchmark row does: this is a model engineered as a substrate for fine-tuning, not a trophy. Released on 15 July 2026 under Apache 2.0, Inkling is a 975-billion-parameter sparse Mixture-of-Experts transformer with 41 billion active parameters, a 1-million-token context window, and native text, image, and audio input. It is the first model Mira Murati’s lab trained from scratch, and its design choices — relative position bias instead of RoPE, short convolutions inside every block, a 5:1 local-to-global attention ratio, and a trained-in thinking-effort dial — depart from the standard large-MoE recipe in ways worth understanding before you commit hardware to it.

What this covers: lineage, layer-by-layer architecture, the training and RL pipeline, the real published benchmark profile with its caveats, deployment cost and VRAM maths, honest limitations, and a decision matrix against GLM-5.2, Kimi K2.6, and DeepSeek V4 Pro.

Context and Background

Thinking Machines Lab was founded in 2025 by Mira Murati, formerly OpenAI’s CTO, and until mid-2026 the company was known for infrastructure and research rather than models. Its public output was Tinker — a managed fine-tuning and post-training platform — plus a research blog covering topics like modular manifolds and deterministic inference, and a preview of an “interaction models” system built around real-time voice and vision collaboration. Inkling is the first artefact that closes the loop: a model the lab trained itself, released with open weights, and made immediately fine-tunable on its own platform.

The competitive context matters. By July 2026 the open-weights tier is crowded and genuinely strong. GLM-5.2 (744B total, ~40B active) leads several agentic and reasoning benchmarks. Kimi K2.6 pushes hard on coding and browsing. DeepSeek V4 Pro remains the reference implementation of the large sparse MoE recipe that most of these models, Inkling included, descend from. NVIDIA’s Nemotron 3 Ultra takes the hybrid Mamba-Transformer route. Against that field, a model that leads almost nothing looks like an odd release — until you notice what it is built to lead on: token efficiency at a given quality level, native multimodal breadth on the input side, safety refusal behaviour, and fine-tunability.

That framing is the thesis of this post. Inkling is best read as a bet that the marginal value of an open-weights model in late 2026 comes from adaptability and cost curve, not peak benchmark score. Every architectural oddity in the model supports that bet. If you want the broader benchmarking context for agentic evaluations referenced throughout, our breakdown of what SWE-bench, GAIA and Tau-bench actually measure covers the methodology traps. The primary source for everything below is the lab’s own Inkling announcement and model card.

Lineage: where Inkling comes from

Inkling has no predecessor. There is no Inkling 1.0 to compare against, no incremental delta to trace, which makes this an unusual “AI model of the day” — the lineage is architectural rather than generational.

The lab is explicit that the MoE design “largely follows DeepSeek-V3.” That inheritance is visible in the specifics: a large pool of fine-grained routed experts, a small number of always-on shared experts, a sigmoid-based router, and auxiliary-loss-free load balancing via a learned bias term. If you have read our DeepSeek V4 architecture deep dive, the skeleton will be familiar. Where Inkling diverges is in attention and in the small structural additions inside each block.

The other half of the lineage is horizontal. Inkling’s post-training was bootstrapped with an SFT pass on synthetic data generated by open-weights models, and the lab names Kimi K2.5 among them. This is worth stating plainly because it is unusually candid: a nearly-1T-parameter frontier-adjacent model used a competitor’s open weights to cold-start its own instruction-following behaviour before large-scale RL took over. The lab notes this bootstrap accounts for only a small fraction of post-training compute. Our Kimi K3 architecture and benchmark analysis covers the K-series lineage that fed into that step.

There is also a sibling. Alongside Inkling the lab previewed Inkling-Small, a 276B-parameter MoE with 12B active parameters trained with a similar recipe but an improved pre-training data mix. Its weights had not been released as of this writing; the lab said it is finishing testing. The preview numbers are striking — Inkling-Small matches or beats the 975B model on HLE with tools (46.6% vs 46.0%), GPQA Diamond (88.3% vs 87.2%), IFBench (83.4% vs 79.8%), and CharXiv RQ with Python (83.4% vs 82.0%). Where it falls off is memorised-knowledge and long-horizon agentic work: SimpleQA Verified drops from 43.9% to 20.9%, Tau 3 Banking from 23.7% to 13.6%, and Terminal-Bench 2.1 from 63.8% to 52.7%. That gap is the clearest published evidence in this release for what the extra ~700B of sparse parameters actually buys — factual recall and sustained agentic competence, not raw reasoning.

Inside the Inkling architecture

The Inkling architecture is a 66-layer decoder-only multimodal transformer with a sparse Mixture-of-Experts feed-forward backbone. Each token is routed to 6 of 256 experts plus 2 shared experts that fire on every token, giving 41B active parameters out of 975B total — a 4.2% activation ratio. Attention alternates sliding-window and global layers at a 5:1 ratio with 8 KV heads, and position is encoded by a learned relative bias rather than RoPE.

Figure 1: One Inkling decoder layer, from embedding through hybrid attention to MoE routing. The stack repeats 66 times.

Reading the diagram top to bottom: every input modality lands in the same embedding space, passes an extra RMSNorm applied directly after the embedding layer, and enters a block where short convolutions sit on the key and value projections. The layer then takes either a 512-token sliding-window attention path or a global path, both reading from a shared learned relative-position bias. Branch outputs get another short convolution before rejoining the residual stream, and the MoE router — sigmoid-gated — sends the token to six routed experts alongside the two shared experts, with all selected scores normalised jointly before their outputs are combined.

Position encoding: the RoPE departure

The most consequential deviation is dropping Rotary Positional Embeddings. Inkling uses a learned, input-dependent relative-position bias in the tradition of Shaw et al. (2018) and the Music Transformer. Instead of rotating queries and keys by a position-dependent angle, the model learns position directly in the attention logits. Hugging Face’s write-up describes a fourth projection alongside query, key and value that produces a per-token, per-head relative feature, which is then modulated by the query-key distance and folded into attention.

Thinking Machines’ justification is short: it “performs better and extrapolates better to longer sequences” than RoPE. The lab did not publish the ablation, so treat the magnitude of the win as unquantified.

Sebastian Raschka’s analysis adds an important structural observation from the released implementation. Of the 66 decoder layers, 55 use local attention with a 512-token window. In the 11 global layers, the learned bias is applied only over the preceding 1,024 tokens; beyond that range, attention is effectively content-based with respect to position. That is close in spirit to NoPE — no positional embeddings — in selected global layers. The architecture therefore gets most of its positional signal cheaply inside small windows, and deliberately declines to impose a positional prior across the full million-token span. That is a coherent story for why a relative scheme extrapolates here where it historically struggled.

Short convolutions and the extra RMSNorm

Two smaller additions are easy to miss and hard to explain from first principles. Each decoder layer applies short kernel-4 1D convolutions in two places: after the key and value projections inside attention, and on the attention and MLP residual-branch outputs before they rejoin the main stream. Hugging Face documents a related SConv operator that reads the current token plus the previous W−1 hidden states, where W is the sliding-window size.

The intuition offered — and it is intuition, not a published ablation — is that these convolutions supply cheap local token mixing and an explicit short-range inductive bias, freeing attention and the MoE from having to reconstruct local structure. In a model where 83% of layers already attend only within a 512-token window, that seems redundant. It probably isn’t: convolution mixes positionally, attention mixes by content, and having both lets the local path specialise.

The second addition is an RMSNorm applied immediately after the token embedding layer, separate from the pre-attention RMSNorm inside every block. It looks near-redundant, but it is explicitly enabled in the released config.json and present in the Transformers implementation. Whether it materially helps would require an ablation nobody has published. My read: with three modalities projected into one hidden space, normalising the embedding output is a stability measure — it prevents an image-patch or audio-bin embedding with a different natural scale from dominating the first block.

Encoder-free multimodality

Inkling does not bolt a vision encoder and an audio encoder onto a text model. Both towers are deliberately thin. Images are cut into 40×40-pixel patches and encoded with a four-layer hierarchical MLP — an hMLP patchifier that progressively merges pixels until each layer produces one embedding per patch. Audio is converted to a mel scale, discretised into dMel spectrogram bins per 100 ms chunk, and embedded through a lightweight audio tower. Both streams are then processed jointly with text tokens by the same decoder.

This is the architectural expression of the interaction-models goal. If the target application is real-time voice-and-vision collaboration, you do not want a heavyweight encoder adding latency and a separate representational bottleneck per modality. You want everything in the decoder’s hidden space as early as possible. The model card specifies the practical envelope: images with each dimension between 40px and 4096px, and 16 kHz WAV audio, ideally under 20 minutes. Image inputs also carry an extra temporal dimension for video, though Hugging Face notes out-of-the-box video performance was not evaluated — a fine-tuning hook rather than a shipped capability.

The trade-off is real. Thin towers mean the decoder does the perceptual work, which likely costs some ceiling versus specialist encoders. Inkling’s MMMU Pro score of 73.5% against Kimi K2.6’s 79.0% is consistent with that, though the comparison is confounded by everything else that differs between the two models.

Sparsity in context

At 41B active from 975B total, Inkling activates 4.2% of its parameters per token. Kimi K2.5 activates 3.2% (32B of 1T). GLM-5.2’s active footprint is roughly identical at ~40B, but from a 744B total — so Inkling carries about 231B more passive parameters for a near-identical per-token compute cost.

That is the shape of the bet. Passive parameters are cheap at inference and expensive at rest: they cost VRAM, not FLOPs. A model with a large passive pool and a modest active footprint is optimised for knowledge capacity per unit of decode compute. The SimpleQA Verified gap against Inkling-Small (43.9% vs 20.9%) is the cleanest evidence that the extra capacity is doing knowledge work. It also explains why Inkling’s deployment story is dominated by memory rather than throughput.

Raschka flags the corollary: with a larger active footprint than Kimi K2.5 and conventional grouped-query attention rather than multi-head latent attention or a recurrent hybrid stack, raw decode speed is unlikely to be Inkling’s advantage. Artificial Analysis measures 72.7 output tokens per second on the first-party API, above the median of 59.2 for comparable open-weights models — respectable, not exceptional, and heavily dependent on quantisation and serving stack.

Training, RL, and the effort dial

Inkling was pretrained on 45 trillion tokens spanning text, images, audio and video, on NVIDIA GB300 NVL72 systems. The optimiser is hybrid: Muon for large matrix weights, Adam for everything else, with hyperparameter schedules derived from the lab’s modular-manifolds research. One specific detail is disclosed — weight decay strength was coupled to the square of the learning rate, which the lab found kept overall weight norms stable across training horizons.

Figure 2: Inkling’s disclosed training pipeline. Note that the RL stage, not SFT, carries the majority of post-training compute.

Post-training is mostly RL

The pipeline inverts the familiar proportions. SFT is a bootstrap — a small fraction of post-training compute, run on synthetic data from open-weights models including Kimi K2.5, purely to get the model into a usable instruction-following basin. The majority of compute goes to large-scale asynchronous reinforcement learning on synthetic and human-created environments, scaled past 30 million rollouts across two long continuous runs.

The published reward curve is one of the more useful artefacts in the release. On a held-out aggregate of reasoning evaluations including AIME, HLE and GPQA, reward rose log-linearly from 0.264 at SFT initialisation to 0.356 at the released checkpoint, with no visible plateau across more than 30M rollouts. Log-linear-with-no-plateau is the claim that matters: it says the lab did not hit a wall, and that further RL compute was still buying reasoning quality when they stopped.

The graders are the interesting part

For epistemics — calibration, instruction following, and censorship resistance — the lab ran RL against two automated graders in combination. A rubric grader scores a response against a checklist of what a good answer should contain. A claims grader verifies each factual claim in the response and penalises claims that don’t check out, performing agentic web search rather than relying on its own knowledge.

The reasoning for pairing them is a genuinely good piece of RL engineering. Rubric graders reward recall and are trivially hackable: a model learns to spray plausibly relevant facts hoping to match rubric items. The claims grader punishes exactly that failure mode. Run together, they push helpfulness and factuality in the same direction instead of trading one against the other — which is normally the hard part of reducing hallucination without inducing over-refusal.

On top of that, the lab added short-form factual QA with abstention-aware rewards: answering only pays off when the model is likely to be right, so the optimal policy is to answer when confident and otherwise say “I don’t know” or hedge. Some prompts explicitly encourage or forbid hedging, teaching the model to follow user preference on forced-guess versus calibrated non-answer. Calibration was also trained directly via RL against proper scoring rules on a corpus of resolved real-world questions.

The published forecasting results reflect this. On ForecastBench Brier Index without search, Inkling scores 61.1 ± 0.79, level with Gemini 3.1 Pro (61.1 ± 0.56), ahead of GPT-5.5 (59.1) and Claude Opus 4.8 (54.6), behind Grok 4.3 (61.7). One caveat the lab states directly: these results were obtained between 30 June and 13 July 2026 on a different checkpoint than the one released. Treat them as indicative, not as measurements of the shipped weights.

How controllable thinking effort was trained

The effort dial is not a decoding trick or a prompt template. During RL, the lab varied the effort level across samples by changing the system message and adjusting the per-token cost in the reward. Rollouts under a high per-token penalty learned to reach the answer in fewer tokens; rollouts under a low penalty learned to think longer. The model internalised the correspondence between the system-message signal and the token budget.

The payoff is a genuine cost-quality curve rather than a single operating point. Sweeping effort from 0.2 to 0.99 traces performance against mean generated tokens on Terminal-Bench 2.1, HLE and IFBench. The headline claim: Inkling matches Nemotron 3 Ultra on Terminal-Bench 2.1 at roughly one third of the tokens. That is the single most economically meaningful number in the release, and it is a curve comparison against competitors plotted at their default operating points — not a like-for-like sweep of every model, so read it as directional. The lab also notes its HLE effort-sweep scores reflect an earlier checkpoint running slightly below final release.

In practice the dial is exposed two ways. Hugging Face transformers takes a reasoning_effort argument with values none, minimal, low, medium, high, xhigh, and max. All published benchmark numbers are at effort 0.99, temperature 1.0, with a 256K max-token trajectory limit on coding evaluations. HF’s own vibe-testing found 0.7 (medium) the best practical trade-off.

One emergent behaviour is worth noting for anyone reading chain-of-thought traces in production. Over the course of RL, Inkling’s reasoning style compressed on its own — dropping articles and connectives, so “we need to understand” becomes “we need determine” — while remaining comprehensible and leaving final answers unaffected. This was not targeted by any reward; efficiency pressure alone drove it. Cognition reported a similar effect training SWE-1.7. If you build tooling that parses reasoning traces, do not assume grammatical English.

Capabilities and benchmarks

Every number in this section comes from Thinking Machines’ published tables or Artificial Analysis. All Inkling scores are at effort 0.99. Where a figure was not published, that is stated rather than estimated.

Figure 3: Inkling’s release-time benchmark profile, sorted by where it leads, matches, and trails the open-weights field.

The honest summary

Inkling leads the compared open-weights field on safety refusal quality, instruction following, and short-form factual reliability. It sits mid-pack on agentic tool use and coding. It clearly trails GLM-5.2 and Kimi K2.6 on hard reasoning and agentic coding.

Benchmark	Inkling	Nemotron 3 Ultra	Kimi K2.6	GLM-5.2	DeepSeek V4 Pro
HLE (text only)	29.7%	26.6%	35.9%	40.1%	35.9%
HLE (with tools)	46.0%	37.4%	54.0%	54.7%	48.2%
AIME 2026	97.1%	94.2%	96.4%	99.2%	96.7%
GPQA Diamond	87.2%	86.7%	91.1%	89.5%	88.8%
SWE-bench Verified	77.6%	70.7%	80.2%	80.0%	80.6%
SWE-bench Pro (Public)	54.3%	46.4%	58.6%	62.1%	55.4%
Terminal-Bench 2.1	63.8%	56.4%	71.3%	82.7%	64%
MCP Atlas	74.1%	44.7%	68.1%	77.8%	73.2%
Tau 3 Banking	23.7%	13.8%	20.6%	26.8%	25.8%
Toolathlon Verified	45.5%	34.3%	58.0%	59.9%	55.9%
SimpleQA Verified	43.9%	32.4%	38.7%	38.1%	57.0%
IFBench	79.8%	81.4%	76.0%	73.3%	76.5%
Global-MMLU-Lite	88.7%	85.6%	88.4%	89.2%	89.3%
FORTRESS (Adversarial)	78.0%	77.6%	65.6%	71.3%	36.0%
StrongREJECT	98.6%	98.7%	99.8%	98.5%	98.6%

Source: Thinking Machines Lab model card, 15 July 2026. Dashes in the original for unreported cells have been omitted here; see the model card for the full grid including closed-weights comparisons.

Two rows deserve emphasis. FORTRESS Adversarial at 78.0% is the highest among the open-weights models compared, and it comes with FORTRESS Benign at 95.9% — meaning Inkling refuses more genuinely harmful requests without over-refusing benign look-alikes. That pairing is the hard part; DeepSeek V4 Pro’s 36.0% adversarial against 98.5% benign shows what an unbalanced model looks like. IFBench at 79.8% beats every open-weights peer except Nemotron 3 Ultra (81.4%), and materially beats GLM-5.2’s 73.3%.

The trailing rows are equally clear. Terminal-Bench 2.1 at 63.8% against GLM-5.2’s 82.7% is a large gap. HLE text-only at 29.7% against 40.1% is larger still. Anyone selecting a model primarily for hard agentic coding should not choose Inkling on these numbers.

Multimodal results

On vision, Inkling scores MMMU Pro (Standard 10) 73.5%, CharXiv RQ 78.1%, and CharXiv RQ with a Python tool 82.0%. Against specialist omni models it leads comfortably — Qwen3-Omni manages 60.0% on MMMU Pro and Nemotron-3 Nano-Omni 53.0% — but trails Kimi K2.6 (79.0%) and Gemini 3.1 Pro (82.0%).

Audio is where the release is most differentiated. Inkling posts Audio MC 56.6%, MMAU 77.2%, and VoiceBench 91.4%. On Audio MC it roughly doubles Qwen3-Omni (24.3%) and Nemotron-3 Nano-Omni (23.2%), and beats Qwen3.5 Omni-Plus (37.6%). Gemini 3.1 Pro still leads all three at 66.8%, 82.5% and 94.3%. Kimi K2.5 and K2.6 have no published scores on these audio benchmarks, so no comparison is possible.

Note the VoiceBench caveat the lab discloses: the benchmark uses rule-based string matching for grading, making it sensitive to output formatting, so a system message enforcing answer format was added. That is a defensible harness choice and also a reason not to over-read small VoiceBench differences.

Artificial Analysis scores Inkling (xhigh) at 41 on the AA Intelligence Index v4.1, ranking #10 of 97 in its comparison class and well above the class average of 25. Its verbosity is above average — 130M output tokens to complete the index, against a 92M median — which is a direct cost consequence of a reasoning model run at its highest effort setting.

On Design Arena’s Agentic Web Dev leaderboard, a blinded human head-to-head evaluation of generated web apps, Inkling scores 1257, tied with Claude Opus 4.6 and ahead of Kimi K2.6 (1249) and GLM 5.1 (1233), but behind GLM-5.2 (1275) and the Claude and Grok leaders. That is a real human-preference signal rather than an automated harness, and it broadly corroborates the “strong but not leading” picture.

Methodology caveats you should carry forward

The lab is unusually transparent about harness details, and they matter. SWE-bench Verified numbers for Inkling use a bash-only harness while external models use self-reported numbers. Terminal-Bench 2.1 uses an internal coding harness, with a small number of solutions found contaminated from web search and assigned a score of 0. For HLE, GPQA Diamond, GDPVal, Tau 3 Banking, AA Omniscience and MMMU Pro, the lab deliberately uses Artificial Analysis’s externally reported scores for both its own and competitors’ models, which improves consistency. CharXiv RQ with Python for Claude Fable 5 and GPT-5.6 Sol was run on the lab’s internal harness.

Raschka’s caution is the right one: some rows combine externally reported values with internal harness results, so small differences should not be over-interpreted. Differences of a few points across harnesses are noise; the 19-point Terminal-Bench gap is not.

Access, deployment, and what it actually costs

Inkling ships under Apache 2.0 — full commercial use, no acceptable-use rider embedded in the licence itself, though the lab publishes a separate model acceptable-use policy. Weights are on Hugging Face as both a BF16 original checkpoint and an NVFP4 checkpoint. Supported numerics are BF16, MXFP8 and NVFP4.

Figure 4: The four practical routes to running Inkling, with the VRAM and pricing constraints attached to each.

Self-hosting maths

The BF16 checkpoint needs at least 2 TB of aggregated VRAM, met by 8× NVIDIA B300 or 16× NVIDIA H200. The NVFP4 checkpoint drops that to at least 600 GB, runnable as W4A4 on 4× B300 — which additionally requires SM100+ architecture — or W4A16 on 8× H200.

Those figures are for weights and activations, before the KV cache. The KV cache is the thing that will surprise you at long context. With 8 KV heads and 55 of 66 layers capped at a 512-token window, Inkling’s cache growth is far better behaved than a fully-global model of this size, but the 11 global layers still scale linearly with sequence length. Both vLLM and SGLang expose the relevant levers: --max-model-len to cap context, and --mem-fraction-static (SGLang) to reserve headroom. If you plan to serve anywhere near 1M tokens, budget the cache explicitly rather than assuming the checkpoint figures cover you.

Software support was day-zero and broad: transformers 5.14.0 (via AutoModelForMultimodalLM and the any-to-any pipeline), SGLang with a custom model implementation, vLLM, TokenSpeed, Unsloth, and llama.cpp. SGLang was described as among the fastest at release. The release also ships MTP drafter layers for speculative decoding — extra layers predicting several tokens at once, acting as drafters at inference for a generation speedup at small VRAM cost, with bit-identical outputs. Enable with use_mtp=True.

For constrained hardware, Unsloth published dynamic GGUF quantisations down to 1-bit, reported to retain roughly 74.2% of top-1% accuracy while being 86% smaller. That is a real number the quantiser published, and it is also a ~26% accuracy loss on that metric — useful for experimentation, not for production quality.

Managed API cost

Artificial Analysis measures the first-party API at $1.87 per million input tokens and $4.68 per million output tokens, with cache write and cache hit both at $0.374 per million (an 80% cache discount). Blended at a 7:2:1 cache-hit/input/output ratio, that is $1.10 per million tokens. Measured throughput is 72.7 output tokens per second with a 1.75-second time to first token.

Be clear-eyed about this: at those rates Inkling ranks #81 of 97 on price in its class, against class medians of $0.60 input and $2.20 output. It is an expensive open-weights model to consume through the first-party API. Third-party endpoints exist on Together AI, Fireworks, Modal, Databricks and Baseten, and their pricing differs — check current rates rather than assuming parity.

The controllable-effort dial is the mitigation. If the one-third-tokens-for-equal-Terminal-Bench-score claim holds on your workload, the effective cost per completed task falls well below what the per-token rate suggests. That is the whole economic argument for this model, and it is testable: run your own task suite at effort 0.4, 0.7 and 0.99 and plot cost per solved task, not cost per token.

Fine-tuning

Inkling is available on Tinker today with context length options of 64K and 256K tokens — notably below the 1M ceiling of the raw weights, a platform constraint rather than a model one. The lab offered a 50% discount for a limited time at launch; check current documentation for live rates. The Tinker cookbook has Inkling-native recipes including three showcasing audio, and tml-renderers handles sampling and post-training with tool calls, reasoning content and multimodal inputs. Hugging Face demonstrated RL post-training with Tinker plus OpenEnv using the ECHO algorithm, and suggests Inkling as a teacher in knowledge-distillation setups — using its document-understanding strength to improve a smaller on-device model via TRL’s GOLD implementation, which matches logits across differing tokenizers.

Trade-offs, gotchas, and what goes wrong

The first and largest gotcha is that Inkling is not a frontier reasoning model and its own authors say so. If your workload is dominated by hard multi-step reasoning or long-horizon agentic coding, the published gaps against GLM-5.2 on Terminal-Bench 2.1 (63.8% vs 82.7%) and HLE text-only (29.7% vs 40.1%) are decisive. Choosing Inkling there because it is newer would be a mistake.

The second is memory economics. A 975B-parameter model with a 41B active footprint is optimised for knowledge-per-FLOP, not bytes-per-FLOP. You pay for all 975B in VRAM whether you use them or not. At 2 TB for BF16, self-hosting is an 8×B300-class commitment; the NVFP4 path at 600 GB is far more accessible but the W4A4 mode requires SM100+ silicon, so an H200 fleet is stuck at W4A16 and its higher memory ceiling. Budget the KV cache separately.

Third, the model card names hallucination, imprecise instruction-following, and degraded performance in long multi-turn conversations as known limitations. The last one is the underrated risk given a 1M context window: a large advertised context is not a guarantee of quality across it, and the lab does not publish a needle-in-haystack or long-context degradation curve. If you plan to operate above a few hundred thousand tokens, measure retrieval quality yourself.

Fourth, safety behaviour is good but not self-sufficient, and fine-tuning can erode it. The lab identifies residual risk in Inkling’s occasional compliance with role-play and indirectly framed prompts on harmful topics, explicitly recommends defence-in-depth rather than relying on the model’s refusals, and names Llama Guard-class moderation as compatible. It also states it is still studying how safety behaviour is affected by fine-tuning on Tinker — which is a polite way of saying the FORTRESS score belongs to the released checkpoint, not to whatever you fine-tune from it.

Fifth, some smaller operational traps. Benchmark scores are at effort 0.99, so a production deployment at medium effort will not reproduce them. Verbosity at high effort is above class median, which compounds with an above-median output price. Video input is architecturally supported but was not evaluated out of the box. Inkling-Small’s weights were not released at launch, so do not plan around them. And the Hugging Face model page displays a 952B parameter count against the 975B figure the lab states — a counter artefact, but worth knowing before you quote a number from a hub widget.

Practical recommendations

Treat Inkling as a base to specialise, not a general-purpose frontier endpoint. That is what its architecture, its release framing, and its Tinker integration all point at. The strongest case for adopting it is a domain where you have proprietary data, a multimodal input requirement, and cost sensitivity — audio-heavy document or call workflows are the obvious fit, since its audio scores lead the open-weights field by wide margins while its API price is only justifiable if you can cut tokens.

The strongest case against is a workload where you need best-available agentic coding today and cannot fine-tune. Use GLM-5.2 or Kimi K2.6.

Before committing:

Run your own task suite across effort 0.3, 0.7 and 0.99, and plot cost per solved task — not cost per token. The whole economic argument rests on this curve holding for your workload.
Decide the checkpoint before sizing hardware: NVFP4 at 600 GB on 4× B300 is a different capital conversation from BF16 at 2 TB.
Model the KV cache separately at your target context length. Do not assume the published VRAM figures cover it.
Benchmark long-context retrieval yourself. The 1M window is unvalidated in public at the top of its range.
If you self-host, enable MTP speculative decoding early — it is bit-identical output for a throughput gain at small VRAM cost.
Layer input/output moderation regardless of the FORTRESS score, and re-run safety evaluations after any fine-tune.
If you only need reasoning and instruction-following rather than factual recall or long agentic runs, wait for Inkling-Small’s full release — the preview numbers suggest it closes most of the gap at 12B active.

How Inkling compares

Use case	Inkling	GLM-5.2	Kimi K2.6	DeepSeek V4 Pro
Agentic coding / terminal work	Weakest of the four on Terminal-Bench 2.1 (63.8%) and SWE-bench Pro (54.3%). Avoid unless fine-tuning.	Best here — 82.7% Terminal-Bench, 62.1% SWE-bench Pro.	Strong second — 71.3% and 58.6%.	Mid — 64% and 55.4%, but best SWE-bench Verified at 80.6%.
Multimodal input incl. audio	Only real choice. Native text+image+audio; leads open weights on VoiceBench 91.4% and Audio MC 56.6%.	No published audio scores.	No published audio scores; better vision (MMMU Pro 79.0%).	No published audio scores.
Fine-tuning base / domain adaptation	Purpose-built. Apache 2.0, Tinker integration, RL-heavy post-training, cookbook recipes.	Open weights, no first-party fine-tuning platform.	Open weights, strong base, no first-party platform.	Widely used base, mature ecosystem.
Safety-sensitive / consumer-facing	Best balanced refusal profile — FORTRESS 78.0% adversarial with 95.9% benign.	Middling: 71.3% / 90.0%.	Weaker adversarial: 65.6%.	Poor adversarial: 36.0%.
Cost-sensitive high-volume inference	Strong if the effort dial works for you; expensive per token at $1.87/$4.68.	Competitive, no comparable effort control published.	Competitive.	Generally the cheapest self-host path per unit quality.
Factual recall / knowledge tasks	Good for its class — SimpleQA Verified 43.9%, best among GLM-5.2, Kimi K2.6, Nemotron.	38.1%.	38.7%.	Best of the four at 57.0%.

The pattern is consistent. Pick Inkling for multimodality, safety balance, fine-tunability, and token efficiency. Pick GLM-5.2 or Kimi K2.6 for peak agentic and reasoning performance. Pick DeepSeek V4 Pro for factual recall and mature self-hosting economics.

Frequently Asked Questions

What is Inkling and who made it?

Inkling is a 975-billion-parameter open-weights Mixture-of-Experts language model released on 15 July 2026 by Thinking Machines Lab, the company founded by former OpenAI CTO Mira Murati. It is the lab’s first model trained from scratch. It activates 41 billion parameters per token, supports up to 1 million tokens of context, natively accepts text, image and audio input, produces text output, and ships under the Apache 2.0 licence with weights on Hugging Face.

How many parameters does Inkling have and how sparse is it?

Inkling has 975B total parameters with 41B active per token — an activation ratio of about 4.2%. Its 66 decoder layers each contain 256 routed experts plus 2 shared experts, with 6 routed experts selected per token by a sigmoid-based router using auxiliary-loss-free load balancing. For comparison, Kimi K2.5 activates 3.2% of its parameters and GLM-5.2 has a near-identical ~40B active footprint from a smaller 744B total.

Why does Inkling use relative position encoding instead of RoPE?

Thinking Machines states that learned relative-position bias “performs better and extrapolates better to longer sequences” than Rotary Positional Embeddings, but has not published the ablation. Structurally it makes sense: 55 of 66 layers use 512-token sliding-window attention, where a learned relative bias supplies ample positional signal cheaply. In the 11 global layers the bias applies only over the preceding 1,024 tokens, leaving longer-range attention effectively content-based — similar in spirit to NoPE.

What hardware do I need to self-host Inkling?

The BF16 checkpoint requires at least 2 TB of aggregated VRAM — 8× NVIDIA B300 or 16× NVIDIA H200. The NVFP4 quantised checkpoint needs at least 600 GB, running as W4A4 on 4× B300 (requires SM100+ architecture) or W4A16 on 8× H200. Both figures exclude the KV cache, which you must budget separately at your target context length. Unsloth’s low-bit GGUFs run on far less but with meaningful accuracy loss.

Is Inkling better than GLM-5.2?

Not on most reasoning and agentic-coding benchmarks. GLM-5.2 leads on Terminal-Bench 2.1 (82.7% vs 63.8%), HLE text-only (40.1% vs 29.7%), and SWE-bench Pro (62.1% vs 54.3%). Inkling leads on instruction following (IFBench 79.8% vs 73.3%), short-form factuality (SimpleQA Verified 43.9% vs 38.1%), and adversarial safety refusal (FORTRESS 78.0% vs 71.3%). Inkling is also natively multimodal on audio, where GLM-5.2 has no published scores.

What does controllable thinking effort actually do?

It exposes a trained-in dial that trades generated tokens against answer quality. Thinking Machines trained it by varying the system message alongside the per-token cost in the RL reward, so the model learned to match its token budget to the requested effort. In transformers it appears as a reasoning_effort argument taking none through max. The lab reports Inkling matching Nemotron 3 Ultra on Terminal-Bench 2.1 at roughly one third of the tokens.

How much does Inkling cost to run via API?

Artificial Analysis measures the first-party API at $1.87 per million input tokens and $4.68 per million output tokens, with cache hits at $0.374 per million — a blended $1.10 per million at a 7:2:1 ratio. That is expensive for its class, where medians are $0.60 and $2.20. Measured throughput is 72.7 output tokens per second at 1.75s time to first token. Third-party endpoints on Together, Fireworks, Modal, Databricks and Baseten price independently.

Inkling Explained: Thinking Machines Lab’s 975B Open-Weights MoE (2026)