Runware vs Leonardo: integration tax meets creative surface

Account for synchronous and asynchronous provider behavior

Runware REST can return synchronous image task results from one POST. Leonardo’s common v1 generation flow returns a generation ID and requires polling or a webhook before URLs are available. Those differences affect timeouts, worker concurrency, observability, and incident handling even when both ultimately return images.

The Leonardo adapter creates a private generation and polls with a bounded deadline. At higher volume, a webhook-backed job implementation is preferable. RenderRoute keeps this complexity out of the public client while preserving a provider generation ID in internal metadata.

Interpret the $0.0006 and $0.0045 measurements narrowly

At the operator’s 960×1472 portrait settings, Runware fast measured $0.0006 and Leonardo approximately $0.0045, a ratio of 7.5. This does not prove that every Leonardo workload costs 7.5 times more. Credits, model settings, pricing revisions, and rejected outputs can change the effective result.

A fair comparison includes engineering and operational cost. Polling, webhook verification, support diagnostics, and model migration all have a cost even when inference prices are close. The router centralizes that work once.

• Compare billed cost, not marketing units alone
• Include time to completion, not only model runtime
• Review private/public output defaults
• Test moderation behavior with a policy set
• Track acceptance and editing effort

Use Leonardo only inside the policy lane that was reviewed

The standard router can use Leonardo after retryable primary failures. The verified 18+ lane excludes it by default. This is intentional: provider eligibility is a policy and contract decision, not something inferred from whether an endpoint technically accepts a prompt.

When provider policies or product agreements change, update the capability review and configuration. Do not enable a provider for a high-risk lane merely because another blog claims it supports a category.

standard fast: Runware → Together → Leonardo → local
verified 18+: Runware → local

No provider crosses lanes unless it is explicitly reviewed and configured.

Keep Leonardo available when its output or platform fit adds value

A fallback can be justified by availability alone, but provider choice can also depend on a particular model, creative control, organization workflow, or future image-edit capability. Evaluate the features you will actually expose, not the provider’s entire catalog.

Document the reason for each route in an architecture decision record. Revisit it after benchmark runs and provider changes. The best router is opinionated today and easy to revise tomorrow.