Back to the tools

Local AI

gpt-oss

gpt-oss is OpenAI's open-weight model family: two sizes under Apache 2.0. We run it on a single workstation for translation and batch jobs.

3 min read

gpt-oss is OpenAI’s open-weight model family, released on 5 August 2025 and the company’s first open-weight release since GPT-2. It comes in two sizes: gpt-oss-120b (117B total parameters, 5.1B active) and gpt-oss-20b (21B total, 3.6B active). Both are text-only mixture-of-experts reasoning models, so each token routes through a small part of the network.

The weights are published under the Apache 2.0 license with a short complementary usage policy. The model card documents the larger model as fitting a single 80GB GPU (NVIDIA H100 or AMD MI300X) and the smaller one as running within 16GB of memory. It does not need a cluster, it needs a workstation.

Sizes and memory

  • gpt-oss-20b: 21B parameters, 3.6B active. Documented as running within 16GB of memory; LM Studio lists at least 16GB of VRAM.
  • gpt-oss-120b: 117B parameters, 5.1B active. The model card names a single 80GB GPU; LM Studio recommends at least 60GB of VRAM.
  • Both carry a 128k token context window, and the MoE weights were post-trained with MXFP4 quantization. Published evaluations used that same quantization, so it is part of the released model.

Attention layers alternate between full context and a 128-token sliding window.

The format it expects

gpt-oss was trained on the harmony response format and, per the documentation, should only be used with it, otherwise it will not work correctly. Harmony defines five roles (system, developer, user, assistant, tool) and splits assistant output into channels: final for user-facing text, analysis for chain-of-thought, commentary for tool calls.

The full chain of thought is available, which helps debugging, but the documentation warns that the analysis channel does not meet the same safety standards as final messages.

Reasoning effort is set in the system message (low, medium, high): low for fast dialogue, high for deeper analysis. One set of weights then covers both quick requests and heavier jobs.

How we serve it

The family runs on Transformers, vLLM, llama.cpp, Ollama and LM Studio, which pulls the model with lms get. LM Studio exposes a local /v1/chat/completions endpoint without an API key, so existing OpenAI SDK code keeps working after a base URL change. vLLM and Transformers also serve OpenAI-compatible endpoints. Recommended sampling is temperature 1.0 and top_p 1.0.

Tool use covers function calling, a browser tool, a Python tool and Structured Outputs.

What to watch

  • The format is not optional. Without harmony the output is wrong, not merely suboptimal.
  • Chain of thought is not user content. The analysis channel is explicitly not meant for end users.
  • The reference code is not production code. The PyTorch implementation is educational, needs at least 4 H100 GPUs by its own documentation, and is untested on Windows.
  • Quantization. Reported results are for the released MXFP4 weights; another quantization is another model.
  • Open weights cannot be recalled. Once the weights are out, refusals can be fine-tuned away and no later mitigation or access revocation is possible, so system-level safeguards are the deployer’s job.

Our choice was simple: gpt-oss-20b fits on a single workstation, so CyberElectro runs its local translation and other batch jobs on it. LM Studio provides the OpenAI-compatible endpoint, the workload stays under Docker, and Hermes Agent can call it like any remote service.

Further reading

Tags
  • open weights
  • local model
  • MoE
  • harmony
  • LM Studio