Real-Time AI Video Changes What You Can Build

Three days after fal shipped a video model that renders faster than you can watch it, an indie maker had a product running on it. The day after that, 37,000 people had watched it. That gap, between a capability landing and a product existing, is now measured in days. It is the most useful thing a founder can take from the arrival of real-time AI video.

fal is the generative media inference platform underneath this. On August 26, 2026 it released H3 Max, a post-trained version of MiniMax's open-weights H3 video model, with numbers that invite disbelief: a 768p five-second clip in 2.78 seconds against 53.20 seconds for the model it was built from. fal separately claims roughly 35 times the throughput of the official MiniMax H3 endpoint, which is a throughput comparison rather than that wall-clock ratio.

fal co-founder Gorkem Yurtseven and head of engineering Batuhan Taskaya walked through how that happened with Jennifer Li, a general partner at a16z, on the firm's podcast. Most of the conversation is kernels and diffusion steps. The parts worth stealing are about demand, timing, and what a customer is actually buying.

What real-time AI video actually means

Real-time AI video is not a quality tier. It is a threshold: the model produces video at least as fast as a person watches it, so a generation stops being a render you wait for and becomes a stream you can interrupt.

Everything about the product changes on the far side of that line. Below it you build a queue, a progress bar, and an email when the job is done. Above it you build a session. The user is present while the thing is being made, which means they can steer it, and steering is a different product with different retention than submitting.

The numbers that crossed the line are specific. fal's published table puts a five-second 768p clip at 2.46 seconds on H3 Max and 1.54 seconds on the faster H3 Max Turbo variant. Its prose cites 2.78 seconds for that same H3 Max clip, so read the headline as roughly two and a half to three seconds rather than a precise constant. The Turbo figure is about what Taskaya and Yurtseven gave on the podcast, at about half the cost and with a small but noticeable quality loss. Independent boards backed the quality side at launch, and the shelf life of that is worth seeing. When fal published in August 2026 it cited Design Arena scoring H3 Max at an Elo of 1,341 and Artificial Analysis ranking it first with audio at an Elo of 1,201 and $3.60 per minute. Checked again in October 2026, Design Arena has it second at 1,324, a point behind Pruna's P-Video-2-Pro, and Artificial Analysis has it fifth at 1,125 and $5.76 per minute, behind the base MiniMax H3 it was post-trained from. Two months moved it from first to fifth on one board. fal's own pages still carry the August ranking, which is the normal half-life of a benchmark claim in this category and a good reason to date every one you repeat.

The founder-relevant point is not that video got fast. It is that a capability threshold arrived in a single step, after two years in which the industry optimized a different axis. As one of them put it, "today these models are so cheap and so fast that I don't think people need any faster," and the next sentence is the one to write down: "let's fix the speed and let's try push for quality and controllability of these models."

Token market fit is the demand test worth copying

Before the engineering, fal has a demand test, and it is the cleanest thing in the interview.

They call it token market fit, and generative media has it alongside coding agents. The test is whether "can a single person productively spend a lot of tokens," and they put a number on what counts: "the amount is like 10k a month something like that." Not a company. One person, doing this as their daily job, sitting in front of a computer all day, spending thousands of dollars.

That is a sharper qualifier than most market sizing a founder will run, because it is a floor on willingness to pay that you can check with five customer conversations instead of a spreadsheet. If one motivated user cannot productively burn through five figures of inference a month in your category, your revenue per user is capped no matter how good the model gets, and you are selling a feature rather than a workflow. If they can, the category will absorb every efficiency gain the labs ship, because the person on the other end has more work than budget. That is the same dynamic behind tokenmaxxing, seen from the supply side instead of the startup side.

Worth being precise about what the test does not tell you. Token market fit measures appetite, not margin. A category where one user can spend 10k a month is a category where your gross margin is a function of somebody else's GPU price, which is why the rest of the fal story is about efficiency rather than growth.

The constraint was compute, not interest

Here is the part that gets skipped in coverage of generative media: demand has not been the problem for a while.

They date the squeeze to around April, when fal and the wider industry became compute constrained in 2026, and the sentence that follows is the whole business condition in nine words: "we are growing as much as we are adding compute." Not as fast as they can sell. Not as fast as they can hire. As fast as chips arrive. Every efficiency they ship is therefore growth they can book without waiting on an allocation, which is why an order-of-magnitude speedup is a revenue event and not an engineering vanity metric.

You can see the same constraint show up at the application layer, in miniature. When Pieter Levels built Infinite Slop on H3 Max, an infinite interactive stream where viewers type the next scene, his own write-up names the cap plainly: only four videos a minute can be generated, so when the stream gets busy not everyone who types gets their scene made. People suggested he let viewers pay to bid for a slot. He declined, because it would make the thing less fun. That is a founder choosing product character over a rationing mechanism, and it is a real decision you will face the first time your AI product is popular.

If you are building anything inference-heavy, the practical reading is that your unit economics and your growth ceiling are the same variable. The discipline for managing it is in AI inference cost, and the strategic version is that efficiency work compounds into capacity you did not have to buy.

Where an order of magnitude actually comes from

The speedup was not one trick. It was four, stacked, and the structure is worth understanding because it is the shape of a defensible technical advantage rather than a lucky benchmark.

Post-training, with quality banked first. Diffusion models buy speed by cutting sampling steps, roughly 50 down to 20, and lose quality on the way down. fal inverted the order: run post-training and reinforcement learning to push the model's quality above the original first, keep those slower high-quality checkpoints, then apply the step reduction on top, so the end result lands at the same or better quality while being far faster. fal's own release describes introducing substantial new data in post-training with a focus on prompt adherence and visual quality, and evaluating checkpoints head to head on quality, prompt understanding, and aesthetics separately rather than against one aggregate score, specifically so they could see where a checkpoint improved and catch regressions a single number would hide. That evaluation discipline is the same one in LLM post-training, and it is the unglamorous reason this worked.

Kernels and systems work. Pure systems optimization, which fal has been doing for three to four years, can get you a model that is roughly "2x 3x faster while producing the same quality," because the architecture is unchanged and you are only extracting more from the chip. They describe lifting hardware utilization from the 30 to 40 percent that is standard in many inference workloads to 70 to 80 percent, which is close to the practical ceiling. That is the roofline, and systems work alone cannot pass it. Combining model co-design with the systems stack is what "enables us to go beyond that roof line by an order of magnitude."

Every stage of the pipeline, not just the model. This is the most transferable observation in the interview. A text-to-video call is a pipeline: a large language model expands the prompt into the format the video model was trained on, the video model generates in latent space, a decoder turns latents back into pixels, and depending on the job an upscaler runs after. Their verdict on that chain: "every single component by default is unoptimized." Each stage has a different optimization profile too. Prompt expansion is single-shot with no cache reuse and low batch sizes, which is nothing like an agent's decoding workload. Teams that only tune the model leave most of the latency on the floor.

Hardware, which helps less than people assume. Moving from Hopper to Blackwell generation chips gives roughly 2 to 3 times improvement on its own, but they are blunt that cost scales with it, so it mostly buys wall-clock time rather than efficiency. It matters when you need to go meaningfully beyond real time and not much otherwise. Most video models today, including this one, serve from a single eight-GPU node, because scaling past that loses more to communication overhead than it gains. The broader argument for designing across that boundary is in hardware software co-design.

Build the factory, not the model

The strategic line in the whole conversation is about where the work was spent.

They had already built post-training pipelines on open image models, one on Ideogram and one on Flux, before video. So when MiniMax released an open-weights model that was genuinely current generation, the capability to exploit it was sitting there. Their framing of how they spend time: "we essentially spend most of the time building it as an infrastructure than just like oneoff training runs." The infrastructure now takes H3 Max and adds any capability, and the same machinery applies to the next model, open weights or closed.

That is the difference between a result and an asset. A one-off training run produces a model that is obsolete in four months. A post-training and serving pipeline produces every model after it, which is the only version of this work that survives the next release. Founders building on top of models should read that as a question about their own stack: when the model you depend on is replaced next quarter, does your advantage transfer, or does it have to be rebuilt?

Open weights are what made the asset usable. They note that fal runs inference for other model labs but never had the right to add capabilities on top, and that MiniMax H3 was the first truly next-generation video model available open source. They are now building LoRA fine-tunes for lip sync, camera angles, and styles on top of it, which is possible at all because "open source adds a whole ecosystem around the model." If you are weighing a build on open versus closed weights, the right question is not benchmark parity, it is whether you are allowed to modify what you are serving. The commercial patterns around that choice are in the open source business model.

What happened when the capability landed inside a ready company

The launch sequence is a small case study in organizational readiness, and it was not planned.

fal ran its own evaluations first, spending what they describe as "a ton of money doing evals on our own," possibly tens of thousands of dollars, and the internal results were good enough that they held the release for three to four days to get external validation before claiming anything, because "the results were a little too good to be true." That is a credibility decision most teams get wrong in the other direction.

Then the model shipped, and within a day people had it running as a real-time stream on Twitch. Internally, in Yurtseven's and Taskaya's telling, "the creativity just explodes and everyone is just working on a new little app," they think they "broke a record on Slack that day," and with a distributed team the work handed off around the clock for three to four days. The outcome: "we had three parallel efforts going on that were all independently going viral on Twitter," and all of them turned into shipped products and experiences within days.

Five or six little projects started inside the company. The three that went viral were an engineer streaming continuous generations from his laptop to Twitch with prompt tricks to keep a story coherent, a separate team's continuous-video version of the model, and a web experience built around it. Outside, Levels shipped Infinite Slop on August 29 and reported 37,000 viewers the following day, crediting the idea to fal engineer Rehan Shei, whose stream came first, and to Marc-Antoine Fon. fal sponsored the compute.

The lesson is not about virality. It is that none of this was on a roadmap, and all of it reached customers in under a week because the company had the inference infrastructure, the post-training stack, and the internal permission to drop everything already in place. Capability jumps in this field are not smooth. Li described the pattern precisely during the interview: unlike language models' steady compounding, generative media has months of quiet while things bubble, then everything bursts at once. You cannot schedule the burst. You can decide in advance whether your team is able to convert one in four days or four months.

Continuity is the harder half

Fast clips are not yet a stream. The interesting engineering is memory.

The continuous version, released as H3 Max Director, generates one unbroken stream and holds state. The architecture, as they describe it: the model attends to roughly the last two minutes of raw, heavily compressed video it generated, and above that mark it carries a gradually evolving summary, something like a system prompt that tracks the overall structure of the world out to 60 minutes. If a scene is 15 to 30 seconds, it remembers the last four to eight scenes in detail and the shape of everything before that. Attending to two minutes of video is extremely compute intensive and scales badly, which is why the clever part is the compression rather than the context length.

Why it matters commercially: without memory you get what the independent clips did, where each new clip is seeded with the last frame of the previous one and remembers nothing else. With it, you can leave a room and come back and the room is the same room. That is the difference between a demo and a format.

The product surface reflects the shift. fal's Director page describes a session as a WebRTC peer connection rather than a queued request, with video and audio arriving as live tracks and directions riding back on a data channel, a first configure message carrying a world prompt of up to 50,000 characters, and sessions billed at $0.08 per second of video generated with a 60-second minimum. Price that out before you design: a minute of continuously directed video is about $4.80, and an hour is about $288.

On the demand side, Yurtseven and Taskaya argue this is the shape of a consumer opening, that the technology is now good and cheap enough that "a truly novel social AI experience can be built on top of it." They also report that within about three weeks H3 Max was the most popular video model on their platform by more than double, which is their own usage data rather than an independent measurement, and the kind of claim to treat as directional.

Hollywood wants point solutions, not magic

The most commercially instructive section is about what professional buyers actually ask for.

Yurtseven and Taskaya say Hollywood went from essentially no usage a year ago to fal's fastest growing segment, and that what studios want is narrow: extend this video slightly, change the camera move, change the lighting. In their words, "small point solutions rather than generating everything from scratch." Then the diagnosis that should be read twice by anyone building on frontier models: "what Hollywood needs and what the creators actually need and what the research labs are working on, there's a little bit of a disconnect there."

That disconnect is the business. Research labs optimize generality and benchmark position. A visual effects artist needs the shot to match the storyboard exactly. The gap between those two is filled by small, specific, unglamorous post-training projects, and fal's claim is that they can do them because they talk to the studios and have the infrastructure to turn a conversation into a model capability.

The workflow they describe makes the point concrete. Artists render a low-resolution version of a scene in Blender, non-AI technology doing exactly what the director intended, then pass that render as a reference to the video model, and "you basically get close to 100% controllability." The AI is the renderer, not the author. That is a very different product than a prompt box, and it is the one professionals pay for.

Control is now the roadmap: references, then per-character voices, then camera paths supplied as structured JSON specifying where the camera sits at each timestamp, then lighting direction, then lip sync driven by supplied audio, then motion transfer. Their honest read on current state is the useful metric: basic prompting gets those controls to 80 to 90 percent reliability, and "what we are targeting is like 99.9% reliability in the outputs." Their summary of the market gap, "the biggest gap is just how controllable these models are," is a clear statement of where an application-layer company should aim.

One claim here needs checking rather than repeating. They said Amazon MGM Studios' production tool is mostly backed by fal infrastructure behind the scenes. Amazon MGM Studios and AWS describe Project Nara as their own platform, built on AWS around a model-agnostic architecture that routes each task to the best model. Their joint announcement does name fal, but only in passing, in an AWS executive's line about partnerships with generative AI providers like Luma and fal. So the narrow claim stands up, that fal is in the picture, while the specific one, that fal is mostly what the tool runs on, is fal's account of its own role rather than something the customer has confirmed. Which is the lesson for anyone selling infrastructure: your name appears in your customer's announcement as a clause, if at all, and most of your best case studies are things you are not allowed to say.

The other half of the problem is legal

The section a security person would write is the one the technical coverage leaves out, and fal names it directly: capability was half the problem, and "the other half of the problem was legal and data residency."

Two concrete moves came out of that. They now have a process for studios to apply with their own intellectual property and unlock it inside the models, which turns a copyright objection into an onboarding step. And they moved Chinese-origin models onto US infrastructure: fal's own page offers Seedance 2.0 on US-hosted infrastructure so that, in its words, sensitive production material does not have to be sent to an overseas endpoint. Read the offer as precisely as a procurement team would. It is request-access only rather than a public endpoint, exclusive to US companies, at 480p and 720p, with pricing set per account. Yurtseven and Taskaya say every Hollywood studio wanted that before they would use it, and they expect studios to "10x 100x their AI usage in the coming months," which is a vendor forecast and should be read as one.

Read the security claim precisely, because buyers in regulated industries will. US-hosted inference locates the compute. It does not by itself settle who can access the data, what the contract permits, or what obligations the model's originator carries elsewhere. If you sell AI into legal, medical, financial, or entertainment workflows, the residency question arrives before the quality question, and the answer has to be a document rather than a reassurance. That is the practical content of trust in this market, and it is covered more fully in AI for startups.

The general form of the lesson: in every regulated category, roughly half the moat is non-technical. Legal posture, data residency, IP provenance, and contractual clarity are build items with owners and deadlines, not objections to handle in the sales call. Teams that treat them as engineering work ship into markets their competitors cannot enter.

What to do this week

1. Run the token market fit test on your own category. Can one motivated user productively spend about 10k a month on what you sell, doing it as their job all day? Write down the number you believe and the customer conversation it came from. If the honest answer is a few hundred dollars, you are building a feature, and you should price and staff accordingly.
2. Find out whether your growth is capped by compute. If revenue tracks the capacity you can get rather than the demand you can create, your efficiency backlog is your growth plan. Rank your top three inference optimizations by capacity released, not by elegance.
3. Profile the whole pipeline, not the model. Time every stage separately: prompt handling, the model itself, decode, any post-processing. Fix the worst stage first. Assume each one is unoptimized until you have measured it.
4. Ask whether your advantage survives the next model. List what you have built in the last six months, then mark each item as a result or an asset. If most of it is results, you are rebuilding every quarter.
5. Decide what crosses a threshold in your product. Identify the one latency or accuracy number that would flip your product from a submit-and-wait to a live session, and the one that would flip it from an assistant to something a professional can trust. Those two numbers are your real roadmap.
6. Make your legal posture a build item. Write down where inference runs, what the contract says about access, and what you can prove about data provenance. Put an owner and a date on each gap. In regulated categories that document closes deals your product cannot.
7. Pre-authorize one burst. Decide now who can drop their sprint to chase a capability jump, and for how long. The teams that converted this one had the infrastructure ready and the permission already granted.

If you want the full operating system for building on top of models that keep moving, the course covers the product, the evals, the cost model, and the go-to-market around it: AI Operating System for Startups.

Sources

• How Real-Time AI Video Is Changing How Creators Work, the a16z podcast episode this article distills, published as The Next Frontier of AI Video Is Control. a16z general partner Jennifer Li with fal co-founder Gorkem Yurtseven and head of engineering Batuhan Taskaya. The published transcript's speaker turns are not reliable around short exchanges, so every quote above is credited to the two fal participants together rather than pinned to one of them.
• Model and platform details from fal: the H3 Max release for the latency table, the 35x throughput figure, and the post-training approach; H3 Max: Built with fal Inference and Training for the platform layers; H3 Max Director for the session model, pricing, and the leaderboard citations; and Seedance 2.0 on US-hosted infrastructure for the data residency offering. These are the vendor's own pages and are cited as such.
• Independent model rankings: Design Arena's image-to-video leaderboard and Artificial Analysis' image-to-video leaderboard.
• Infinite Slop, including the four-videos-per-minute cap and the 37,000 viewers: Pieter Levels' own posts, I built Infinite Slop and 37,000 people watched Infinite Slop.
• Amazon MGM Studios' Project Nara, for the check above: the Amazon MGM Studios and AWS announcement, which carries the AWS line naming Luma and fal as generative AI partners, and Variety for the model-agnostic architecture.
• fal background: founded in 2021 by Burkay Gur and Gorkem Yurtseven, per TechCrunch and Fortune.
• Leaderboard positions were re-checked against the live boards on October 18, 2026, which is why the article dates them rather than repeating a vendor page.