Inkling-Small Beats Its Own Parent Model on Coding

Inkling-Small is an open-weights agentic coding model that outscores the model it was distilled from. Thinking Machines Lab released it on July 30, 2026 — a Mixture-of-Experts transformer with 276 billion total parameters and 12 billion active per token — and the vendor’s own benchmark table puts it ahead of the 975B/41B Inkling on SWEBench-Verified, Humanity’s Last Exam and GPQA Diamond. A quarter of the size, ahead on the benchmarks teams actually buy for.

The reason that matters is narrower than the headline suggests. Serving compute scales with active parameters, not total ones, and 12B active against 41B active is a different cost structure for anyone running a coding agent on their own hardware. That is the honest core of this release: not that a small model won a leaderboard, but that the cheapest thing to serve in the family is now also the best at the specific job most agent stacks are built around.

It is also a genuinely two-sided trade, and the vendor says so plainly. Inkling-Small’s SimpleQA Verified score falls to 20.6% against the parent’s 43.9% — the single largest gap anywhere in the comparison. This guide works through the full per-benchmark ledger, flags the one coding win that does not survive an independent rerun, separates the three pricing surfaces, resolves the context-window numbers that disagree across sources, and translates active-parameter counts into what they actually change for a self-hosted agent stack.

Thinking Machines Lab published Inkling — its 975B-total, 41B-active open-weights model — on July 15, 2026. Fifteen days later, on July 30, it shipped Inkling-Small. The vendor added an update note to the July 15 post reading, in its own words: “Update: Two weeks after this post was published, we launched Inkling-Small.” We covered the original release in our coverage of Inkling’s July 15 launch, which is the baseline every number below is measured against.

Inkling-Small is a 42-layer decoder-only sparse MoE transformer: 256 experts, six routed plus two shared active per token, hybrid local/global attention layers, trained on NVIDIA GB300 NVL72 systems. It takes audio (dMel spectrograms) and images (40×40-pixel patches through a four-layer hMLP) natively, encoder-free, processed jointly with text tokens; output is text only. Weights are on Hugging Face under Apache 2.0 — confirmed both on the Inkling-Small model card and in the Hugging Face repo metadata — with fine-tuning through Tinker and chat access through Tinker Playground.

The architecture lineage is worth naming because the vendor names it itself: Inkling’s MoE design “largely follows DeepSeek-V3” — 256 routed plus two shared experts, a sigmoid router with auxiliary-loss-free load balancing, interleaved sliding-window and global attention at a 5:1 ratio with eight KV heads, and relative positional embeddings rather than RoPE, which the vendor says extrapolates better to long context. If you want the wider frame on how these routing choices differ across labs, see how Inkling’s MoE routing compares to GPT, Claude, DeepSeek and Qwen.

Most coverage of this release repeats the vendor’s summary framing — reasoning and coding up, factuality down — without showing readers the actual spread. The table below is the full per-benchmark ledger, grouped by capability class, with the harness named on every row.

The margin column is computed as Inkling-Small minus Inkling, in percentage points for percentage metrics and in index points where the metric is an index or a score. A positive margin means the smaller model is ahead. Nothing here is weighted, normalised or averaged across benchmarks — a composite score would hide exactly the thing this table exists to show.

Read the margin column as a whole and the shape of the release becomes obvious. Every win Inkling-Small posts is between half a point and three points. Every loss in the knowledge column is measured in eight to twenty-three points. This is not a model that got broadly better while shrinking; it is a model that had a large amount of stored world knowledge traded away to buy a few points on the reasoning and coding evals it was optimised against.

That is a perfectly reasonable engineering decision — and a terrible one to generalise from. A coding agent that reads a repository, runs tests and edits files is not being asked to recall obscure facts unaided; it is being asked to reason over context it was handed. A research or support agent answering unaided questions is doing precisely the opposite, and there the parent’s 43.9% against Small’s 20.6% is the number that governs.

The coding numbers in the table above come from Thinking Machines’ own evaluation harness. The vendor says so itself, and it publishes a footnote for Terminal-Bench specifically: the Inkling and Inkling-Small numbers are reported using an internal coding harness, and a small number of solutions found to be contaminated from web search were assigned a score of 0. That is a good-faith disclosure, not an evasion — but it also means the result depends on a scaffold nobody outside the lab can reproduce.

Artificial Analysis ran its own independent evaluation of both models and published the results on the same day as the release. Two of the vendor’s claims come through largely intact. One does not.

The practical rule this produces is simple and worth applying beyond this one release. When a vendor and an independent evaluator agree on the direction and rough size of a gap — as they do on Humanity’s Last Exam, GPQA and AA-Briefcase — you can plan around it. When only the vendor’s harness separates two models, as with Terminal-Bench, treat the gap as an artifact of the scaffold until someone else reproduces it. Inkling-Small’s SWEBench-Verified lead sits in an uncomfortable middle: it is vendor-primary and precisely stated, but none of the independent coverage reviewed for this piece carried a SWEBench-Verified rerun of either model to check it against.

This is the part of the story that most coverage skipped. In a Mixture-of-Experts model, only a fraction of the network fires for any given token. Compute per token scales with the active parameter count, while the memory needed to hold the model resident scales with the total count. Inkling-Small changes both at once, and by almost the same proportion.

The table below computes each ratio as Inkling-Small ÷ Inkling × 100, rounded to the nearest whole percent, using only figures the vendor published itself. The comparison is a proxy, not a measured throughput benchmark — real serving cost also depends on batch size, expert routing efficiency, quantization format and KV-cache pressure. But it is a proxy built entirely from primary numbers.

The alignment across those three rows is the finding. Compute drops to 29%, resident memory drops to 28%, and the vendor’s own list output price drops to 30%. Thinking Machines did not publish a cost-per-token model, but its pricing decision is consistent with one: it is charging in proportion to the active parameters it has to spend, and the difference between the parameter ratio and the price ratio is smaller than a rounding artifact.

There is one lever this table deliberately leaves out, because it does not follow the parameter ratio at all: KV-cache memory. That scales with the context you actually serve and the number of concurrent sessions, not with active or total parameters. Cut your model to 28% of its weight footprint and then run it at a half-million-token context across a fleet of agents, and KV cache becomes the binding constraint rather than the weights. Section 06 is about why that number is harder to pin down than it should be.

Inkling-Small’s pricing is published in three different places and they do not fully agree. The output price is identical everywhere — $1.20 per 1M tokens — which makes it safe to quote without a qualifier. The input price is not, and quoting it without naming the surface is how a cost model ends up wrong by two-thirds. Every figure in the table below is what the named surface showed when it was checked for this piece; provider listings move, so re-read them before they go into a budget.

The gap between $0.30 and $0.50 on input is 67% — meaningful for any workload that is input-heavy, which agentic coding emphatically is. Repository context, file reads and tool outputs dominate the token bill in a coding agent; output tokens are comparatively thin. If your cost model was built on the vendor-API input rate and you actually route through OpenRouter, the bill lands well above the projection. Cache-hit pricing at $0.06 per 1M on the vendor API is the other side of that: a coding agent that re-reads the same repository context across a long session is close to the ideal cache-hit workload, and that discount is larger than any benchmark margin in this post.

Artificial Analysis’ model page for Inkling-Small puts throughput on the Thinking Machines API at 95.1 output tokens per second, with time-to-first-token of 1.67 seconds. Neither figure is remarkable in either direction; both are worth measuring against your own prompts before assuming they hold under your concurrency. If cheap inference in bulk is the shape of your problem, the same discipline applies across vendors — see our playbook for bulk workloads on cheap inference.

There is no single correct context-window number for Inkling-Small, and any post that prints one is choosing a surface without telling you. The vendor states “up to 1M tokens” for both Inkling and Inkling-Small. The OpenRouter listing checked for this piece listed 524,288 tokens. Artificial Analysis’ article text describes a 256K token context window, while Artificial Analysis’ own model-listing page for the same model says 1M — an inconsistency inside a single analyst’s coverage.

The most instructive data point is one the vendor volunteered about the parent. On Tinker, Thinking Machines’ own fine-tuning and serving platform, Inkling is offered with context length options of 64K and 256K tokens. The lab that trained the model to “up to 1M” chose to serve it at a quarter of that or less. That is not dishonesty; it is what KV-cache economics look like when someone has to pay for the memory.

This distinction is going to matter more, not less, over the next few releases. Long-context training has outrun long-context serving economics across the whole open-weights field, and the gap keeps widening as labs advertise the trained ceiling while platforms quote what they can afford to hold in memory. The honest question for any agent stack is not “what is the context window” but “what context length can I sustain across N concurrent sessions at my memory budget” — and those two numbers have been diverging all year.

Inkling-Small is not a from-scratch build. Thinking Machines post-trained an earlier checkpoint it had already shipped — “Inkling-Small (preview),” announced alongside the parent on July 15 with its own, lower preliminary benchmark table — in part using on-policy distillation with Inkling as the teacher model. Starting from that checkpoint, the lab continued scaling agentic-coding reinforcement learning for two weeks.

That sequence explains the shape of the ledger better than the headline does. On-policy distillation transfers the teacher’s behaviour on the student’s own generated trajectories — it is good at moving reasoning patterns and tool-use habits, and much worse at moving the stored factual knowledge that lives distributed across a 975B-parameter network. Then two weeks of RL pointed specifically at agentic coding sharpened exactly the axis that RL reward signals can reach. Reasoning and coding up, factuality down, is the predicted outcome of that recipe rather than a surprise.

The parent’s own training is the other half of the context: 45 trillion pretraining tokens spanning text, images, audio and video, a hybrid optimizer using Muon for large matrix weights and Adam for the rest, weight decay coupled to the square of the learning rate for stability, and RL scaled past 30 million rollouts across two long continuous runs. That is the knowledge base Inkling-Small was distilled from — and the reason its factuality gap is a distillation artifact rather than a training defect.

The two-week cadence is itself the news. A fifteen-day turnaround from parent release to a distilled sibling that outscores it on the evals buyers care about suggests the fast-follow small model is becoming a standard release pattern rather than an occasional one. For a longer view of how that pattern developed across the field, see the H1 2026 open-weight retrospective.

The decision this release forces is narrower than “should we switch models.” It is a routing decision, and the ledger above answers it per workload class rather than in aggregate.

That last row deserves a sentence of its own, because open weights are not a single legal category. Inkling-Small’s Apache 2.0 licence imposes no revenue threshold and no commercial-inference gate, which is materially different from Kimi K3’s more restrictive open-weights licence. If your deployment plan involves serving the model to paying customers, the licence text is a harder constraint than any benchmark on this page.

Our read on where this goes: the interesting frontier for self-hosted agent infrastructure is no longer the largest model a lab will publish, but the smallest active-parameter count that clears the bar on the specific eval a stack is built around. A 12B active model at 80% on SWEBench-Verified puts a serious coding agent within reach of hardware budgets that could not have hosted the parent at all, and the distillation recipe that produced it is repeatable. Expect more parent-plus-fast-follow pairs, and expect the factuality gap to be the recurring cost — which makes retrieval architecture, not model selection, the thing worth investing in. If you are evaluating open weights against closed frontier for specific pipelines, our AI transformation engagements start with exactly this kind of comparative eval, and our engineering team builds the retrieval and evaluation harnesses that make the comparison mean something.