gpt-oss-120b is an open-weight, 117B-parameter Mixture-of-Experts (MoE) language model developed by OpenAI. The model features configurable reasoning effort, full chain-of-thought transparency, and native tool-calling capabilities. Licensed under Apache 2.0, it represents a major shift in OpenAI's strategy, offering frontier-level performance for open-source deployment. Lyceum Technology serves gpt-oss-120b via our OpenAI-compatible Serverless Inference API, allowing European teams to deploy this powerful reasoning model on EU-hosted infrastructure that supports customers' GDPR compliance with zero code changes.
gpt-oss-120b: specs, benchmarks, and how to run it on Lyceum
gpt-oss-120b brings OpenAI's reasoning capabilities to the open-source ecosystem. With 117B parameters and a sparse MoE architecture, it delivers o4-mini-level performance while fitting on a single 80GB GPU.
Caspar Lehmkühler
June 18, 2026 · Head of Product at Lyceum Technology
Last updated August 3, 2026
Get started: call gpt-oss-120b on Lyceum
Access gpt-oss-120b through Lyceum Technology's OpenAI-compatible API. Migrating existing reasoning workflows requires only updating the base URL and providing an API key, allowing teams to switch infrastructure providers without rewriting application logic.
from openai import OpenAI
client = OpenAI(
base_url="<the base URL shown in your Lyceum dashboard>",
api_key="<your lyceum api key>",
)
response = client.chat.completions.create(
model="openai/gpt-oss-120b",
messages=[{"role": "user", "content": "Hello!"}],
max_tokens=256,
)
print(response.choices[0].message.content)
Pricing and region for gpt-oss-120b
On Lyceum, gpt-oss-120b is served through Serverless Inference, which is billed per token and has no service tiers: the model you address sets the balance between latency and capability. The model is hosted in the eu-north1 region, so requests for it are processed in European data centres for compliance-sensitive applications. Pricing is strictly pay-per-token at $0.15 per million input tokens and $0.60 per million output tokens. There are no base fees, no minimum commitments, no egress fees, and no idle costs. You only pay for the exact compute your application consumes, making it highly efficient for bursty workloads.
What gpt-oss-120b is good at
Configurable reasoning and chain-of-thought
Unlike standard dense models, gpt-oss-120b allows developers to adjust the reasoning effort (low, medium, high) based on latency and complexity requirements. It provides full chain-of-thought (CoT) visibility, granting complete access to the model's internal reasoning process. This transparency makes debugging complex agentic workflows significantly easier and increases trust in the final outputs, as engineers can inspect exactly how the model arrived at a specific conclusion.
Agentic capabilities and tool use
OpenAI optimized gpt-oss-120b specifically for agentic workflows. It features native support for function calling, web browsing, Python code execution, and Structured Outputs. This makes it an exceptionally strong candidate for building autonomous agents that need to interact with external APIs, query databases, or execute multi-step logic. The model's ability to reliably output structured JSON ensures that downstream systems can parse its responses without brittle regex workarounds.
Hardware efficiency via sparse MoE
Despite having 117 billion total parameters, gpt-oss-120b uses a highly efficient sparse Mixture-of-Experts (MoE) architecture. During inference, it activates only about 5.1 billion parameters per token, which is roughly 4.4 percent of the total network. Combined with MXFP4 quantization applied during post-training, this architectural choice allows the model to deliver near-frontier performance while fitting entirely on a single 80GB GPU, such as an NVIDIA H100 or AMD MI300X. This efficiency translates directly into lower inference costs and faster time-to-first-token metrics.
Limitations and trade-offs
Where gpt-oss-120b falls short
While gpt-oss-120b excels at reasoning and agentic tasks, it has notable limitations compared to proprietary frontier models. Independent testing indicates that its multilingual capacity is relatively weak. The model was primarily trained on English STEM and coding data, meaning teams requiring robust performance in non-English languages may find it underperforms compared to models like Llama 3 or proprietary alternatives. If your application serves a diverse global user base, you may need to implement translation layers or choose a different base model.
Additionally, while it performs exceptionally well on theoretical coding benchmarks, some developer evaluations have reported disappointing performance on highly specific practical coding tasks. For example, generating complex Three.js rendering code or implementing niche framework logic can sometimes trip up the model. In these specific edge cases, alternative open-weight models like GLM-4.5-Air have occasionally shown an edge in practical execution.
Finally, the model relies heavily on OpenAI's specific "harmony response format" to function correctly. If you are self-hosting the model or bypassing standard chat templates, failing to apply this exact format will result in severely degraded performance and broken chain-of-thought outputs. Fortunately, when you consume the model via an API provider, this formatting complexity is abstracted away. Lyceum's inference engine handles the harmony formatting automatically, ensuring you get optimal performance without managing the underlying template structures.
Benchmarks and how it compares
gpt-oss-120b benchmark results
The figures below are taken from the gpt-oss model card [3] and are measured at high reasoning effort. Each one is an accuracy percentage on the named benchmark, so higher is better, and together they show a model punching well above its 5.1 billion active parameters per token.
| Metric / Benchmark | gpt-oss-120b | Source |
|---|---|---|
| AIME 2024, accuracy with tools | 96.6% | Model card [3] |
| GPQA Diamond, accuracy with tools | 80.9% | Model card [3] |
| MMLU, accuracy | 90.0% | Model card [3] |
| SWE-bench Verified, issues resolved | 62.4% | Model card [3] |
When compared to its smaller sibling, gpt-oss-20b, the 120B model offers significantly higher reasoning capabilities at the cost of increased VRAM requirements (80GB versus 16GB). Against other open-weight models in the 100B+ class, the practical draw is that reasoning effort is a dial rather than a fixed cost. The same model card reports SWE-bench Verified at 47.9% on low effort against 62.4% on high [3], so you can trade accuracy against the volume of reasoning tokens generated per workload instead of swapping to a different model. Because those reasoning tokens are billed as output, that dial is a direct cost control in production rather than only a quality setting.
Using it in production
Production configuration for gpt-oss-120b
When deploying gpt-oss-120b, managing its massive 131,072-token context window is critical for cost control. Because it is a reasoning model, it generates internal chain-of-thought tokens before producing the final answer. You must account for these reasoning tokens in your output budget, as they contribute to the total tokens billed per request.
On Lyceum Technology, the model runs on Serverless Inference, hosted in the eu-north1 region. There is no tier to select: you address the model by name and pay per token, and the reasoning tokens it generates are billed as output. The serving stack provides the memory bandwidth needed to handle the model's sparse MoE routing efficiently.
Consider a production workload processing complex document analysis. If you send a 10,000-token input prompt and the model generates 1,500 output tokens (including its reasoning chain), the cost math is straightforward:
- Input cost: 10,000 tokens × ($0.15 / 1,000,000) = $0.0015
- Output cost: 1,500 tokens × ($0.60 / 1,000,000) = $0.0009
- Total cost per request: $0.0024
Because Lyceum bills serverless inference per token, you only pay for the exact compute used. There are no idle costs when your application is not serving traffic, making this setup highly economical for bursty agentic workflows that experience variable demand throughout the day.
Running gpt-oss-120b on EU-sovereign infrastructure
Why run gpt-oss-120b on Lyceum
For European AI startups and enterprise teams, data residency is often a strict requirement. Routing sensitive data across the Atlantic introduces compliance risks. Lyceum Technology provides an EU-hosted alternative, serving gpt-oss-120b from the eu-north1 region. Prompts and completions for this model are processed in European data centres rather than routed to a US region.
By running this model on Lyceum, your requests are served from European data centres in Spain, Paris and the Nordics, with per-token billing on Serverless Inference and no base fee, no minimum commitment and no idle charge between bursts of traffic. Because the serving stack is open, built on vLLM, NVIDIA Dynamo and TensorRT-LLM, and because the weights themselves are Apache 2.0, you keep the option of running the same model elsewhere rather than depending on an inference engine you cannot inspect. The largest model in that family is covered in our notes on Qwen3.5-397B-A17B and how to run it.
To learn more about how we secure your data and maintain regulatory alignment, read our comprehensive guide on GDPR-compliant LLM inference in Europe. Lyceum provides the reasoning power of gpt-oss-120b via an OpenAI-compatible API, ensuring infrastructure meets European data standards.
Sources
[1] openai/gpt-oss-120b - Hugging Face; [2] gpt-oss-120b Model | OpenAI API; [3] [2508.10925] gpt-oss-120b & gpt-oss-20b Model Card - arXiv
Frequently Asked Questions
How much does gpt-oss-120b cost on Lyceum?
What is the context window for gpt-oss-120b?
Where is my data processed when using this model?
How do I migrate to Lyceum's gpt-oss-120b API?
How does gpt-oss-120b compare to o4-mini?
What license does gpt-oss-120b use?
Lyceum Technology