Inkling Model Card

Inkling Model Card

1. General information

Model name

Inkling

Legal name of the model provider

Thinking Machines Lab, Inc.

Date of release

July 15, 2026

License

Apache 2.0

Intended uses

Inkling is a general-purpose multimodal model that accepts text, image and audio inputs and generates text outputs. It is intended for use in English and other languages, and across multiple coding languages. The model is designed to be used by developers building AI-powered applications, including agentic and tool-use systems, coding assistants, chatbots, and retrieval-augmented generation systems, and is suitable for general-purpose conversational use, instruction-following, and other natural language and multimodal tasks. It is released with open weights to support research, fine-tuning and integration into third-party products by downstream developers.

Model Acceptable Use Policy

Languages

English, general multilingual support

1. Model properties

Model type

Multimodal autoregressive transformer

Architecture type

A 66-layer decoder-only transformer with a sparse Mixture-of-Experts (MoE) feed-forward backbone: each token is routed to 6 of 256 experts, plus 2 shared experts active on every token. Attention is a hybrid of local and global layers. The model is natively multimodal — images are encoded via a hierarchical patch encoder, and audio via discrete token encoding — with all modalities projected into a shared hidden space and processed jointly by the decoder.

Parameters

975B total, 41B active

Numerics support

BF16, MXFP8 and NVFP4

Input modalities

Text: UTF-8 encoded text

Image: Any pixel-based image input. For optimal performance, each image dimension should be between 40px to 4096px.

Audio: WAV format, sampled at 16kHz. For optimal performance, audio length should be within 20 mins.

Inkling supports a context window of up to 1M tokens.

Output modalities

Text: UTF-8 encoded text

1. Methods of distribution

The model is available via API access through Tinker, our service for fine-tuning. The model is also available via API access through third party inference providers.

The weights are available for download through Hugging Face.

API access to the model

For accessing our model via Tinker, you can get started by referring to the Tinker Cookbook here, and installing the tml-renderers package here.

For accessing our model via third party inference providers, you can refer to the documentation from our inference provider partners.

Running the open weights model on your own system

Required hardware

The model is distributed in two checkpoint formats.

The BF16 checkpoint requires a GPU cluster with at least 2 TB of aggregated VRAM. This can be met with either of the following configurations:

8x NVIDIA B300 GPUs

16x NVIDIA H200 GPUs

The NVFP4 checkpoint offers a quantized alternative that reduces the aggregated VRAM requirement to at least 600 GB. This checkpoint can be run as:

W4A4 on 4x NVIDIA B300 GPUs (note: W4A4 mode additionally requires SM100+ architecture)

W4A16 on 8x NVIDIA H200 GPUs

Required software

Running the model directly on GPU hardware requires an inference deployment framework–either SGLang, vLLM, TokenSpeed, Unsloth, or Hugging Face, along with all of their respective dependency libraries.

1. Training

Data types

Training data includes a broad variety of content types, including text, images, audio, video.

Data provenance

Training data for the model was drawn from publicly available sources, acquired from third-parties, or synthetically generated or augmented. Publicly available data includes content from the public internet and publicly accessible repositories.

Curation methodologies

Data curation includes cleaning, processing, and modifying datasets. These processing steps, which vary by data type, may include deduplication and filtering to remove junk or other low-quality data, or to advance safety or other objectives.

1. Evaluations

Open weights

Closed weights

Inklingeffort=0.99

Nemotron 3Ultra

Kimi K2.5

Kimi K2.6

GLM 5.2

DeepSeek V4Pro

Gemini 3.1 Pro(high)

Claude Fable 5(max)

GPT 5.6 Sol(max/xhigh)

Reasoning

HLEtext only

29.7% 26.6% 29.4% 35.9% 40.1% 35.9% 44.7% 53.3% 47.2%

HLEwith tools

46.0% 37.4% 50.2% 54.0% 54.7% 48.2% 51.4% 64.5% 55.0%

AIME 2026

97.1% 94.2% 95.8% 96.4% 99.2% 96.7% 98.3% 99.9% 99.9%

GPQA Diamond

87.2% 86.7% 87.9% 91.1% 89.5% 88.8% 94.1% 92.6% 94.1%

Agentic (coding)

SWEBench Verified*

77.6% 70.7% 76.8% 80.2% 80.0% 80.6% 80.6% 95.0% 82.2%

SWEBench ProPublic

54.3% 46.4% 50.7% 58.6% 62.1% 55.4% 54.2% 80.0% 64.6%

Terminal Bench 2.1*Best Harness

63.8% 56.4% 51.3% 71.3% 82.7% 64% 73.8% 84.6% 89.5%

Agentic (general)

GDPVal-AA v2

1238 1164 1009 1190 1514 1307 962 1760 1748

MCP Atlas

74.1% 44.7% 64.0% 68.1% 77.8% 73.2% 78.2% 83.3% 81.8%

Tau 3 Banking

23.7% 13.8% 14.2% 20.6% 26.8% 25.8% 16.5% 26.8% 33.0%

BrowseCompw/ ctx management

77.1% – 74.9% 83.2% – 83.4% 85.9% 88.0% 90.84%

Factuality

SimpleQA Verified

43.9% 32.4% 36.9% 38.7% 38.1% 57.0% 77.3% 68.3% 71.6%

AA Omniscience

2.1 -1.0 -8.0 6.0 4.0 -10.0 33.0 40.0 22.0

Chat

IFBench

79.8% 81.4% 70.2% 76.0% 73.3% 76.5% 77.1% 63.5% 72.7%

Global-MMLU-Lite

88.7% 85.6% 84.0% 88.4% 89.2% 89.3% 92.7% 93.3% 91.8%

Vision

MMMU ProStandard 10

73.5% – 75.0% 79.0% – – 82.0% 84.2% 83.0%

Charxiv RQ

78.1% – 77.5% 80.4% – – 80.2% 86.5% 84.7%

Charxiv RQ†with python

82.0% – 78.7% 86.7% – – 89.9% 89.4% 87.8%

Audio

Audio MC†

56.6% – – – – – 66.8% – –

MMAU

77.2% – – – – – 82.5% – –

VoiceBench†

91.4% – – – – – 94.3% – –

Safety

FORTRESSAdversarial

78.0% 77.6% 54.1% 65.6% 71.3% 36.0% 65.2% 96.0% 82.4%

FORTRESSBenign

95.9% 90.5% 98.3% 97.2% 90.0% 98.5% 98.0% 55.1% 98.1%

StrongREJECT

98.6% 98.7% 99.5% 99.8% 98.5% 98.6% 98.0% 98.7% 98.5%

*We assign a score of 0 to Terminal Bench 2.1 rollouts with solution contamination from web search. †We benchmarked Claude Fable 5 and GPT 5.6 Sol (max/xhigh) on CharXiv RQ (with python) using our internal Python harness.

For all input images whose long edge is smaller than 2048 px, we resize the long edge to the smaller of 2048 px or 2× its original length.

1. Safety

We conducted safety evaluations ahead of release, spanning both everyday human-AI interaction and dangerous-capability testing. Because Inkling is multimodal, we paid attention to whether safety behavior held consistently across text, audio, and image inputs. We applied mitigations to reduce risks before release.

For everyday interaction, we evaluated sycophancy, harmful manipulation, and psychological-harm patterns like parasocial dependency and validation of delusional reasoning, including through multi-turn, open-ended external red-teaming designed to surface issues that only emerge over longer conversations. We also assessed whether the model refuses genuinely harmful requests without over-refusing benign ones. For CBRN and cyber, we assessed knowledge and procedural uplift through internal evaluations, external testing, and refusal-suppressed variants intended to estimate latent capability with safeguards removed. For loss of control, we evaluated agentic capability, strategic deception, and sabotage potential, benchmarked against public frontier models, and found the model materially below frontier capabilities.

Across all areas, we concluded that Inkling did not present risk of material uplift beyond what’s already available in the open-weight ecosystem.

The residual risks identified in our evaluations — specifically, Inkling’s occasional tendency to comply with role-play and indirectly framed prompts concerning harmful topics — are consistent with what you would see from any open-weight model, and are best addressed with defense-in-depth rather than relying on the model’s refusals alone. Common downstream moderation tools, such as Llama Guard, are compatible with Inkling and can be layered around the model to catch jailbreak attempts, filter unsafe outputs, and enforce use-case-specific policies. We would encourage treating this kind of input/output classification as a part of your deployment stack, especially for consumer-facing or high-traffic applications where adversarial prompting is more likely.

1. Bias, risks and limitations

Inkling may exhibit general limitations common to foundation models, including hallucination (generating plausible but factually incorrect or unsupported content), occasional failures to follow instructions precisely, and degraded performance in long multi-turn conversations. As with other large-scale models trained on web-derived and synthetic data, Inkling may reflect biases present in its training data, including demographic, cultural, or linguistic biases, and may perform unevenly across languages, dialects, or subject domains that were less represented during training.

Inkling’s knowledge is limited to information available as of its training cutoff, and it may not reflect events, developments, or changes that occurred afterward.

We recommend that downstream developers and deployers apply appropriate human oversight and review for outputs used in high-stakes or safety-critical contexts, rather than relying on Inkling’s outputs without verification.

Conduct their own evaluation of Inkling’s performance, safety, and fairness for their specific use case, language, and population prior to deployment, particularly for applications involving vulnerable groups.

Implement additional safeguards – such as content filtering, rate limiting, and monitoring – at the application layer, especially for open deployment contexts where Inkling’s built-in mitigations may not be sufficient on their own.

Avoid deploying Inkling in domains such as medical, legal, or safety-critical decision-making without additional fine-tuning, domain-specific validation, and human oversight

1. Legal

Training Data Documentation