Summary
GemmaAPITextEncode.extract_model_id() reads a metadata key named encrypted_wandb_properties from the selected checkpoint's safetensors header to build the model_id sent to https://api.ltx.video/v1/prompt-embedding. None of the LTX-2.5 checkpoints published on Lightricks/LTX-2.5 carry that key, so the node always fails with "Model ID cannot be identified from the provided model file" for any 2.5 checkpoint.
Details
Checked the safetensors header metadata (via a range request, not a full download) on both:
diffusion_models/ltx-2.5-22b-distilled-transformer-bf16.safetensors
diffusion_models/ltx-2.5-22b-dev-transformer-bf16.safetensors
Both return the same metadata key set:
['model_version', 'gemma_source_checkpoint', 'license', 'config']
encrypted_wandb_properties is absent from both. gemma_source_checkpoint is present instead, e.g.:
{"ltx_version": "2.5.0", "gemma_version": "gemma4-12b-ltx-v1"}
The Aug 11 launch-day update (PR #547) touched gemma_api_conditioning.py for multi-folder checkpoint resolution, but model_id_key = "encrypted_wandb_properties" itself was left unchanged, so the lookup still targets the old key.
I also tried calling /v1/prompt-embedding directly with a few plausible substitute model_id values derived from the new metadata (gemma4-12b-ltx-v1, ltx-2.5.0, 2.5.0, ltx-2.5, and a combined form) in case the API itself would accept a simpler identifier for 2.5. All were rejected identically:
{"type":"error","error":{"type":"invalid_request_error","message":"The requested model_id is not served by this endpoint."}}
So this isn't just a stale key name on the client side - the API endpoint doesn't yet recognize any plain identifier for LTX-2.5 either, at least none I could guess from public metadata.
Expected behavior
GemmaAPITextEncode should work against LTX-2.5 checkpoints the same way it does for 2.3, either by:
- LTX-2.5 checkpoints carrying a valid
encrypted_wandb_properties (or equivalent) value again, or
- the node/API being updated to derive a valid
model_id from the new gemma_source_checkpoint/config metadata that 2.5 checkpoints do carry.
Environment
- ComfyUI-LTXVideo: latest
master (ac4d99839020b983e956a8ab67ec38aec1b6e65a, 2026-08-11)
- Checkpoints: Lightricks/LTX-2.5, both distilled and dev transformer variants
Summary
GemmaAPITextEncode.extract_model_id()reads a metadata key namedencrypted_wandb_propertiesfrom the selected checkpoint's safetensors header to build themodel_idsent tohttps://api.ltx.video/v1/prompt-embedding. None of the LTX-2.5 checkpoints published on Lightricks/LTX-2.5 carry that key, so the node always fails with "Model ID cannot be identified from the provided model file" for any 2.5 checkpoint.Details
Checked the safetensors header metadata (via a range request, not a full download) on both:
diffusion_models/ltx-2.5-22b-distilled-transformer-bf16.safetensorsdiffusion_models/ltx-2.5-22b-dev-transformer-bf16.safetensorsBoth return the same metadata key set:
encrypted_wandb_propertiesis absent from both.gemma_source_checkpointis present instead, e.g.:{"ltx_version": "2.5.0", "gemma_version": "gemma4-12b-ltx-v1"}The Aug 11 launch-day update (PR #547) touched
gemma_api_conditioning.pyfor multi-folder checkpoint resolution, butmodel_id_key = "encrypted_wandb_properties"itself was left unchanged, so the lookup still targets the old key.I also tried calling
/v1/prompt-embeddingdirectly with a few plausible substitutemodel_idvalues derived from the new metadata (gemma4-12b-ltx-v1,ltx-2.5.0,2.5.0,ltx-2.5, and a combined form) in case the API itself would accept a simpler identifier for 2.5. All were rejected identically:{"type":"error","error":{"type":"invalid_request_error","message":"The requested model_id is not served by this endpoint."}}So this isn't just a stale key name on the client side - the API endpoint doesn't yet recognize any plain identifier for LTX-2.5 either, at least none I could guess from public metadata.
Expected behavior
GemmaAPITextEncodeshould work against LTX-2.5 checkpoints the same way it does for 2.3, either by:encrypted_wandb_properties(or equivalent) value again, ormodel_idfrom the newgemma_source_checkpoint/configmetadata that 2.5 checkpoints do carry.Environment
master(ac4d99839020b983e956a8ab67ec38aec1b6e65a, 2026-08-11)