OpenAI ships gpt-oss under Apache 2.0 and calls it a model card, not a system card

What OpenAI actually released

OpenAI published two open-weight reasoning models, gpt-oss-120b and gpt-oss-20b, under the Apache 2.0 license plus a gpt-oss usage policy. Both are text-only and compatible with OpenAI's Responses API.

The framing is agentic. The models are built for instruction following, tool use such as web search and Python code execution, and reasoning. A notable detail: developers can adjust the reasoning effort, dialing it down for tasks that don't need deep reasoning. The models are customizable, expose full chain-of-thought, and support Structured Outputs.

For teams that have integrated against the Responses API with closed models, that compatibility matters. It means gpt-oss can drop into an existing tool-calling and structured-output workflow rather than requiring a new integration surface.

The chain-of-thought is fully exposed

OpenAI states the models provide full chain-of-thought. For applied teams, a visible reasoning trace is useful for debugging agent behavior, auditing tool calls, and building evaluation harnesses that inspect intermediate steps rather than only final answers.

That transparency is a direct consequence of open weights: there is no server-side layer hiding the reasoning. It cuts both ways, giving builders more insight and giving anyone else the same insight into how the model reaches its outputs.

Why they call it a model card, not a system card

OpenAI is explicit about the naming choice. Because gpt-oss will be embedded in systems built and maintained by many different stakeholders, the document describes the model, not a system. The safety of any deployed system is left to whoever builds it.

While the models are designed to follow OpenAI's safety policies by default, other stakeholders will also make and implement their own decisions about how to keep those systems safe.Montana Labs

The company also states the risk profile differs from proprietary models: once released, determined attackers can fine-tune the weights to bypass refusals or optimize for harm, with no way for OpenAI to add mitigations or revoke access afterward. Developers and enterprises are told they may need extra safeguards to replicate the system-level protections that come with API-served models.

The adversarial fine-tuning test and its stated limit

OpenAI ran scalable capability evaluations on gpt-oss-120b and reports the default model does not reach its indicative High-capability thresholds in any of the three Tracked Categories of its Preparedness Framework: Biological and Chemical, Cyber, and AI Self-Improvement.

It then simulated an attacker by adversarially fine-tuning the model for the biological/chemical and cyber categories, using what it describes as its field-leading training stack. The Safety Advisory Group reviewed the results and concluded the model still did not reach High capability in either domain.

On whether the release advances the open-model frontier, OpenAI says no: for most evaluations, one or more existing open models perform near the adversarially fine-tuned gpt-oss-120b in their default state. In other words, the argument for release rests partly on the capability already being available elsewhere.

The specific implication: safety moves to the integrator

The concrete shift here is that responsibility for refusal behavior and system-level protection transfers from OpenAI's servers to whoever deploys the weights. The model card documents pre-release testing; it cannot bind what happens after fine-tuning.

For teams adopting gpt-oss, that means the safeguards OpenAI's API quietly provided are now line items to build and own. The Apache 2.0 license and Responses API compatibility lower the cost of adoption; the model card makes clear that the safety engineering does not come with them.