You have a paid subscription, you ask Hermes for an illustration one day, and the result looks fine — but you cannot find anywhere in the settings which model drew it. The reason is simple: you never opened the image lane in hermes tools, so the picture came from the first-run default, and that default used to be FAL’s FLUX 2 Klein 9B.

There was a second, smaller annoyance alongside it. You handed over a reference image and asked the model to draw something in that style. Instead it ran a vision pass over the picture and wrote a long style description into the prompt — because the schema told it you wanted to edit that image. Krea 2 does not edit anything; it copies the look.

A change merged in this window fixes both.

The default is written under a very narrow condition

The new rule in one sentence: a paid account defaults to Krea 2 Medium Turbo, but only when the image section was never configured, holds no stored model, and the account is actually entitled to Krea.

Each qualifier earns its place:

• “Never configured”: if you have ever picked a model in hermes tools, nothing is overwritten. That is the most important property here — this is not “changing a default”, it is “giving a better starting point to people who never chose”.
• “Paid account”: the free pool is not entitled to Krea, so it keeps the FAL default. Free users do not get handed a model they cannot use.
• “Entitled to Krea”: the entitlement check and the write are the same rule (_krea_image_default), and first-run gateway default application uses that same rule, so there is no second copy of the logic to drift.

On the Krea plugin side, krea-2-medium-turbo is now an entry of this shape (plugins/image_gen/krea/__init__.py):

"krea-2-medium-turbo": { path: "medium-turbo", price: "$0.015 (text) / $0.0175 (style refs)", upscale: false }

In plain terms: about $0.015 per text-only generation, about $0.0175 with style references, and no implicit upscale pass.

A reference image copies a look; it does not edit a picture

This is the half of the change with the most direct effect on quality. The image_generate schema used to describe image_url as a source image to edit and reference images as guiding that edit. Read that wording and Krea 2 did the reasonable thing: a vision call over the picture, then a long style description written into the prompt.

Now a provider can declare, in its capabilities:

def capabilities(self) -> dict:
    return { ..., "source_image_role": "style" }

Once declared as style, the schema wording changes: the picture’s look is copied, not edited; prompt asks for the subject and the scene, and references supply only the look. Every other backend renders exactly the schema it rendered before — the switch is strictly per backend.

The practical difference is visible immediately. Give it a watercolour reference and you used to get a paragraph of “watercolour, wet-on-wet, paper grain …” injected into your prompt. Now the model simply paints in the look of the picture you supplied.

When it falls back to FAL — and when it must not

The fallback is not “Krea is unhappy, rerun everything”. It has a deliberately narrow admission rule, and the core requirement is that the request provably created no job:

Eligible:

• The connection was never established (a DNS failure or a refused connection) — no server ever accepted the request.
• The gateway answered 429, which it documents as “no job was created”.

Never eligible:

• A connection dropped after sending, a timeout, a 5xx, any other 4xx, unparseable JSON, and anything that happens after a job id exists — in those cases the job may exist and has already been authorized for billing, so rerunning would pay twice.
• Requests that carry source images never fall back, because FAL would route them to an edit endpoint with different semantics.

To tell “never connected” apart from “dropped after sending”, connection failures now report as unreachable (in plugins/image_gen/_common.py), separately from a drop after send.

After a fallback, the result says what happened

A rerun is never silent. The tool result carries:

Field	Meaning
provider / model	who actually ran it
fallback_from	which model (usually Krea’s) it came from
fallback_reason	why the rerun was triggered
note	a one-line explanation; if FAL failed as well, the note says the fallback failed too

Two details worth knowing:

• An upscale you asked Krea for stays on the rerun, where it means FAL’s Clarity Upscaler, and the note says so.
• On an install that has never used FAL, the first fallback installs Hermes’ optional FAL feature — with a prompt in a terminal and silently otherwise, exactly like any first FAL use.

Turning the fallback off

image_gen:
  krea:
    fallback_to_fal: false   # do not rerun a failed Krea submit on FAL

The key means “on by default, off only when explicitly set to false” (fallback_to_fal_enabled()). If predictable billing matters more to you than “get an image out anyway”, switching it off is a reasonable call.

Checking what you are actually running

# see the current pick for the image lane
hermes tools

# what the config stores for image generation
hermes config get image_gen

# generate once and read the provider / model fields in the result
hermes chat -q "generate an image of a mountain lake at dusk"

If hermes tools shows a model you picked yourself, this change does not touch it. If you see krea-2-medium-turbo (paid) or the FAL default (free pool), you are on the new default.

For backend selection and routing in the image lane, see the image and vision routing guide; for controlling vision context, see the vision budget guide.