Windflow vs Reactor: choosing a realtime model session API
Compare Windflow and Reactor by session lifecycle, model-specific controls, billing boundaries and integration work, using dated primary sources.
Windflow and Reactor both provide persistent sessions for interactive video and world models. Evaluate the exact model, controls, access conditions and session lifecycle your application needs. Windflow is an option for teams evaluating its hosted catalog in private beta; Reactor publishes its own model SDKs, starter applications and session API. A shared model name does not establish identical serving behavior or a drop-in migration.
This comparison is maintained by Windflow. Competitor documentation was checked on November 9, 2026. It is a source-based integration comparison, not a head-to-head inference or availability benchmark.
Compare a concrete integration
| Decision | Windflow | Reactor | What to verify |
|---|---|---|---|
| Continuous video | Helios and LongLive service profiles with model-specific controls | Published Helios reference and typed SDK | Prompt timing, scene cuts and reference-image support on the exact profile |
| Navigable generated world | LingBot-World 2.0 profile with seed conditioning and persistent input state | Published LingBot World 2 reference with movement/look commands | Input vocabulary, key release, version and weight terms |
| Browser authentication | Backend-held account key exchanged for a scoped session token | Backend token exchange documented for model-scoped sessions | Token scope, expiry, session limits and reconnect behavior |
| Ending ownership | Release the owner session; stopping a player alone is insufficient | Terminate the owner session; recoverable disconnect retains the meter | What happens when the tab closes or the network disappears |
Reactor's Helios reference documents prompt/image controls and a server-to-browser token flow. Its LingBot World 2 reference describes image and prompt conditioning plus movement/look control. Windflow's corresponding public integration guides are Helios and LingBot. Compare command semantics rather than translating names mechanically.
The billing boundary changes the estimate
Reactor's billing documentation says its meter starts at ready, ends when the session terminates and continues during a recoverable disconnect. Its connecting and waiting states are unbilled. A guest leaving a shared session does not terminate its owner's meter.
Windflow's current rule is: Billing starts at the session's first generation_started event and stops when the session is released or ends. Queueing, worker startup, time before generation starts and the documented reconnect grace are not billed. After generation starts, paused or unwatched time remains billable; release the owner session to stop the meter. Rates are model-specific and published on pricing; the public catalog's range is $0.0017–$0.0069 per billable second. These are private-beta service rates, not a quote for dedicated GPU capacity.
For each provider, write down when the meter begins, what keeps it running, and which action actually ends it. Include time spent preparing inputs after readiness, idle time, failed starts, retained reconnects and independent concurrent sessions. Compare the resulting workload cost. This page does not infer a price multiplier from two different models or billing windows.
Migration work to plan
- Pin one workload. Start with a prompt-driven video session or a fixed world-navigation sequence. Record inputs, served version, output size and required controls.
- Map lifecycle events. Account for queued/ready state, explicit generation start, visible media, rejected commands and session end. An accepted command is not proof that its effect is already on screen.
- Map state changes. Decide whether an update retains scene history, resets conditioning or starts independent content. Check this for each model rather than assuming all prompt setters behave alike.
- Implement cleanup first. Release the owner on cancellation and application exit, handle late session-creation responses, and surface unconfirmed cleanup before allowing another paid session.
- Evaluate your actual client path. Measure first visible frame, control-to-visible delay, presented FPS and freezes under the same conditions. Keep failed or interrupted sessions in the report.
For example, Reactor documents snapshot and rewind functionality in its Helios overview. A product that depends on that workflow needs an explicit capability check during migration; similarity of model names is insufficient evidence of feature parity.
When each belongs on your shortlist
Evaluate Reactor when its published SDK, starter or exact model controls fit your product, including features you already depend on. Evaluate Windflow when you want to assess its session API across continuous generation, live editing and worlds, and can work within private-beta access and current capacity. Use the runnable browser examples to inspect the lifecycle before arranging a live trial.
Windflow's dated measurements explain specific experiment boundaries. They do not establish that Windflow is faster than Reactor. A fair service decision requires the same workload and visible client measurements on both.
FAQ
Is Windflow a Reactor alternative for interactive world models?
Windflow offers a hosted session API with a LingBot-World profile and other interactive models. It is an alternative to evaluate after checking the exact model version, controls, access and current readiness. It is in private beta.
Can I keep the same client code when switching providers?
Expect integration changes. Token APIs, commands, media offers, state transitions and cleanup semantics belong to each provider's contract. Preserve your application's interaction design, then adapt and verify its session layer.
Does disconnecting always stop billing?
No. Reactor documents continued billing for recoverable disconnects. On Windflow, release the owner session to stop its meter after generation has begun; merely pausing or hiding video is insufficient. Follow the current billing rules for each service.