Você tem uma assinatura paga, um dia pede uma ilustração ao Hermes e o resultado fica bom — mas você não encontra em lugar nenhum, nas configurações, qual modelo a desenhou. A razão é simples: você nunca abriu a pista de imagens em hermes tools, então a figura veio do padrão de primeira execução, e esse padrão costumava ser o FLUX 2 Klein 9B da FAL.

Havia uma segunda irritação menor ao lado disso. Você entregou uma imagem de referência e pediu que o modelo desenhasse algo naquele estilo. Em vez disso, ele rodou uma passada de visão sobre a figura e escreveu uma longa descrição de estilo dentro do prompt — porque o schema dizia a ele que você queria editar aquela imagem. O Krea 2 não edita nada; ele copia o visual.

Uma mudança mesclada nesta janela corrige as duas coisas.

O padrão é escrito sob uma condição bem estreita

A nova regra em uma frase: uma conta paga usa o Krea 2 Medium Turbo por padrão, mas só quando a seção de imagem nunca foi configurada, não guarda nenhum modelo e a conta de fato tem direito ao Krea.

Cada qualificador justifica o seu lugar:

• “Nunca configurada”: se você já escolheu um modelo em hermes tools, nada é sobrescrito. Essa é a propriedade mais importante aqui — isto não é “mudar um padrão”, é “dar um ponto de partida melhor a quem nunca escolheu”.
• “Conta paga”: o pool gratuito não tem direito ao Krea, então ele mantém o padrão da FAL. Usuários gratuitos não recebem um modelo que não podem usar.
• “Com direito ao Krea”: a checagem de entitlement e a escrita são a mesma regra (_krea_image_default), e a aplicação do padrão de gateway na primeira execução usa essa mesma regra, então não há uma segunda cópia da lógica para divergir.

Do lado do plugin Krea, krea-2-medium-turbo agora é uma entrada desta forma (plugins/image_gen/krea/__init__.py):

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

Em termos simples: cerca de $0.015 por geração só de texto, cerca de $0.0175 com referências de estilo, e nenhuma passada de upscale implícita.

Uma imagem de referência copia um visual; não edita uma foto

Esta é a metade da mudança com o efeito mais direto sobre a qualidade. O schema de image_generate descrevia image_url como uma imagem de origem a editar e as imagens de referência como guias dessa edição. Lendo esse texto, o Krea 2 fazia a coisa razoável: uma chamada de visão sobre a figura e depois uma longa descrição de estilo escrita dentro do prompt.

Agora um provider pode declarar, nas suas capabilities:

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

Uma vez declarado como style, o texto do schema muda: o visual da figura é copiado, não editado; o prompt pede o sujeito e a cena, e as referências fornecem apenas o visual. Todo outro backend renderiza exatamente o schema que renderizava antes — a troca é estritamente por backend.

A diferença prática é visível de imediato. Dê a ele uma referência em aquarela e você costumava receber um parágrafo de “aquarela, wet-on-wet, textura de papel …” injetado no seu prompt. Agora o modelo simplesmente pinta no visual da figura que você forneceu.

Quando cai para a FAL — e quando isso não pode acontecer

O fallback não é “o Krea não gostou, reexecuta tudo”. Ele tem uma regra de admissão deliberadamente estreita, e o requisito central é que a requisição comprovadamente não criou job:

Elegível:

• A conexão nunca foi estabelecida (uma falha de DNS ou uma conexão recusada) — nenhum servidor chegou a aceitar a requisição.
• O gateway respondeu 429, que ele documenta como “nenhum job foi criado”.

Nunca elegível:

• Uma conexão derrubada depois do envio, um timeout, um 5xx, qualquer outro 4xx, JSON não parseável e qualquer coisa que ocorra depois de existir um job id — nesses casos o job pode existir e já foi autorizado para cobrança, então reexecutar pagaria duas vezes.
• Requisições que carregam imagens de origem nunca caem para fallback, porque a FAL as rotearia para um endpoint de edição com semântica diferente.

Para distinguir “nunca conectou” de “caiu depois do envio”, falhas de conexão agora são reportadas como unreachable (em plugins/image_gen/_common.py), separadamente de uma queda após o envio.

Depois de um fallback, o resultado diz o que aconteceu

Uma reexecução nunca é silenciosa. O resultado da tool carrega:

Campo	Significado
provider / model	quem de fato rodou
fallback_from	de qual modelo (geralmente do Krea) veio
fallback_reason	por que a reexecução foi acionada
note	uma explicação de uma linha; se a FAL também falhou, a nota diz que o fallback falhou também

Dois detalhes que vale conhecer:

• Um upscale que você pediu ao Krea permanece na reexecução, onde significa o Clarity Upscaler da FAL, e a nota diz isso.
• Em uma instalação que nunca usou a FAL, o primeiro fallback instala o recurso opcional FAL do Hermes — com um prompt em um terminal e silenciosamente fora dele, exatamente como qualquer primeiro uso da FAL.

Desligando o fallback

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

A chave significa “ligado por padrão, desligado só quando definido explicitamente como false” (fallback_to_fal_enabled()). Se um billing previsível importa mais para você do que “conseguir uma imagem de qualquer jeito”, desligá-lo é uma decisão razoável.

Verificando o que você está realmente rodando

# veja a escolha atual para a pista de imagens
hermes tools

# o que a config guarda para geração de imagens
hermes config get image_gen

# gere uma vez e leia os campos provider / model no resultado
hermes chat -q "generate an image of a mountain lake at dusk"

Se o hermes tools mostra um modelo que você mesmo escolheu, esta mudança não o toca. Se você vê krea-2-medium-turbo (pago) ou o padrão da FAL (pool gratuito), você está no novo padrão.

Para seleção de backend e roteamento na pista de imagens, veja o guia de roteamento de imagem e visão; para controlar o contexto de visão, veja o guia de orçamento de visão.