What is Inkling?
Inkling is Thinking Machines Lab's first public model, and the lab is refreshingly upfront that it isn't trying to win the leaderboard. The pitch is a broad, balanced open foundation that you fine-tune for your own use, using the lab's Tinker platform. In other words, Inkling is meant to be a starting point you shape, not a chatbot you subscribe to.
The specs that matter, straight from the model card:
- Architecture: a Mixture-of-Experts (MoE) transformer, 975B total parameters with 41B active per token (it routes each token through 6 of 256 experts, plus 2 shared experts). That's why a roughly trillion-parameter model can be served at a sane speed, only a slice of it runs on any given token.
- Inputs: text, images, and audio (16 kHz WAV, best under about 20 minutes). Output is text only.
- Context window: up to 1M tokens, which ties it with the top tier of models on length.
- License: Apache 2.0, so commercial use is allowed and the weights are on Hugging Face.
- Released: July 15, 2026.
The audio part is the novel bit. As the top comment on the launch thread put it, this is the "largest open weight model that supports audio," which matters if you ever want a model to listen to a support call rather than just read a transcript of it.
How Inkling is built
If you like the plumbing, Inkling makes a couple of unusual architecture choices. Instead of the now-standard rotary position embeddings (RoPE), the team's own writeup describes a relative-position scheme baked into the attention logits, plus short convolutions on the keys and values before they hit the cache. The practical goal is the same one every long-context model is chasing: keep attention stable and cheap when the context stretches toward a million tokens.
You don't need to parse the diagram to get the takeaway: Inkling is engineered around long context and efficient reasoning, not around topping a single benchmark. That shows up again in the way it thinks.
The thinking-effort dial
Inkling is a reasoning model, and it exposes a controllable "thinking effort" setting. In the Hugging Face integration that's a reasoning_effort level running from none and minimal up through low, medium, high, xhigh, and max. Turn it down and the model answers fast and cheap; turn it up and it spends more tokens thinking before it replies.
The claim Thinking Machines leans on here is token efficiency: they say Inkling reaches the same Terminal-Bench score as Nemotron 3 Ultra while spending about a third of the tokens getting there. For anyone paying per token or renting a GPU, "same answer, fewer tokens" is a more useful number than a fractional benchmark win.
The benchmarks: strong, not king
Here's where you have to separate the vendor's pitch from the independent read. Thinking Machines' own tables show flattering numbers at maximum effort, but the cleaner signal comes from Artificial Analysis, which benchmarks everyone the same way.
Their verdict: Inkling scores 41 on the AA Intelligence Index, which is #10 of 97 on their curated leaderboard, well above the ~25 average for open-weights models of its size. So it's a smart model. But it sits below the frontier leaders (Claude Fable 5, GPT-5.6, Kimi K3, Grok 4.5, GLM-5.2) and lands in a cluster with peers like DeepSeek V4 Flash. Community trackers that fold in more models put it lower still, nearer #41, which is where the "is 'competitive' fair?" debate came from.
| Evaluation (Artificial Analysis) | Inkling | What it tests |
|---|---|---|
| GPQA Diamond | 87% | Scientific reasoning |
| AA-LCR | 63% | Long-context reasoning |
| Terminal-Bench v2.1 | 55% | Agentic coding + terminal use |
| SciCode | 46% | Coding |
| AA-Omniscience (accuracy) | 40% | Knowledge |
| GDPval-AA v2 | 37% | Real-world work tasks |
| Humanity's Last Exam | 30% | Reasoning + knowledge |
| CritPt | 5% | Physics reasoning |
Read that table honestly and you get a real personality: Inkling is strong on scientific and long-context reasoning and noticeably weak on physics and raw knowledge reliability (its AA-Omniscience knowledge-reliability index is a lowly 2 on a −100-to-100 scale). It's a model with sharp edges, not a smooth all-rounder.
The launch thread caught the same thing. Praise and skepticism sat side by side:
"I just looked at the benchmarks and was kinda disappointed that it seems to be between KimiK2.6 and KimiK2.7 on most of the benchmarks."
And the most useful reply in the whole thread, the one worth taping to your monitor before you trust any model comparison:
"want to know how good a model is? Run it with your own non-public benchmark, basically the only way to get proper answers you can somewhat rely on, everything else is manipulated, misunderstood or over-relied on."
That instinct, that the only benchmark that counts is your own data, is exactly the one I'd hold onto if you ever point a model at your support queue. More on that below.
How much does Inkling cost?
This is the part that surprised me. Inkling is open weights, and yet on Thinking Machines' own API it's priced like a proprietary frontier model. Per Artificial Analysis, it lands at #81 of 97 on price, i.e. among the most expensive in its class.
| Access path | What you pay | Notes |
|---|---|---|
| Thinking Machines API - input | $1.87 / 1M tokens | Class average is ~$0.43; this is expensive |
| Thinking Machines API - output | $4.68 / 1M tokens | Class average is ~$1.25 |
| Blended rate | ~$1.10 / 1M tokens | At a 7:2:1 cache:input:output mix |
| Cache read/write | $0.374 / 1M tokens | Cache hit is −80% vs input |
| Self-host the weights | $0 for the model | Apache 2.0; you pay for hardware instead |
| Tinker fine-tuning | Paid service | The lab's actual business model |
Two things stand out. First, there's currently one API provider, Thinking Machines itself, so there's no cheaper third-party host undercutting them yet. Second, "open weights" only makes it free if you're willing to run it, which is a real decision, not a footnote.
Running Inkling yourself
Because the weights are open, the community had it running locally on day one. The Hugging Face launch blog lays out three rough tiers, which the ladder above summarizes: the full BF16 checkpoint wants around 2 TB of VRAM (data-center territory), the NVFP4 quant drops that to about 600 GB on Blackwell hardware, and community 1-bit GGUF builds cut it by roughly 95%, enough to run a heavily-quantized version on a beefy workstation.
Support landed fast, too: day-zero integration in transformers 5.14, SGLang, vLLM, and llama.cpp/Unsloth, plus speculative-decoding drafter layers for a lossless speed-up. Here's a 1-bit build actually running in Unsloth's studio, writing a full HTML game and "thinking" for 321 seconds against a million-token window:
That "run it yourself" story is the real reason to care about Inkling. If you're weighing an open model against a closed one, the tradeoff is control versus convenience: you own the weights, your data never leaves your infrastructure, and nobody can deprecate the model out from under you, but you're now on the hook for the GPUs.
The enterprise angle
For teams that want the control without babysitting a GPU cluster, Inkling showed up on Databricks on day zero, reachable through the Unity AI Gateway with governance built in. The enterprise argument they make is the same one that makes open weights attractive: fine-tune on your own data, keep it inside your governance boundary, and skip per-token pricing.
Should you reach for Inkling?
Rather than a "depends on your needs" cop-out, here's a straight decision path based on what Inkling is actually good and bad at.
Inkling is a strong fit. Apache 2.0, downloadable, and it runs locally down to a 1-bit build. Budget for the GPUs.
Few open models match this. Inkling is one of the only ones. Reach for it.
Look elsewhere. At $1.87 in / $4.68 out, cheaper open-weights peers (GLM, Qwen, DeepSeek) win on price.
A model alone won't answer tickets safely. You want a platform that wraps a model in your knowledge, guardrails, and testing. Keep reading.
What the community actually thinks
The Hacker News launch thread (1,214 points, ~292 comments) is the clearest snapshot of how developers received Inkling. The mood was enthusiastic but measured, and the excitement was less about scores and more about who shipped it:
"Not to mention - it is American. This is the first competitive non-Chinese open weights model since what, Llama 3?"
That framing got pushback (people named Mistral, Cohere's North, Gemma, and others as counter-examples), but the underlying sentiment, that a credible Western open-weights option was overdue, ran through the whole thread. There was also a healthy dose of "how does a company that gives its model away survive?", with the answer landing on Tinker, the hosted fine-tuning business:
"Tech history is littered with the corpses of "open source but we sell hosting" services. Models are so expensive to train, you can't be losing the big clients once they get super profitable."
Whether that model holds is the open question hanging over Inkling. But for right now, developers got a capable, multimodal, fully open model to poke at, and most of them were happy about it.
What a model like Inkling means for customer support
Here's where I've spent the last few years, so let me be direct about it. I build the agent layer that sits on top of models like Inkling, and the thing I've learned watching real rollouts is this: a better base model rarely changes what actually ships to a support queue.
A raw model, however smart, doesn't know your refund policy, can't see the last 40,000 tickets your team already solved, and has no idea when it should shut up and hand off to a human. Point it straight at customers and it will answer confidently and wrongly, which is worse than not answering. That failure mode, the confident-but-wrong bot, is the exact reason AI hallucinations in support get teams burned, and it's why the model is only ever the engine.
The car is the layer around it. That's what eesel is: it learns from your solved tickets and help docs (not just a marketing page), routes on confidence so low-certainty answers get drafted instead of sent, and, the part I care most about, it lets you simulate the agent against your own past tickets before a single customer sees it. That simulation is the "run it on your own benchmark" advice from Hacker News, turned into a product step.
It also means you don't need to bet your support stack on any single model. The best model changes every few weeks (Inkling today, something else next month), so eesel stays model-agnostic and rides whichever one is strongest, while the part that matters to your customers, the knowledge, the guardrails, the ticket triage, stays put.
Try eesel
Inkling is an interesting release, but a model card is not a support agent. If your actual goal is to automate tier-1 support, what you need is the layer that turns any strong model into a teammate: eesel plugs into your existing helpdesk (Zendesk, Freshdesk, Gorgias, HubSpot, Front and 100+ others), learns from your history, and lets you simulate on real past tickets before you go live, so you see coverage and accuracy first, not after a customer catches a bad reply. Gridwise used exactly that approach to resolve 73% of tier-1 requests in their first month.
Pricing is usage-based at around $0.40 per resolved ticket, with no per-seat fees, and you can start free. It's the difference between admiring a great engine and actually driving somewhere.
Frequently Asked Questions
What is Inkling?
Is Inkling free and open source?
How much does Inkling cost to use?
How does Inkling compare to GLM, Kimi, and DeepSeek?
Can I use Inkling for customer support?
Who makes Inkling and what is Tinker?
Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.
