Inkling: What Thinking Machines Actually Shipped

Thinking Machines released Inkling on July 15, 2026. It is the company's first model trained from scratch, it is open-weights under Apache 2.0, and it accepts text, images, and audio natively. The weights landed on Hugging Face with support across the usual serving stack: transformers, SGLang, vLLM, and llama.cpp.

The headline number is 975 billion total parameters, with roughly 41 billion active per token. That is a large number, but it is not the part worth staring at longest.

What makes Inkling interesting is that it does not feel like a generic decoder model with a vision encoder glued on. It makes a few pointed architectural choices: relative attention instead of RoPE, hybrid attention, short convolutions, thin modality towers, sparse routing, and a reasoning-effort dial. Most of those choices point in the same direction: make the model cheaper to run and easier to reshape after pretraining.

Thinking Machines Inkling launch artwork, source: Hugging Face launch post

What Inkling Is

Before the architecture details, here is the compact profile:

Property	Value
Total parameters	975B
Active parameters	41B per token
Architecture	66-layer decoder-only sparse MoE transformer
Experts	256 routed experts, top-6 active, plus 2 shared experts
Context window	Up to 1M tokens
Input modalities	Text, image, audio
Output modality	Text
Training data	45 trillion tokens across text, images, audio, and video
Numerics	BF16 and NVFP4 checkpoints
License	Apache 2.0

The model card is worth reading directly because it is unusually concrete for a launch like this. The Hugging Face launch post is useful too, especially for the architecture diagrams.

One detail from the launch discussion stuck with me: internally, the team reportedly thinks less in terms of parameter count and more in terms of depth and sparsity. Inkling is "D66" to the people who built it. The 975B number is what the rest of us notice.

That is a small detail, but it tells you what the design loop was probably optimizing.

Relative Attention Instead of RoPE

The most surprising choice is positional.

Rotary position embeddings, usually shortened to RoPE, have become a default way to inject position into transformer attention. Inkling does not use that default. Instead, it learns relative position features directly in the attention logits.

Relative attention diagram for Inkling, source: Hugging Face launch post

That distinction matters. Absolute position and relative position answer different questions.

Absolute position asks:

"Where is this token in the sequence?"

Relative position asks:

"How far is this token from the token I care about?"

Most language structure depends heavily on relative position. The same phrase can appear early or late in a document, but the relationship between neighboring or dependent tokens remains important.

This is why the choice connects directly to the theory behind positional encoding explained. Inkling is not simply using a bigger version of the usual recipe. It is making a different decision about how order should enter attention.

The interesting lesson is not that RoPE was wrong. John Schulman's framing in the launch discussion was more modest than that: RoPE probably would have worked too. Relative attention was familiar to the team and fit the sliding-window setup.

That is exactly why the choice is worth noticing. Transformer defaults are not laws of physics. Sometimes an older idea from reinforcement learning or batching work comes back because the constraint has changed.

Hybrid Attention and Short Convolutions

Two more efficiency choices sit next to the position change.

Instead of making every layer attend globally across the entire context, the model alternates local and global attention. Most attention layers use sliding-window attention, while some layers use global attention over the full context. The final layer is global.

That gives the model a balance:

local layers handle nearby structure cheaply
global layers preserve long-range access
the final representation still has a full-context path

Alongside that, Inkling uses a short 1D convolution over hidden states, called SConv in the release materials. The point is cheap local mixing. Local sequence structure does not always need a full attention operation.

SConv short convolution over hidden states, source: Hugging Face launch post

The intuition is division of labor. Let SConv handle nearby mixing, let sliding-window attention handle short-range token interaction, and reserve global attention for the layers where full-context access matters most.

That is the recurring theme in Inkling: avoid spending the most expensive mechanism on every kind of structure.

Sparse Routing and the Real Efficiency Story

Inkling is a Mixture-of-Experts model. Each token is routed to a small subset of experts rather than activating the entire parameter set.

That is why the model can have 975B total parameters while activating about 41B per token.

This distinction is important for readers who see the parameter count and assume all parameters are used on every token. They are not. Sparse routing lets the model carry a large amount of specialized capacity while keeping per-token compute closer to the active subset.

The efficiency story is therefore not one trick. It is a stack:

sparse expert routing
hybrid local and global attention
short convolution for local mixing
controllable reasoning effort
quantized checkpoints
speculative decoding support through MTP drafters

That is how a model can be both enormous on paper and still designed around deployability.

Thin Modality Towers

Inkling accepts text, images, and audio natively.

Many multimodal systems rely on substantial encoders for each modality. Inkling takes a thinner approach. Images are handled through a hierarchical patching path, and audio is represented through a discretized mel-spectrogram path before being projected into the shared model space.

The important design signal is that the modality towers are deliberately light.

The model is not trying to make every modality encoder a serious independent model. It keeps those adapters comparatively simple and asks the shared decoder to do more of the work at scale.

That is a strong version of the "bitter lesson" instinct: when possible, prefer scalable general computation over heavy handcrafted specialization.

The caveat is equally important. Thinking Machines does not present this as a settled law. The design space is still underexplored, and the current model is evidence, not the final word.

One consequence is useful: because images carry an extra temporal dimension in the setup, video processing has a path through the image side. It was not the main evaluated capability at launch, but the path is there for future tuning.

Reasoning Effort Is a Cost Dial

Inkling exposes a reasoning_effort argument.

That sounds like an interface detail until you price a deployment.

Reasoning effort changes how many tokens the model spends on deliberation. More effort can help on harder tasks, but it also increases cost and latency. The Hugging Face evaluations show the practical pattern: maximum effort is not automatically better for every task, and medium or lower settings may be more efficient for many workflows.

For audio, the pattern can be different again. If the hard part is transcription rather than deliberation, extra reasoning does not necessarily buy much.

So this is exactly the kind of setting that should be tuned against real tasks, not chosen globally.

For production systems, the relevant question is not:

"What is the biggest effort setting?"

The better question is:

"What effort setting clears the quality bar at the lowest acceptable cost?"

That is the same discipline behind how to evaluate AI systems in production: evaluation should be attached to the workflow, not to a generic model preference.

One useful operational detail from the Hugging Face evaluations: on multimodal questions, the model often grounds itself by transcribing or OCR-ing first, then reasoning over that text. That is sensible, but it also gives you an obvious failure surface to test. If OCR is weak, downstream reasoning can look worse than the model's reasoning ability really is.

Running Inkling: Open Does Not Mean Laptop-Sized

Inkling is open-weights. It is not small.

That distinction matters.

The BF16 checkpoint requires multi-node class memory. The NVFP4 checkpoint lowers the requirement substantially but still targets serious accelerator hardware. Quantized GGUF builds from Unsloth make local deployment more plausible on a single well-equipped node, but that still means hundreds of gigabytes of memory, not a consumer laptop.

Inkling running in Unsloth Studio at aggressive quantization, source: Hugging Face launch post

So "open" means:

you can inspect the weights
you can fine-tune or adapt the model
you can choose your own serving stack
you can avoid depending entirely on a closed API

It does not mean:

cheap inference by default
low operational complexity
no validation burden

This is the difference between openness as a licensing and control property, and locality as a hardware property.

The quick-serving routes are what you would expect: llama.cpp for quantized local serving, SGLang or vLLM for serious GPU serving, and hosted providers if you do not have the hardware. The release also ships an MTP drafter for speculative decoding, which is the kind of small throughput detail that matters once you stop reading model cards and start paying inference bills.

The Release Is Really About Post-Training

Strip away the parameter count and the strategic center of the release is post-training.

Thinking Machines sells Tinker, a managed post-training platform. Inkling is positioned as a broad model that organizations can fine-tune or adapt to their own workflows, domains, and constraints.

Post-training metrics from the Inkling OpenEnv run, source: Hugging Face launch post

That makes the release less about "our base model beats every other model" and more about:

open weights
domain adaptation
data control
specialized behavior
model ownership

For many teams, that is the more important argument. A model you can reshape on your own terms may be more valuable than a stronger closed model that never absorbs your private corrections in a controlled way.

That is especially true for organizations with data residency, regulatory, or domain-specific evaluation requirements.

The honest part of the release is that Thinking Machines is not pretending Inkling was magically optimized for every fine-tuning use case from day one. Schulman's answer on the launch discussion was closer to: it is a good model for fine-tuning because it is generally capable, and they want to improve that further with customers.

That answer is more credible than the usual launch-day certainty.

Where Inkling Lands on Benchmarks

The published benchmarks put Inkling near strong recent open models, but not consistently ahead of closed frontier systems.

Some reference points from Thinking Machines' published table:

AIME 2026: 97.1%
GPQA Diamond: 87.2%
SWE-Bench Verified: 77.6%
MCP Atlas: 74.1%
SimpleQA Verified: 43.9%
MMAU: 77.2%
VoiceBench: 91.4%
FORTRESS Adversarial: 78.0%
StrongREJECT: 98.6%

That is not a crown. It is a capable, broad, open-weight model with visible factuality limits and useful multimodal/audio strength.

The right takeaway is more nuanced than a benchmark headline: Inkling becomes most interesting when you control the adaptation loop.

Safety and Deployment Reality

Open weights shift responsibility.

With a closed hosted model, the provider controls more of the serving environment, safety layer, model update path, and access policy. With open weights, downstream deployers gain control but also inherit more responsibility.

That means teams need their own validation plan:

task-specific evaluation
safety checks
red-team prompts
calibration around reasoning effort
monitoring after deployment
human review where failures carry real cost

Inkling should not be treated as safe for medical, legal, financial, or safety-critical decisions without domain validation and human oversight.

That is not a criticism of Inkling specifically. It is the normal burden of deploying powerful open models.

What I Would Take From This

Three things.

First, architecture is still moving. Relative attention, hybrid attention, short convolutions, and thin modality towers are reminders that the transformer recipe has defaults, not final laws.

Second, efficiency is being won in several small places at once. Sparse routing, hybrid attention, SConv, quantized checkpoints, speculative drafters, and controllable reasoning effort all push on the same problem from different angles.

Third, open weights are becoming an infrastructure decision.

The question is no longer only:

"Is this model cheaper than a hosted frontier API?"

The better question is:

"Do we need control over weights, data, fine-tuning, serving, and evaluation?"

For some teams, the answer will be yes. For others, a hosted closed model will still be the better engineering choice.

Common Misunderstandings

Is Inkling a local model?

No. Inkling is open-weights, but it is not laptop-sized. Even aggressive quantized builds require serious hardware.

Does replacing RoPE mean RoPE was wrong?

No. Relative attention is a different design choice, not proof that rotary embeddings are obsolete.

Does a 975B parameter count mean every token uses 975B parameters?

No. Inkling is sparse. It has 975B total parameters, but about 41B are active per token.

Is maximum reasoning effort always better?

No. Higher effort can improve some hard tasks, but it also raises cost and latency. It should be tuned against the target workflow.

FAQ

What is Inkling?

Inkling is an open-weights multimodal Mixture-of-Experts transformer from Thinking Machines. It accepts text, images, and audio as input and generates text output.

How large is Inkling?

Inkling has 975B total parameters and about 41B active parameters per token.

Is Inkling open source?

The model weights are released under Apache 2.0. The practical meaning is open-weight access, not low-cost local inference on ordinary hardware.

What makes Inkling architecturally interesting?

Its most interesting choices include relative attention instead of RoPE, hybrid local/global attention, short convolutions for local mixing, sparse MoE routing, and thin modality towers.

Can Inkling be used in production?

Yes, but only with task-specific evaluation, hardware planning, and safety review. Open weights give teams more control, but they also shift more deployment responsibility to the operator.

Sources

Architecture commentary in this post also draws on the Hugging Face launch discussion with Ben Burtenshaw, Merve Noyan, Soumith Chintala, John Schulman, and Daniel Han.