Read one partner model's input and output schemas as an OpenAPI document.

A standalone OpenAPI document describing one Comfy Router model's input and output - the body POST /v2/models/{provider}/{model} accepts for that model, under the operation's requestBody, and the body it returns, under that operation's 200 content. It is what GET /v2/models/{provider}/{model}/openapi.json returns. The component keeps its historical name, which predates the output half; the shape it describes is the whole document, not the input alone. It is a full OpenAPI document rather than a bare JSON Schema because that is what the tools this endpoint exists for consume: an SDK generator takes an OpenAPI document. The document is STANDALONE: every schema component EITHER half references travels with it under its own components.schemas - the two closures are unioned, because the document has only one components section - so nothing in it points at a section the caller does not have. A DESCRIBED output is keyed application/json, or with whatever media type its authored component declares through x-comfy-router-output-media-type (a media-type string, e.g. video/mp4) - so a generated client decodes the body the way the provider actually sends it rather than trying to JSON-parse a binary one. An output Comfy has NOT described yet is keyed */*, not application/json. The two are different claims: an undescribed output is unknown in its media type as much as in its shape, and some Router models answer with binary bodies, so keying the permissive output as JSON would assert a contract Comfy has not established. Read x-comfy-output-schema-authored to tell the two apart. The shape is left open here on purpose. Its concrete contents are an OpenAPI document, and restating the OpenAPI meta-schema inside this spec would be a second copy of a specification Comfy does not own - the exact publish-versus-enforce drift this endpoint exists to prevent, one level up. It is a named component (never an inline anonymous object) because ComfyUI's spec-driven codegen needs a class to generate. Five Comfy extensions are carried at the document root and are part of this contract. x-comfy-router-model-id repeats the canonical model ID, so a document saved to disk still names the model it describes. x-comfy-input-schema-authored is a boolean reporting whether the embedded REQUEST schema was authored for this model (true) or is the permissive fallback served until one is (false); the two are indistinguishable from the schema alone, and a caller that cannot tell them apart would read "any JSON object" as a narrowed contract. x-comfy-output-schema-authored reports the same thing for the RESPONSE schema under the 200. The two flags are INDEPENDENT and must be read separately: the halves are authored one at a time, so an authored input with an undescribed output is the ordinary state rather than an edge case. x-comfy-router-input-modalities and x-comfy-router-output-modalities are arrays naming the kinds of media the model consumes and emits, each element one of text, image, video, audio or 3d. The INPUT array records what the model is DOCUMENTED TO ACCEPT, which is a narrower claim than what the request schema admits: request schemas are shared across sibling models (one GeminiPart serves every Gemini spelling), so the schema may admit media kinds this model ignores. The array, not the schema, is the capability signal; the schema is still exactly what the server validates against. The output array is ORDERED: its first element is the model's primary output and any later element a secondary one (a video model that returns a soundtrack is ["video","audio"]). Both are always present and never empty on a document this server builds; an absent key means a server that predates them, not a model with no modality.