Thinking Machines Inkling: Open Weights Built to Be Fine-Tuned
Rohit RamachandranJul 17, 2026Updated Jul 17, 2026
Rohit RamachandranRohit RamachandranRohit RamachandranThe most important number in Thinking Machines Lab's first foundation-model release is not 975 billion parameters.
It is the distance between 975 billion total parameters and 41 billion active parameters—and the business that Thinking Machines has built across that gap.
Inkling, released on July 15, is a large open-weight multimodal model that does not top the launch table. Thinking Machines says so plainly. Claude Fable 5, GPT-5.6 Sol, GLM-5.2, and Kimi K2.6 beat it on many headline reasoning and coding evaluations. Inkling's release is more interesting because the company is declining the usual benchmark-crown contest and making a different bet: a broad model becomes more valuable when a team can train it into its own specialist.
That is why the checkpoint and Tinker arrived as one story. The weights create control and portability. Tinker supplies remote post-training, evaluation, checkpoint management, and a route into managed inference. The product is not merely “a model you can download.” It is a model whose behavior is meant to move.
There is a hard limit to the openness story, though. Inkling's BF16 checkpoint needs at least 2TB of aggregate GPU memory. Even the NVFP4 version starts at 600GB. These are not gaming-PC numbers or generous workstation numbers. They are lab, cloud, sovereign-compute, and large-enterprise numbers.
The useful way to read Inkling is therefore not open versus closed. It is as a three-layer bet:
open weights for control
managed training for differentiation
institution-scale infrastructure for independent operation
That combination could be a real frontier product strategy—even if Inkling is not the strongest zero-shot model on July 17.
Inkling's release post, model card, and Hugging Face repository describe the same model from different angles. They also reveal why “open model” is too blunt a label.
The capability contract describes the checkpoint: a 66-layer multimodal transformer, sparse expert routing, one-million-token context capacity, controllable effort, and text, image, and audio processing.
The product contract is narrower: Tinker currently offers 64K and 256K post-training options, and the supported output is text. The operating contract adds multi-GPU hardware, a compatible runtime, model-specific rendering, safety controls, and two legal documents.
Inkling documents all three layers. Buyers still have to keep them separate.
Inkling is a 66-layer decoder-only transformer with a sparse Mixture-of-Experts backbone. The first two feed-forward layers are dense; in each of the remaining 64 MoE layers, each token is routed to six of 256 routed experts, while two shared experts remain active. The selected and shared expert scores are normalized together before their outputs are combined.
That routing explains how a model with 975B total parameters can activate roughly 41B for a token. It does not mean the rest of the checkpoint vanishes. The inactive experts still need to be stored and made reachable. Sparse activation reduces the computation performed per token; it does not magically turn the model into a 41B download.
Attention follows another selective pattern. Thinking Machines interleaves five local sliding-window layers for each global-attention layer; the checkpoint uses 16 key-value heads in local layers and eight in global layers. It applies relative positional embeddings rather than RoPE. Short convolutions appear after key and value projections and on residual branches. The design is aimed at making long context less computationally wasteful without giving up periodic access to the full sequence.
Inkling's sparse decoder creates the base capability; the commercial loop begins when private examples and graders enter Tinker.
The multimodal path is deliberately simple. Images are divided into 40-by-40-pixel patches and passed through a hierarchical MLP patchifier. Audio becomes discrete dMel spectrogram tokens. Those media embeddings enter the same hidden space as text and are processed jointly by the decoder rather than delegated to a large frozen encoder tower.
The integrated design supports a cleaner multimodal fine-tuning story for private industrial images, calls, field audio, charts, and other domain artifacts.
Inkling was pretrained on text, images, audio, and video. The Hugging Face architecture description says images and video use a hierarchical patch encoder, and Hugging Face's technical launch article says image inputs include a temporal dimension for video processing.
But the supported interface is narrower. Thinking Machines' model card lists only text, image, and audio inputs, with text output. The Hugging Face model card does the same. The integration article adds the decisive caveat: the temporal capability may be useful for downstream fine-tuning, but out-of-the-box video performance had not been evaluated.
So the honest wording is:
trained with video
architecturally able to represent a temporal image dimension
not currently documented as a supported general video-input contract
This distinction is more than editorial fussiness. Training modality, latent capability, and supported product behavior are different promises. A team evaluating video should treat it as an experiment to validate and possibly fine-tune—not a launch-day production feature.
The same discipline applies to output. Inkling accepts audio, but it does not generate audio. It reasons over image and audio inputs, but its official output modality is UTF-8 text. That text can include code, tool calls, structured data, or an answer about media; it is still text.
Thinking Machines reports Inkling at effort 0.99 and temperature 1.0. Coding evaluations use a 256K maximum trajectory. For several benchmarks the company imports Artificial Analysis results; elsewhere it uses internal harnesses or external self-reported numbers. Inkling's SWE-bench Verified result uses a bash-only harness, while its Terminal-Bench 2.1 result uses an internal coding harness and assigns zero to a small number of contaminated solutions.
Those caveats do not make the table useless. They define what the table can support: a broad directional comparison, not a laboratory-grade declaration of a universal winner.
The comparison becomes clearer when the models are read as products rather than rows.
| Model | HLE + tools | SWE Pro | Terminal 2.1 (best harness) | Strategic advantage | Control boundary |
|---|---|---|---|---|---|
| Claude Fable 5 | 64.5% | 80.0% | 84.6% | Highest capability in this subset and a polished governed product surface | Closed weights; behavior and access stay with Anthropic |
| GPT-5.6 Sol | 55.0% | 64.6% | 89.5% | Frontier agent capability integrated into OpenAI's model and work stack | Closed weights and vendor-operated inference |
| GLM-5.2 | 54.7% | 62.1% | 82.7% | Open-weight coding and long-horizon agent performance | Downloadable, but still a large-model infrastructure project |
| Kimi K2.6 | 54.0% | 58.6% | 71.3% | Strong open-weight reasoning and agent baseline; also available for Tinker training | Open weights, with system behavior still dependent on the serving harness |
| Inkling | 46.0% | 54.3% | 63.8% | Multimodal breadth, effort control, full weights, and first-party trainability through Tinker | Maximum checkpoint control; practical independent hosting starts at cluster scale |
These are Thinking Machines' release-table numbers, not a RohitAI rerun. Fable's SWE-bench result and Inkling's bash-only run, for example, should not be read as perfectly controlled twins. The comparison is still decisive on one point: Inkling is not the zero-shot champion.
That does not make the launch an apology. It makes the bet measurable. If customization is the advantage, Thinking Machines must show that Inkling learns a domain faster, preserves general capabilities better, and costs less to adapt than a stronger frozen model costs to prompt.
RohitAI's earlier Claude Fable 5 analysis explains why Fable is a governed frontier service. The GPT-5.6 GA analysis shows OpenAI packaging its model family into a work platform. GLM-5.2 is the sharper open coding comparison. And the Kimi K3 harness analysis makes the complementary point that weights never eliminate the system contract around a model.
Inkling's answer to all four is not “we score higher.” It is “you can shape this one.”
The launch demo asks Inkling to make itself a lipogram model that never uses the letter “e.” Inkling writes an objective and training data, runs 96 steps through Tinker, evaluates the checkpoint, then switches OpenCode to the updated weights. The demo reports completion in about 27 minutes.
The behavior is playful; the loop is not:
describe a target behavior
generate or collect examples
define a loss or reward
train remotely
sample the updated checkpoint
evaluate against the base
export or deploy
repeat with real failures
Tinker's quick start maps this into two first-class flows. Supervised fine-tuning uses a LoRA training client, forward/backward passes, optimizer steps, saved weights, and sampling. RL adds on-policy rollouts, rewards, log probabilities, importance-sampling updates, and repetition. The Tinker Cookbook adds DPO, RLHF, distillation, tool-use training, multi-agent RL, evaluators, and deployment utilities.
Tinker owns the interface where private data becomes behavior. Repeated lessons about recipes, renderers, evals, and production checkpoints can improve both the platform and the next base model. Meanwhile, exportable adapters and weights reduce lock-in fear. Tinker has to win on training quality rather than captivity.
There is a second-order advantage. Multimodal specialization is often more defensible than generic chat tuning. A manufacturer has defect images. A call center has acoustically messy calls. A medical-device company has instrument displays and domain audio, subject to its own validation rules. A research group has charts and microscopy. None of that private distribution is fully represented by a public benchmark.
If Inkling can learn those distributions without losing its general reasoning floor, the fact that Fable scores higher on HLE may not decide the purchase. The relevant comparison becomes a fine-tuned Inkling against an unmodifiable API model on the buyer's own data.
That “if” is doing real work. Thinking Machines reports more than 30 million RL rollouts during its own post-training and says reward improved log-linearly across two long runs. That demonstrates that its training stack scaled for the lab. It does not yet prove every customer can obtain clean domain gains from modest data. Tinker's next phase needs public case studies with baselines, costs, ablations, regressions, and deployment outcomes.
The official hardware table is refreshingly specific.
The BF16 checkpoint needs at least 2TB of aggregate VRAM. Thinking Machines lists either eight NVIDIA B300 GPUs or sixteen NVIDIA H200 GPUs.
The NVFP4 checkpoint needs at least 600GB of aggregate VRAM. It can run W4A4 on four B300s, with SM100-or-newer architecture required, or W4A16 on eight H200s.
Weights openness creates multiple operating routes. It does not collapse the full checkpoint into a personal-computing workload.
The supported software list is broad: SGLang, vLLM, TokenSpeed, Unsloth, and Hugging Face Transformers. The release also credits work on llama.cpp support, while API partners include Together AI, Fireworks, Modal, Databricks, and Baseten.
That ecosystem work matters. Framework support prevents a large checkpoint from becoming a research artifact stranded behind one custom runtime. But support is not the same as simplicity. Operators still need expert parallelism, multi-node networking, quantization-compatible kernels, context-aware memory planning, batching, monitoring, upgrade discipline, and a safety layer.
This is managed open weights: the model is auditable, customizable, exportable, and provider-portable, while most customers still rent its operation. That is a different promise from local AI.
For a workstation-accessible model, total size matters more than the marketing glow around sparse activation. Inkling-Small may eventually be the more relevant artifact: the preview has 276B total and 12B active parameters, and Thinking Machines says full weights will follow after testing. Even that is not small in consumer terms. On July 17, it remains a preview, not a downloadable alternative.
Thinking Machines' model card labels Inkling Apache 2.0. That is meaningful: Apache provides broad rights to use, modify, and distribute, with its familiar notice and patent provisions.
The Hugging Face page also links a separate Model Acceptable Use Policy. The AUP says that accessing, downloading, or using the model weights, parameters, associated materials, or modified versions binds the user to that policy unless Thinking Machines agrees otherwise in writing.
The restrictions cover illegal activity, weapons and critical-infrastructure attacks, child exploitation, harmful surveillance, doxxing, privacy violations, certain consequential automated decisions, fraud, impersonation, and unauthorized professional practice. The policy also places responsibility on a deployer for users of products built with the model and says the company may update the AUP.
The right procurement conclusion is not “Apache is misleading.” It is that the release has two legal documents serving different functions:
Apache 2.0 -> copyright and patent permissions for the code/weights artifact
Model AUP -> behavioral and deployment conditions imposed by the provider
Whether and how those terms apply in a particular jurisdiction is a question for counsel, not a benchmark table. Engineers should still surface the two-document structure early, especially before distributing a derivative, exposing an end-user service, or building a high-risk application.
Thinking Machines says Inkling was pretrained on 45 trillion tokens spanning text, images, audio, and video. Its EU-format training-content disclosure puts the modalities into broad bands: more than 10 trillion text tokens, more than one billion images, more than one million hours of audio, and more than one million hours of video.
Those figures are not meant to be added as if an image and an hour of audio were naturally the same unit as a text token. The 45T figure describes the model's tokenized pretraining mixture; the EU ranges communicate the scale of each source modality.
The provenance categories include publicly available material, partnership or third-party access, and synthetic or internally generated data. The model card says public sources include the open internet and publicly accessible repositories. Thinking Machines' training-data documentation acknowledges that its broader datasets can contain both public-domain and IP-protected material. Its EU-format training-content summary reports no training data collected from user interactions with the company's services.
Post-training adds another layer. Thinking Machines says it bootstrapped a small initial SFT stage with synthetic data generated by open-weight models including Kimi K2.5, then spent most post-training compute on large-scale RL in synthetic and human-created environments.
This is more disclosure than “trained on public and licensed data,” but it is not dataset-level reproducibility. The public documentation does not enumerate the full mixture, exact source weights, per-modality filtering rates, or the contribution of specific domains. It tells us the magnitude and source classes, not a ledger that a rights holder or scientist could reconstruct.
That matters precisely because Inkling is open weight. A customer can inspect and adapt the artifact, but cannot rewind the pretraining corpus. Weight access and data provenance are independent transparency layers.
Choose this when proprietary examples, reward signals, or multimodal domain data could create a measurable advantage. Run a learning-curve eval before committing to production.
Choose this when data locality, model inspection, sovereign operation, or provider independence justifies a B300/H200-class cluster and a specialist inference team.
Use Tinker for adapters or checkpoints and a supported provider for serving. You keep more portability without owning the entire hardware and runtime burden.
Pick Fable, GPT-5.6, GLM, or Kimi when zero-shot completion rate matters more than weight control and your task does not gain enough from customization.
First, open-weight competition is moving from checkpoint quality to adaptation velocity. Once several models clear a useful capability floor, the winning platform may be the one that turns 1,000 private examples into a safe production gain fastest. Public leaderboards measure the base. Enterprise value increasingly lives in the gradient between the base and the deployed derivative.
Second, trillion-parameter sparse models are creating a managed-open category. Inkling, GLM, and Kimi show why “open” and “local” must be separate filters. Organizations may demand downloadable weights and provider portability while still buying hosted inference. Cloud economics do not disappear; bargaining power changes.
Third, multimodal data can make customization more defensible. Generic text instruction tuning is easy for competitors to imitate. A company's visual defects, machine sounds, customer-call acoustics, chart conventions, or instrument outputs are harder to copy. Inkling's integrated media path gives Tinker a credible route into those private distributions.
There is also a risk. If the best Inkling experience depends on Tinker's renderers, recipes, managed training, partner deployment, and undocumented operational knowledge, customers may discover that checkpoint portability is higher than behavioral portability. A weight file can move while performance changes with kernels, chat templates, tool schemas, reasoning-effort controls, and sampling.
The correct portability test is therefore not “can we download it?” It is:
Can we reproduce quality on a second stack?
Can we export the adapter and its renderer?
Can we rerun the eval from raw examples?
Can we roll back the full behavior package?
That is the harness contract every serious open-weight buyer should demand.
Is Inkling open source or open weight?
Inkling is best described as open weight. Thinking Machines publishes the full model weights and labels the model Apache 2.0, but the complete training code and pretraining dataset are not available as a reproducible source package. A separate Model AUP also governs use of the model materials and modified versions.
Can Inkling run on a normal workstation?
Not the official full checkpoint configurations. BF16 needs at least 2TB of aggregate VRAM, while NVFP4 needs at least 600GB. The lowest documented configuration is four B300 GPUs in W4A4 mode, and that mode requires SM100-or-newer architecture.
Why does a 41B-active model require so much memory?
Forty-one billion describes the approximate parameter subset used for a token's computation. The system still stores and routes across 975B total parameters. It also needs memory for runtime state, communication, cache, and serving overhead. Sparse compute is not sparse ownership.
Does Inkling support video input?
Video was part of pretraining, and the Hugging Face architecture notes a temporal dimension in the image path. However, the official model card lists text, image, and audio—not video—as supported inputs, and Hugging Face says out-of-the-box video was not evaluated. Treat video as a downstream fine-tuning opportunity, not a guaranteed launch feature.
Is Inkling better than Claude Fable 5 or GPT-5.6 Sol?
Not as a blanket zero-shot claim. Thinking Machines' own table places Fable and GPT-5.6 ahead on many reasoning and agentic coding benchmarks. Inkling's case is control, multimodal breadth, efficient effort scaling, and first-party customization. The only meaningful winner is the model that performs best on your post-training and production eval.
What is Tinker's role?
Tinker is Thinking Machines' managed training API. It lets developers run LoRA-based supervised fine-tuning and reinforcement learning, save and sample checkpoints, evaluate them, and export adapters or merged Hugging Face weights while the service handles distributed GPU work. For Inkling, Tinker currently offers 64K and 256K context options.
Does Apache 2.0 mean there are no use restrictions?
No. Apache 2.0 grants broad artifact permissions, but Thinking Machines separately links and applies its Model Acceptable Use Policy. Teams should review both rather than inferring the full deployment contract from the license badge.
Did Thinking Machines train Inkling on customer conversations?
The company's EU-format training-content disclosure says no user interaction data from its services was used. It does report public, partnership or third-party, and synthetic or generated sources. That statement does not mean the public corpus contains no personal information; the general training-data documentation says public material may include information people shared online.
Inkling is not a benchmark king disguised as an open model. It is a customization platform disguised as a model launch.
The checkpoint gives Thinking Machines credibility: full weights, a serious multimodal architecture, one-million-token capacity, controllable effort, broad framework support, and an explicit path away from its own inference surface. The hardware requirements prevent that openness from becoming a consumer-local story. The benchmark table prevents it from becoming a strongest-model story.
What remains is the more interesting contest.
Can a team take Inkling, add private examples and rewards through Tinker, and create a specialist that beats a stronger closed model on work that matters? Can it export that behavior, reproduce it on another stack, and operate it at an acceptable cost? Can Thinking Machines make the training loop so good that customers voluntarily stay even though the weights can leave?
If the answer is yes, Inkling does not need to win the public chart.
It needs to become the model companies can most reliably make their own.