Add a realtime Flux Klein example over Trickle (remote signer + local SDK)

[rickstaa]

Is your feature request related to a problem?

Over the last months we've been improving the gateway experience by disaggregating the go-livepeer gateway, which is heavy and forces operators to run media processing and payment signing in one node (see transformation SPE retrospective).

• We shipped a standalone remote signer that holds the Ethereum key and signs PM tickets out of the media path, plus local SDKs (e.g. livepeer-python-gateway) so a gateway becomes an embeddable library — point it at a signer URL + key, media stays local. The gateway ↔ orchestrator payment flow is unchanged (PM, settling in ETH).
• Building on that, Josh built a new live runner that allows full container passthrough over HTTPS, SSE, WebSockets, and Trickle. Builders ship a standard container, orchestrators deploy it with a single docker pull + docker run, and it becomes discoverable on the network. The goal: a builder takes the same container they already run on their existing cloud infra and runs it on Livepeer instead — making the network a direct, decentralized replacement for that infra, with payments handled by the protocol. Relevant branches: go-livepeer#3938 (Live Runner) and livepeer-python-gateway#20 (Live Runner + Scope support).

We created livepeer/live-runner-example-apps to showcase one example per communication schema (some are not yet merged and will ship later this week).

To get people trying this out and to gather first-hand feedback, we'd like a builder to add realtime Flux Klein (fal-ai/flux-2/klein/realtime) as another example using the Trickle protocol — and to report on the developer experience and any problems encountered.

Describe the solution you'd like

A standalone flux-klein/ example folder that runs realtime FLUX.2 [klein] over Trickle on the live runner, both offchain (free) and on-chain (paid, via the remote signer). The streamdiffusion example showcases exactly this pattern (GPU, realtime trickle, static registration, self-hosted weights, offchain + on-chain) — model the new example on it. Note: streamdiffusion is not yet merged; it ships later this week, so build against it once it lands. At minimum:

• runner.py — the app serving Klein img2img over trickle via the SDK.
• client.py — publishes video, reads the result, re-prompts live (--signer for on-chain).
• Dockerfile + docker-compose.yml (offchain) + docker-compose.onchain.yml (paid) — bring up the orchestrator + app with one command each.
• README.md — how to run it offchain and on-chain.

Use the open-weights FLUX.2-klein-4B (Apache-2.0), self-hosted. hthillman/scope-flux-klein is an open-source realtime Klein implementation to use as the reference for the model wiring and weights.

Also include written feedback on the developer experience and any issues hit along the way.

Alternatives

None.

Additional context

• Model (realtime Klein, fal hosted reference): https://fal.ai/models/fal-ai/flux-2/klein/realtime
• Open-weights model to self-host — FLUX.2-klein-4B (Apache-2.0): https://huggingface.co/black-forest-labs/FLUX.2-klein-4B
• Open-source realtime Klein reference (Daydream Scope plugin): https://github.com/hthillman/scope-flux-klein
• Example apps repo: https://github.com/livepeer/live-runner-example-apps
• Closest template — the streamdiffusion example (realtime trickle, static, offchain + on-chain); not yet merged, ships later this week.
• go-livepeer Live Runner branch: Live Runner go-livepeer#3938
• Local SDK branch: Live Runner + Scope support livepeer-python-gateway#20

Retroactive Grant Notice

Important

Compensation cap: $500

Before picking this up, read the Retroactive Grants post in full. Key points:

• Not pay-for-delivery. Compensation is based on demonstrated adoption and community impact — not on shipping. Real, named community contributors must use your work and publicly attest to it. Building in isolation, then asking for a grant, does not qualify.
• Talk to the community first. A public discussion (Discord or Forum) about the problem must precede the work, and evidence of it must be part of your application. No prior discussion, no tempcheck, no public signal = won't pass review.

Required steps before investing more time:

1. Read the original Retroactive Grants post in full.
2. Start a public discussion (Discord or Forum). Get input. Confirm direction.
3. Secure at least one community proof point — a Discord thread with positive signal, a Review Team acknowledgement, or evidence of active adoption.
4. Identify, by name, who has this problem.
5. Build, ship, and confirm it's actually being used.
6. Apply with at least one named community contributor willing to publicly attest to your work's impact on the forum post.

Skipping steps 2, 3, 4, or 6 will halt the application. Reach out to jj.a.ss.o.nn_everestnode on Discord before you start building.

[rickstaa]

Important

The streamdifussion example has not yet shipped since I'm working on an SDK update. Plan to ship this this week so people have a full example to work from.