GPT-OSS 20B

GPT-OSS 20B is OpenAI's small open-weight Mixture-of-Experts model. The canonical model id openai/gpt-oss-20b-unmetered is the same model's metered route with no daily usage quota, called through /v1/chat/completions.

Model	Context	Input / Output ($/1M)
openai/gpt-oss-20b-unmetered	131,072	0.03 / 0.14

curl "$LLMTR_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-oss-20b-unmetered",
    "messages": [
      { "role": "user", "content": "Summarize pagination parameters for a REST API in a few sentences." }
    ],
    "max_tokens": 512
  }'

Relation to openai/gpt-oss-20b

The provider withdrew the free tier behind openai/gpt-oss-20b on 24 August 2026 and that model id was retired. The metered id on this page is a separate, independent model and is unaffected.

Reasoning and reasoning_effort

This model reasons by default: the reasoning_effort parameter measurably changes completion length (see the table below), and as with other members of the GPT-OSS family, that reasoning trace also carries in message.reasoning_content. Those tokens are counted in completion_tokens and billed at the output rate.

reasoning_effort supports two levels:

{ "model": "openai/gpt-oss-20b-unmetered", "reasoning_effort": "none", "messages": [{ "role": "user", "content": "What is 137 * 42?" }], "max_tokens": 256 }

Level	Effect
none	Turns reasoning off; measured completion length drops noticeably relative to the default.
high	Reasons more deeply; measured completion length grows noticeably relative to the default.

low and medium can be sent (the request is not rejected with 400), but neither has a measurable effect on this deployment: low produces output byte-for-byte identical to none, and medium is byte-for-byte identical to the unset default. The gateway therefore rejects both levels with 400 — offering a control with no effect would be worse than not offering it.

Tool calling

Tool calling is native. tool_choice works correctly with auto and required; the returned tool_calls arguments are valid JSON. See Tool Calling for details.

curl "$LLMTR_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-oss-20b-unmetered",
    "messages": [{ "role": "user", "content": "What is the weather in Istanbul?" }],
    "tools": [{
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Get current weather for a city",
        "parameters": {
          "type": "object",
          "properties": { "city": { "type": "string" } },
          "required": ["city"]
        }
      }
    }],
    "tool_choice": "auto"
  }'

A named tool_choice is not enforced

Forcing one specific function by name ("tool_choice": { "type": "function", "function": { "name": "..." } }) does not act as a constraint on this deployment and fails silently: the request returns 200, but the model calls whichever tool fits the prompt instead of the one you named.

Measured (2026-08-24), with a two-tool list:

Requested name	Question	Tool actually called
get_time	weather	get_weather

The name is still validated: sending a name not present in tools returns 422. So the parameter is parsed, then ignored as a constraint.

A named choice only appears to work when the tool you asked for happens to match the one the model would have picked anyway. Do not rely on named tool_choice with this model; build your flow on auto or required, and if only one tool may ever be called, narrow the tools list to that single tool instead.

Structured output

response_format accepts both json_object and json_schema:

{
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "person",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "name": { "type": "string" },
          "age": { "type": "integer" }
        },
        "required": ["name", "age"],
        "additionalProperties": false
      }
    }
  }
}

Limits

• No image, audio, or video input. The model accepts and produces text only. A request carrying an image is explicitly rejected by the upstream ("does not accept image input") rather than being counted as text and billed by mistake.
• No prompt caching. A repeated prompt prefix is not discounted; every request bills the full input rate.
• A named tool_choice is not enforced. See the section above.
• reasoning_effort accepts only none and high. See the section above.
• No separate output ceiling. max_tokens is bounded only by the context window (131,072).