GemmaAPITextEncode: no LTX-2.5 checkpoint carries the 'encrypted_wandb_properties' model_id key

Open
  • Is something wrong?
#549 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
api, machine-learning

Research direction

Start in gemma_api_conditioning.py, where extract_model_id() sets model_id_key to 'encrypted_wandb_properties' and reads it from the checkpoint's safetensors header. Compare that with the gemma_source_checkpoint and config metadata that 2.5 files carry. The issue shows the /v1/prompt-embedding endpoint rejects the obvious substitute IDs, so the fix probably needs maintainer input on the valid model_id. Done means a 2.5 checkpoint either resolves to an accepted ID or fails with a clear message.

Written by the indexing model from the issue text.

Description

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
Dominant language
Python
Stars
4.2k
Forks
508
Avg merge
7h 14m
Merged PRs (30d)
3

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Lightricks/ComfyUI-LTXVideo

All issues in Lightricks/ComfyUI-LTXVideo

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.