Inkling Model: Specs, Benchmarks and How to Use It

Inkling model editorial cover with Mira Murati and abstract multimodal expert-network imagery

Written by

in

The Inkling model is Thinking Machines Lab’s first open-weight foundation model: a 975-billion-parameter Mixture-of-Experts system with 41 billion active parameters, native text, image, and audio reasoning, and weights designed for customization. It arrived on July 15, 2026, with a deliberately measured pitch. Thinking Machines Lab does not call Inkling the strongest model overall. It presents Inkling as a broad base that developers can inspect, deploy, and fine-tune.

That distinction matters. Inkling combines an unusually large sparse architecture, controllable reasoning effort, multimodal inputs, and a native context window of up to one million tokens. But the practical product has boundaries: hosted Tinker access currently exposes 64K and 256K contexts, self-hosting demands hundreds of gigabytes to terabytes of accelerator memory, and most headline benchmark results come from the vendor’s release evaluation rather than a uniform independent test.

This guide separates the Inkling model’s published specifications from its marketing, explains how its architecture works, interprets the benchmarks, and shows the realistic options for trying, fine-tuning, or self-hosting it.

Mira Murati, founder and CEO of Thinking Machines Lab
Mira Murati founded Thinking Machines Lab after serving as OpenAI’s chief technology officer. This source cover image accompanied the original Chinese report.

Inkling Model specs at a glance

Specification Published detail Practical interpretation
Release July 15, 2026 First model release from Thinking Machines Lab
Architecture Decoder-only sparse Mixture-of-Experts Transformer 975B total parameters, 41B active per token
Layers and experts 66 layers; 256 routed experts plus 2 shared experts per MoE layer Six routed experts activate for each token
Context Up to 1M tokens in the native model Tinker currently offers 64K and 256K configurations
Inputs and output Text, images, and 16 kHz WAV audio in; text out Video appeared in pretraining data but is not a documented runtime input
Pretraining 45 trillion multimodal tokens Exact corpus mix and training cutoff are not disclosed
Fine-tuning Available through Tinker Playground and cookbook recipes lower the evaluation barrier
Checkpoints BF16 and NVIDIA-oriented NVFP4 BF16 needs at least 2 TB aggregate VRAM; NVFP4 at least 600 GB
License position Checkpoints labelled Apache 2.0 plus a separate Model Acceptable Use Policy Accurate shorthand is “open-weight,” not unrestricted open source
Smaller model Inkling-Small preview: 276B total, 12B active Full weights were not released as of July 16, 2026

What is the Inkling Model?

Inkling is a general-purpose multimodal model trained from scratch by Thinking Machines Lab. Its stated purpose is not to dominate one benchmark category. The company trained it across reasoning, coding, tool use, instruction following, factuality, vision, audio, conversation, and safety so that organizations can adapt one foundation to different workflows.

The company’s release announcement emphasizes three properties:

  1. Open weights: developers can download the checkpoint rather than accessing it only through a closed API.
  2. Native multimodality: text, image, and audio representations are processed jointly by the model.
  3. Controllable thinking effort: applications can trade additional reasoning tokens for performance instead of using one fixed inference budget.
Thinking Machines Lab announcement introducing Inkling
Thinking Machines Lab’s launch announcement describes Inkling as an open-weight model for reasoning across text, images, and audio, with fine-tuning available through Tinker.

Inkling is also intended to become the background reasoning component for the company’s interaction-model work, where users collaborate through voice and vision. That helps explain why the first release prioritizes breadth and customizability over a narrow benchmark crown.

Open weight does not mean completely open

Inkling’s Hugging Face repositories label the checkpoints Apache-2.0. However, Thinking Machines Lab also applies a binding Model Acceptable Use Policy with additional restrictions. The complete pretraining corpus, corpus proportions, full training code, and total compute budget are not published.

For that reason, “open-weight model” is the precise description. “Fully open-source AI” would imply a level of training transparency and unrestricted use that the release does not provide.

Architecture: 975B total, 41B active

Inkling is a 66-layer sparse MoE Transformer. Although the checkpoint contains 975 billion parameters, only about 41 billion are active for each token. Sparse activation is what makes a model of this total size computationally usable: the router sends each token to a subset of specialized expert networks instead of evaluating every parameter.

Each MoE layer contains 256 routed experts and two shared experts. Six routed experts activate per token. Their outputs are combined with the shared experts after joint score normalization. The router uses sigmoid scores and an auxiliary-loss-free balancing bias, following ideas popularized by DeepSeek-V3.

The attention stack alternates five sliding-window layers for every global-attention layer, producing 55 local and 11 global layers. There are eight key-value heads. Thinking Machines Lab chose learned relative-position attention instead of RoPE, reporting better long-sequence extrapolation in its experiments. Short convolutions appear after key/value projections and again before attention and MLP residual branches return to the main residual stream.

These details are not cosmetic. Local attention controls cost, periodic global attention carries information across the sequence, and sparse experts expand capacity without activating the entire 975B checkpoint for every token.

Inkling using Tinker to participate in a self-fine-tuning workflow
The launch demo places Inkling inside an OpenCode harness and asks it to write, run, and evaluate a Tinker fine-tuning job. It is a product demonstration, not an independent autonomy benchmark.

Multimodal inputs and the 1M-token context window

The native Inkling architecture supports up to one million tokens, but that number needs qualification. Thinking Machines Lab’s Tinker service currently exposes 64K and 256K variants. A buyer evaluating the hosted service should plan around those product limits rather than assuming the full native window is available through every endpoint.

The formal model card documents three runtime input types:

  • UTF-8 text;
  • pixel images, with recommended dimensions between 40 and 4,096 pixels;
  • WAV audio sampled at 16 kHz, with an optimal length of 20 minutes or less.

Output is text. Although video was part of the 45-trillion-token pretraining mixture, video is not listed as a supported runtime input. Calling Inkling a text-image-audio model is therefore more accurate than calling it a video model.

Vision inputs are divided into 40×40-pixel patches and transformed through a four-layer hierarchical MLP. Audio enters as dMel spectrogram representations. Lightweight embedding front ends convert both modalities into representations processed jointly with text tokens by the decoder. Thinking Machines Lab describes this as encoder-free because it avoids a separate large vision or audio encoder.

Inkling capability profile across reasoning, coding, factuality, vision, and audio
The vendor’s radar chart illustrates breadth rather than a single aggregate score. Comparing axes with different evaluation methods should be treated as directional.

Inkling benchmarks: strengths and trade-offs

The most useful way to read Inkling’s results is as a capability profile, not a universal leaderboard. Thinking Machines Lab ran its release evaluations at thinking effort 0.99 and temperature 1.0. Coding trajectories could use up to 256K tokens. Some comparator results came from Artificial Analysis, some were self-reported by other vendors, and others used Thinking Machines Lab’s internal harnesses.

Selected published Inkling results include:

Area Evaluation Inkling result
Reasoning Humanity’s Last Exam, text only 29.7%
Reasoning with tools Humanity’s Last Exam 46.0%
Science reasoning GPQA Diamond 87.2%
Coding SWE-bench Verified 77.6%
Coding SWE-bench Pro Public 54.3%
Terminal agents Terminal-Bench 2.1, best harness 63.8%
General agents MCP Atlas 74.1%
Instruction following IFBench 79.8%
Vision MMMU Pro 73.5%
Audio VoiceBench 91.4%

The company explicitly says Inkling is not the strongest model overall. Closed models lead many reasoning and coding rows, while other open-weight systems win specific tasks. Inkling’s argument is that one downloadable checkpoint is competitive across several domains and can be adapted.

Agentic coding and artifact creation

Thinking Machines Lab trained Inkling in multiple coding-agent harnesses and randomized tool definitions to reduce dependence on one interface. In Design Arena’s blinded web-development comparison, Inkling appeared among the stronger open-weight entries at launch, but below several closed models.

Inkling position on the Design Arena agentic web development leaderboard
Design Arena uses pairwise human judgments of generated web applications. It is useful evidence about visual artifact quality, but it is not a substitute for repository-level software correctness testing.

The demos also show Inkling creating a multi-page travel journal and refining a multiplayer snake game over 40 feedback rounds with a Codex model acting as reviewer. These examples demonstrate sustained tool use and visual consistency under curated conditions. They do not prove that arbitrary long-running tasks will finish without supervision.

Multi-page PDF artifact generated by Inkling
A launch demo shows a nine-page food-and-travel journal with consistent visual styling. The animated source is preserved from the original article.

Controllable thinking effort

Inkling can vary its reasoning budget from approximately 0.2 to 0.99 effort. During reinforcement learning, the team changed system-message instructions and the per-token cost so the model learned to respond with different amounts of computation.

This creates a more useful deployment question than “What is the best score?” Applications can ask what score is available at an acceptable token budget and latency. In the vendor’s Terminal-Bench sweep, Inkling matched Nemotron 3 Ultra’s score with roughly one-third as many generated tokens. That is promising efficiency evidence, but it remains a vendor-run comparison whose harness and operating points matter.

Inkling effort and token-efficiency curves on Terminal-Bench, HLE, and IFBench
Inkling’s blue curves trace performance as effort rises. Competitors are shown at default operating points, so the chart compares a sweep with individual reference points rather than identical inference policies.

Audio and vision

Inkling’s reported audio results place it near specialist open-weight audio models: 77.2% on MMAU and 91.4% on VoiceBench. The VoiceBench score should be read carefully because the benchmark uses formatting-sensitive string matching; Thinking Machines Lab added a system instruction to produce the expected answer format.

For vision, Inkling reported 73.5% on MMMU Pro and 78.1% on CharXiv reasoning questions, rising to 82.0% when a Python tool was available. Tool-assisted image reasoning can zoom, crop, or calculate, but it also means the tool environment contributes to the final result.

Inkling audio and vision benchmark comparison
The multimodal comparison mixes open- and closed-weight systems. Missing cells mean the source did not report a directly comparable score.

Safety results are a starting point

The vendor reports 78.0% on FORTRESS Adversarial, 95.9% on FORTRESS Benign, and 98.6% on StrongREJECT at effort 0.99. The combination is intended to measure refusal of harmful prompts without excessive refusal of benign look-alikes.

Inkling safety comparison on FORTRESS and StrongREJECT
These are release-time safety evaluations, not a guarantee for every deployment. Fine-tuning, tools, system prompts, and application context can materially change behavior.

Open weights make independent evaluation possible, but they also let deployers modify safeguards. Any production use still needs domain-specific red teaming, access control, logging, and post-fine-tuning evaluation.

Why the full benchmark table needs footnotes

Inkling’s open-weight comparison shows strong results in some instruction-following, coding, and multimodal rows, while GLM, Kimi, Nemotron, or other systems lead elsewhere.

Inkling benchmark comparison with open-weight models
The open-weight table uses a mixture of external scores, vendor self-reports, and Thinking Machines Lab harnesses. Small differences should not be treated as statistically decisive.

The table against closed models is even more useful as a reality check: Inkling generally trails the strongest proprietary systems on difficult reasoning and coding rows, despite competitive instruction-following and some agentic results.

Inkling benchmark comparison with open- and closed-weight models
Thinking Machines Lab’s own table supports its restrained positioning: Inkling offers breadth and control, not across-the-board frontier leadership.

Teams should rerun their own prompts, tools, latency limits, and cost assumptions. A one-point difference from a release table is less important than reproducibility in the intended environment. For a broader evaluation framework, see Graphify’s guide to the best LLMs for coding in 2026.

How the Inkling model was trained

Inkling was pretrained on 45 trillion tokens spanning text, images, audio, and video. The model card describes broad source categories—public internet and repositories, acquired third-party data, and synthetic or augmented data—but does not publish the mix, named datasets, or cutoff date.

Large matrix weights used the Muon optimizer, while other parameters used Adam. The team coupled weight decay to the square of the learning rate and used schedules inspired by its modular-manifold research. Post-training covered math, agentic coding and tool use, audio, vision, conversation, factuality, and safety.

An initial supervised fine-tuning stage used synthetic data generated by open-weight models, including Kimi K2.5. Thinking Machines Lab says that stage consumed a small share of compute and that the majority went to large-scale reinforcement learning on synthetic and human-created environments.

The asynchronous RL program exceeded 30 million rollouts over two long continuous runs on NVIDIA GB300 NVL72 systems.

Inkling reinforcement-learning reward over more than 30 million rollouts
The held-out aggregate reward rose roughly log-linearly across the reported run. Because the aggregate combines several evaluations, it does not reveal whether every capability improved at the same rate.

The team also observed that the model’s hidden reasoning traces became shorter and more telegraphic as training rewarded efficiency. That observation is interesting, but compressed internal reasoning should not be confused with a guarantee of lower end-to-end latency or higher answer quality.

Early and late reinforcement-learning reasoning traces from Inkling
The example shows fewer grammatical connectives in a later RL trace while retaining the same solution path. It is an illustrative sample, not a population-level measure.

Inkling-Small preview

Inkling-Small is a separate 276B-parameter MoE preview with 12B active parameters. Thinking Machines Lab reports that it uses a similar architecture, improved pretraining data and recipe, and the same scalable post-training stack.

The smaller model is close to Inkling on several published rows and slightly ahead on HLE with tools, GPQA Diamond, IFBench, and a few multimodal tests. It is also materially behind on Terminal-Bench 2.1, Tau 3 Banking, SimpleQA Verified, and AudioMC.

Inkling and Inkling-Small preview benchmark comparison
Inkling-Small trades capacity for 12B active parameters. As of July 16, 2026, it remained a preview and its full weights had not been released.

There is no published firm release date, complete hardware profile, standalone price, or public checkpoint for Inkling-Small. Treat it as a roadmap signal rather than a deployable option today.

How to access and use Inkling

There are three practical paths.

1. Evaluate or fine-tune through Tinker

Tinker offers Inkling with 64K and 256K context configurations. The Inkling Playground provides chat and integrated web search for quick qualitative testing. Tinker’s cookbook adds audio recipes, while tml-renderer supports sampling and post-training with tool calls, reasoning content, and multimodal inputs.

Thinking Machines Lab advertised a limited-time 50% discount at launch. Its July 16 documentation listed, per one million tokens:

Tinker mode Prefill Cached input Sample Train
64K $1.87 $0.374 $4.68 $5.61
256K $3.74 $0.748 $9.36 $11.23

Pricing is time-sensitive, and the documentation warned of broader changes effective July 17. Verify current prices before budgeting.

2. Use a hosted inference provider

Thinking Machines Lab announced Together AI, Fireworks, Modal, Databricks, and Baseten as API partners. Availability can differ by provider and date: Modal and Baseten published live launch support, while Together’s public page still said “coming soon” during this review. Check the chosen provider’s actual endpoint, context limit, modality support, and price rather than assuming every announced integration is live.

3. Download and self-host the weights

The official Hugging Face organization publishes BF16 and NVFP4 checkpoints. The model is integrated or being integrated with Transformers, SGLang, vLLM, TokenSpeed, and llama.cpp-related workflows.

Hardware is the main constraint:

  • BF16: at least 2 TB of aggregate VRAM; the model card gives examples such as eight B300 or sixteen H200 GPUs.
  • NVFP4: at least 600 GB; W4A4 targets four B300 GPUs, while W4A16 can target eight H200 GPUs.

Those are minimum memory profiles, not complete production sizing. KV cache, context length, concurrency, multimodal preprocessing, networking, and serving overhead all affect the real cluster requirement.

Fine-tuning Inkling with Tinker

Inkling is most differentiated when a team needs to adapt a generalist model to specialized judgments, tools, audio workflows, or internal data. A sensible pilot is narrower than “fine-tune our company model”:

  1. Define one measurable task and a held-out test set.
  2. Establish the base model’s quality, latency, token use, and refusal behavior.
  3. Fine-tune on a small, provenance-controlled dataset.
  4. Compare the checkpoint against the base using blinded review and task metrics.
  5. Re-run safety, privacy, and regression tests after every training change.
  6. Record the exact checkpoint, renderer, prompt format, effort setting, and tool schema.

The model’s size does not remove the usual fine-tuning risks. Poor labels, leaked evaluation examples, narrow reward signals, and aggressive specialization can degrade useful general capabilities.

Limitations and who should use it

Inkling is a credible candidate for teams that need a customizable text-image-audio base, can evaluate models rigorously, and have either a Tinker workflow or access to substantial inference infrastructure. Agentic coding teams may value tool-schema robustness and controllable effort. Audio and visual-reasoning teams gain a single checkpoint rather than separate specialist models.

It is a weaker fit when:

  • a closed API already meets the quality target at lower operational complexity;
  • the deployment cannot support the hardware or provider cost;
  • a fully reproducible training dataset and pipeline are mandatory;
  • the application needs documented video input;
  • “open source” procurement rules conflict with the additional acceptable-use policy;
  • benchmark leadership matters more than customization.

The best evaluation is a workload-specific curve: quality versus total tokens, latency, price, human correction rate, and failure severity. Inkling’s controllable effort is useful only if those operating points are measured in the real application.

Inkling Model FAQ

Is the Inkling model open source?

Its full weights are downloadable and the Hugging Face repositories are labelled Apache 2.0, but use is also subject to Thinking Machines Lab’s Model Acceptable Use Policy. The training data and full training pipeline are not public. “Open weight” is the more precise term.

How large is Inkling?

Inkling has 975 billion total parameters and activates about 41 billion per token through a sparse Mixture-of-Experts architecture.

Does Inkling support a one-million-token context?

The native model supports up to 1M tokens. Tinker currently exposes 64K and 256K configurations, and third-party providers may have different limits.

What modalities does Inkling accept?

The model card documents text, images, and 16 kHz WAV audio as inputs and text as output. Video was included in pretraining data but is not a documented runtime input.

Can Inkling run locally?

Technically yes, but not on ordinary consumer hardware. Official minimums start around 600 GB aggregate VRAM for NVFP4 or 2 TB for BF16, before serving overhead.

Is Inkling-Small available?

Not as a full public checkpoint as of July 16, 2026. Thinking Machines Lab has published a 276B-total, 12B-active preview and says weights will follow after testing.

Bottom line

The Inkling model is best understood as a large, open-weight multimodal foundation for customization—not a claim to universal state of the art. Its 975B/41B-active MoE design, controllable effort, text-image-audio support, and Tinker integration create a flexible platform. Its value will depend on whether teams can reproduce the vendor’s strengths in their own harnesses while accepting the hardware, licensing, data-transparency, and evaluation constraints.

Sources

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *