Thinking Machines Outlines Staged Framework and Safety Testing for Open-Weight AI Releases

Thinking Machines Outlines Staged Framework and Safety Testing for Open-Weight AI Releases Thinking Machines has outlined its framework for responsibly releasing open-weight models, balancing the benefits of distributed AI governance against misuse risks in areas like cybersecurity and CBRN. Grounded in evaluations from the release of Inkling and Inkling-Small, the strategy centers on evaluating model capability, researching the decoupling of harmful knowledge from general intelligence, and iteratively building ecosystem readiness through staged access. Thinking Machines released open-weight models Inkling and Inkling-Small after finding they do not add material incremental risk beyond existing open models. Safety evaluations for Inkling included internal harm testing across 17 languages and modalities, red-teaming by four external organizations, and adversarial fine-tuning to strip refusals. The organization hypothesizes that empirical dangerous knowledge in domains like biology can be decoupled from general reasoning through pretraining data filtering. Release readiness relies on staged deployments—such as monitored inference APIs and hosted fine-tuning platforms like Tinker—before fully opening weights. Thinking Machines announced upcoming Tinker safety grants to fund community defense, fine-tuning risk research, and external evaluations. The Dual-Use Dilemma of Open Weights Open-weight models democratize AI development, prevent the concentration of expertise within a few laboratories, and allow external inspection of training assumptions. However, public weight releases are irreversible and accessible to malicious actors. In cybersecurity and CBRN domains, capable models can shift the offense-defense balance. For instance, models that autonomously find and exploit software vulnerabilities can significantly reduce the cost of offensive attacks across unpatched systems, necessitating non-indiscriminate release practices. Safety Testing of Inkling and Inkling-Small Before releasing Inkling and Inkling-Small, Thinking Machines evaluated whether the models would expand the frontier of dangerous capabilities. Testing incorporated three tracks: internal benchmarks covering CBRN, cyber operations, agentic tool abuse, and multimodal harms across 17 languages; external evaluations conducted by Scale, Apollo Research, Handshake AI, and FAR AI; and adversarial fine-tuning. Because fine-tuning can strip safety guardrails from open weights, the team tested helpful-only variants and found they offered no new uplift in CBRN or cyber tasks compared to already available open models. Decoupling Dangerous Knowledge from Reasoning Challenging the assumption that all hazardous abilities emerge organically from general intelligence, the organization hypothesizes that specialized risks often depend on empirical facts memorized from pretraining data. In biological contexts, withholding specific experimental protocols, reagents, and conditions via document-level data filtering may suppress hazardous competencies without compromising broader reasoning. Although general models might theoretically re-derive omitted knowledge, early research indicates pretraining filtering provides a viable safeguard. Staged Access and Ecosystem Readiness To prevent risks outstripping societal defenses, Thinking Machines proposes an iterative, evidence-based release structure. Access can progressively expand from vetted or monitored inference APIs to hosted fine-tuning environments like Tinker—which allow users to train on private data without direct weight exposure—before reaching complete open-weights status. To bolster defensive capabilities, the organization plans to introduce Tinker safety grants to support defensive cyber teams and independent safety researchers.

Thinking Machines 提出开源权重模型的安全路径框架 Thinking Machines 探讨了在滥用风险不可逆的背景下权衡开源模型益处与安全性的机制，并结合其最新发布的 Inkling 系列模型测试结果，提出了基于模型评估、危险能力解耦与生态分阶段防御的开源路径。 开源权重具有使 AI 训练透明、分散技术权力的公共品属性，但发布具有不可逆性，可能降低网络攻击或两用领域的滥用门槛。 针对 Inkling 和 Inkling-Small 的内外部多维度评估显示，两者未突破现有的危险能力前沿，对抗性微调移除拒绝机制后亦未带来实质增量风险。 提出危险领域知识（如生物化学细节）可能通过预训练数据过滤与通用智能解耦的研究假说。 设计包括受控 API、托管微调（如 Tinker）再到开放权重的多阶段迭代发布框架，并设立安全资助以强化防御生态。 开源权重的双刃剑效应 开源权重模型使开发者能够直接定制系统并审查训练中的偏差与假设，防止开发专长过度集中在少数机构。然而，一旦公开权重，滥用者同样可以获得这些能力。特别是在网络安全等双用领域，模型可能大幅压缩攻击所需的时间与成本，而单纯依赖模型权重发布并不利于保障生态整体安全。 Inkling 系列的安全性评估实证 团队对 Inkling 和 Inkling-Small 进行了三项评估：针对 CBRN、网络攻击、恶意内容及 17 种语言多模态测试的内部评估；四家外部独立机构的红队测试；以及移除拒绝机制的对抗性微调。结果表明，即使被恶意微调，两款模型均未拓展已存开源模型的危险能力前沿，增量风险处于可控范围。 危险能力与通用智能的解耦假说 针对危险能力必然随通用智能同步涌现的传统观点，团队提出不同假设：生物等领域的特定实证知识（如实验步骤与试剂配方）高度依赖具体文档，或可通过预训练语料过滤加以剔除，同时保留正常的推理能力。尽管通用推理是否会逆向推导出被过滤内容仍属悬而未决的研究课题，但早期过滤实验已显示出可行性。 分阶段发布与生态防御建设 为缓解模型能力提升与滥用扩大的冲突，发布机制可依序采取受限监控 API、兼顾定制与防护的托管微调服务，以及最终的权重开源。每个阶段均依据安全证据递进，使防御方有时间升级响应能力。Thinking Machines 计划推出 Tinker 安全资助，支持社区开展微调风险评估与生态防御研究。

**Abstract:** Safe open-weight models are public goods, as they put AI development and safety work in many hands and make training choices inspectable. Open models also carry real misuse risks, and release is irreversible. To release safely, we must consider both the model and the ecosystem it enters. For the model, we conduct robust safety testing and research whether dangerous capabilities can be decoupled from general intelligence. For the ecosystem, we invest in its readiness through staged releases, supporting defenders, and collaboration with safety researchers. By iteratively choosing the most open option the evidence supports while building up the ecosystem's resilience, we can move toward openness safely. The [mission](https://thinkingmachines.ai/blog/the-future-worth-building-is-human/) of Thinking Machines is to build AI that extends human will and judgment. In pursuit of that mission, we recently released [Inkling](https://thinkingmachines.ai/news/introducing-inkling/) and [Inkling-Small](https://thinkingmachines.ai/news/inkling-small/), two open-weight language models that anyone can own, run, and customize. Strong open-weight models put AI development in many hands. We believe that this is a good thing: the knowledge of what AI should do lives with the people doing the work, so they should be able to shape their models directly. All models, including our own, carry the assumptions and biases of those who trained it; open weights make those choices inspectable and revisable. Without strong open models, training and deployment expertise risks becoming concentrated in a few labs, leaving everyone else less able to understand, adapt, or govern the technology. Once weights are public, anyone can use them, including bad actors. Cybersecurity shows what this means. In April 2026, Anthropic reported that Claude Mythos Preview found thousands of previously unknown vulnerabilities across every major operating system and browser and wrote working exploits without human guidance. Systems like this could substantially lower the time, cost, and expertise required for offensive cyber operations. Will our society be safer when open-weights models allow everyone to have superhuman cybersecurity skills? There are genuine uncertainties around the net effect of open weights on security and the offense-defense balance. These models could find and patch vulnerabilities before offenders do when they’re in defenders’ hands, but the same capabilities could accelerate exploitations across large numbers of unpatched systems when they are in attackers’ hands. Similar tradeoffs exist in other dual-use domains like chemistry and biology. Given these uncertainties, releasing weights indiscriminately is not a safe path forward. Is there a safe path to open the weights of powerful models when the misuse risks are real? We think that a path exists, though we have not mapped all of it. The central idea is that safe release depends on the model and the ecosystem around it. Robust safety testing – an imperfect but essential proxy for real-world capability in dangerous domains – must be a necessary part of our model release process. What harmful tasks can it complete? How accessible is it? What happens if guardrails are removed? More broadly, additional safety research is needed. For example, we are particularly interested in whether dangerous capabilities that depend on specialized knowledge can be reduced through pretraining data curation or post-training interventions. This remains an active research question rather than an established solution. Readiness means layered defense. The first layer is to enable individual organizations to patch their systems early or catch attacks in progress. Defensive research adds another layer, developing tools and techniques that let AI models themselves strengthen defenses at scale. These are just two of many layers. To prepare the ecosystem with layered defenses, we plan to collaborate with the safety community and provide access to capable models. A tension here is that the ecosystem builds defenses by working with capable models, but every expansion of access also expands who can misuse them. To address this tension, we can carefully stage releases with options such as monitored API access, hosted fine-tuning, and vetting defenders. Considering the rapid speed of AI capability advancement, these stages also need to move quickly enough for defensive learning to remain relevant. On a safe path to openness, each stage should widen access only when the evidence supports it. The path is therefore iterative: at each step, choose the most open option the evidence supports, and let each release inform the next. A model held back today can become less risky as the ecosystem changes, and new evidence might suggest that we can open its weights. Inkling and Inkling-Small are not the most capable models at the frontier. Our release decisions therefore primarily addressed whether releasing their weights would add material incremental risk beyond what existing open-weights models already pose. A finding that a model does not advance the dangerous-capability frontier is important but not sufficient. We also considered whether Inkling’s multimodality, capacity for customization, or accessibility could make harmful capability meaningfully easier to use. We tested Inkling and Inkling-Small in three ways: internal evaluations across a broad taxonomy of harms, external testing by four independent organizations, and a fine-tuning study to elicit worst-case capabilities. Based on the results of these evaluations, we concluded that releasing Inkling was not likely to add material risk beyond what existing open-weight models already pose. **Internal safety evaluations.** Our internal evaluation suite spanned three tracks. The first targeted dangerous dual-use domains like CBRNchemical, biological, radiological, and nuclear and offensive cybersecurity, testing both what the model knows about these domains and whether it can operationalize that knowledge in realistic settings. The second was a broad misuse set covering direct requests for harmful content and behavior in agentic, tool-use settings. The third was our own multimodal content evaluation, which tests models on harmful prompts paired with benign look-alikes across 17 languages and text, image, and audio inputs. In each of these tracks, Inkling and Inkling-Small’s results were in line with other open-weight models. **External red-teaming.** We worked with four external organizations, giving them early access to Inkling for pre-deployment testing in four areas: Across these areas, external testers did not identify capabilities that would meaningfully increase real-world risk beyond what is already achievable with existing open-weight models, or, where relevant, they did not find the safeguards of Inkling or Inkling Small to be meaningfully weaker than those of existing open-weight models. **Adversarial fine-tuning.** Because open weights can be customized to strip a model of its safety training, refusal behavior cannot be treated as a durable safeguard for an open-weight release. To assess this, we fine-tuned variants of Inkling and Inkling-Small optimized to comply with, rather than refuse, harmful requests – and ran them against our dual-use evaluations. This tests whether the model raises new material risks if its safeguards are removed. In our experiments, it did not: the helpful-only variants did not provide new uplift on CBRN and cyber tasks, and remained comparable to existing open-weight models. Taken together, neither model extends the dangerous-capability frontier. Neither meaningfully broadens access to it, as models of comparable or greater strength in these domains are already downloadable. Although refusals can be removed, doing so did not reveal substantially greater capability on these evaluations. Defenders, meanwhile, are already contending with models at or above this level. Based on these points, we concluded that releasing Inkling was not likely to add material risk beyond what existing open-weight models already pose. As our models approach the capability frontier, the balance across capability, accessibility, safeguard removability, and ecosystem readiness will change. Our safety approach will need to change with it. A common assumption holds that dangerous capabilities emerge without explicit training and correlate strongly with general intelligence. As a result, cyber-range results[How fast is autonomous AI cyber capability advancing?](https://www.aisi.gov.uk/blog/how-fast-is-autonomous-ai-cyber-capability-advancing) (AI Security Institute, 2025) are often treated as just another capabilities benchmark to optimize – some researchers go so far as to celebrate gains as milestones. However, we hypothesize that not all dangerous capability automatically emerges without training on it. In biology, for instance, a meaningful share of the knowledge rests on specific empirical findings, like protocols, conditions, reagents, and results, that a model acquires from particular documents in its pretraining corpus rather than inferring through general reasoning. As a result, such knowledge can potentially be withheld at training time without disturbing ordinary use. Recent work shows early promise: document-level filtering of CBRN-related content from pretraining reduces performance on harmful-capability evaluations while leaving unrelated capabilities intact.[Deep Ignorance: Filtering Pretraining Data Builds Tamper-Resistant Safeguards into Open-Weight LLMs](https://arxiv.org/abs/2508.06601) (O’Brien et al, 2025); Chen et al., 2025 This is still an open research question. General reasoning may transfer sufficiently well to let a capable model re-derive what was filtered, and the line between dangerous and ordinary technical knowledge and capability may be too blurry to cut cleanly. However, the early evidence is enough that we think the distinction is worth pushing on. Another way to make an open-weight release safer is to make the ecosystem in which it lands safer. Expanding access in stages lets society build up its defenses as it goes: a release can begin with inference API access for a limited population, widen to monitored general availability, and eventually reach open weights. Fine-tuning APIs like Tinker add a stage between inference access and open weights. They allow providers to host weights without releasing them, while still letting users fine-tune with their own data, loss functions, and training loops. That control still captures most of the benefits of openness, and it raises the misuse ceiling above what an inference API alone allows.[Model Tampering Attacks Enable More Rigorous Evaluations of LLM Capabilities](https://arxiv.org/abs/2502.05209) (Che et al, 2025) However, the risks stay below releasing weights: the provider can monitor usage, maintain guardrails, and revoke access. Each stage does specific work: These stages are not a fixed sequence that automatically ends with releasing the model’s weights. Instead, we think of them as a way to gather evidence and build resilience while moving towards greater openness. Progression should depend on what we learn about the model and whether the surrounding ecosystem is ready. This post offers a high-level framework, not a complete release standard. Important questions remain: what evidence should justify moving from one stage to the next, how uncertainty should affect that decision, what changes in capability or accessibility should pause progression, and how ecosystem readiness should be measured. We plan to publish a more detailed framework covering evaluations, access criteria, and stop conditions as we learn from Inkling and future models. This safe path to open models only works if the ecosystem’s defenses improve as quickly as the models do. We will do our part: deciding carefully what to release, and researching how to decouple intelligence from dangerous capability. However, most of the work above happens outside our lab, and much of what this post describes builds on other people’s work: for example, data filtering (Anthropic, EleutherAI, and the UK AI Security Institute), our external pre-deployment safety testers (Scale, Apollo Research, Handshake AI, and FAR AI), the framework for fine-tuning safety (OpenAI), and countless others working on cyber-defense. No lab builds this path alone. Each new defense lets us open models that were previously too risky to release. This takes many more hands than ours alone, and we want to support that work broadly. We will shortly launch Tinker safety grants: funding for the community to strengthen the ecosystem’s defenses. If you do safety research, our Tinker platform makes it easy to study fine-tuning and its risks, so give it a go. If you defend systems, we want to give you a head start. If you evaluate models, we want you to scrutinize ours. And if you want to do this from the inside, join our safety team—[we’re hiring](https://thinkingmachines.ai/#join-us)!