USER GUIDE
Every layer of the production pipeline: project structure, brief and reference, recipe-driven generation, versioning, approval, delivery and role-based access.
You do not need technical familiarity to follow this guide. Sections labelled "For the team" are for you; you can skip the designer and manager chapters. If a term trips you up, click the underlined word — the Glossary explains it.
From joining early access to being invited to the pilot and getting ready before the first shot: how to get started with Velvet.
You sign up for the early access list with the form on the main site; the trial rate per address is limited. Your signup goes to a list that only the organization owner can see. Once you are admitted to the pilot team, you access your account with your own credentials.
Your production line is organized as Organization → Project → Role. Each project carries its own production context: history, queue, images, and saved files live within that project's boundaries. In a local installation, the first project comes ready; rename it from the Project screen.
When you log in, the home page lists your projects. Once you enter a project, the single workspace available to your role opens: the designer sees the graph editor, the operator the recipe screen, the reviewer the review queue. On the screenplay screen the breakdown appears; on an approved scene 'Suggest shots' drafts plans from the model, 'Edit' corrects them, and 'Render ready shots' sends them all to the engine in one go.
Why and how a shot is produced, which decisions must not change, and how the visual language is kept alive within the project.
The shot's narrative purpose, framing, motion, and emotional tone are clarified in the project before production. When the recipe is run, this goal is written into the creative direction field in natural language.
Character, product, location, camera, and timing constraints are locked fields in the recipe. The operator cannot change them; only the recipe itself can be updated, through a new version.
Character, style, and world references are used as production input; user files are separated per project. The recipe determines which reference fields are exposed to production.
Production methods where technical expertise is locked in and the creative team runs them with confidence.
A recipe is a versioned record of the production graph plus a parameter list that states who can change which fields in that graph. The operator never sees the graph; they fill in values and the system builds the graph on the server.
You only change the fields the recipe opens to you: text, a number with lower and upper bounds, an option list, or yes/no. No value the recipe does not define ever enters production; model files, samplers, and the graph itself are fixed by the publisher.
The same recipe can be run at different qualities: a fast resolution is used for preview, a high resolution for final. The recipe determines which field means which route; the operator merely selects.
A preview recipe starts with an empty image generation node and ends with a Save Image step; the seed, step count, and text fields are open to the operator. This structure is used to quickly produce a small preview.
The version of the same graph that outputs EXR uses a VelvetSaveEXR step after the Empty Image generator; that step sets the file prefix and precision (half precision/float), and the output is saved as linear EXR.
The operator screen shows only the fields the recipe opens: a text box, a number range, a dropdown list, or a checkbox. Model files, the graph layout, and internal nodes are not visible on the operator screen.
Directing in natural language, producing controlled variations, and comparing results within the shot.
When starting production you describe the goal rather than hunting for technical parameters. Only members with a production role (producer, technical designer, operator) can start production; every production is recorded along with who requested it.
Fields such as duration, rate, and the number of variations are limited to the ranges the recipe permits. The limits in the browser are only for convenience; the real control is applied on the server by the recipe.
Every production lands in the project's history. The 'Recent productions' list shows which recipe, which values, and who requested it together; decision comments are attached to the same record during review.
'Render' on a plan's card opens the recipe screen with the plan's values: duration, lens, height, movement and the English prompt prepared by 'Compose prompt' are filled in and can be edited before sending. 'Render ready shots' on the scene card runs the same path for every ready plan in one click; a plan whose recipe still has an unfillable required field is skipped and stays ready.
A production cannot be published until it is approved; every delivery carries a traceable record.
Productions awaiting approval appear in the review list; the reviewer gives an 'Approve' or 'Reject' verdict for each job and may leave a short note. The note shows on the job row and on the plan's card, so the operator reads there what to fix. Jobs that are not approved cannot be delivered to the shot.
The operator who started the production cannot make a review decision; approval and rejection are open only to the reviewer and producer roles. The decision is made by a different eye from the person who produced the job.
Delivery happens after approval and through an explicit action: the 'Deliver' button on an approved row in the review queue; pressing it again opens a new version. Along with the published files a manifest is written: which recipe version, which values, who requested it, who approved it, and file checksums.
Final outputs are written as linear EXR, before the production engine's 8-bit loss; the plate reaches the shot with its full tonal range. The thumbnail in the queue is a preview derived from the EXR itself, clipped for the screen: it does not touch the plate and does not stand in for it.
The work you do determines the screen you see; when you enter a project, the server routes you to your role's workspace.
| Role | Scope of access |
|---|---|
| Producer / ownerowner | The entire production line: graph editor, recipe publishing, production, review, and delivery decisions. |
| Technical designerworkflow_designer | Graph editor; building the production graph and publishing recipes. |
| Operatoroperator | Recipe screen; entering values, starting production, preview/final. |
| Reviewerreviewer | Review queue; approval and rejection decisions. Cannot start production; can examine the images. |
A role is granted at the organization level: you carry the same role across every project in the same organization. A role without access to the graph editor reaches production only through published recipes.
Where the production graph is built: a graph editor open only to the technical designer and owner roles.
When you enter a project with a designer or owner role in your organization, the server routes you to the graph editor. The production engine runs in the background at a private address only Velvet can reach; there is no direct access to it.
The interface is maintained under the Velvet brand and with the Velvet session: the engine offers no identity layer of its own, and Velvet opens it to no one. Account management is hidden, API nodes are disabled, and the production trail is separated per project.
The graph is where the production method is defined; on project entry the server routes operator and reviewer to their own screens. It is not possible for them to go beyond published recipes.
The production graph is built from single-purpose pieces (nodes); a recipe locks the graph and opens only selected fields.
A node is a single operation in the graph: it takes input, processes, and produces output. Nodes are chained by connections, and the resulting graph represents the production path. Velvet calls the published form of this graph a recipe.
A typical production graph builds layers: encoding the prompt, loading the model, sampler steps, and writing the output. Demo recipes illustrate this with nodes that generate a starting frame (EmptyImage) and write the output; published nodes stay locked, and the user only touches the opened fields.
The 'Save EXR (Velvet)' node that Velvet adds to the engine writes the running tensor as linear EXR before the 8-bit loss and selects precision (half/float). SaveImage's 255 scaling and uint8 clipping is right for a web preview but wrong for a virtual stage wall; EXR also stores values above 1.0.
When a preview is requested, the graph also carries a preview node such as SaveImage; it is kept separate from the delivery node. This way a delivered output is never silently an 8-bit copy.
Engine features used by the graph editor in Studio: queue, history, image viewing, and graph protection.
Jobs submitted from Studio first enter the queue; when finished, they appear in your project's history. The queue and history views cover only your own project's jobs; another organization's work is never listed.
Preview images and intermediate results open within the project scope; a produced image link gives no access to another project.
When you want to stop the sampler, the interrupt action only affects jobs in your own project.
An arbitrary definition (API node) cannot be loaded into the graph from outside; graph editing and recipe publishing run only under the designer/owner roles, within the project scope.
| Action | Shortcut |
|---|---|
| Send to queue (start production) | Cmd+Enter |
| Send to the front of the queue | Cmd+Shift+Enter |
| Stop the running production | Cmd+Alt+Enter |
| Open a graph | Cmd+O |
| Save a graph | Cmd+S |
| Add a new node | Double-click empty space |
| Edit shortcuts | Settings → key mapping |
| Term | Meaning |
|---|---|
| Queue | Queue: pending productions |
| Interrupt | Interrupt: stopping a running production |
| History | History: the list of finished productions |
| Load | Load: loads the graph or the model |
| Save | Save |
| Seed | Initial noise; the same settings and seed produce the same result |
| Keybinds / Keybinding | Shortcut mapping settings |
| Prompt | Production command / text request |
Turning a production graph into a recipe the team can run: which fields become parameters, and which rules apply.
The Velvet pill in the editor carries a 'Publish recipe' panel: it reads the current graph, lists the free inputs, and turns the ones you add into parameters with key, type, bounds and default; you enter a name, a slug and a kind (still / video / plate), and the publication gets a version number. A plate recipe without a trailing 'Save EXR (Velvet)' is warned about, not refused.
Only inputs that actually exist in the graph and are not connected to another node can be opened as parameters. Model files, samplers, and the graph itself stay fixed; the user only touches the fields you open.
Text (length-limited), number (lower/upper bound), option list, and yes/no. Every parameter can carry a default value; at publish time that default is validated with the same rules.
Each publish bumps the recipe's version number (V1 → V2 → …). Versions are stored append-only; whichever version produced a job appears in its delivery record.
A recipe name may contain only letters, digits, and hyphens; parameter keys must be identifiers and unique. You cannot write two parameters to one input, and inputs connected to another node cannot be changed.
Explanations of the production engine terms you may encounter on the recipe screen, in Studio, and in team discussions.
| Term | Definition |
|---|---|
| Workflow / Graf | The production graph built from nodes and connections. In Velvet its published form is called a 'recipe'. |
| Model / Checkpoint | Trained weights; the basis of image and video production. Fixed by the recipe; the operator cannot choose. |
| Sampler | The mathematical method that governs the denoising steps from noise to image. |
| Scheduler | Determines how the denoising strength is distributed across the steps. |
| Seed | Defines the initial noise; the same settings and the same seed produce the same result. |
| Pozitif / negatif prompt | The text that describes what should be included in and what should be excluded from production. |
| CFG | How strongly the prompt guides production; a high value gives a more faithful, sometimes more extreme result. |
| Denoising | How much of the existing image is changed in image-to-image jobs. |
| Latent | The compressed image representation the model works on (not pixels). |
| Upscale | The step that scales production to a higher resolution; usually used at the end of the chain. |
| Kontrol katmanı | Configuring production with signals such as pose, depth, face, and mask. |
| EXR / doğrusal | A high dynamic range image format; Velvet writes plates as EXR before any 8-bit loss. |
| VAE | The layer that converts the latent space into pixels; at the decode stage it determines the look of the output. |
| Adım sayısı | The number of denoising steps a production applies; more steps usually give a more settled, but slower, result. |
| LoRA | A small additional model that applies a specific style or character without training the whole base model. |
| Ön işleme | The step that turns a conditioning image such as pose, depth, or drawing into a guide the production can understand. |
What happens in the background when production starts; expectations for the queue, model loading, interrupt, and output.
Production first enters the queue. If the model is loading for the first time, the first job takes longer; the queue is watched together with your own jobs within the project scope.
The 'Latest production' section tracks the job from the moment it starts until it finishes; when complete, the images land in the project's history and the review list.
You can stop your own jobs in the queue; the interrupt only affects jobs in your own project.
Final outputs are EXR; the lists show a small preview derived from the EXR. It is made only for the format Velvet's EXR writer produces; for another node's compressed EXR the list says 'EXR'.
The common production patterns behind the showcase examples; each is shared with the team through a recipe.
Producing a moving shot from a single frame; the reference frame and motion direction are given through the fields the recipe opens.
Re-creating the same character and location under different conditions using signals such as pose, depth, face, or mask; world consistency via references.
First a preview is produced with a fast engine; once the direction is approved, the same recipe is run on the high-quality final route.
Character, location, and style rules stay in the recipe's locked fields; the operator only produces variations and cannot break the rules.
A conditioning image such as an OpenPose skeleton drives the character's stance; the same character is produced in another pose while facial and location integrity are preserved.
A grayscale depth map preserves the near-far relationship in the shot; in portraits, architecture, and product scenes, spatial layout and perspective do not fall apart.
The model first produces a small frame in most scenes; the upscale model enlarges the output without losing detail. If needed, it is chained as 2x then 4x.
Instead of generating over and over from text, adding a conditioning image (pose, depth, drawing) makes the result easier to own and lowers the number of attempts.
The reference descriptions of the patterns are adapted from the control and upscaling sections of the production engine's official documentation. See also: Glossary of terms for these same concepts in the language of the machine.
Where the production engine lives, how data is scoped, and who can change what.
The production engine has no authentication of its own; that is why it runs at a private address only Velvet can reach. Every user gets their access through a Velvet session.
History, queue, image viewing, deletion, and interrupt touch only the caller's own project jobs; interacting with another project's work is impossible.
In recipe-driven production the operator sends only values; the graph is built on the server from the recipe's stored version. No input the recipe doesn't know about can be changed.
Graph editor and recipe publishing are designer/owner only; starting production is producer, designer, and operator; approval and rejection are reviewer/owner.
Prototype limits: input media is currently kept in a single shared directory and the process-wide cache is shared across jobs. In a production setup these gaps are closed; a per-tenant worker, PostgreSQL RLS, and project-isolated storage are the goal.
From day one to the first delivery: enter the pre-provisioned area, produce with the demo recipe, approve, and deliver.
The team admitted to the pilot logs in with the account created during setup. The home panel shows your projects and your role in each; entering a project binds your session to that workspace.
On the 'Production' screen you select a recipe; the recipe sets the limits, and you enter the values and start production. The job lands in the 'Latest production' list — with its version and values.
The reviewer examines the images; approval grants the job delivery rights. A rejected job returns to be fixed and produced again.
The approved job is written to the delivery directory with its plates (EXR) and manifest; the stage pipeline picks up the output from there. Which version produced which job stays on record.
Roles and projects belong to the organization; team members come with a membership.
Every user is a member of the organization, and each membership carries a role; on project entry the server takes you to your role's workspace. You carry the same role across every project in the same organization.
One account can be a member of multiple organizations; their projects are listed separately on the home panel. Entering the active project binds the session to that workspace.
Within the pilot scope, member accounts are created during setup; the interface for member invitations and role changes will come in the production release. Membership and multi-project infrastructure are ready today.
Authentication, session lifetime, and account behavior.
You sign in with your email and password. For security the system does not store passwords; if either the account or the password is wrong, it shows you a single warning: 'Incorrect email or password.'
A sign-in stays valid for 12 hours and that time does not extend; when it expires you enter your password again. The same sign-in is valid across multiple tabs of the same account.
The sign-out button resets your access; on the next page your password is requested again.
The demo area starts with the admin account defined in the setup; password values are set during setup and never shared externally.
Where productions and customer material are stored, and what leaves the premises.
Data stays on the setup's machine: the database, shots (separate per project), and delivered plates. Customer material never leaves the workspace.
There is no external analytics or usage tracking; on the site only the waitlist form collects data, and that only for an access request.
The form on the site is only an access request record; access is later granted by the admin during setup.
The production engine runs at a private (local) address; jobs and outputs never leave that address. All access goes through a Velvet session.
Where the files produced at the end of production live, what they contain, and how they are verified.
Delivered plates are written to the setup's delivery directory; every delivery is arranged together with a manifest that carries the production record.
manifest.json; it carries which recipe version was used, the entered values, the identity of the requester and approver, and file checksums; it is the verifiable record of the delivery.
The EXR writer step uses the default 'velvet/plate' prefix; the prefix and precision (half precision/float) are set in the recipe definition and cannot be changed by the operator.
The final output is linear EXR; what is shown in the browser is a preview derived from it and clipped for the screen. So you don't mix the two, see the 'Commonly confused concepts' section.
The file checksums in the manifest are used to verify that the delivered files have not been altered; the pipeline counts this verification as part of the delivery.
File names and folder layout vary by setup; the structure is established together with the expectations of the pipeline that receives the delivery. See also: Approvals for the approval and delivery order, and Commonly confused concepts for the EXR mix-up.
Typical situations you may meet and the steps to take.
A value outside the recipe's limits shows an error directly on the form; bring the value into the range the recipe describes.
An unapproved job is not delivered with 'approval required': first the reviewer's approval, then delivery.
When the model loads for the first time, the first job can be noticeably slower than later ones; this is normal for the engine, not an error.
The lists preview files from Velvet's EXR writer. If the word 'EXR' stays, the file came from another node (compressed or tiled); make sure the recipe ends with 'Save EXR (Velvet)'.
After 12 hours you are asked to sign in again; once you go back to the project after signing in, your workspace returns.
If production never starts, the engine may not be running at its local address; if you see a connection error, report it to your admin.
An error like 'Model not found' indicates that the model file the recipe looks for is absent; the admin adds the model to the engine's model folder and production is retried.
Channel and dimension errors usually come from wiring models from different architecture families (for example the flux family with the SD1.5 family) into the same graph; the recipe designer uses models from the same family with a matching VAE.
Model files can be several gigabytes; if disk and memory run out, loading errors out. The admin checks disk space, drive speed, and cache settings.
An error like 'Error while deserializing header' usually points to a corrupted or incomplete model file; the problem is resolved by downloading the model again.
The model symptoms and solutions are adapted from the troubleshooting section of the production engine's official documentation. See also: Error message: what should I do? for copy-paste matches.
Matches the typical error messages you may see on screen with a copy-paste section.
| Error | What to do |
|---|---|
| Model not found | The model file is missing or moved out of its path; the admin adds the model to the model folder and the job is retried. |
| Error while deserializing header | A corrupted or incomplete download; the model is re-downloaded from a verified file. |
| Latent/dimension mismatch | Models from different architecture families have been wired into the same graph; use models from the same family and keep the VAE compatible. |
| Connection refused | The production engine is not running; report it to the admin. When the engine is up, the job automatically returns to the queue. |
| EXR won't open in the browser | This is normal: EXR's linear format does not open directly in the browser. The lists make a thumbnail from Velvet's writer's EXR; if the word 'EXR' stays, the file came from another node. |
| Value out of range | The form rejected it by enforcing the recipe rule; bring the value into the described range. |
The table is compiled from the model issues section of the production engine's official documentation and Velvet symptoms; the message text can differ slightly by version. If you can't find an exact match, reach out to your admin with a screenshot. See also: Troubleshooting.
On the team side, only a browser; the engine and data run locally.
Only a browser is needed; no additional server address or port information is required. Identity and workspace come from a single sign-in.
The production engine's version is reported in the setup's system status; recipes are pinned to engine behavior. A version update is an admin decision, and recipes are run through a verification run first.
Velvet and the production engine run on the setup's machine; the engine uses model files, and the load is visible on the first production. While the engine is off, production stops.
The local setup is served on 127.0.0.1:8788 (changeable via VELVET_PORT); the engine runs on 127.0.0.1:8188. If the team is not using the same machine, the admin publishes the area through a secure proxy.
The pilot runs on a single machine; in setups where multiple organizations produce at the same time, isolation with a per-tenant worker is the production goal.
A documentary team's step-by-step flow from brief to delivery; you'll recognize ahead of time what you see on screen when it happens.
The example combines the role separation and approval chain described in Velvet's documentation with a real flow; names may differ for your setup.
Sets side by side the terms that look alike but mean different things.
| When you say | You mean | Difference |
|---|---|---|
| Preview | Final | A preview is for the screen: the fast route's output, or the clipped thumbnail derived from the EXR; the final is delivered as a linear EXR plate. The two are not the same file. |
| Recipe | Production | A recipe is a graph record versioned from a publication plus a parameter list; a production is the single job that runs the recipe. The recipe stays fixed; production is redone. |
| Queue | History | The queue shows pending jobs; history is the list of finished jobs. Production first enters the queue and falls into history when done. |
| Organization | Project | An organization is the address of the team that owns people and roles; a project is the production area inside it. The role runs at the organization; the work runs in the project. |
| EXR / linear | JPEG preview | EXR is the high dynamic range file that preserves the plate's tonal range; the JPEG preview is only the compressed image seen on screen. EXR does not open directly in the browser; Velvet derives its thumbnail from the EXR. |
| Approval | Delivery | Approval is the reviewer's verdict after seeing the job; delivery is the file publication that follows that approval. No delivery can be made without approval. |
| Version | Production | A version is an immutable snapshot of the recipe record; a production runs that version. Every production always binds to a single version. |
All of the concept pairs are explained in the table beside; reading it together with the troubleshooting section is recommended.
Trusted external sources for inspiration and explanation; this site complements them but does not replace them.
The production engine's official documentation: concepts, interface guide, tutorials, and troubleshooting. Most of the concepts in our guide are adapted from there; the English source may be needed for technical detail.
Example production graphs and templates shared by the community; used for inspiration. Review the 'Publishing recipes' section before moving them into Velvet.
The docs describe the raw engine layout for setup, data, and model files; Velvet manages these itself. Consult your admin before applying steps from external sources to your setup.
External source material is brought into this guide in adapted form; quoted uses credit the source and comply with its licenses.
Short answers to the most common questions.
Delivery is open only to approved jobs. A job pending review or rejected does not reach the shot; the reviewer's approval comes first.
Any value that violates a recipe rule is rejected with an error message; production does not start. The limits are enforced on the server, not in the browser.
Your role uses the recipe screen or the review queue. The graph editor is open only to the technical designer and owner roles.
When production starts, the 'Latest production' section on the same page tracks the job; when finished, the images land in the project's history and the review list.
The published files are written to the delivery directory the stage pipeline watches; it contains manifest.json carrying the production record.
Sessions expire after 12 hours; when the time is up you must sign in again.
Finished productions land in the project's history and review list; delivered plates rest in the delivery directory with the manifest. If neither is present, the job may be incomplete; see the 'Error message: what should I do?' section.
The graph editor is open only to the designer/owner role, and recipe versions are append-only records: an accidentally broken version is not published, the previous version's record is not damaged, and it can be reverted.
An operator cannot delete a production; production records stay in the project until delivered. Deletion happens through your own data-management means, if any.
The model options the engine behind Velvet can use: open-source models run on your own machine (through ComfyUI), while closed models are connected through an API. The tables below compare open-source and API-based options for voiceover, video generation, and language models.
| Model | Type | Description |
|---|---|---|
| F5-TTS | Open source (local) | Zero-shot voice cloning; highly natural and multilingual. |
| E2-TTS | Open source (local) | Same family as F5-TTS; fluent and faithful speech. |
| Kokoro | Open source (local) | Very fast and light; strong English quality. |
| XTTS v2 | Open source (local) | Voice cloning; supports 17 languages. |
| OpenVoice v2 | Open source (local) | Voice cloning and style transfer; multilingual. |
| Fish Speech | Open source (local) | Expressive speech with emotion tags. |
| GPT-SoVITS | Open source (local) | Voice cloning from a 5-second reference. |
| Chatterbox | Open source (local) | Zero-shot cloning with a natural tone. |
| CosyVoice | Open source (local) | Zero-shot cloning; multilingual. |
| StyleTTS 2 | Open source (local) | Style-controlled speech with low latency. |
| Zonos | Open source (local) | Large and multilingual; high quality. |
| Bark | Open source (local) | Can also generate non-speech sounds and music. |
| Piper | Open source (local) | Lightweight and very fast on CPU. |
| ChatTTS | Open source (local) | Conversation-focused, natural chat tone. |
| MeloTTS | Open source (local) | Multilingual with strong English support. |
| Orpheus | Open source (local) | 3B-class expressive, real-time speech with emotion tags. |
| Sesame CSM | Open source (local) | Natural conversation and dialogue with expressive intonation. |
| Spark-TTS | Open source (local) | Zero-shot voice cloning; multilingual. |
| MetaVoice | Open source (local) | English voice cloning under a permissive license. |
| Dia | Open source (local) | Multi-speaker dialogue generation with natural turn-taking. |
| Parler-TTS | Open source (local) | Describe and control the voice in text. |
| WhisperSpeech | Open source (local) | Research-focused, Whisper-ecosystem aligned. |
| OpenAI TTS | Closed API | Paid API; high naturalness, good English. |
| ElevenLabs | Closed API | Paid API; the most popular for commercial voiceover. |
| Google Cloud TTS | Closed API | Paid API; many languages and voices. |
| Azure Neural TTS | Closed API | Paid API; enterprise English voices. |
| Amazon Polly | Closed API | Paid API; multilingual. |
| Model | Type | Description |
|---|---|---|
| Wan 2.1 / 2.2 | Open source (local) | Text-to-video and image-to-video; Apache-2.0, the 5B version runs on 8 GB VRAM. |
| LTX-Video / LTX 2.3 / 2.5 | Open source (local) | Very fast; LTX 2.3+ has native synchronized audio + video (up to 4K). |
| Hunyuan Video 1.0 / 1.5 | Open source (local) | High cinematic motion quality. |
| CogVideoX 2B / 5B | Open source (local) | High prompt adherence. |
| Mochi 1 | Open source (local) | Fluid motion; a fine-tuning base. |
| Stable Video Diffusion | Open source (local) | Image-to-video; low memory. |
| Open-Sora / Open-Sora 2.0 | Open source (local) | Fully open source; long, cinematic videos. |
| VACE | Open source (local) | Open Wan-based family; video editing and control. |
| OpenAI Sora | Closed API | Paid API; high quality and long scenes. |
| Google Veo | Closed API | Paid API; realistic motion with good control. |
| Runway Gen | Closed API | Paid API; cinematic video. |
| Pika | Closed API | Paid API; creative stylization. |
| Kling | Closed API | Paid API; strong physics and animation. |
| Luma Dream Machine | Closed API | Paid API; strong image-to-video. |
| Hailuo / MiniMax | Closed API | Paid API; smooth, high-quality video. |
| Model | Type | Description |
|---|---|---|
| Qwen 2.5 / Qwen3 / Qwen3.5 / Qwen3.6 | Open source (local) | Runs locally as GGUF; strong text, code, and multimodal. |
| Qwen3-VL / Qwen2.5-VL | Open source (local) | Multimodal; can understand images. |
| Gemma 3 / Gemma 4 | Open source (local) | Multimodal and text; local GGUF. |
| Llama 3.1 / Llama 4 | Open source (local) | A strong general-purpose open family; very long context. |
| Mistral / Mixtral / Mistral Small 4 | Open source (local) | Fast, efficient, and multilingual; Apache-2.0. |
| DeepSeek V3 / R1 / V4 | Open source (local) | Strong reasoning and code generation; MoE. |
| gpt-oss-20b / gpt-oss-120b | Open source (local) | OpenAI's open-weights model; local. |
| Phi-3 / Phi-4 | Open source (local) | Lightweight yet capable small models. |
| Nemotron | Open source (local) | Commercial open family; local GGUF. |
| Kimi K2 / K3 | Open source (local) | Moonshot's open family; strong reasoning and agents. |
| GLM-5 / GLM-5.2 | Open source (local) | Z.ai's open model; strong code and agentic work. |
| OLMo / Tülu 3 | Open source (local) | Fully open source (weights + data + code). |
| Falcon | Open source (local) | Open family; text and code. |
| MiniCPM-V / LLaVA | Open source (local) | Local multimodal models that understand text and images. |
| OpenAI GPT | Closed API | Paid API; strong general-purpose and multimodal. |
| Anthropic Claude | Closed API | Paid API; strong in creative writing and reasoning. |
| Google Gemini | Closed API | Paid API; multimodal with a long context. |
Rows marked 'Open source (local)' run on your own hardware through ComfyUI nodes; rows marked 'Closed API' connect over the internet to a paid service and require an API key. Verify a model's current license before commercial use.