Hugging Face id on Sume video models: the field is always null

No. Every row from Sume's GET /v1/videos/models carries a hugging_face_id key, and in the current catalog code its type is literally null, so the field never points you at downloadable weights. It exists because the endpoint follows the OpenRouter video-generation shape field for field; it is not a statement about which models are open.

That matters when you are comparing open-weights video models (Wan 2.2, LTX, HunyuanVideo, Mochi) with hosted routes. A null hugging_face_id does not mean a model is closed, and a model you can download is not automatically on Sume. This post shows how to read the catalog correctly and what to do with that answer.

Where does hugging_face_id come from?

The Video generation docs describe the video models endpoint and show an example row. That row includes "hugging_face_id": null, next to supported_resolutions, supported_durations, pricing_skus and allowed_passthrough_parameters.

In the API source the descriptor type declares hugging_face_id: null, and the builder sets it to null for every model. The OpenAPI schema marks it nullable string so that clients written against the OpenRouter contract keep working after only a base URL and key change.

• It is a compatibility field, not a download pointer.
• It is present on every model row, hosted-only or otherwise.
• Do not branch your code on it; branch on id, supported_durations and supported_input_references.

How do I check what the catalog actually lists?

Ask the endpoint and print the fields that decide whether a model fits your job. The script below needs only requests and a key in SUME_API_KEY.

import os
import requests

resp = requests.get(
    "https://api.sume.com/v1/videos/models",
    headers={"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"},
    timeout=30,
)
resp.raise_for_status()
for m in resp.json()["data"]:
    durations = m["supported_durations"]
    print(
        m["id"],
        m["supported_resolutions"],
        f"{min(durations)}-{max(durations)}s",
        "hf:", m["hugging_face_id"],
    )

What does the catalog say about open-weights families?

The docs name wan-3.0 as a catalog id that accepts 2 to 30 seconds. The docs I read do not list an LTX, HunyuanVideo or Mochi id, so treat the live endpoint as the only authority and run the script above before you assume anything. If an id is missing from the output, a request naming it will not work.

Open weights and hosted routes answer different questions. Weights answer "can I run this on my own GPU, with my own modifications?" A hosted route answers "can I submit a request and get an MP4 without owning a GPU?" The pages for the open projects tell you about the first question; the catalog tells you about the second.

What should I do when an open model is not in the catalog?

You have two honest options. Run the weights yourself, accepting the GPU, the setup and the license terms, or pick the nearest hosted id and test the same prompt there. The open-source video model vs API post lays out the trade, and what is hosted for Wan 3.0 covers the one family where the hosted id and the open name overlap in spirit but not in weights.

Sume does not proxy arbitrary Hugging Face repositories, does not accept a weights path, and the video request has no LoRA or checkpoint field. If you need your own fine-tune, that is a self-hosting job.

Which request fields still work across models?

Once you have picked an id from the catalog, the request is the same POST /v1/videos body: model, prompt, optional duration, resolution, aspect_ratio, frame_images, input_references, generate_audio and callback_url. Poll the job as described in Jobs and results. No v1 model accepts a seed; the catalog reports seed: false, so do not rely on reproducible reruns.