AI livestream architecture builder

For a MiniMax H3 Max AI livestream built from individual clips, the planner above sizes generation lanes and a buffer from your measured timings. It also applies to Turbo when you replace the timing and price inputs with your own measurements.

The clip-buffer planner does not simulate Director's internal scheduling. Use the Director guide and session calculator for that route. A persistent world also needs application state: preserve inventory, character facts and audience decisions independently of video generation.

Write down a runtime, a fictional setting, a maximum number of new clips and a spending ceiling. “One hour, one channel, 480p, fifteen-second clips” is a much more testable brief than “an infinite stream.” At the published standard H3 Max rate, an hour of fresh 480p video is $180 before other costs.

If that is too much for a first test, make a shorter show. Ten fresh minutes at the same rate are $30. A longer broadcast can combine a small amount of fresh output with reviewed replays, provided viewers can understand what they are watching.

Decide who can submit a prompt. An operator-only queue is simpler to test than anonymous public input. You can add participation after generation, moderation and recovery behave predictably.

A workable architecture keeps content selection separate from both generation and playback. A failure in any one stage should not make every stage retry blindly.

You can implement these with different platforms. The important property is durable ownership of each job: after a restart, the system should know whether a provider request already exists. Do not attach a paid request directly to every chat message.

Pieter Levels has not published a complete official repository for the production Infinite Slop service in the sources reviewed here. Two independent projects now make the broader build pattern concrete: Reactor's infinite-livestream and SlopTV. They are useful reference architectures, not the original backend and not evidence that every similarly named repository is affiliated with Infinite Slop.

These figures are not a controlled model comparison. The projects use different checkpoints, resolutions, clip lengths, kernels, hardware and playout strategies. Reactor's four-B200 profile is approximately real-time generation for its longest supported clip. SlopTV keeps the broadcast continuous even though local generation is slower than playback by alternating two workers and replaying clips from its growing pool.

The reusable architecture

Both projects support the same high-level separation, even though their internal contracts differ:

YouTube or Twitch chat → admission and moderation → LLM scene planning → application queue → video generation → output review or ready pool → WebRTC or RTMP delivery

The queue belongs to the application, not to chat and not to the video model. It needs a stable job ID, bounded capacity and a decision about what happens when generation is late. WebRTC is useful between a live model session and a controller; RTMP is useful for sending one paced broadcast to services such as YouTube or Twitch. Neither protocol decides which prompt should air.

Public code is not one interchangeable license

Reactor's repository states that its application code uses Apache License 2.0, while the FastH3 weights use the separate MiniMax H3 Community License. SlopTV publishes its implementation and workflow for inspection, but the repository did not present a recognized reuse license during this review. Read the current code and model licenses before copying, modifying or operating either stack.

If your goal is self-hosting, start from the hardware you can measure rather than from the word “local.” A two-5090 pool can demonstrate the full interaction with lower fresh-output frequency. A B200 deployment can approach or exceed real-time generation, but adds a very different infrastructure and cost profile. In both cases, a reserve of approved clips is what turns variable generation into a watchable channel.

A budget check only after completion is too late if several requests run at once. Before submitting a job, reserve its maximum expected charge from the remaining allowance in a transaction or another atomic operation. If the reservation fails, leave the job unsubmitted.

Record reservations separately from settled cost. A request can be in flight while its actual bill is unresolved. If the response is ambiguous, check the known request ID rather than blindly submitting another copy. Reconcile completed work against the provider's billing behavior and retain enough headroom for uncertainty.

Useful limits include total spend per show, new seconds per day, maximum concurrent jobs and a per-user submission rate. A global stop switch should prevent new provider requests even when old messages are still waiting in the queue.

fal documents a queue-based request lifecycle, including submission, status lookup and result retrieval. Your application's queue and the provider's queue are different systems: the first decides which ideas deserve work; the second tracks work you have already sent.

Save the returned provider request ID immediately. Model your own states explicitly, for example pending → reserved → submitted → reviewing → ready, with separate rejected, failed and uncertain outcomes. A unique internal job ID helps prevent duplicated settlement or playback.

If you use callbacks, validate them using the provider's documented security mechanism and make processing idempotent. If you poll instead, use a bounded interval and stop polling terminal jobs. Neither approach should print private keys or raw user information into public logs.

Input checks keep obvious abuse away from an expensive model call. Output checks stop a surprising or unsuitable generation from reaching viewers. One is not a substitute for the other.

For a first public show, choose a narrow theme and retain human control over what airs. Do not treat a keyword filter as a complete safety system. Review likenesses, sexual or graphic material, harassment, dangerous instructions and misleading depictions of current events. Make the synthetic nature of the show apparent.

A rejected clip may already have incurred generation cost. Keep those billable discarded outputs in your budget model. A late or rejected result should not trigger an immediate unlimited sequence of retries; use a retry cap and a reviewed fallback.

Generate and approve several clips before beginning playback. The viewer should consume a stable manifest of ready content, not discover unfinished provider jobs. Store enough information to reconstruct the sequence after a page reload.

Measure end-to-end completion time rather than copying a model benchmark into your capacity plan. A buffer protects against short interruptions, but it cannot permanently compensate for a generator that produces less video than the channel consumes.

Test a deliberate interruption: stop submitting new jobs, observe how long the reserve lasts, and confirm that the player transitions to a clear pause or permitted fallback. Also test malformed files, missing URLs and a client reconnecting halfway through the show.

For independent comedy sketches, a text-to-video request per scene may be enough. For an ongoing character, you may want an image anchor, a compact state summary and a list of attributes that should remain unchanged.

There is a dependency tradeoff. If the next scene must use the exact last frame of the current generation, it cannot start until that frame exists. Generating several unrelated clips in parallel improves throughput but does not solve sequential story continuity.

The H3 Max image-to-video documentation is a place to inspect current image inputs. Keep your implementation claims separate from the official Infinite Slop system, whose full backend is not public in the sources we reviewed.

Serve viewers through an appropriate content delivery layer instead of asking the model for a new copy for each visitor. Keep long-lived provider credentials out of video URLs and out of the browser.

Plan file retention and usage rights. A provider result URL may not be a permanent archive contract. If you store outputs yourself, establish that storage and redistribution are permitted and include bandwidth and storage in your operating budget.

Make muted autoplay, user-initiated sound and mobile reconnection part of your player test. Avoid browser workarounds that obscure permission choices. It is better to show an honest playback state than to claim “Live” while the client has no playable video.

A video model supplies media; a broadcast pipeline supplies a program to a destination. For clip-based shows, queue approved files, normalize their audio and encoding, and feed them to your chosen playout or RTMP tool. Inspect the open implementations linked above for examples of that separation.

For Director, start with its WebRTC receive session. An OBS browser capture or server-side bridge is an integration option to test, not a promise that the API exports an RTMP URL. Check destination ingest settings, authorization and reconnect behavior in a private test before a public broadcast.

For either route, generate one shared program for the audience, give the operator a stop control, and define what appears when new media is unavailable. Keep stream keys on the delivery server. Viewer count, generation lanes and independent channels are different quantities; only independently generated programs multiply the generation budget.

• Restart the generator during an in-flight request and confirm it does not submit the same job twice.
• Reach the spending ceiling and confirm new submissions stop before another paid request.
• Reject an output and confirm it never reaches the public manifest.
• Simulate a slow provider response and an unavailable video file.
• Reconnect a viewer and check the shared sequence and sound controls.
• Confirm the public bundle contains no API key, private callback secret or admin credential.
• Check reporting, takedown and emergency-stop paths.
• Calculate the observed cost per accepted broadcast minute, including billable waste.

Use the results to decide the next experiment. A more expensive model, a longer schedule or a larger audience should be a conscious change to a measured system, not an accidental effect of opening a chat box.