Ox vs Kyo: Scala's Concurrency Crossroads
Ask five Scala engineers which framework you should use and you'll get five confident, contradictory answers. That's not because the ecosystem is immature. It's because "Scala framework" is doing the work of three separate questions: which HTTP backend serves your requests, how you define and document your API surface, and how you handle concurrency and errors underneath it all. Most comparison posts collapse all three into one list and call it a day. That's how you end up with Play, Tapir, and ZIO sitting in the same bullet point when two of them solve completely different problems.
If you're an engineering leader trying to make a real decision, that conflation costs you time and, eventually, a rewrite. This post separates the three questions and gives you a straight answer to each.
Pick your HTTP backend first (Play for full-stack teams, http4s for purely functional shops, Pekko for existing Akka investments). Tapir is not a competing framework, it's an endpoint-definition layer that sits on top of whichever backend you choose. For concurrency, Ox is the production-ready bet backed by a real company, while Kyo is technically impressive but carries real single-maintainer risk.
Scala Concurrency Now Splits Into Two Camps, Monadic and Direct-Style
Every concurrency library in this post is solving the same underlying problem: how do you run things in parallel, handle failures, and manage resources safely, without leaving your team exposed to race conditions or silent errors. Where they differ is the price they charge for that safety.
Monadic systems, cats-effect, ZIO, and now Kyo, encode effects as values. Every computation returns a wrapped type that a runtime later interprets. That gives the compiler precise, checkable information about what a function does, at the cost of a real mental model shift for anyone new to the style.
Direct-style systems, Ox and the experimental Gears, take the opposite bet. Code reads like ordinary, synchronous Scala. Safety is enforced structurally, through scoped constructs and compile-time rules, rather than through the function's return type. You give up some of the compiler's visibility into what a function does in exchange for code that any Scala engineer, not just one fluent in monadic composition, can read at a glance.
Cats-Effect and ZIO Are the Mature, Production-Safe Choice
If your team is already comfortable with monadic effect systems, cats-effect and ZIO remain the safest production bet in Scala concurrency. Both have large ecosystems, years of production hardening, and enough public track record that "will this scale" isn't really an open question anymore. The choice between the two is mostly a matter of team taste and existing familiarity, not a technical gap.
Neither is going anywhere, and neither needs a hedge in this post. The real decision most teams are actually facing right now is what to do about the newer options layered on top of, or built as alternatives to, that foundation.
Kyo Pushes Effect Tracking Further Than Cats-Effect or ZIO
Kyo, built by longtime Scala open-source contributor Flavio Brasil, takes the monadic approach and pushes it a step further than either of the established options. Where ZIO bakes specific channels like errors and dependencies directly into its effect type, Kyo lets a computation declare an open set of effects and only pay the cost for the ones it actually uses. The result is more precise, and it catches unsafe combinations, like mutating shared state inside a concurrent computation, as a compile error rather than a runtime surprise.
That's a genuine technical achievement, and Kyo's pace of development has been fast. It reached its 1.0 release candidate in July 2026, with a large and active surface area already covering streaming, structured concurrency, and typed actors.
Kyo Is Not Yet Safe to Bet a Production System On
Kyo is maintained primarily by one person. That's the whole risk, stated plainly. A single point of failure in your core concurrency library is a real operational exposure, regardless of how strong the technical design is. There's no clear succession plan in place if that changes.
For a personal project or an internal tool, that's an acceptable trade for Kyo's technical sophistication. For a system your business depends on, it's a governance question that belongs next to the technical evaluation, not underneath it.
Ox Is the Production-Ready Answer to Direct-Style Concurrency
Ox, built by SoftwareMill, the team also behind Tapir, is the most credible direct-style alternative available today. Instead of wrapping computations in an effect type, Ox lets you write code that looks like plain, synchronous Scala, while enforcing safety through structured concurrency scopes underneath. Running two computations in parallel looks like a normal function call. Retrying, timing out, or racing computations reads the same way. There's no new syntax to learn before your team can be productive.
Ox shipped its 1.0 release and has continued past it, at version 1.0.6 as of this year. It's backed by a real company with an existing product, Tapir, already trusted across the ecosystem, which gives you a real answer to the question every CTO should ask about any dependency: what happens if the maintainers move on. With Ox, the answer is a company with an existing revenue relationship to the library, not one person's continued goodwill.
Ox Requires Scala 3 and JDK 21
This is the constraint that actually matters for planning. Ox is built on Project Loom's virtual threads and Scala 3's language features, and it doesn't run on older infrastructure. If your team is still on Scala 2 or an older JVM, Ox isn't available to you today, full stop. That turns "should we adopt Ox" into a two-part question for a lot of teams: is a Scala 3 migration on the roadmap, and does this justify moving it up.
What Ox Still Doesn't Cover
Even SoftwareMill's own team is candid about gaps. Ox's parallel combinators don't yet support Either-based error channels the way some teams would prefer, and a few of its APIs, like the pattern needed to run several unit-returning tasks in parallel, still feel like a missing piece rather than a finished design.
Because Ox deliberately skips effect tracking in the type system, a function's signature won't tell a new engineer what it actually does underneath. That's the direct trade-off for the simpler syntax: less compile-time visibility into behavior, in exchange for code nobody has to learn a new paradigm to read. Neither of these gaps undermines the core approach, but they're worth knowing going in rather than discovering mid-project.
Gears Is a Research Project, Not a Production Option
Gears, built at EPFL under Martin Odersky's direction as part of the Caprese research initiative, takes direct-style concurrency even further than Ox by representing effects as capabilities, contextual parameters a function requires to run, rather than as values at all. The result is code with almost no wrapper types anywhere.
Gears is currently at version 0.3.1, released in May 2026, and its recent progress is real. Its Scala.js and WebAssembly target saw a 74 percent memory usage reduction from collapsing redundant async calls, and a long-standing Node.js stack overflow issue was finally resolved once Node 26 shipped a fix on its end. That's genuine momentum. It's also explicitly a research project, and its ambition to run across the JVM, Scala.js, and Scala Native at once is part of why it's further from production readiness than Ox, which deliberately stayed JVM-only to get there faster. Treat Gears as something to watch as the underlying Caprese research matures, not something to build a production system on this year.
Direct-Style Code Is Easier to Hire and Onboard For Than Monadic Effects
This is the part of the decision that rarely makes it into a technical comparison, and it's the part that actually determines how expensive your choice is over time. Monadic effect systems ask every new engineer to learn a specific style of composition before they can be productive in your codebase. That's a real cost, and it compounds every time you hire.
Direct-style code doesn't remove that cost, it relocates it. A new engineer can read Ox code on day one because it looks like ordinary Scala. What they still need to learn is where the structural safety rules live, and those rules are less familiar territory for most engineers than a monad is, simply because fewer teams have used them yet. As Scala's talent shortage makes clear, any concurrency choice that isn't the ecosystem default narrows your hiring pool somewhat. The question is whether the narrowing is worth what you get in return.
Choosing Between Ox and Kyo Comes Down to Risk Tolerance, Not Feature Lists
If your team already writes fluent cats-effect or ZIO, there's no urgent reason to move. Both remain safe, mature choices, and switching concurrency models is a real cost with no guaranteed payoff.
If you're building something new and want to avoid the monadic learning curve entirely, Ox is the credible option today, provided you're already on or planning to move to Scala 3. Its backing gives you a real answer to the governance question that Kyo can't yet match.
Kyo deserves a place on your radar, not your production roadmap. Its technical approach is genuinely ahead of where ZIO and cats-effect are today, and it's worth revisiting once its governance picture is less dependent on one person's continued availability.
This is one of the areas covered in our full breakdown of modern Scala framework choices, alongside the HTTP and API-layer decisions that usually come before this one.
Ox only runs on Scala 3. If your team is still on Scala 2, that's the decision underneath this one.
A migration changes what's actually available to you, and it's not a project to scope alone the first time. Whether you're planning a Scala 3 migration or need engineers who already know these trade-offs, talk to a Scala expert.
Frequently Asked Questions
What Is Ox in Scala?
Ox is a direct-style concurrency library built by SoftwareMill for Scala 3. It lets developers write structured concurrency, error handling, and resource management using plain, synchronous-looking code instead of wrapping computations in an effect type.
Is Kyo Ready for Production Use?
Kyo reached its 1.0 release candidate in July 2026 and is technically advanced, but it currently has a single primary maintainer and has previously paused development due to unresolved community conflict. Teams should weigh that governance risk separately from Kyo's technical strengths before relying on it for critical systems.
What Is the Difference Between Ox and Kyo?
Ox uses a direct-style approach, meaning code looks like ordinary synchronous Scala with safety enforced structurally. Kyo is a monadic effect system that encodes what a computation needs directly into its type. Ox is backed by SoftwareMill with a shipped 1.0 release; Kyo is maintained largely by one person.
Do You Need Scala 3 to Use Ox?
Yes. Ox requires Scala 3 and JDK 21, since it relies on Project Loom's virtual threads and Scala 3 language features. Teams still on Scala 2 or an older JVM cannot adopt Ox until they migrate.
Is ZIO or Cats Effect Better for Concurrency?
Both are mature, production-grade monadic effect systems with large ecosystems. The choice between them is largely a matter of team familiarity and existing codebase conventions rather than a meaningful capability gap.
