gpt-oss-120b does not care about the answer budget
This is the boring half of a result, and it is the half that makes the other half mean anything.
Nemotron 3.5 gained 7.6 points when its answers were allowed to run to 65,536 tokens instead of 3,072. On its own that number proves less than it looks like it does. Raising a generation cap means restarting the server with a longer context, re-running the harness, and occupying the machine for twice as long — plenty of room for something other than the cap to be responsible.
So the same change ran on a model that cannot be cap-sensitive.
The measurement
gpt-oss-120b’s answers are short. At the original 3,072-token cap it averaged 524 tokens per answer, nowhere near the ceiling. If a generation cap is what moved Nemotron, this model should not move at all.
| Subject (accuracy %) | 3,072-token cap | 65,536-token cap | Spread |
|---|---|---|---|
| other | 64.5 | 69.0 | 4.5 |
| history | 60.0 | 64.0 | 4.0 |
| law | 52.5 | 49.0 | 3.5 |
| business | 81.5 | 84.0 | 2.5 |
| math | 89.5 | 87.5 | 2.0 |
| physics | 82.0 | 80.0 | 2.0 |
| economics | 83.5 | 82.0 | 1.5 |
| philosophy | 67.0 | 68.5 | 1.5 |
| biology | 83.5 | 84.5 | 1.0 |
| computer science | 82.5 | 83.0 | 0.5 |
| engineering | 63.5 | 63.0 | 0.5 |
| psychology | 77.5 | 77.0 | 0.5 |
| chemistry | 80.5 | 80.5 | 0.0 |
| health | 71.5 | 71.5 | 0.0 |
| Mean | 74.3 | 74.5 | 0.3 |
74.25 to 74.54. A mean change of +0.29 points from twenty-one times the answer budget.
Why this reads as nothing rather than as a tiny gain
Three things, and the first is the weakest:
The size. +0.29 on a mean of fourteen subjects is far inside what 200 questions per cell can resolve. That alone would only mean “we cannot see it.”
The direction. The fourteen deltas split six up, six down, two flat. A real effect pushes subjects the same way — that is what it did on Nemotron, where twelve of fourteen moved up together. Splitting evenly is what scatter looks like, and it is the same reasoning that settled the reboot question and the 1-bit quantisation question.
The mechanism. Tokens per answer went down, 524 to 513, and the sweep finished slightly faster (3.9 hours against 3.7). A model given twenty-one times more room used marginally less of it. There is no pathway by which the cap could have changed the score, because the cap was never reached.
| Subject (tokens/answer) | 3,072-token cap | 65,536-token cap |
|---|---|---|
| biology | 386 | 428 |
| business | 617 | 565 |
| chemistry | 822 | 843 |
| computer science | 441 | 422 |
| economics | 310 | 291 |
| engineering | 1409 | 1413 |
| health | 283 | 270 |
| history | 333 | 293 |
| law | 560 | 546 |
| math | 586 | 592 |
| other | 306 | 284 |
| philosophy | 401 | 398 |
| physics | 654 | 617 |
| psychology | 226 | 217 |
What it is for
A benchmark campaign that only measures where it expects to find something
cannot tell a real effect from a change in conditions. This is the negative
control, and it was run on the same machine, in the same week, with the same
harness, the same serving change, and the same raised --max-model-len.
The pair is the result:
| Mean @3,072 | Mean @65,536 | Change | Direction of the 14 deltas | |
|---|---|---|---|---|
| Nemotron 3.5 | 72.11 | 79.75 | +7.64 | 12 up, 1 flat, 1 down |
| gpt-oss-120b | 74.25 | 74.54 | +0.29 | 6 up, 6 down, 2 flat |
One model moved by eight points and one did not move at all, under an identical intervention. That difference is the generation cap.
It also inverts the ranking. At the low cap gpt-oss outscored Nemotron, 74.25 to 72.11. At the honest cap Nemotron outscores gpt-oss, 79.75 to 74.54. Neither model changed; the benchmark did.
Total run time
| Arm | What ran | Questions | Tokens generated | Machine time |
|---|---|---|---|---|
| 3,072-token cap | 14 subjects · 3,072-token cap | 2,800 | 1,466,513 | 3.9 h |
| 65,536-token cap | 14 subjects · 65,536-token cap | 2,800 | 1,435,582 | 3.7 h |
| Total | 5,600 | 2,902,095 | 7.6 h |
The high-cap arm was faster. 3.7 hours against 3.9, for the same 2,800 questions on the same machine.
That is not a speedup and nothing was optimised — it is the clearest statement of the finding available. A generation cap costs time only when it is reached, and this model never reaches it. Tokens generated barely moved (1.47 million against 1.44 million), so the two arms did the same work and finished in about the same time, with the difference well inside normal run-to-run variation.
Set against Nemotron’s 5.6 to 10.0 hours under an identical change, the contrast is as sharp in machine time as it is in accuracy. One model was being cut off and had a great deal more to say; the other was already finishing.
The practical version
If your model is terse, the generation cap is not your problem. gpt-oss-120b scores the same at 3,072 as at 65,536, and every hour spent re-measuring it at the higher cap bought nothing. Its published numbers on this site were already right.
If your model reasons at length, the cap is measuring your model’s patience rather than its knowledge. The way to tell them apart is not to argue about it: check what fraction of answers ended because the model stopped, against what fraction ended because the harness did.
That check costs nothing and would have saved this site several weeks of wrong numbers.
What this does not tell you
A negative result at this sample size is not proof of zero. 200 questions per cell puts roughly ±9 points around a single subject comparison. A one-point real effect would be invisible here. The claim is that gpt-oss shows no cap sensitivity that this measurement can detect, and there is a mechanism — answers well short of the ceiling — explaining why it should not.
One model, one harness. gpt-oss-120b at MXFP4 on vLLM, five-shot CoT, greedy. A different prompt could make the same model verbose enough to be truncated.
Reasoning effort was left at its default. This model ignores that setting anyway, which is a separate measurement, but it does mean this post does not test a configuration where gpt-oss might generate substantially more.
Setup
- NVIDIA GB10, 121 GiB unified memory, production services stopped for the duration
- vLLM (
nvcr.io/nvidia/vllm:26.04-py3), MXFP4 with the marlin backend,--max-model-len 73728 - lm-evaluation-harness,
local-chat-completions, 8 concurrent requests mmlu_pro_fair: permissive answer extraction, truncating stop sequence removed- 5-shot CoT, greedy, 200 questions per subject, fourteen subjects