Image baseline policy reference¶

Topics: generation, kudos, workers

Two separate authorities decide what a request may ask of the baselines it names, and neither is a table in this repository:

The served baseline catalog. Published on models.aihorde.net and read through model_reference.baseline_record(baseline). It states what exists for a model family: which ControlNet, layer-diffusion and QR-code weights have been published, whether the architecture has a remix mechanism, whether a flow-matching timestep shift is meaningful for it, and the kudos, batching, lease and resolution-floor policy the horde applies to it.
The bridge feature table. BRIDGE_BASELINE_FEATURES in horde/bridge_reference.py, keyed by bridge version. It states which bridge releases actually render a feature on a baseline.

horde/baseline_policy.py reads both and nothing else. To add a baseline, see add an image baseline.

What each authority decides¶

Feature	Catalog capability	Bridge feature	Rejection code
`flow_shift`	`flow_matching`	`flow_shift`	`FlowShiftInapplicable`
`hires_fix`	-	`hires_fix`	`HiResMismatch`
`transparent`	`transparent`	`transparent`	`InvalidTransparencyModel`
`workflow: qr_code`	`qr_code`	-	`ControlNetMismatch.`
`control_type` with no weights	`controlnet_types_unavailable`	-	`ControlNetUnsupported`
`control_type`	`controlnet`	`control_type`	`ControlNetMismatch`
`source_processing: remix`	`remix`	-	`InvalidRemix`

A feature that both columns cover needs both to allow it. The features are evaluated in the order above, so a request tripping two of them is refused for the first.

A request naming several models can be dispatched for any of them, so a feature is accepted only where every requested baseline renders it.

Which bridge releases render what¶

bridge_supports(feature, baseline, bridge_agent=None) is the only reader. It is cumulative by version in the same way get_bridge_capabilities is: a worker gets the union of every version at or below its own.

Bridge	Version	Feature	Baselines
AI Horde Worker reGen	1	`hires_fix`	SD1, SD2 768, SD2 512, SDXL
AI Horde Worker reGen	1	`control_type`	SD1, SD2 768, SD2 512
AI Horde Worker reGen	6	`hires_fix`	Stable Cascade
AI Horde Worker reGen	8	`transparent`	SD1, SDXL
AI Horde Worker reGen	17	`flow_shift`	Flux.1, Flux Schnell, Flux Dev, Qwen-Image
AI Horde Worker	13	`hires_fix`	SD1, SD2 768, SD2 512
AI Horde Worker	15	`control_type`	SD1, SD2 768, SD2 512

Accepting a request asks whether any known bridge kind at any version renders the combination, so a request is refused with 400 only where nothing in the fleet could ever run it. Dispatch asks the same question of the worker's own agent, so an older worker holding the model is passed over rather than sent a job it would render wrongly. The flux graph capability stays a flat capability checked at dispatch alone.

The horde policy on a baseline¶

Read with policy(baseline), which returns the record's horde_policy or the par default.

Field	Meaning
`kudos`	What one generation costs relative to a par baseline.
`kudos_qr_code`, `kudos_hires`	The factor where that workflow changes the shape of the render rather than only its settings.
`batching`	How much this baseline's cost inflates in the batch size calculation, which holds the batch count down for an architecture that wants most of a card.
`ttl`	How much longer than its sampler work implies a lease runs.
`resolution_floor`	The resolution every user reaches regardless of queue pressure. Zero claims no floor.

An uncatalogued baseline¶

A baseline the catalog publishes no record for, including one the installed horde_model_reference vocabulary does not carry, is given conservative capabilities and priced at par. A plain txt2img request remains accepted, while baseline-dependent workflows are refused until the catalog states that the required weights or mechanism exist and, where applicable, a bridge release states that it renders them.