New BFL-API-flux-3-video.json covers all three modes: t2v straight to
SaveVideo, i2v fed by Flux3Keyframes, and v2v fed by LoadVideo through
VideoToBase64. The tools workflow gains a Flux Virtual Try-On v2 group
mirroring the v1 setup; remaining churn in that file is ComfyUI
frontend metadata (aux_id -> cnr_id, node order/positions) and the
outpaint mode widget value written by the current node schema.
README gains the three Flux 3 Video rows at the top of the generation
table plus the Flux 3 Keyframes, Video to Base64 and VTO v2 entries.
CHANGELOG gets an Unreleased section covering the new nodes and the
Reasoning/Generating polling fix.
Wrap the new flux-3-video endpoint (t2v, i2v, v2v modes) in three
generation nodes plus two workflow utilities:
- BaseFlux3Video reuses BaseFlux post/poll, overrides process_result to
download the signed MP4 and return ComfyUI's native VIDEO type, and
returns a 1-frame black video on every failure path. Polling ceiling
is 240 attempts (~20 min): a real v2v+fhd task was still generating
at 11 minutes.
- Flux3Keyframes combines up to 10 image sockets into the keyframes
string; timing 'even' sends a plain list, 'custom' sends
[seconds, image] pairs (start pinned at 0, end_time = clip length).
- VideoToBase64 converts a ComfyUI VIDEO to a base64 MP4 string for
v2v's start_video.
Nodes register only when comfy_api is importable so the package keeps
loading on older ComfyUI versions.
BFL's get_result reference documents two intermediate statuses the
Status enum was missing: Reasoning and Generating (returned by FLUX 3
tasks). Status(status) raised ValueError on them, which landed in the
JSON-parsing error handler with a misleading log line. Both now retry
like Pending, and the retry log prints the actual status.
BFL released flux-tools/vto-v2 on 2026-07-17 with sharper face
preservation and inputs up to 4 MP. The request/response format is
identical to v1, so the node subclasses FluxVirtualTryOn and overrides
only the endpoint path via a new URL_PATH class attribute.
BFL added a `mode` parameter to flux-tools/outpainting-v1 (2026-06-09)
selecting the quality/speed tradeoff. Expose it as a combo defaulting
to "high" (the API default) and only send it when set to "fast", so
the default request body stays unchanged.
Wrap the new BFL flux-tools/vto-v1 endpoint as FluxVirtualTryOn,
following the erase/outpaint tool-node pattern: base64 string
person/garment inputs, a required prompt, and optional
seed/webhook/config over the shared BaseFlux post -> poll path. Update
the README node table and add two virtual try-on groups to the tools
example workflow.
adds FluxErase (POST flux-tools/erase-v1) and FluxOutpaint
(POST flux-tools/outpainting-v1) in a new nodes/flux_tools.py
module. these wrap the two new BFL tool endpoints from May 2026.
also:
- ImageToBase64_BFL gains an image_format dropdown (jpeg / png) so
masks can be encoded losslessly
- BaseFlux.generate_image moves check_multiple_of_32 inside the
try/except so non-multiple-of-32 dims return a blank image
instead of crashing the workflow
- bump version to 1.1.0; start CHANGELOG.md fresh at 1.1.0
introduces project-level claude code tooling — CLAUDE.md behavioral
rules and BFL conventions, agents/commands/skills under .claude/, and
hooks that block accidental config.ini API-key commits and run ruff
after edits. wires ruff into pyproject.toml as a dev extra with the
project's lint/format config, and ignores claude runtime artifacts.
- Added permissions for issue writing in the workflow.
- Modified condition to check repository owner instead of fork status.
- Updated action version from `main` to `v1` for stability.
Çağan Kiraz