vllm-project/vllm · error · Error

gpt_oss uses native Harmony output parsing; generic {kind} p

Error message

gpt_oss uses native Harmony output parsing; generic {kind} parser override `{selection}` is not supported

What it means

vLLM's gpt-oss models parse their output natively through the Harmony format; this error is returned when a configuration explicitly overrides the generic parser selection for a gpt-oss model. The frontend detects model id `gpt-oss*` and rejects any `--tool-call-parser` / structured-output parser override because it would bypass Harmony.

Source

Thrown at rust/src/chat/src/error.rs:53

    #[error("{kind} parsing is disabled by frontend configuration")]
    ParserDisabled { kind: &'static str },
    #[error(
        "{kind} parser `{name}` is not registered{}",
        available_parser_hint(.available_names)
    )]
    ParserUnavailableByName {
        kind: &'static str,
        name: String,
        available_names: Vec<String>,
    },
    #[error("failed to initialize {kind} parser `{name}`")]
    ParserInitialization {
        kind: &'static str,
        name: String,
        #[source]
        error: BoxedError,
    },
    #[error(
        "gpt_oss uses native Harmony output parsing; generic {kind} parser override `{selection}` is not supported"
    )]
    HarmonyParserOverrideUnsupported {
        kind: &'static str,
        selection: String,
    },
    #[error("harmony output parsing failed")]
    HarmonyOutputParsing {
        #[source]
        error: BoxedError,
    },
    #[error(
        "this model's maximum context length is {max_model_len} tokens, \
         but the prompt contains {prompt_len} input tokens"
    )]
    PromptTooLong { max_model_len: u32, prompt_len: u32 },
    #[error("chat request stream `{request_id}` closed before terminal output")]
    StreamClosedBeforeTerminalOutput { request_id: String },

View on GitHub (pinned to c794754062)

Solutions

1. Remove the parser override from the config for gpt-oss models and let Harmony parsing handle output.
2. If you truly need a generic parser, serve a non-gpt-oss model.
3. Check the model_id detection: only the actual gpt-oss model family takes this path, so verify which model the frontend resolved.

Example fix

# before
model = "openai/gpt-oss-120b"
tool_call_parser = "hermes"

# after
model = "openai/gpt-oss-120b"
# no tool_call_parser override: Harmony parsing is used natively

let is_gpt_oss = model_id.starts_with("gpt-oss");
if is_gpt_oss {
    assert!(tool_call_parser_override.is_none(), "gpt-oss uses native Harmony parsing; remove the parser override");
}

fn forbids_parser_override(model_id: &str) -> bool {
    model_id.starts_with("gpt-oss")
}

match result {
    Err(e @ vllm_chat::Error::HarmonyParserOverrideUnsupported { .. }) => {
        eprintln!("remove the parser override for gpt-oss models: {e}");
        std::process::exit(2);
    }
    other => other?,
}

When it happens

Trigger: Launching the Rust frontend serving a gpt-oss model with an explicit generic parser selection set in the frontend config (e.g. `tool_call_parser = "hermes"`).

Common situations: Copy-pasting a server config built for Llama/Qwen models onto a gpt-oss deployment; upgrading vLLM where the override used to be silently ignored and is now rejected.

Related errors

• {kind} parser `{name}` is not registered{}
• harmony output parsing failed
• failed to initialize {kind} parser `{name}`
• failed to read chat template file
• chat template looks like a file path but does not exist

AI-assisted analysis of vllm-project/vllm@c794754062 (2026-08-14). Data as JSON: /api/errors/0d6e9f6a4667f2a9. Report an issue: GitHub.