Skip to content

How do Models work?

No model is the point. They differ in what they are good at, what they cost, what they will accept as input, and how they like to be addressed, and they change constantly. Lorvara is built so that none of that has to be your problem unless you want it to be.

The agent chooses by default. A Skill names the kinds of model that suit the work, and the agent picks from what is actually on the roster today. You can override it in the Studio whenever you want something specific.

Your project sets defaults. The image and video models a project generates on are project state, so a stills campaign and a film in the same world can run on different models without arguing.

Cost is shown before you commit. Credits are the meter, and what a generation costs depends on the model, the size and, for video, the duration. You see the number before you generate, not after.

Capabilities differ, and it matters most with references. Some models take many reference images, some take a few, some take none at all. If a model cannot receive the references you attached, the prompt says so rather than quietly dropping them.

The picker shows you what can do the job. It opens on Usable (the models that can actually perform the operation you have chosen, at the duration you have asked for), with All Models one press away, every grayed card carrying the reason it is grayed. See The model picker.

Rights differ too. Each model carries its commercial-use status, so you can tell before you generate rather than before you ship.

The current list, for you and your assistant

Section titled “The current list, for you and your assistant”

Lorvara publishes the models it offers right now at https://lorvara.com/api/models.json. It is read live from the same records the Studio uses, so a model added or retired shows up there within minutes, with no release in between. For each model it gives what changes how a brief is written: the clip lengths a video model takes, the aspect ratios it offers, whether it makes its own audio, and whether it takes character references and how many. It never shows prices.

It is plain JSON, made for an assistant to read. When your assistant writes a brief, have it fetch the list first and copy the model names exactly. A value the records do not state comes back empty and is named as missing, rather than guessed. A model that offers no aspect choice, because the start picture decides the shape, says so: its aspect list is empty and its aspect_choice reads none, so a brief should not name a ratio for it. An unknown list reads unstated instead.

The roster moves, and the product is built around that. Models arrive, change price and retire. Skills deliberately describe the work rather than naming a model, and where a Skill does record which models suit it, those are stored as identifiers resolved when read, specifically so a Skill can never confidently route to a model that no longer exists.

One description, many dialects. The agent renders the same Skill into whichever model’s language it is aiming at: terse tags for some, prose for others, shot-structured cinematography for others again. You do not maintain a prompt per model, and adding a model does not mean rewriting your Skills.

Prompt length is a model property. Prompts composed for a project are written to fit the default model’s limit, and the limits differ by more than tenfold. Change the default and what gets written changes with it; move a finished prompt to a tighter model and it can be refused on length alone, which is what the Prompt Agent’s refactor is for.

The register, not this page, is the source of truth for any number. Per-model credit costs, reference caps, sizes and rights status live with the models themselves and are shown in the app. Figures typed into documentation go stale quietly, so this page carries none.