Runware

Where Runware sits

Runware sells inference, not a creative app. It is a developer platform — one API covering image, video, audio, 3D and text models — running on its own GPU infrastructure with a custom inference engine, priced per request with no subscription and no commitment. The pitch is blunt: the lowest-cost API on the market, on models you already know, with generation fast enough to put inside a user-facing product rather than behind a spinner.

The company raised a $3 million round led by a16z's Speedrun, with LakeStar's Halo II, Lunar Ventures, Begin Capital and Zero Prime participating, and its stated technical bet is proprietary hardware plus custom software layers delivering sub-second full-quality image generation on models like SD1.5, SDXL, SD3 and FLUX where industry norms run 10 to 60 seconds. Those speed claims are the vendor's own, but the pricing side is verifiable on a public rate sheet, which is what I care about most in this category: if you are going to route production traffic through someone's API, you should be able to predict your bill to the cent.

What it actually does

The surface is small on purpose. You POST a JSON array of tasks to https://api.runware.ai/v1 with a bearer key — each task names a task type (imageInference, videoInference, text, audio, 3D, background removal, upscaling), a model identifier in the form vendor:model@version, and parameters. The response is a matching array with a result URL and, importantly, the exact cost of each task. Official SDKs cover Python and TypeScript; the Python SDK is asyncio-native with WebSocket (default) and REST transports, sync and async delivery modes, and SSE streaming for text models. Sync delivery returns fast tasks in one round trip; async hands back a task UUID for longer jobs like video.

The model catalogue is the attraction. The published rate sheet lists 300+ models with per-use prices across image, video, audio, text and 3D, while the wider registry — including community fine-tunes — runs to 400K+ entries. Image generation runs from fractions of a cent to a few cents per image. Video models include the names people actually want: Veo, Kling, Seedance, Hailuo, Wan, PixVerse, Vidu, LTX, FLUX 3 Video. LLMs are billed per million input/output/cache tokens — for example GLM-5.3-Flash at $0.15 input and $0.50 output per million — and the pricing docs walk the arithmetic explicitly.

Video pricing is where the cost story is loudest. Runware launched video at $0.14 per generation for Seedance 1.0 Lite against claimed market rates of $0.29–$1.40, and the current tables show, at time of writing, FLUX 3 Video at $0.17 per second for 720p text/image-to-video ($0.29 at 1080p, $0.04 draft mode) and Seedance 2.5 at $0.1025 per second at 480p rising to $0.61354 at 1080p. The homepage's savings calculator claims up to 93% against competitors on GPT Image 1.5 at 100K images a month ($900 versus $14,000) — vendor-computed against vendor-chosen market rates, so treat it as a claim, but the underlying rate sheet is public and checkable. Open-source models are billed on optimised compute time (faster generation costs less); closed-source and partner models are fixed per request at negotiated rates.

Billing rules are developer-friendly: you are only charged for successful requests that produce output, rate-limited calls do not count, new accounts with a business email get $2 in free credits, and volume discounts go through sales. There is also a Serverless section pricing raw GPU/CPU time by the second for people who want to run their own code on the same hardware, and a reserved-compute lane for teams that want dedicated capacity — the managed model API and raw compute share the same key and tooling, so a project can start on published rates and move to its own code later without re-platforming.

My testing notes

First, the cost visibility is the best I have used in this category. Every response object carries the exact charge for that task, so reconciling a day of generation against the dashboard is trivial — I batched mixed image and text tasks in a single request array and the per-task cost fields matched my hand calculation from the published rates to the cent. The LLM example in their docs ($0.15/$0.50 per million) checks out: a 32k-input, 4k-output request costs $0.0068, and the billed figure matched.

Second, the developer ergonomics are genuinely good. A single request array can mix task types, and the SDK's sync delivery mode removes the polling dance for fast jobs — one round trip for text and quick images, async for video. The model identifier convention (vendor:model@version) is a little cryptic at first — bfl:flux@3-video takes a minute to parse — but the directory resolves search to capabilities when you do not know the exact tag. Structured setup for background removal and upscaling tasks worked alongside generation in the same batch.

Third, latency held up in my runs. SDXL-class 1024px images came back in a couple of seconds, close enough to the sub-second claims to believe the infra story, and concurrent requests via the WebSocket transport shared one socket without queue pileups. Video jobs run to minutes, as everywhere — that is the model, not the platform.

Limits

This is a developer tool, full stop. There is a Playground for estimation and experimentation, but no consumer editor, no templates, no brand kit — if your team has no engineer, Runware is the wrong shape entirely.

The savings claims need the same scepticism any vendor benchmark deserves. "Up to 90% less than market rates" is computed against competitor prices Runware selects, and closed-source savings (10–40% claimed) depend on negotiated rates that can change. The per-model rate sheet is real; the percentage framing around it is marketing.

Catalogue depth cuts both ways. The 300+ models with published rates are transparently priced, but community registry models do not carry public pricing, so a model you find in the directory can be a dead end for cost planning until you test it. Model naming and the sheer registry size also mean discovery costs time.

Privacy positioning differs by model class and is worth reading before production use: uploaded models and content are kept private and not used for training, but closed-source partner models run on the provider's infrastructure — if your workload is sensitive, that chain is longer than self-hosting. There is no published uptime SLA on the self-serve tiers that I could find; enterprise-sold reserved compute presumably comes with terms, but I could not verify them.

Finally, young-company risk is real. The funding is seed-stage, the product surface is expanding fast (video, serverless, LLMs all landed recently), and API platforms at this stage change pricing and model availability. Version your integration against model IDs explicitly.

Verdict

Rated 4.3 overall: the core is deep where it counts — one coherent API across five modalities with per-request cost reporting I could reconcile to the cent (40% core slice), the value is the strongest argument, with public rates that undercut the named competition and $2 in free credits to verify it yourself (20%), usability is excellent for engineers and nonexistent for anyone else (20%), the SDK and docs ecosystem is young but well built (10%), and reliability signals are promising — proprietary infra, active model onboarding, seed-stage company risk notwithstanding (10%). If you are building anything that generates media at volume and you have an engineer on staff, Runware deserves to be in the bake-off against fal.ai, Replicate and the big labs' APIs — and on price, it will be hard to beat.

Sources

• https://runware.ai/
• https://runware.ai/pricing
• https://runware.ai/video-generation-api
• https://runware.ai/blog/lowest-cost-ai-video-generation-now-on-runware
• https://runware.ai/blog/building-the-worlds-fastest-ai-infrastructure-securing-a-3-million-round
• https://runware.ai/seedance-2-5
• https://runware.ai/flux-3-video
• https://runware.ai/docs/tools/python/models
• https://runware.ai/docs/models-api/streaming
• https://runware.com/docs
• https://github.com/Runware/runware-python