Table of Contents
Inkling vs Kimi K3: Which July 2026 Open-Weight Model Should AI Builders Use?
Pick Inkling if you need open weights you can download and fine-tune this week; pick Kimi K3 if you want the stronger coding agent and can call an API until its weights land July 27. That is the decision, and the specs underneath it are less symmetric than the two launch posts make them look. Both models shipped inside 24 hours of each other, Inkling on July 15 and Kimi K3 on July 16, and a builder choosing an open-weight base right now has two options that did not exist a week ago. One of them you can pull today. The other you can call today, but you cannot own until the 27th.
Here is the shape of it before the details. Thinking Machines built Inkling to be adapted: 975B total parameters, Apache-2.0, full weights live on Hugging Face, and a fine-tuning platform (Tinker) that is the actual product. Moonshot built Kimi K3 to be big and to code: 2.8 trillion parameters, a live API, and the strongest agentic-coding scores any open-weight model has posted, with weights promised by July 27. Neither is a frontier model, and both labs say so. What separates them for a product team is not raw ranking. It is what you plan to do with the model.
What each one actually is
Inkling is a Mixture-of-Experts transformer, 975B total parameters and 41B active per token, pretrained on 45 trillion tokens of text, images, audio, and video, per the Thinking Machines launch post. It reasons over text, images, and audio in one model and carries a context window up to 1M tokens. The Hugging Face model card lists it as Apache-2.0, which means you can ship a fine-tuned version inside a commercial product without a royalty (Hugging Face model card). Alongside it, Thinking Machines previewed Inkling-Small at 12B active parameters, though its full weights are not out yet. The pitch is stated plainly in the post: "Inkling is not the strongest overall model available today, open or closed." It is a broad base designed to be tuned on your data.
Kimi K3 is a sparse MoE with 2.8 trillion total parameters that activates only 16 of its 896 experts per token, so the per-token compute sits closer to a 16B model than a 2.8T one, per MarkTechPost. Moonshot calls it the world's largest open-weight model by parameter count. It ships a 1M-token window with native vision, a new attention scheme (Kimi Delta Attention) tuned for fast long-context decoding, and quantization-aware training baked in from the SFT stage. The API is live now through an OpenAI-compatible endpoint. The weights are not: Simon Willison's write-up quotes Moonshot promising an open-weight release "by July 27, 2026" (Simon Willison, July 16).
The benchmark reality: coding flips the story
The tidy assumption is that the bigger model is the better model across the board. It is not, and the split is what makes this choice interesting.
On instruction-following and general reasoning, Inkling holds its own for an open-weight base. It sits at #20 of 200 on the BenchLM public leaderboard with an overall score of 67.54, and its single strongest category there is instruction-following, ranked #11 (BenchLM, verified July 19). The launch post puts it at 77.6% on SWE-bench Verified and 79.8% on IFBench. Respectable numbers for a model you can download and tune.
Coding is where it slips. BenchLM lists coding as Inkling's weakest tracked category, ranked #92, and the launch post's own hard-coding rows show it trailing Chinese open-weight releases: 54.3% on SWEBench Pro against GLM 5.2's 62.1% (BenchLM, Thinking Machines). If you were expecting an agentic-coding champion, this is not it.
Kimi K3 is. On SWE Marathon, the benchmark that rewards a model for browsing a real repo, writing a patch, and running tests across many steps, K3 posts 42.0 against Claude Fable 5's 35.0 and GPT-5.6 Sol's 39.0 on Moonshot's own suite, per MarkTechPost. It leads BrowseComp too, at 91.2. Read those as vendor-reported numbers, because they are, but the direction is corroborated: Artificial Analysis placed K3 behind only Fable 5 on long-horizon knowledge work, per Willison. For multi-step agent loops that fit inside a 1M window, K3 is the stronger coder of the two by a clear margin.
The candid con on K3's benchmarks: they cover the multi-step agentic case, not the hard single-shot problem, where frontier closed models still lead. And they are self-reported at a single reasoning setting.
The hardware and access reality
This is the part the parameter counts hide, and it is where the "which is available" question gets real.
Inkling's weights are downloadable today, but the checkpoint ships as an NVFP4 format built for NVIDIA Blackwell systems, so running the full 975B model on standard cloud GPUs is not practical right now (launch post). At 4-bit that footprint is roughly 490GB (975B parameters at half a byte each), which would fit an 8-GPU node on memory alone, but the Blackwell-specific format is the catch. The accessible routes are the ones Thinking Machines built for exactly this: fine-tune and serve on Tinker, or call the base model through partners like OpenRouter at $1 input and $4.05 output per million tokens (OpenRouter listing, pulled 2026-07-20). Tinker's own serving rates are $1.87 input and $4.68 output per million, currently under a limited-time 50% launch discount that roughly doubles the rate when it lifts (Tinker pricing, pulled 2026-07-20).
Kimi K3 is the opposite trade. You can call it today through Moonshot's API, and the pricing is aggressive for long-context agent loops: cache-hit input at $0.30 per million tokens, cache-miss at $3.00, and output at $15.00, per MarkTechPost. Moonshot reports above 90% cache hits in coding workloads, where an agent resends the same repo map on every step. But the self-host path is heavy. At MXFP4 quantization, 2.8 trillion parameters is roughly 1.4TB of weights before the KV cache, and Moonshot recommends supernode configurations of 64 or more accelerators, not a single card (MarkTechPost). An 8x H100 80GB box (640GB) cannot hold it; you are looking at large-memory nodes like 8x MI300X (1,536GB) at the smallest, and even those Moonshot frames as below its recommendation. Neither model runs on a laptop, and neither runs on a single consumer card.
Side-by-side decision table
| Criterion | Inkling | Kimi K3 | Source |
|---|---|---|---|
| Released | July 15, 2026 | July 16, 2026 | TM / SW |
| Weights available | Now, on Hugging Face | Promised by July 27 (API live now) | HF / SW |
| Total / active params | 975B / 41B | 2.8T / 16 of 896 experts | TM / MTP |
| Context window | Up to 1M (256K via Tinker) | 1M | TM / MTP |
| License | Apache-2.0 | Open weights (terms land July 27) | HF / SW |
| Coding rank | Weakest category (#92 on BenchLM) | Leads open-weight agentic coding (SWE Marathon 42.0) | BenchLM / MTP |
| Fine-tuning | Purpose-built on Tinker | Impractical for most (weights pending, 1.4TB) | TM / MTP |
| Self-host footprint | ~490GB, NVFP4 (Blackwell) | ~1.4TB MXFP4, 64+ accel supernode | TM / MTP |
| API price (per 1M) | $1/$4.05 OpenRouter; $1.87/$4.68 Tinker | $0.30 cache-hit / $3.00 miss in, $15 out | OR / MTP |
All prices pulled 2026-07-20. Tinker's Inkling rates carry a limited-time 50% discount that will lift.
Which one to pick, by use case
1. You want a fine-tuned domain model on private data: Inkling
This is the case Inkling was built for, and it is the cleanest win of the piece. You have proprietary data (legal, medical, internal tooling, a support corpus) that shifts model behavior, and you want to own the tuned weights. Inkling is downloadable, Apache-2.0, and the Tinker fine-tuning loop is live. The economics favor it hard: a fine-tuned Inkling on Tinker serves at roughly a tenth of frontier API token prices, and even after the 50% launch discount lifts it stays about four times cheaper than a hosted Claude plan on an input-heavy workload (Tinker pricing). K3 is a non-starter here: its weights are not out until July 27, and full fine-tuning on 2.8 trillion parameters is out of reach for almost any team. Where the pick flips: if your task is squarely hard coding, no fine-tune closes Inkling's coding gap, and you should be reading use case 2.
2. You want the strongest open-weight coding agent, via API today: Kimi K3
If the job is an agent that opens a repo, holds the module graph in context, and grinds through a refactor over many tool calls, K3 is the pick right now. It leads SWE Marathon and BrowseComp among open-weight models, the API is live, and the cache-hit pricing rewards exactly the repo-context-reloading pattern coding agents produce. You do not own the weights until July 27, but you also do not need to for an API-backed dev loop. The candid con: K3 has a single reasoning effort, max, and it is heavy. Willison watched it spend over 13,000 reasoning tokens on a trivial prompt, so short one-shot queries cost more than the sticker input rate suggests (Willison). Warm cache and long context are where it pays.
3. You need data-sovereign self-hosting at frontier scale: wait for K3 (budget a supernode)
Compliance rules out sending inputs to a US lab, and you want the biggest open-weight model on your own hardware. That is K3's territory, once the weights land. Plan for July 27, then price the cluster honestly: roughly 1.4TB of weights and Moonshot's own recommendation of 64-plus accelerators mean this is a multi-node build, not a single box (MarkTechPost). If a single 8-GPU node is your ceiling and you need weights sooner, Inkling's ~490GB footprint is an order of magnitude smaller, though its Blackwell-format checkpoint still constrains where it runs. For most teams below serious volume, an API is cheaper and simpler than either self-host until the numbers force the move.
4. You want low-cost long-context agentic inference right now: Kimi K3
Purely on API cost for long, cache-warm agent sessions, K3's $0.30-per-million cache-hit input is the number to beat, and its $15 output rate is the lowest of the frontier-adjacent coding models (MarkTechPost). Inkling via OpenRouter ($1/$4.05) is cheap too and better if your workload is multimodal or headed for a fine-tune, but for a pure long-context coding loop, K3 wins on price and on coding quality at once. The flip condition: short prompts. On sub-8,000-token queries, K3's reasoning overhead erases the cache advantage, and a hosted frontier model is both cheaper and stronger.
How to wire either one into your stack today
Both models speak the OpenAI protocol, so any agent that accepts a custom endpoint runs them with one config change. Here is how to try each with a single request before you wire in anything heavier.
Inkling through OpenRouter, no fine-tune, OpenAI-compatible:
curl https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "thinkingmachines/inkling",
"messages": [{"role": "user", "content": "Summarize this contract clause."}]
}'Kimi K3 through Moonshot's native API. Note the constraints from the docs: reasoning_effort accepts only max, and you should omit temperature, top_p, and n, which are fixed (MarkTechPost):
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
completion = client.chat.completions.create(
model="kimi-k3",
reasoning_effort="max",
messages=[{"role": "user", "content": "Refactor this module for testability."}],
)
print(completion.choices[0].message.content)To fine-tune Inkling instead of just calling it, install the Tinker SDK, set your key, and point a LoRA client at the base model (Tinker quickstart):
uv pip install tinker
export TINKER_API_KEY="<YOUR_API_KEY>"import tinker
service_client = tinker.ServiceClient()
training_client = service_client.create_lora_training_client(
base_model="thinkingmachines/Inkling", rank=32
)Both drop into an IDE agent the same way. In Cline, add an OpenAI-compatible provider and swap the base URL and model for whichever you are running:
{
"provider": "openai-compatible",
"baseUrl": "https://api.moonshot.ai/v1",
"apiKey": "<YOUR_MOONSHOT_API_KEY>",
"model": "kimi-k3"
}Send one request before you wire either into a real loop, and read the usage block. On K3 at max effort you should see a reasoning-token count that dwarfs the visible output, which is your early signal that short prompts will cost more than the input sticker rate. On Inkling you should see a straight completion at the OpenRouter rate above. If your agent already points at an OpenAI-compatible endpoint, the switch between the two is a one-line change to the base URL, so testing both against your own repo takes an afternoon, not a sprint. For a deeper look at what tool-calling actually costs in an agent loop, our Cursor SDK custom tools vs MCP servers guide walks the trade-offs.
To try Inkling in your coding editor today, configure Cline's bring-your-own-model mode to point at the Tinker API endpoint (OpenAI-compatible, 256K context).
What to watch after July 27
The comparison changes the week the K3 weights drop, so hold these three open.
First, the K3 weights themselves. Once they are public, independent benchmarks and real self-host reports will either confirm the SWE Marathon lead or soften it, and the license terms (unpublished as of July 20) will decide how freely you can ship it in a product.
Second, Inkling-Small. The 12B-active preview is the version that could actually change the local-hardware math, since a model that size is far easier to serve than the full 975B. Its full weights are not released yet; when they are, use case 3 gets a genuine single-node contender.
Third, Tinker's launch pricing. The 50% discount on Inkling's serving and fine-tuning rates is temporary, and the real cost of a fine-tune-and-serve build roughly doubles when it lifts. That still leaves Inkling well under frontier API rates, but it moves the crossover point, so re-run your own volume math when the promotion ends.
FAQ
Is Inkling or Kimi K3 better than GPT-5.6 Sol or Claude Fable 5 for coding? No, not out of the box. Both labs say their models trail the frontier closed models, and on hard single-shot coding problems Fable 5 and Sol still lead. K3's edge is narrow and specific: multi-step agentic coding loops on Moonshot's own suite. For a general "best coding model" call, a hosted frontier plan is still ahead.
Can I run either one on a Mac or a single GPU? No. Inkling's full weights ship in a Blackwell-specific NVFP4 format, and K3 is roughly 1.4TB at 4-bit and needs a multi-accelerator supernode. Neither loads on consumer hardware today. Use the APIs (OpenRouter or Moonshot) or Tinker for Inkling instead.
Will Kimi K3 be fine-tunable after July 27? Technically yes, once the weights are public, but full fine-tuning on 2.8 trillion parameters is impractical for almost any team, and even LoRA needs the same datacenter-class cluster the model requires to run. If fine-tuning is your goal, Inkling on Tinker is the realistic path today.
What is controllable thinking effort in Inkling? It is a dial that sets how hard the model works per request, from a fast, cheap setting to a thorough one, which lets you trade token spend against answer quality per call (Thinking Machines). Kimi K3 has no equivalent: it runs a single max effort, which is why short prompts on K3 carry heavy reasoning-token overhead.
For the longer form on each model on its own, our Inkling review works the fine-tuning cost math in detail, and our Kimi K3 review runs the coding-agent pricing session by session. For the broader agent-tool landscape, start at the AI agent tools hub.