The company says the feature is intended for workloads that need continuity across reconnects, including voice agents, streaming speech-to-text, stateful web UIs, and multiplayer games.
The mechanism differs from request-level routing and the best-effort affinity previously available through Modal Servers. Session tokens carry routing metadata, while the container host tracks session lifecycle. Autoscaling uses active sessions and queued demand as inputs; containers can be configured to handle one or more concurrent sessions, and new sessions may queue when capacity is exhausted.
This is a product capability release, not evidence of a general guarantee that application state survives container replacement. Modal’s post describes routing, authorization, load balancing, and scaling design, but does not provide independent performance or reliability measurements. Source: https://modal.com/blog/serverless-routing-made-sticky