Short answer: it’s usable in production, but I wouldn’t call it “frozen and finalized” yet.
The API is still evolving as I refine the workflow and add features. Network replication in particular isn’t fully optimized. With higher player counts you can see recv bandwidth spike. Send bandwidth is sitting between 10-20 kb/s from where I last left the replication layer.
That doesn’t sound right to me since right now I don’t replicate raw transform CFrames. Instead, I replicate driver changes (the parameters that actually produce the animation). Each client takes those driver values and recomputes the exact same pose locally. It should be more deterministic, lightweight, and avoids shipping full pose data every frame. Yet it’s still 20 kb/s. so I’m not quite sure where I might’ve missed an optimization.
Long‑term, I’m hoping my Engine Request gets traction so we can eliminate the need for custom replication on rigs entirely and let the engine handle animation state sync natively, ultimately removing the need for Remotes with Fluxa.
Fluxa is being used in real projects. I’m using it myself, and there’s already a really cool paintball game that someone else is building on top of it. So, while it’s not “production‑ready” in the sense of being locked‑down and API‑stable, it’s absolutely capable of shipping a game today. It’s open‑source, constantly improving, and easy to fork or extend if someone needs something specific.
So the realistic answer: it’s stable enough to build with, but still evolving, and that’s by design.