Running HappyHorse via API and open source
The web editors are where you learn. But at some point you may want HappyHorse inside a pipeline — a batch job, a product feature, a render farm — and that means the API or the open-source weights. This guide is an honest map of both paths, including the costs nobody puts on the landing page.
Your three options, ranked by effort
| Path | Effort | Best for |
|---|---|---|
| Web editors (HappyHorse online, WeShop AI) | None | Learning, one-off content, small campaigns |
| Hosted API (fal.ai and other partners) | An afternoon | Automation, apps, batch generation |
| Self-hosting the open 1.0 weights | A weekend, then ongoing | Research, fine-tuning, full control |
The hosted API path
Partner APIs expose HappyHorse as a request/response endpoint: send a prompt (and optionally a first-frame image), poll or webhook for the result, download an MP4 with audio. The things worth knowing before you wire it up:
- Model versions differ by host. Partners typically serve HappyHorse 1.0 — the open release. The 1.1 improvements (sharpest lip sync, full seven-language support) may lag on third-party hosts. If dialogue is your product, verify the served version before committing.
- Everything in these guides transfers. The five-part prompt structure, the image-anchor patterns, the audio direction — a prompt is a prompt whether it's typed or POSTed. Build your prompt templates in a web editor first, then parameterize.
- Design for asynchrony. Generation takes tens of seconds. Queue jobs and notify on completion; don't hold HTTP connections open across a render.
- Budget per finished asset, not per call. The 60/30/10 exploration split applies to automated pipelines too — assume several generations per shipped clip when you price a feature.
The open-source path
HappyHorse 1.0's weights being public is genuinely significant — it's why a whole ecosystem of HappyHorse tools exists, and it's insurance that the model you build on can't be repriced out from under you. That said, self-hosting a video-with-audio diffusion model is a real infrastructure commitment:
- Hardware. The ~38-second generation figure comes from H100-class data-center GPUs. On consumer cards, renders that complete at all take many minutes, and VRAM is the binding constraint. Renting GPU time by the hour is the sane middle path — at which point compare your effective cost against the hosted API before assuming self-hosting is cheaper.
- The gap between weights and product. The web editors wrap the raw model in prompt preprocessing, safety filtering, retry logic, and encoding. Raw weights give you none of that; budget engineering time for the wrapper, not just the deployment.
- What you get in exchange. Fine-tuning on your own footage, LoRA-style style adapters, no per-generation fees at scale, no content-policy surprises, and reproducibility pinned to a checksum. For research groups and studios with steady volume, this trade is often worth it. For everyone else, it usually isn't — yet.
An honest decision rule
- Making content? Stay in the web editors.
- Making a product or pipeline? Hosted API until your GPU bill rivals an engineer's salary.
- Making the model itself better — fine-tunes, adapters, research? That's what the open weights are for.
Wherever you land, the craft is portable. The model doesn't care whether the prompt arrived through a text box or a JSON payload — it cares whether you directed or described.