In partnership with
It is not the strongest model available. Thinking Machines Lab says this explicitly. What Inkling is designed to be is the best open-weights base for customization: broad multimodal capability, efficient thinking, and tight integration with Tinker for fine-tuning. The proof of that claim is a demo where Inkling fine-tuned itself.
SnackOnAI Engineering | Senior AI Systems Researcher | Technical Deep Dive | July 17th, 2026
The most common assumption about a new open-weights model release is that the benchmark numbers are the point. More capable = better release. The Inkling announcement leads with the opposite: "Inkling is not the strongest overall model available today, open or closed." This is a deliberate positioning decision, not false modesty. The model is designed for a specific use case: being fine-tuned into something domain-specific by the engineers and researchers who work with it.
This matters because it changes what architectural decisions make sense. If your model will be fine-tuned thousands of times for different domains, the base model's architecture should support rapid, efficient adaptation. Broad capability without depth in any one area is the correct tradeoff. Controllable thinking effort matters because fine-tuned domain models get called millions of times in production pipelines where cost is a real constraint. Multimodal capability matters because most real-world domains involve more than text.
The self-fine-tuning demo makes the design intent concrete: Inkling ran inside OpenCode, wrote objective.py, train.yaml, and self_update.py, posted a fine-tuning job to the Tinker API, and loaded the resulting weights. The target behavior was a lipogram model that never uses the letter "e." Prompting alone cannot reliably achieve this. The model produced a fine-tuned checkpoint that does. This is the demo loop Thinking Machines Lab wants Tinkerers to understand: the model trains itself, and the Tinker platform handles the execution.
Scope: Inkling's architecture (MoE design, attention with relative positional embeddings, short convolutions on the residual stream, encoder-free multimodality), the training and RL pipeline (30M+ rollouts, emergent CoT compression, dual-grader instruction following), the controllable effort mechanism, the benchmark results, and the Tinker integration. Inkling-Small (276B total, 12B active, preview) is covered briefly. Not covered: the full Tinker SDK API, the interaction models system Inkling is designed to power, or the tml-renderers library in depth.
What It Actually Does
Inkling is an open-weights base model available for fine-tuning. Install via Tinker or deploy directly from HuggingFace. The key integration hook:
# Tinker SDK: set Inkling as your base model
model_name = "thinkingmachines/Inkling"
# Or load directly from HuggingFace with transformers
from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained(
"thinkingmachines/inkling",
device_map="auto",
torch_dtype="auto"
)
tokenizer = AutoTokenizer.from_pretrained("thinkingmachines/inkling")
# NVFP4 checkpoint for Blackwell inference
# thinkingmachines/inkling-nvfp4 (efficient quantized format for GB300/H200)
Available via: TogetherAI, Fireworks, Modal, Databricks, Baseten, SGLang (RadixArk/Miles), vLLM (Inferact), llama.cpp (Unsloth), TokenSpeed (Lightseek), HuggingFace transformers. Context: 64K and 256K on Tinker; up to 1M in the full architecture.
The Architecture, Unpacked
The two places short convolutions appear (after K/V projections, and on attention+MLP residual branches before rejoining the main stream) are the most unusual architectural decision in Inkling. This is not a standard recipe. It adds local inductive bias at two distinct points in each transformer layer without disrupting the global attention path.
The Code, Annotated
Snippet One: Controllable Thinking Effort via Tinker
# Inkling: controllable thinking effort
# Source: tinker-docs.thinkingmachines.ai/cookbook/inkling/thinking-effort/
# Design intent: effort is a first-class parameter, not a prompt trick.
# During RL training, different samples got different system messages
# AND different per-token cost penalties. The model learned to internalize
# the effort/quality tradeoff as a function of the effort signal.
import tinker
from tinker.types import SamplingParams
client = tinker.SamplingClient(base_url="https://api.tinker.thinkingmachines.ai")
# ─── LOW EFFORT: fast, cheap, good for classification / retrieval / routing ──────
response_fast = client.sample(
model="thinkingmachines/Inkling",
messages=[{"role": "user", "content": "Is this customer message positive or negative?"}],
sampling_params=SamplingParams(
effort=0.2, # ← THIS is the key: 0.0 to 1.0, float
# At 0.2: short chain-of-thought, direct answer
# Benchmark: ~8K tokens generated on Terminal Bench 2.1
# vs ~25K at effort=0.99 for the same benchmark
max_tokens=512,
)
)
# ─── HIGH EFFORT: deep reasoning, hard math, complex agentic tasks ────────────────
response_deep = client.sample(
model="thinkingmachines/Inkling",
messages=[{"role": "user", "content": "Prove that for prime p > 3, 24 divides p²-1."}],
sampling_params=SamplingParams(
effort=0.99, # ← Maximum effort: full chain-of-thought expansion
# At 0.99: Inkling matches Nemotron 3 Ultra on Terminal Bench 2.1
# at ~1/3 the tokens Nemotron uses
# This is the efficiency claim: same score, fewer tokens
max_tokens=32768,
)
)
# ─── THE EFFORT SWEEP FOR FINDING YOUR OPTIMAL POINT ──────────────────────────────
# The correct approach for fine-tuning: sweep effort alongside learning rate.
# tinker-cookbook provides sample_reasoning.py for exactly this comparison.
#
# Effort/performance curve data from the blog:
# Terminal Bench 2.1:
# effort=0.2: ~20% score, ~8K tokens
# effort=0.5: ~45% score, ~25K tokens
# effort=0.99: ~64% score, ~75K tokens
#
# HLE (Humanity's Last Exam):
# effort=0.2: ~10% score, ~5K tokens
# effort=0.99: ~30% score, ~50K tokens
#
# ← The key engineering insight: at effort=0.5, you often get 70% of the
# max-effort performance at 30% of the cost. For production pipelines
# that call the model 10M times per day, this is the decision that matters.
# ─── IN THE OPENAI-COMPATIBLE API ────────────────────────────────────────────────
import openai
client_compat = openai.OpenAI(
base_url="https://api.tinker.thinkingmachines.ai/v1",
api_key="your-tinker-api-key"
)
response = client_compat.chat.completions.create(
model="thinkingmachines/Inkling",
messages=[{"role": "user", "content": "Analyze this patient report for key risk factors."}],
extra_body={"effort": 0.7}, # ← effort passed as extra body param in OAI-compat mode
)
The effort mechanism is not a sampling parameter like temperature. It is a learned capability trained with RL by varying both the system message (describing desired verbosity) and the per-token cost penalty (penalizing token usage). The model internalized these signals during training, meaning it genuinely produces different quality chains-of-thought at different effort levels, not just truncated versions of the same reasoning.
Snippet Two: Self-Fine-Tuning Loop and Tinker Integration
# Inkling: fine-tuning via Tinker (and the self-fine-tuning demo recreation)
# Source: thinkingmachines.ai/news/introducing-inkling + tinker-docs
# Design intent: the model is designed to be customized; the fine-tuning API
# is meant to be callable by the model itself, not just by humans.
import tinker
from tinker_cookbook.supervised import Config as SFTConfig, ChatDatasetBuilder
# ─── STANDARD FINE-TUNING WORKFLOW ──────────────────────────────────────────────
training_client = tinker.TrainingClient(
base_url="https://api.tinker.thinkingmachines.ai",
api_key="your-api-key"
)
# Step 1: Build training dataset
builder = ChatDatasetBuilder(model="thinkingmachines/Inkling")
builder.add_conversation([
{"role": "user", "content": "Analyze the following financial statement..."},
{"role": "assistant", "content": "<think>Let me examine the key ratios...</think>Recommendation: ..."}
# ← Notice: reasoning content in <think> tags is part of the training data
# ← The model learns to reason in this domain during fine-tuning
# ← tml-renderers handles the correct token formatting for thinking/non-thinking content
])
dataset = await builder.build()
# Step 2: Configure and run SFT
config = SFTConfig(
model="thinkingmachines/Inkling",
dataset=dataset,
learning_rate=1e-5,
# ← Blog explicitly recommends sweeping lr AND thinking effort together
# ← The right lr depends on the effort distribution in your training data
epochs=3,
)
run = await training_client.create_training_run(config)
# ─── THE SELF-FINE-TUNING DEMO STRUCTURE ────────────────────────────────────────
# From the blog: "we asked Inkling to fine-tune itself"
# Inkling ran inside OpenCode harness, executed the following 7-step loop:
#
# Step 1 (OpenCode start): Inkling receives target behavior + Tinker API docs
# Step 2 (base answer): Inkling writes its current answer to the lipogram task
# (still uses "e"s — prompting alone cannot fix this)
# Step 3 (fine-tuning intent): Inkling decides it needs fine-tuning to change this
# Step 4 (rubric): Inkling writes a rubric to evaluate "no e" compliance
# Step 5 (training data):
#
objective_py = """
# Inkling wrote this file during self-fine-tuning
def objective(completion: str) -> float:
'''Score completions that avoid the letter e'''
if 'e' in completion.lower():
return -1.0 # ← heavily penalize any use of "e"
return len(completion) / 100.0 # ← reward longer valid completions
"""
#
train_yaml = """
# Inkling wrote this training config
model: thinkingmachines/Inkling
task: lipogram_no_e
epochs: 2
learning_rate: 2e-5
effort_levels: [0.5, 0.99] # ← sweep as recommended in the cookbook
"""
#
# Step 6 (training): Inkling calls Tinker API with the above config
# POST https://api.tinker.thinkingmachines.ai/v1/training-runs
# body: {"model": "thinkingmachines/Inkling", ...}
#
# Step 7 (self-update): Inkling loads new weights into OpenCode, replaces itself
# Output: model no longer uses "e" in its completions
# This behavior cannot be achieved by prompting alone
#
# ← THIS is the full loop:
# Model identifies behavior gap → writes its own training objective
# → generates synthetic data → calls fine-tuning API → loads new weights
# Human involvement: zero after setting the initial target
The self-fine-tuning demo is significant not because of the lipogram constraint but because of the loop structure. The model recognized that prompting could not achieve the target behavior, decided that fine-tuning was the correct intervention, wrote the training objective, generated the data, and executed the job. A model that can autonomously improve itself on a programmable objective is a qualitatively different tool from one that only responds to prompts.
It In Action: Effort Sweep for a Real Domain Task
Input task: Financial document analysis. A bank uses Inkling to classify customer messages and escalate to analysts only when needed.
Step 1: Baseline without effort sweep
All messages routed through effort=0.99 (default):
"Can I check my balance?" → 8,400 tokens generated → $0.084 per call
"I think my account was hacked, multiple charges I don't recognize" → 12,200 tokens → $0.122
Daily volume: 500,000 messages
Daily cost at effort=0.99: ~$45,000
Latency: 4-8 seconds per response (too slow for balance check)
Step 2: Sweep effort levels against task categories
Using sample_reasoning.py from tinker-cookbook:
effort=0.2 on "Can I check my balance?" type queries:
→ 420 tokens generated
→ Accuracy on classification: 94.2% (vs 95.1% at effort=0.99)
→ 0.8pp accuracy loss at 20x cost reduction
→ Latency: 0.4 seconds
effort=0.5 on "transaction dispute" queries:
→ 2,100 tokens generated
→ Accuracy: 91.4% at classifying fraud vs. error
→ Latency: 1.2 seconds
effort=0.99 on "unusual pattern, possible fraud" queries only:
→ 11,800 tokens with full reasoning trace
→ Accuracy: 97.3% with calibrated confidence score
→ Latency: 6.1 seconds (acceptable; routed to analyst for review)
Step 3: Routed effort system
# Production routing based on query complexity
def get_effort(message: str, classifier_score: float) -> float:
if classifier_score < 0.3: # clearly simple queries
return 0.2
elif classifier_score < 0.7: # moderate complexity
return 0.5
else: # complex / potential fraud
return 0.99
# Outcome:
# 72% of queries → effort=0.2 (balance, basic FAQ)
# 21% of queries → effort=0.5 (transaction questions, dispute initiation)
# 7% of queries → effort=0.99 (suspected fraud, complex situations)
Step 4: Result
Daily cost with effort routing:
72% × 500K × $0.004 = $1,440
21% × 500K × $0.021 = $2,205
7% × 500K × $0.118 = $4,130
Total: $7,775/day vs $45,000/day at flat effort=0.99
Cost reduction: 82.7%
Accuracy impact: -0.4pp on classification task
Latency: 94% of queries respond in < 1.5 seconds
The effort sweep produces an 82.7% cost reduction at a 0.4 percentage point accuracy cost. This is the production case Thinking Machines Lab is making for controllable effort: not "effort=0.99 beats other models," but "the effort curve itself has value that a single benchmark number cannot capture."
Why This Design Works, and What It Trades Away
The encoder-free multimodal design is a philosophical bet. Most multimodal models use pretrained, dedicated encoders for vision and audio: a CLIP/SigLIP vision tower for images, a Whisper-type encoder for audio. These encoders are trained on their modality and provide high-quality representations. The cost is separate training dynamics, separate inference paths, and representations that are not jointly optimized with the language backbone.
Inkling processes audio as dMel spectrograms and images as 40x40 pixel patches via a 4-layer hMLP, both fed directly into the main token stream after a lightweight embedding layer. No separate encoders. One gradient flow for everything. This means the model can reason natively over combined multimodal inputs rather than fusing representations from separate towers. The benchmark results (VoiceBench 91.4%, Charxiv RQ with Python 82.0%) suggest the encoder-free approach is competitive, though the top closed models (Gemini 3.1 Pro, Claude Fable 5) still outperform on most tasks.
The relative positional embedding over RoPE is the most defensible architectural choice the team made. RoPE extrapolates poorly to contexts much longer than training: performance degrades roughly quadratically past the training context. Relative PE encodes token-to-token distance directly, which generalizes more naturally. For a model designed with a 1M token context, this is the right call.
The short convolutions on the residual branches are the most novel choice. Standard transformer residual streams carry global information; adding short convolutions before the residual add provides local temporal structure at the cost of additional parameters. This is consistent with the insight from hybrid attention-convolution models (e.g., Mamba hybrids) that local and global processing are complementary, but applying it specifically to the residual branches rather than the main activations is an unusual implementation.
What Inkling trades away:
The benchmark table is honest about the ceiling. HLE with tools: 46.0% vs Claude Fable 5 at 64.5%, GPT 5.6 Sol at 55.0%. SWEBench Pro: 54.3% vs Claude Fable 5 at 80.0%. SimpleQA: 43.9% vs Gemini 3.1 Pro at 77.3%. The model is not at the frontier on raw capability. Teams that need maximum task performance on a specific benchmark today should not use Inkling as a drop-in replacement for frontier closed models.
The forecast benchmark caveat: ForecastBench and Prophet Arena results were obtained on a different checkpoint than the one released, between June 30 and July 13. The released checkpoint may perform differently.
Terminal Bench 2.1 contamination: the team explicitly notes some solutions were found to be contaminated from web search and were scored 0. This is correct practice but makes the 63.8% number directly comparable to reported numbers from other teams less clear.
Technical Moats
The RL pipeline at 30M+ rollouts with log-linear improvement throughout. Most publicly documented RL training runs show reward saturation well before 30M rollouts. Sustaining log-linear improvement over two long continuous runs at that scale requires careful curriculum design (what problems are presented at what stage), a reliable async infrastructure that handles rollout failures gracefully, and graders that produce consistent and informative signal throughout. The dual-grader system (rubric grader for recall, claims grader with agentic web search for factual accuracy) is directly responsible for avoiding the tradeoff between helpfulness and accuracy that plagues simpler RLHF setups.
Emergent CoT compression as a signal of RL quality. The chain-of-thought compression that emerged over RL training ("We need to understand" → "We need determine") was not a targeted reward. The model discovered that shorter reasoning chains achieve similar scores with fewer tokens, and shifted its style accordingly. This emergent compression is a sign that the RL environment was well-designed: the model found genuine efficiency improvements rather than reward hacking. The Cognition SWE-1.7 team noted a similar effect. This pattern suggests a general property of well-structured RL: models learn to be more concise when token efficiency is implicitly penalized.
Inkling-Small's anomalous benchmark parity. Inkling-Small (12B active) nearly matches Inkling (41B active) on HLE with tools (46.6% vs 46.0%), GPQA Diamond (88.3% vs 87.2%), SWEBench Verified (77.4% vs 77.6%), and IFBench (83.4% vs 79.8%). The team attributes this to "improvements to the pre-training data and recipe for the smaller model." If Inkling-Small's full weights match these preview numbers, a 12B active parameter model at near-frontier reasoning performance is a significant result for the cost-efficiency use case the model family is targeting.
Insights
Insight One: The 1M token context window is not what this model is designed for in practice. The Tinker platform offers 64K and 256K context options. The 1M context exists architecturally but is not the primary deployment target. This matters because the architectural choices that support 1M context, specifically the relative positional embedding over RoPE and the 5:1 sliding-window-to-global attention ratio, add complexity and potentially hurt performance on shorter context tasks. Teams evaluating Inkling against other models on short-context tasks should not penalize it for architecture choices designed for contexts they are not using. Conversely, teams that actually need 1M context will find that Inkling's architecture is specifically designed for it in a way that most RoPE-based models are not.
Insight Two: The Design Arena Agentic Web Dev leaderboard placement (1257 ELO) puts Inkling in a competitive cluster with Claude Opus 4.6, Gemini 3.5 Flash, and Kimi K2.6, well below Claude Sonnet 5 (1333) and Claude Fable 5 (1329). This is an evaluation by blinded human judges on generated web apps, not a synthetic benchmark. It reflects real human preferences about code quality, design coherence, and functional correctness. The cluster at 1250-1260 is effectively tied. The important observation is that Inkling is competitive here against much larger or more expensive closed models for a task, generating production-quality web application code, that is directly relevant to the agentic coding use case Thinking Machines Lab emphasizes. The gap to the top is real and measurable, but the benchmark-appropriate conclusion is "comparable performance at open-weights" not "significantly worse."
Surprising Takeaway
The hybrid optimizer (Muon for large matrix weights, Adam for other parameters) and the weight decay coupling (decay strength proportional to learning_rate²) are production-validated hyperparameter choices from Thinking Machines Lab's research on modular manifolds. The Muon optimizer, introduced in 2024, computes updates using a sign of the gradient with a specific normalization derived from the Shampoo/spectral norm literature. Coupling weight decay to learning rate squared keeps weight norms stable across variable-length training runs and is grounded in recent theoretical work (Kosson et al 2023, Defazio 2025). Most publicly documented large model training runs use AdamW uniformly across all parameters. The choice to split by parameter type and couple the decay to the learning rate schedule represents a meaningful departure from standard practice, and the log-linear RL reward improvement across 30M+ rollouts suggests it worked. The training stability at this scale, without saturation across two long continuous RL runs, is not standard.
TL;DR For Engineers
Inkling (thinkingmachines/Inkling, open-weights, July 15, 2026): 975B total / 41B active MoE, 1M context, encoder-free multimodal (audio as dMel spectrograms, images as 40x40 pixel patches via 4-layer hMLP), controllable thinking effort (float 0.0-1.0). Trained on 45T tokens on GB300 NVL72. Pretrained + SFT + 30M+ async RL rollouts.
Architecture departures: relative positional embedding (not RoPE) for better length generalization; 5:1 sliding-window-to-global attention ratio with 8 KV heads; short convolutions after K/V projections AND on attention+MLP residual branches before rejoining main stream; MoE follows DeepSeek-V3 (256 routed + 2 shared experts, 6 active, sigmoid router with aux-loss-free load-balancing bias).
Effort sweep results: matches Nemotron 3 Ultra on Terminal Bench 2.1 at ~1/3 the tokens. Key benchmarks at effort=0.99: HLE tools 46.0%, AIME 2026 97.1%, GPQA Diamond 87.2%, SWEBench Verified 77.6%, Design Arena 1257 ELO, FORTRESS Adversarial 78.0% (best open-weights).
Inkling-Small (preview): 276B total / 12B active. Near-parity with Inkling on HLE tools (46.6% vs 46.0%), GPQA Diamond (88.3% vs 87.2%), SWEBench Verified (77.4% vs 77.6%). Full weights pending safety testing.
Tinker integration:
model_name = "thinkingmachines/Inkling", sweep learning rate AND effort. tml-renderers for multimodal inputs. Loss functions available: Cross-Entropy, PPO, CISPO, DRO, Importance Sampling, Custom. Available via: TogetherAI, Fireworks, Modal, Databricks, Baseten, SGLang, vLLM, llama.cpp, TokenSpeed, HuggingFace transformers.
The Right Base Model Is Not the Strongest Model
The Inkling launch stakes out a clear position: the base model that produces the best fine-tuned outcomes is not necessarily the strongest generalist. It is the model with the right combination of multimodal coverage, efficient thinking, and a platform designed for rapid adaptation.
The self-fine-tuning demo is the argument in its most compressed form. A model that can identify its own behavioral gaps, write its own training objective, generate its own synthetic data, and call its own fine-tuning API is a different kind of tool than a model you prompt and hope for the best. Whether that loop produces reliable, safe outcomes at scale is an open question. That it is technically possible with today's infrastructure is now demonstrated.
The benchmark numbers tell you what Inkling can do at inference time. The effort sweep and the fine-tuning platform tell you what it becomes after you work with it. Thinking Machines Lab is betting that the second number matters more.
References
dMel: Speech Tokenization made Simple, arXiv:2407.15835, He Bai et al, 2024
Three things everyone should know about Vision Transformers, arXiv:2203.09795, Touvron et al, 2022
Self-Attention with Relative Position Representations, arXiv:1803.02155, Shaw et al, 2018
Explain It Like I'm New
Most powerful AI models today are like specialist consultants: very good at their job, but you cannot customize them. You use them as-is, at whatever price the provider sets, with whatever capabilities they have decided to prioritize. If your specific use case needs the model to be more cautious with medical advice, or to respond faster but with slightly less detail, or to understand audio and images in addition to text, you are largely working around the model rather than with it.
Inkling is Thinking Machines Lab's attempt at a different model. It is "open-weights," meaning the underlying mathematical parameters are available for anyone to download and modify. It is designed specifically to be customized through a process called fine-tuning, where you show the model examples of the behavior you want and it adjusts itself accordingly. The company's platform, Tinker, provides the infrastructure to do this at reasonable cost.
What makes Inkling technically interesting is a feature called controllable thinking effort. Most AI models either reason slowly and carefully for every request or quickly for every request. Inkling learned, through a training process involving millions of examples with varying difficulty and cost signals, to adjust how much thinking it does based on what you ask of it. A simple question gets a fast, cheap answer. A hard question gets a slow, thorough one.
The demonstration where Inkling fine-tuned itself, deciding what training data to generate, writing the training script, and calling its own API, is not just a clever demo. It shows where this technology is heading: AI systems that can improve themselves on specific tasks without constant human intervention.
See It In Action
Inkling Introduction and Capabilities Demo Source: Thinking Machines Lab | https://thinkingmachines.ai/news/introducing-inkling/ The official launch post includes embedded video demos: the one-shot web app with embedded browser use, the multiplayer snake game built through 40 iterations of GPT Codex feedback, and the nine-page polished PDF food journal. Watch the web app demo specifically to understand what "agentic coding" means in practice at this model tier.
Inkling Self-Fine-Tuning Demo (OpenCode harness) Source: Thinking Machines Lab (embedded in blog post) | https://thinkingmachines.ai/news/introducing-inkling/#customizing-inkling The seven-panel walkthrough of Inkling fine-tuning itself: starting prompt, base model answer, fine-tuning intent, rubric generation, training, self-update, and updated model answer. The key technical insight is panel 2 vs panel 7: prompting cannot produce the no-"e" behavior, but 2 epochs of fine-tuning can.
Tinker Cookbook: Thinking Effort Guide Source: Thinking Machines Lab Documentation | https://tinker-docs.thinkingmachines.ai/cookbook/inkling/thinking-effort/ The technical reference for sweeping effort values, recommended defaults, and the runnable
sample_reasoning.pyscript that lets you compare effort values on your specific task before committing to a fine-tuning run. Start here before deploying Inkling in production.Inkling Playground Source: Tinker Console | https://tinker.thinkingmachines.ai/playground Free-for-limited-time developer interface with integrated agentic web search. The fastest way to get a qualitative sense of the model before evaluating it programmatically. The playground supports effort control and multimodal inputs.
Community Conversation
Thinking Machines Lab (@thinkymachines) on X: Inkling announcement https://x.com/thinkymachines The official launch thread highlights the self-fine-tuning demo and the open-weights commitment. The framing is "a model you can make your own" rather than "the strongest model" — an explicit positioning choice against Anthropic, OpenAI, and Google.
Tinker API (@tinkerapi) on X: Forecasting fine-tune outperforms frontier LLMs https://x.com/tinkerapi/status/2056798250532057139 A prior Tinker result showing that fine-tuned models on forecasting tasks can outperform frontier closed models. Context for why Thinking Machines Lab cites calibrated forecasting as a key differentiator for Inkling: they have production evidence that fine-tuning on this task works, and Inkling was trained to be a good base for exactly this kind of improvement.
Cognition team blog: SWE-1.7 emergent CoT compression https://cognition.com/blog/swe-1-7 The Inkling post explicitly cites the Cognition SWE-1.7 observation that chain-of-thought compression emerged during RL training there too. Two independent teams observing the same emergent pattern (shorter reasoning, same performance, no targeted reward) is meaningful signal about the general dynamics of well-structured RL at scale.
Cognition team blog: Measuring the Trustworthiness of Open-Source-Derived Models https://cognition.com/blog/measuring-open-source-model-trustworthiness Cognition evaluated Inkling on their Propaganda and Censorship Eval and found strong censorship non-compliance patterns. This is cited in the Inkling blog as evidence of epistemic quality: the model answers directly on topics that may be subject to censorship. Worth reading for the evaluation methodology.
Inkling (thinkingmachines/Inkling, open-weights, Thinking Machines Lab, July 15, 2026) is a 975B-total/41B-active Mixture-of-Experts transformer with 1M token context window, pretrained on 45 trillion tokens of text, images, audio, and video on NVIDIA GB300 NVL72. Architecture departures from the standard recipe: relative positional embedding over RoPE for better length generalization; 5:1 sliding-window-to-global attention ratio with 8 KV heads; short convolutions applied at two unusual points (after K/V projections, and on attention+MLP residual branches before rejoining the main stream); encoder-free multimodal inputs (audio as dMel spectrograms, images as 40x40 pixel patches via 4-layer hMLP); MoE following DeepSeek-V3 (256 routed + 2 shared experts, 6 active per token, sigmoid router with auxiliary-loss-free load balancing); hybrid optimizer (Muon for large matrix weights, Adam for others) with weight decay coupled to learning_rate². Post-training: SFT bootstrapped on synthetic data from open-weights models including Kimi K2.5, followed by 30M+ asynchronous RL rollouts with log-linear reward improvement throughout. Controllable thinking effort (float 0.0-1.0) trained via system message + per-token cost during RL. Key benchmarks at effort=0.99: HLE with tools 46.0%, AIME 2026 97.1%, GPQA Diamond 87.2%, SWEBench Verified 77.6% (bash-only), Terminal Bench 2.1 63.8%, Design Arena 1257 ELO, FORTRESS Adversarial 78.0% (best open-weights vs Nemotron/Kimi/GLM/DeepSeek). Inkling-Small (276B/12B active, preview): near-parity with full model on most reasoning benchmarks, full weights pending. Available on Tinker, TogetherAI, Fireworks, Modal, Databricks, Baseten, SGLang, vLLM, llama.cpp, and HuggingFace transformers. NVFP4 checkpoint for Blackwell inference.
Sponsored Ad
If you enjoy practical AI insights, check out SnackOnAI and support the newsletter by subscribing, sharing, and exploring our sponsored ad — it helps us keep building and delivering value 🚀
Write docs 4x faster. Without hating every second.
Nobody became a developer to write documentation. But the docs still need to get written — PRDs, README updates, architecture decisions, onboarding guides.
Wispr Flow lets you talk through it instead. Speak naturally about what the code does, how it works, and why you built it that way. Flow formats everything into clean, professional text you can paste into Notion, Confluence, or GitHub.
Used by engineering teams at OpenAI, Vercel, and Clay. 89% of messages sent with zero edits. Works system-wide on Mac, Windows, and iPhone.