# Inkling: Thinking Machines' Open-Weight Model Designed for Fine-Tuning [Thinking Machines Lab](https://thinkingmachines.ai) released its first model On July 15, 2026: **Inkling, a 975-billion-parameter open-weight multimodal model built from scratch and released under the Apache 2.0 license**. The company was founded by Mira Murati, former CTO of OpenAI, and is valued at $12 billion. Inkling isn't positioned as a frontier general-purpose model. The company is explicit about that: "Inkling is not the strongest model available today, closed or open." The bet is that enterprises care less about topping leaderboards and more about owning a model they can genuinely customize on their own data. This article covers Inkling's architecture, what the benchmarks show, when fine-tuning makes more sense than prompting, and how the Tinker platform makes customization accessible. ## Specifications and availability Inkling's weights are available on [Hugging Face](https://huggingface.co/thinkingmachines/Inkling) under the Apache 2.0 license. The model can be fine-tuned through [Tinker](https://thinkingmachines.ai/inkling/), Thinking Machines' training platform, and accessed via API through third-party inference providers including Together AI, Fireworks, Modal, Databricks, and Baseten. ![The Hugging Face page for the Inkling model, showing its key details like license, model size, and download statistics.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/27ae6501-62eb-4d32-780e-6b7a09d1c000/md2x =1280x720) Key specs: - **Total parameters:** 975 billion - **Active parameters per token:** ~41 billion - **Context window:** 1 million tokens - **Training data:** 45 trillion tokens of text, images, audio, and video - **License:** Apache 2.0 - **Modalities:** Text, images, audio (native, not adapter-based) A quantized NVFP4 checkpoint is available alongside the full BF16 version. The BF16 checkpoint requires at least 2 TB of aggregated GPU VRAM; the NVFP4 checkpoint reduces that requirement to at least 600 GB. Thinking Machines also announced Inkling-Small (276B total, 12B active parameters), with weights to follow once testing is complete. ## Architecture ### Mixture-of-Experts Inkling is a 66-layer decoder-only transformer with a sparse Mixture-of-Experts backbone. Each token is routed to 6 of 256 experts per layer, plus 2 shared experts that activate on every token. The result is that only about 41 billion parameters are active for any given request, despite the model holding knowledge across 975 billion total parameters. You get the capacity of a near-trillion-parameter model while paying compute closer to a mid-size one. ![An animation illustrating the Mixture-of-Experts (MoE) concept, where a single token is routed to a small subset of a large grid of experts.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/40c95432-02f5-4f3a-740e-04f72c32bf00/md2x =1280x720) ### Native multimodality Most multimodal models handle non-text inputs through a pipeline of separate steps: a speech-to-text model transcribes audio, a vision encoder produces a text description of an image, and those text representations get fed to the language model. This approach loses information at every conversion step: tone and inflection disappear in transcription, visual nuance gets flattened into words. ![A flowchart showing the traditional, multi-step process for handling audio, involving a separate speech model, transcription to text, and then input to the LLM.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/cb857723-2cf3-485e-aa99-0c1e19c89900/md2x =1280x720) Inkling processes all three modalities natively. Images go through a hierarchical patch encoder; audio is encoded via discrete token encoding. Both are projected into the same shared hidden space as text tokens, so the decoder processes all modalities jointly rather than sequentially. This approach preserves nuance that conversion-based pipelines discard, and is one reason why Inkling is particularly well-suited as a base for fine-tuning tasks involving audio or visual content. ## Benchmark positioning Thinking Machines released benchmark comparisons alongside the launch, and they're transparent about where Inkling leads and where it doesn't. ![A comparison of benchmark scores for Inkling and GLM 5.2 on IFBench and Terminal-Bench, illustrating its relative strengths and weaknesses.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/4383bae6-dd41-489b-2c5d-1a3956d03000/md2x =1280x720) On IFBench, which tests instruction-following, Inkling scores 79.8 against GLM 5.2's 73.3. On Terminal-Bench, which evaluates autonomous agentic task completion, Inkling scores 63.8 against GLM 5.2's 82.7. Inkling follows explicit instructions well but is weaker at independent multi-step reasoning. That profile maps directly to fine-tuning use cases: you define the task clearly, and the model executes it reliably at scale. ## Fine-tuning vs. prompting Fine-tuning and RAG (Retrieval-Augmented Generation) address different problems. A useful way to think about the split: RAG teaches a model *what* to know; fine-tuning teaches it *how* to respond. RAG is the better choice when you need a model to answer questions based on a specific knowledge base it wasn't trained on, like internal documentation or proprietary research. You retrieve the relevant information and include it in the prompt. Research has consistently shown RAG outperforms fine-tuning for injecting new factual knowledge. Fine-tuning is stronger in three specific scenarios: **Tone and style.** If you need a model to consistently adopt a particular brand voice, character persona, or writing style across thousands of outputs, training on examples of that style produces more reliable results than prompting. Describing a style in a system prompt can never be as precise as showing the model thousands of examples of it. **Rigid structured output.** For tasks requiring consistent complex output formats, such as specific JSON schemas, domain-specific code patterns, or structured reports, fine-tuning on a large dataset of correct examples teaches the format more reliably than few-shot prompting. **Cost and latency distillation.** Using a large frontier model for a narrow, high-volume task is expensive. You can fine-tune a smaller, more efficient model on outputs from the larger one, distilling the capability for that specific task into a model that runs faster and costs less. Inkling is well-positioned for this: it's capable enough to serve as the distillation target for most production tasks while being significantly cheaper to run at scale than frontier models. ![A slide listing the three primary use cases for fine-tuning: Tone of voice, Rigid structured output, and Cost and latency distillation.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/ff3a2c53-875a-4537-f4c1-abf5a60e3300/lg2x =1280x720) ## Tinker and LoRA Inkling is designed to be fine-tuned through [Tinker](https://thinkingmachines.ai/inkling/), Thinking Machines' training platform. Tinker handles the infrastructure, letting users focus on data and objectives. Fine-tuning a 975-billion-parameter model sounds computationally prohibitive, but Tinker uses LoRA (Low-Rank Adaptation) to make it practical. Rather than retraining the full model, LoRA freezes the original weights and injects small trainable adapter matrices into the layers. Only those adapters are updated during training. Because they're orders of magnitude smaller than the full model, training is significantly faster and requires much less VRAM. The original weights and the adapter outputs combine at inference time to produce the fine-tuned behavior. ### Self-fine-tuning One demonstration the Thinking Machines team ran shows Inkling using Tinker to fine-tune itself. Given the instruction "Fine tune yourself with Tinker to be a lipogram model where you never use the letter 'e' in your responses," the model understood the task, generated a synthetic training dataset and the necessary code, executed the fine-tuning job via the Tinker API, loaded the new weights, and responded to subsequent prompts without using the letter 'e'. ![The command line interface showing Inkling being prompted to fine-tune itself, followed by the code it generates to create the training objective.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/a33a280b-bbe7-4d73-751c-912218cdd500/orig =1280x720) It's a contrived example, but it demonstrates the tight integration between the model and the training platform and shows what's possible when a model can treat its own fine-tuning as a tool. ## Thinking effort Most models offer a discrete set of effort levels (low, medium, high). Inkling exposes a continuous float slider from 0.0 to 1.0, letting you set exactly how much compute to spend on reasoning for any given request. This gives precise control over the cost-quality tradeoff, which is especially useful in production contexts where different request types warrant different reasoning budgets. ![A comparison diagram showing the discrete settings for a model like GPT-OSS versus the continuous "Thinking Effort" slider available for Inkling.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/5815c6a7-54a3-47b6-cfd5-2d4f3abf9100/lg2x =1280x720) ## When to use Inkling **Inkling is not a drop-in replacement for frontier general-purpose models on open-ended tasks**. Where it fits: narrow, well-defined, high-volume tasks where you have enough domain data to fine-tune on, and where the cost savings of a specialized model matter at scale. Audio tasks are a particular strength given the native audio encoding, which preserves the tonal and emotional information that transcription-based pipelines discard. For teams already paying frontier model prices for a task they run thousands of times a day, fine-tuning Inkling or using it as a distillation target for a smaller model is a well-defined path to significant cost reduction with comparable or better task-specific performance. The Hugging Face model page at [huggingface.co/thinkingmachines/Inkling](https://huggingface.co/thinkingmachines/Inkling) includes the model card, inference configuration details, and links to the Tinker Cookbook for getting started with fine-tuning.