Moonshot AI と Thinking Machines Lab がオープンウェイトモデルを相次ぎ公開

Two frontier-class models shipped open weights this week, from two very different labs. Moonshot AI announced Kimi K3, a 2.8-trillion-parameter multimodal model with a 1M-token context window, with full weights promised by July 27 under a modified MIT license. Thinking Machines Lab, the startup founded by former OpenAI CTO Mira Murati, released Inkling, a 975B-parameter Apache-2.0 model that they explicitly position as a base for fine-tuning rather than a finished product.

If you run coding agents at any scale, this changes your options. A year ago, "use an open model for agentic coding" meant accepting a real capability gap. That gap is now small enough that the other variables — cost, data control, customization — start to dominate the decision.

Kimi K3: the largest open-weight release yet

Kimi K3 is a sparse mixture-of-experts model: 2.8T total parameters, but only 16 of 896 experts fire per token. It takes text, images, and video, and it debuted at #1 on the Frontend Code Arena leaderboard, ahead of the top closed models. API pricing runs 0.30–0.30–3.00 per million input tokens (cached vs. uncached) and $15 per million output tokens.

Two caveats worth stating plainly. First, as of this writing the K3 weights are announced, not downloadable — Moonshot says July 27. Third parties can benchmark the model through its API (more on that below), but nobody can verify self-hosted throughput, latency, or hardware efficiency until the checkpoint ships. Second, self-hosting this thing is not a weekend project: Moonshot recommends deployment on configurations with 64 or more accelerators and hasn't published a minimum viable GPU setup.

Inkling: a Western base model built to be fine-tuned

Inkling is out now. It's a 975B-total, 41B-active MoE trained on 45 trillion tokens of text, image, audio, and video, with a context window up to 1M tokens. It ships with day-0 support in transformers, SGLang, and llama.cpp, plus an NVFP4 quantized variant for cheaper inference. Thinking Machines is candid that Inkling isn't the top model on popular benchmarks; their pitch is that it scores well among open-weights models on agentic evals like Terminal-Bench 2.1 and that it responds unusually well to fine-tuning through their Tinker platform. There's also a preview of Inkling-Small, a 12B-active sibling for latency-sensitive work.

Inkling also fills a strategic gap. Until this week, nearly every frontier-class open model came from a Chinese lab, and the regulatory picture around those models is unsettled: US federal and state governments have already restricted DeepSeek on government systems, and reporting this month suggests broader restrictions are under consideration. A competitive, Apache-2.0, US-built open model — joining Nemotron and Gemma — means an open-weights strategy no longer has a single point of geopolitical failure.

The scoreboard: open vs. closed

The cleanest way to see the gap is on the two SWE-bench variants: Verified (500 human-validated GitHub issues) and the harder, more recent Pro (public set). The Verified numbers below come from Vals AI's independent re-run (updated July 17), which evaluates every model with the same minimal bash-only mini-SWE-agent harness — no vendor self-reporting, no harness games. Pro numbers are from Thinking Machines' published comparison and the morphllm aggregate.

**Inkling's Verified score is Thinking Machines' self-report, also with a bash-only harness.*

That K3 number is the headline. An open-weight model, independently measured, sits 1.6 points behind Claude Fable 5 and ahead of every other closed model on the board — including Claude Opus 4.8 by nearly five points. No open release has been that close to the top of a third-party Verified leaderboard before. Vals' difficulty breakdown shows K3 holding 93% even on tasks estimated at 1–4 hours of human work, right alongside Fable 5.

The honest footnotes: K3 was the slowest model in Vals' top tier at 619 seconds average latency per task, 3.4x GPT-5.6 Sol's 182 seconds. Its weights aren't downloadable until July 27, and nobody has published a SWE-bench Pro number for it — on Pro, where every model drops 20-plus points, Fable 5's 80.0% still leads the best open score (GLM-5.2's 62.1%) by a wide margin. So the gap hasn't closed everywhere. But on the benchmark the industry has treated as the standard for three years, an open model is now inside the error bars of the frontier.

What open weights buy you

Cost, at sufficient scale. Coding agents are token furnaces. A single issue-resolution run can burn hundreds of thousands of input tokens, and teams running agents in CI or on every pull request hit seven-figure monthly token counts fast. At that volume, the math on a dedicated inference cluster — or on the much cheaper per-token pricing that open-model API providers offer — starts to beat frontier closed-model pricing by multiples. Below that volume, it usually doesn't. Do the arithmetic before you buy GPUs.

Data sovereignty. With self-hosted weights, your prompts, your codebase, and your agent traces never leave infrastructure you control. For teams in regulated industries, or anyone whose legal department has opinions about proprietary source code transiting a third-party API, this is the whole argument. No data processing agreement can match "the packets never left the building."

Fine-tuning. A closed model is frozen at whatever the provider trained it to be. An open model can learn your internal frameworks, your migration patterns, your code review conventions. This is Thinking Machines' entire bet: their launch post argues that centrally trained, set-in-stone AI underperforms AI that organizations shape themselves, because so much expertise is specific to the people who hold it. You don't have to buy the full thesis to see that a mid-size model fine-tuned on your monorepo can beat a generalist frontier model on tasks that live in that monorepo.

Switching without rewrites. When weights are open and every serious serving stack speaks the OpenAI-compatible API, moving from one model to another is a config change. When your workflow is welded to one provider, it's a migration project.

The costs are real too: you own the pager for your inference cluster, you own capacity planning, and when the model does something baffling there's no vendor support ticket. Open weights trade a monthly bill for an operational responsibility. That trade is worth it at scale and a bad deal below it.

Don't marry your harness either

Model flexibility is worthless if your agent harness quietly assumes one provider. Provider-built coding tools are tuned end-to-end for their own models: the prompts, the tool definitions, and the models themselves are co-trained. You can hack Claude Code into talking to Kimi through an Anthropic-compatible API shim — people did exactly this with K2 — but engineers at Thoughtworks who tried it concluded that Claude Code wasn't the best tool for Kimi even when it was cheaper to run. The harness works; it just doesn't work *well*, because none of its tuning transfers.

This isn't a knock on provider tools. It's a supply-chain observation: if the harness and the model come from the same vendor, your ability to switch models is theoretical. A model-agnostic harness — one that's tested and tuned across many models — is what makes weeks like this one actionable instead of merely interesting.

Trying these models with an agent that doesn't care who made them

OpenHands is open source and model-agnostic by design: the same agent runs against a closed frontier API or an open model served on your own cluster, so weeks like this one are a configuration change rather than a migration.

To decide *whether* a model is worth serving, check the OpenHands Index, a continually updated leaderboard that benchmarks both closed and open models on real software engineering work — issue resolution, greenfield apps, frontend development, testing, and information gathering — scored on accuracy, cost, and runtime. The cost-accuracy Pareto curve is exactly the graph you need when a new open model drops and you want to know if it earns a spot in your rotation. The benchmarking code is open source, and when results turn out to be wrong, the corrections are published.

For running agents where your data lives: Agent Canvas is the MIT-licensed, self-hostable coding workspace — run it locally, in Docker, or on your own VMs, backed by whatever model endpoint you choose. OpenHands Enterprise adds SSO/RBAC, isolated sandboxes, budgeting, and observability for teams that need the whole stack in their own cloud or datacenter, pointed at self-hosted models.

The practical next step: when the K3 checkpoint lands on July 27, or with Inkling today, stand up an endpoint, wire it into a model-agnostic harness, and run it against your own backlog for a week. The gap between open and closed is now small enough that your workload — not the leaderboard — should make the call.