gpt-oss
Two permissively licensed open-weight releases sized so the larger fits on a single high-memory GPU — strong reasoning, configurable effort, no licence conditions to negotiate, and reasoning traces to keep away from clients.
Tier B — conditional, and the easiest recommendation in this index on licence and hardware grounds: Apache 2.0, no conditions, and a model that fits on one card while doing serious work. The caveats are behavioural and manageable — a confident streak it will not flag, and reasoning traces that must be kept out of anything a client sees. If the firm already owns a GPU, this is the model we would test first.
Specifications, as published
| Publisher | OpenAI |
| Family | OpenAI's Apache-2.0 open-weight releases, in two sizes, with configurable reasoning effort and a published response format |
| Parameters | Two releases in a mixture-of-experts pattern: one around twenty billion total parameters with a few billion active, and one several times larger in total parameters with a similarly small active fraction |
| Context | Long context as published for the series; as everywhere in this index, effective context under real retrieval is lower than the published figure |
| Licence | Apache 2.0 — permissive, with an explicit patent position and no acceptable-use rider attached to the weights |
| Weights | Downloadable, including the publisher's own low-precision format, which is what the published evaluations were run in |
| Release | A small, stable family rather than a moving line — a genuine advantage for evaluation and procurement |
| Licence posture | Apache 2.0 — permissive, with an explicit patent position and no acceptable-use rider attached to the weights |
Specifications are as published by the publisher at the review date and change frequently. Confirm them in your own evaluation before you procure.
Releases and variants
| Release | Size | Context | Serving footprint | What it is for |
|---|---|---|---|---|
| gpt-oss-120b | 117B total with 5.1B active per token — sparse mixture of experts, post-trained in MXFP4 | 131,072 tokens as published, with a configurable reasoning effort | ~63GB at the publisher's MXFP4 precision, published as running on a single 80GB GPU | The release a firm of 10–50 fee-earners should actually run: the small active-parameter fraction makes a 117B model cheap to serve for its total size, and one 80GB card holds it in the exact precision its published evaluations used. |
| gpt-oss-20b | 21B total with 3.6B active per token — sparse mixture of experts, post-trained in MXFP4 | 131,072 tokens as published | ~16GB at MXFP4 (published as fitting within 16GB of memory) | The one to run if the firm has only a workstation: it performs extraction and classification well on a 24GB card, though the loss of analysis quality against the 120B release is real and prompt-steering does not recover it. |
| gpt-oss-safeguard-120b | 117B total with 5.1B active per token — safety-reasoning fine-tune of gpt-oss-120b, driven by a policy you supply | 131,072 tokens as published | ~63GB at MXFP4, published as fitting a single 80GB H100-class GPU | Not a legal-work model: it is a content-classification and policy-enforcement release whose own card says it is not intended for exposure to general users, so a firm might use it to filter tool inputs and outputs, never to draft. |
| gpt-oss-safeguard-20b | 21B total with 3.6B active per token — safety-reasoning fine-tune of gpt-oss-20b | 131,072 tokens as published | ~16GB at MXFP4 (published as fitting GPUs with 16GB of VRAM) | The workstation-sized member of the safeguard pair, useful as an input filter on a small deployment and not as an alternative to the two main releases for legal analysis. |
Sizes, context windows and licences are as published by the publisher at the review date. The variant you pick matters more than the family name: a small dense release that fits one workstation and a large mixture-of-experts release that needs a multi-GPU server are not the same product, whatever the marketing says.
How it behaves on legal work
gpt-oss is the entry in this index with the least friction and the most familiar behaviour. It was post-trained with a structured response format and configurable reasoning effort, and the practical effect on legal tasks is that you get a model which is unusually easy to make predictable: set effort low for extraction and classification, high for analysis, and the behaviour moves in the direction you asked for rather than merely getting slower. Instruction following is strong. Give it a schema, a refusal rule, a length limit and a tone and all four survive into the output — the refusal rule being the one most other open models quietly drop. Extraction into a fixed schema is reliable and clean, with the caveat that this is a reasoning model at heart and it will sometimes explain itself before producing the JSON, which a parser must tolerate or the prompt must forbid. Drafting is good and slightly cool: it writes in the register of a well-briefed professional adviser rather than a brand, does not pad, and rarely produces the flourishes that make a letter memorable. For internal drafting — file notes, chronologies, position summaries, attendance notes — that is close to ideal. Summarisation fidelity is the strongest of the general-purpose models we have assessed at this size, and it holds qualifications rather than dropping them, which is the failure we see most often elsewhere. Ask it to summarise under a quote-or-omit rule and it complies; ask it to summarise freely and it compresses sensibly, though it will still occasionally fold a conditional into an absolute. The remaining gap is stylistic rather than substantive: its summaries read like a briefing note, not like a headnote, and a fee-earner will usually re-cut the first sentence. Its reasoning traces are the most useful and the most awkward feature. They are complete and legible — the publisher exposes the full chain of thought deliberately — and for triage and analysis they let a reviewer see exactly where an assumption arrived. They are also explicitly not intended for end users, and they read like thinking rather than like advice. Strip them before anything reaches a client, and prefer instructing the model to place its answer in a marked section over post-processing the trace, which is the cleaner route and works reliably in our tasks. Over-assertion is present and takes the familiar reasoning-model form: a confident conclusion resting on a step that was assumed rather than derived. It is more likely to state an answer firmly than to flag that the documents were silent, and the firmness does not scale with the strength of the evidence. An explicit abstention rule with a defined refusal string fixes most of this and is the single highest-value change to the system prompt. There is also a safety-model variant published alongside the main releases, tuned to classify content against a policy the operator supplies. For a firm thinking about how to triage confidentiality, privilege or client-imposed content rules at volume, that is a more interesting artefact than the language models themselves, and it is the sort of tooling that normally exists only behind a commercial API. Week one: fee-earners find the answers better than expected from a model that fits on one card, and find the licence conversation refreshingly short. The friction is operational rather than behavioural — the larger release needs a serious GPU or a host, and the smaller is good enough for extraction but visibly weaker at analysis, so the choice between them is not as simple as starting small and scaling up.
Quotation fidelity is good when the instruction is explicit, and its summary work holds qualifiers better than most — the failure mode is folding a conditional into an absolute rather than silently rewriting a quotation. Abstention is average by default and good under instruction: an explicit refusal string plus one worked example is the prompting that moves it most, and it responds well to a rule that every asserted fact carries a document reference. Its reasoning trace is also your audit tool: if a trace starts arguing from principle rather than from a passage, treat the answer as ungrounded regardless of how confident it sounds.
What we would use it for
- Extraction into a fixed schema, with reasoning effort set low and a strict output format
- Summarisation of bundles and long documents under a quote-or-omit rule
- Internal drafting — file notes, chronologies, position summaries
- Reasoning-heavy triage: which issues does this document set actually raise
- A single-GPU pilot for a firm that already owns infrastructure
- Confidentiality and content triage using the publisher's policy-driven safety variant
What to watch
- Reasoning traces that read as deliberation and must be kept away from clients
- Confident conclusions resting on an assumed step
- Reasoning preamble that breaks a naive JSON parser
- Advertised context above what survives a real matter file
- The smaller release is materially weaker at analysis than at extraction
What it costs to run
Run gpt-oss-120b rather than the 20B if the firm wants one model for extraction, summarisation and analysis: it is published to run on a single 80GB GPU in the MXFP4 format its evaluations were run in, and that is the deployment we would sign off. One 80GB card supports a handful of concurrent fee-earners at low or medium reasoning effort, with the high-effort setting materially slower on multi-document work; the 20B release fits within 16GB of memory, so it runs on a workstation for a single team at a visible cost in analysis quality. Keep the reasoning traces out of anything a client sees, and pin the exact release in your evaluation record.
| Basis | GPU hours | Hourly (USD) | Monthly (USD) | When this is the right pattern |
|---|---|---|---|---|
| Always-on server (24/7) | 730 h | $1.58 – $5.24 | $1,150 – $3,820 | Firm-wide access, no cold starts, predictable latency |
| Business hours (10 h × 21 days) | 210 h | $1.58 – $5.24 | $330 – $1,100 | The realistic pattern for a firm of 10–50 fee-earners: power it up, use it, stop paying |
| Bursty / autoscaled endpoints | 60 h | $3.30 – $6.90 | $200 – $415 | Occasional analysis and pilots; you pay only for the seconds the model is working |
| Storage — weights, index and evaluation sets (~150 GB) | — | — | $20 | Billed whether the model is running or not — the quiet line on the invoice |
Indicative GPU class: 80GB class — A100 80GB / H100. Every figure above includes a 50% buffer on the underlying cloud rates — for encrypted storage, egress, idle capacity between requests, cold starts, operational overhead, and the plain fact that these are estimates rather than quotes. Rates move weekly and vary by region, tier and commitment.
With a small, stable two-release family and no licence conditions to negotiate, this is the model that most repays renting first: a single 80GB instance across a month of real matters will tell you more than any benchmark, and the storage volume is the only thing you keep paying for after you stop it. Buying the 80GB server class is indicatively $25,000–60,000, and the honest case for it is a firm using the model for most of every working day that wants the weights inside its own perimeter; below that, you are paying for idle hardware. These figures are indicative only — obtain quotes for your own specification.
Two rules of thumb that hold across the models we have deployed: renting beats buying until a firm is using the model more than about half of every working day, and stopping the instance matters more than the hourly rate — an idle server, and an idle storage volume attached to it, are where private AI budgets quietly go.
Sampling and prompt settings
Extraction and classification: reasoning effort low, temperature 0, top_p 0.8, strict schema. Summarisation: effort medium, temperature 0.1. Analysis and triage: effort high, temperature 0.2. Drafting: effort medium, 0.3–0.4. Record the effort setting in your evaluation record alongside the model version — a high-effort run and a low-effort run are different systems, and comparing them without labelling them will mislead you. Pin the release; the family is small and stable enough that pinning is easy, which is an advantage you should use.
Pin the exact model release in your evaluation record. Behaviour moves between point releases, and an evaluation that does not name a version cannot be reproduced.
Hardware and quantisation
| Deployment profile | What it fits | What to know |
|---|---|---|
| Single workstation, smaller release at low precision | Extraction, classification and internal drafting for one team | Runs in a workstation-class memory footprint, but analysis quality drops sharply relative to extraction — do not assume it can do the larger model's job |
| Single high-memory GPU server, larger release | Firm-wide extraction, summarisation and analysis | The cleanest capability-per-card story in this index; run the publisher's low-precision format rather than requantising it yourself |
| Private tenancy of a hosted build | Firms without GPUs that still need an owned, fixed model version | Confirm the host serves the pinned release you evaluated and that no prompt or output leaves your tenancy |
Who it suits
Firms with a GPU or a private tenancy that want permissive terms, predictable structured output, and reasoning good enough for triage and internal drafting.
Firms expecting a turnkey legal product, or anyone who will show raw model output — traces included — to a client.
Review history
| Date | Change |
|---|---|
| Sep 2026 | First entry. |
Sources
- gpt-oss releases and documentation (OpenAI)
- gpt-oss model cards (Hugging Face)
- Open source LLM landscape 2026
- Probative Co: private AI in law — the 2026 guide