3.1 The Model Landscape: A Map Without Marketing

Identity consistency lives almost entirely in the reference and edit path. A generate-from-scratch workflow with no identity conditioning will drift no matter how good the model is. If you find yourself re-rolling a prompt forty times to get the same face, the problem is not the model — it is that you are asking a sampler to do a retrieval job.

Both categories matter and you need both. Chapter 4.2 sets out when to use which. The point here is that when you evaluate a model, the first question is which of the two jobs it is for, because a model that is excellent at one is often poor at the other.

The image families, by role

Grouped by the job they do, with the licenses that matter. Licenses are the column people ignore until it costs them money — chapter 11.4 explains why.

Two observations about that table.

The permissive-license column is the one that decides whether you own your identity artifact. Chapter 4.5 has you training a LoRA. A LoRA trained on a non-commercial base inherits the restriction, which means the file at the center of your business carries a license you may not be able to use commercially. Read the base model license before you train, not after.

The API-only entries are not interchangeable with the open ones. They offer frontier quality and zero control. You cannot train on them in the way that produces a portable artifact, you cannot run them offline, and you cannot keep them if the vendor changes the price or discontinues the product — which, per chapter 0.2, is not a hypothetical.

The video models

Video is where the cost per asset lives and where the vendor risk is highest, because a single discontinued API can take a whole content calendar with it.

The cost column is why chapter 7.3 builds an approval gate before rendering. At $0.40 per second, a 30-second clip costs $12 before you have posted anything, and a re-render doubles it. At $0.05 per second on the Lite tier, the same clip costs $1.50. The quality difference between tiers is real, and so is the difference between generating ten variants and generating two.

The open-weight video options exist and are the only ones you can run without a vendor's permission. They are slower, require the hardware from 3.3, and produce a shorter effective clip length in most setups. They are also the only continuity insurance you have for video, which is why chapter 12.4 staggers the dependency.

Axis two: open weights or hosted API

The second decision, and the one where the honest answer depends on volume rather than preference.

Choose API when: you are producing fewer than roughly 30 published assets a month, you do not have and do not want a GPU, you are still finding the persona's look, or the frontier quality of a specific model is the point of the content. The API removes an entire category of maintenance work that has nothing to do with making content.

Choose open weights when: you are producing more than roughly 100–200 generations a month, your identity strategy requires training and reference control, you need the output to stay on your own hardware, or — the real reason most operators switch — the per-generation cost of an API has become a line item you can no longer absorb.

The arithmetic that decides it is simpler than it looks, and it contains one non-obvious term.

Cost per published post, not cost per generation. Chapter 0.4 defines it, and the reason matters here: retries. A subscription or a fixed-cost local setup absorbs retries. A metered API multiplies them. If your workflow needs eight attempts to get one usable image, a $0.36 aggregator call becomes $2.88 of usable output, while a $10/month subscription that permits unlimited attempts stays at $10. Two operators with identical pipelines and different billing models have cost bases that differ by an order of magnitude, and the difference is entirely in how their vendor charges for failure.

One comparison worth internalizing. A general-purpose AI subscription at roughly $10 per month works out to about $0.006 per image at a thousand images, against roughly $0.36 per image through a typical aggregator API — a factor of about sixty. [AS OF 2026-10] The aggregator is more convenient, gives you one billing relationship and one API surface, and costs what convenience costs. Neither is wrong. Knowing which one you bought is the point.

Cloud GPU is the third path and often the right first one. Renting a 4090-class machine runs roughly $0.50 to $2.00 per hour on RunPod, with vast.ai commonly cited at around a third of that and a great deal more setup friction. [AS OF 2026-10] A LoRA training run costs about $2 at fal.ai's base training price and takes two to seven hours, which means a training campaign on rented hardware is measured in single-digit dollars. [AS OF 2026-10] Rent before you buy. Chapter 3.3 calculates the purchase break-even.

The one-family rule

Here is the rule that saves the most time and is the least popular, because it sounds like a constraint on quality.

Pick one model family and stay in it for the persona's look.

The reason is mechanical. Every family has its own latent space, its own prompt-following behavior, and its own statistical idea of what a face looks like at a given age in a given light. An identity adapter trained for one family does not load in another. A LoRA trained on SDXL is not a LoRA for FLUX. And when you alternate between families across a content calendar, the seams are visible in the feed: the jawline shifts, the skin texture changes character, the way the model renders catchlights moves.

Your audience will not name it. They will feel it, and the feeling is "this account is not a person," which is the one impression you cannot afford in a category built on consistency.

The rule in practice:

• One family for the persona's generated look. Everything published in that register comes from it.
• One edit/reference model, in the same family where possible, for variation and continuity.
• Other models are allowed for work outside the persona's face — graphic overlays, typography, b-roll, backgrounds, thumbnails.
• Changing the family is a project, not a setting. It means re-deciding the look and retraining the identity artifact. Chapter 12.4 covers when that is worth doing.

Where this goes wrong

Chasing rankings. A leaderboard tells you which model wins a contest, not which one holds a face across two hundred assets under a license you can sell under.

Mixing families to get "the best of each." The best of each arrives with visible seams and an identity that will not stabilize. One family, deliberately chosen, beats five chosen by benchmark.

Training on a base whose license forbids the commercial use you planned. This is the most expensive version of not reading, because the retraining and the migration cost more than the model ever did.

Buying a card before renting one. Rent for a month, measure your real volume and your real per-post cost, and let the numbers from 3.5 decide.

Treating an aggregator as a strategy. An aggregator is a billing relationship. It does not give you control, portability, or a lower cost per published post.

Believing a model upgrade will fix inconsistency. Consistency is a workflow property. The upgrade changes the pixels, not the method, and chapter 4.2 is where the method lives.

The gate

1. Which family have you chosen, and what is the license of its base?
2. Which model do you use for generation, and which for reference editing?
3. What is your monthly generation volume, and which side of the API-versus-local threshold are you on?
4. What does one published post cost you today, after retries?
5. Which single vendor, if it disappeared tomorrow, would take your content calendar with it?

What you leave with

Two axes that organize the entire market, a family-by-family map with the license column populated, the cost model that decides API versus local — retries included — and one rule worth more than the rest: one family, chosen on purpose, and changed only as a project.