Inkling 2 Small Has 594B Parameters, but Self-Hosting Must Wait

Thinking Machines introduced Inkling 2 Small on November 5, reporting a mixture-of-experts model with 594 billion total parameters and 17 billion active parameters. Access is closed on Tinker now. The company intends to release full weights under Apache 2.0 next week after external safety testing; that is not the same as weights being available today.

The announcement also reports a 292 million-parameter vision encoder and an AA Intelligence Index score of 31. For coding, Thinking Machines gives results of 72.1% on DeepSWE v1.1 and 86.3% on SWEBench Pro v2 Hard. Those figures provide reasons to evaluate the model, not permission to assume it meets your application’s requirements.

A buyer therefore has separate decisions to make. Hosted behavior can be examined through the access currently offered. Self-hosting remains conditional on release availability and deployment evidence that a parameter headline cannot supply.

Active parameters are not the storage requirement

The distinction between 594B total and 17B active parameters is central to the announcement. Active parameters describe the model’s reported computation pattern; they should not be treated as a direct statement of the memory needed to host all model weights. The fact sheet supplies no deployment-memory figure.

A procurement estimate that starts with the active count and silently treats it as the complete model size skips the relevant engineering work. Builders need the actual release artifacts and a supported deployment approach before they can establish resource requirements. The announced architecture is useful context, but it does not fill those gaps.

The same restraint applies to the 292M vision encoder. Its reported size identifies part of the system, not the complete cost of processing your inputs. Keep architecture facts in the technical summary and resource requirements in a separate section marked unverified until tested.

Coding scores need workload-specific interpretation

Thinking Machines reports 72.1% on DeepSWE v1.1 and 86.3% on SWEBench Pro v2 Hard. Preserve those benchmark names and versions whenever the figures appear in a buying document. Removing the evaluation label makes a bounded result look like a general promise about software development.

Your acceptance test should instead describe the changes a developer needs and what counts as a usable result. A generated change that needs extensive repair is not equivalent to a change accepted after normal review. That distinction is a proposed evaluation principle, not an additional result reported for Inkling.

The AA Intelligence Index score of 31 belongs beside those coding results, not above them as a universal purchasing verdict. Different evaluations can inform different questions. None of the supplied numbers establishes how the model will behave with your repository’s conventions or how much supervision its work will require.

Waiting for weights has an operational cost

The release timing creates a real planning trade-off. Teams can spend effort evaluating hosted behavior now, but a later self-hosted deployment would still need its own operational review. Results from the hosted route should not be presented as proof of a deployment configuration that has not been tested.

There is also a scheduling risk in converting an intended release into a committed dependency. The company ties the planned weight release to external safety testing. The announcement does not establish that the testing is complete or that buyers can already obtain the full artifacts under the intended license.

Keep work that depends on those artifacts outside your critical production path until availability is confirmed. That does not require ignoring the model. It means making clear which current tests answer application questions and which later tests must answer infrastructure questions.

License intention and release verification are different checks

The intended Apache 2.0 license is commercially relevant, but its status matters. A statement about the license planned for future weights is not evidence that a usable package is currently distributed. Procurement should capture both the intended terms and the fact that the release remains pending.

When the artifacts arrive, the reviewer should confirm what was released and which terms accompany it. Engineering can then establish whether the available runtime supports the intended workload. Neither step should be replaced by a screenshot of the announcement or a shorthand description of the model as already open.

A useful evaluation record can survive a delayed or changed release. It should identify the hosted interface used and the acceptance criteria applied, with deployment-dependent questions left open. That way the team retains evidence from present testing without confusing it with readiness to operate the model independently.

What To Do About It

• Separate the workstreams: This week, have the engineering lead distinguish hosted application tests from pending self-hosting checks, keeping the hosted access reference as Tinker.
• Preserve benchmark labels: Have the evaluator attach task definitions and review outcomes to any comparison rather than turning the vendor score into a guarantee, including DeepSWE v1.1.
• Hold resource assumptions: Have the infrastructure owner mark memory sizing as unverified instead of deriving it from the active parameter count, 17B.
• Verify the release: Have procurement confirm actual weight availability and accompanying terms before approving a self-hosted dependency under the intended Apache 2.0.

The Bottom Line

Inkling 2 Small offers reported coding results worth examining, but the 594B total parameter count and pending weights define separate operational questions. Evaluate the access that exists without pretending the self-hosted product is already available. Keep resource sizing and licensing approval conditional on the actual release. That produces a useful comparison now without making next week’s intention a production commitment.