The OmniChar project has released version v1.3.26: an open studio for consistent AI characters under the GPLv3 license, where the entire character — face, body, clothing, and trained LoRA adapter — is packaged into a portable .char file. The format works with image and video generation via FLUX.2, Krea 2, MiniMax H3, and other models, connects to local ComfyUI and the OmniChar Cloud beta, and measures appearance drift between renders with a number. The idea is for a character to stop being a setting of a specific pipeline and become a portable artifact.

image
image
image

What happened

On September 25, 2026, the open studio OmniChar released v1.3.26 — a tool for generating consistent AI characters, distributed under GPLv3. The key entity of the project is the .char file: a zip archive containing a manifest, reference images, face crops, a "frozen" text description of the character, and embeddings for scoring; in fact, a single file transfers the character's face, body, clothing, and its trained LoRA adapter. The format connects to image generation via FLUX.2, Krea 2, Z-Image Turbo, and LTX-2.5 22B, to video with sound via MiniMax H3, and to video without sound via LTX-2.5 22B and Z-Image Turbo. You can work with .char from local ComfyUI via a separate node or from the OmniChar Cloud beta, which is open as a public test.

Context

Before the emergence of such formats, consistency was assembled manually for each base model: either a personal LoRA was trained for hours, or face adapters like PuLID and InstantID were used, which transfer only the face and do not hold clothing and body. For video, MiniMax H3 had separate lightweight RefMods — .safetensors files of about 1–1.6 MB in size, working exclusively with this model. OmniChar builds consistency checking from known components: YuNet detects faces, SFace builds 128-dimensional signatures, DINOv2-base forms a 768-dimensional subject centroid; each render receives a continuity score from 0 to 100, and appearance drift is read as a number, not by eye. There is no scientific novelty here — the value is in the engineering assembly and the attempt to establish .char as a contract between tools, similar to how safetensors standardized weight exchange.

Why this matters for the industry

Under a single format, three different identity transfer mechanisms are hidden: FLUX.2 klein reads references directly via its own multi-reference channel, sending them as tokens into the prompt sequence without any training; Krea 2 requires a trained LoRA adapter; MiniMax H3 receives references via a separate node, accepting up to 9 images, 3 clips, and 3 audio files. For builders, this means that .char is a portable data format, not a portable model feature: maintaining a character across the entire funnel from images to video no longer requires hours of training for each base, the cost of consistency drops, and the tie to a single tool weakens. The continuity score for the first time gives production pipelines a quantitative quality criterion instead of manual review of renders. A limiting factor: vendors are embedding native reference mechanisms into the models themselves, and if this continues, the value of the format will shift from transfer to management — scoring drift, character libraries, and their versioning between projects.

Why this matters for users

You can use it today if you have an NVIDIA card or a fal account: the path with 16 GB of VRAM is being tested for training adapters for FLUX.2, Krea 2, and Z-Image Turbo. Installation is reduced to git clone and running ./webui.sh --install --extra all, after which the web UI opens at http://127.0.0.1:8848; ready-made workflows for FLUX.2 Klein 9B and MiniMax H3 are included, there is a library of other people's .char files, and a ready-made character can be transferred between projects with a short prompt. The video pipeline on MiniMax H3 requires serious hardware — about 40 GB of weights and 64 GB of RAM, — so owners of modest cards have a realistic path now through the cloud or through local image generation.

What is still unknown / limitations

Scenes with multiple people are currently broken: the character's face "spreads" to other characters. Performance is sensitive to the number of references: five references at 1024px resolution slow down one generation step by about six times, so the latency budget should be planned in advance. The project is in version 1.x, there is no public data on the price of the cloud beta and exact latency, and the methodology of the continuity score — the formula, calibration, and thresholds — is not published, which makes the metric homemade and not verifiable by third parties. Comparative baselines with LoRA training or PuLID/InstantID on the same hardware are also not provided, so the gain in time and quality is currently confirmed only by the authors' descriptions. Finally, one cannot expect the same consistency from each supported model out of the box: the quality of transfer depends on which reference mechanism a specific base uses.

Sources

Author

Look at AI, editorial team