Reactor, Photon Fusion 2, and Coherence are three of the options developers evaluate for Unity multiplayer with managed hosting. They differ in architecture, pricing model, and design philosophy.
The short answer: Reactor runs game logic and physics on a built-in authoritative server and bills for compute time ($0.02 to $0.50 per room-hour by size) plus bandwidth at $0.05 to $0.10 per GB. Photon Fusion 2 is a relay billed per CCU, and server authority means running your own dedicated servers on top of the relay fee. Coherence bills CCU time, simulator compute, and bandwidth through a credit system, with bandwidth at $0.20 to $0.32 per GB. In a controlled benchmark syncing 250 physics objects at 30 Hz, Reactor used about 15 kB/s per client and Photon Fusion 2 about 112 kB/s; Coherence does not publish bandwidth numbers.
At a glance
| Reactor | Photon Fusion 2 | Coherence | |
|---|---|---|---|
| Server authority | Built-in | Requires separate dedicated server | Requires headless Unity instance |
| Server-side physics | Yes (PhysX) | No | No |
| Max tick rate | 120 Hz | No platform limit | 30 Hz cap |
| Compute billing | CPU-time ($/hr per vcore) | Per CCU relay fee | Per CCU + CPU-time (via credits) |
| Bandwidth rate | $0.05-$0.10/GB | $0.05-$0.10/GB | $0.20-$0.32/GB |
| Bandwidth per client (250 objects, 30 Hz) | ~15 kB/s | ~112 kB/s | Not published |
| Multi-room player connections | Yes | No | N/A (simulator model) |
Prices verified May 2026. Pricing pages: Reactor, Photon Fusion 2, Coherence.
Disclosure: KinematicSoup makes Reactor. This comparison is written by the Reactor team. It draws on public information from all three vendors. Verify claims against each vendor’s documentation before making a purchasing decision.
Reputation and community
Photon has a long track record. It has been the default recommendation for Unity multiplayer for years, and the community reflects that: extensive documentation, a large pool of developers who have used it, and many public examples to learn from. For developers entering multiplayer for the first time, that ecosystem lowers the learning curve.
Coherence is newer. Its onboarding requires little setup, its community is smaller, and its track record is shorter.
Reactor has been in development since 2015 and has shipped in commercial games. The community is smaller than Photon’s, and public documentation is less extensive. Developers who choose Reactor tend to do so for technical reasons rather than ecosystem size.
Developer experience
Coherence puts the most work of the three into the first-run experience; setup is short and the tooling is approachable.
Photon Fusion 2 is well documented and the API is straightforward to start with. Shared mode requires little setup to sync objects across clients.
Reactor’s structure differs. It uses a local development server and a server-side scripting model. That structure is familiar to anyone who has done backend or dedicated-server work, and it separates client and server code, defines what is shared between them, and shortens build times by decoupling client builds from server builds. With Photon, state synchronization code grows with the codebase; Reactor generates and maintains the data model from game state.
Server authority
All three solutions support server-authoritative multiplayer, but the implementations differ.
Photon Fusion 2 offers two modes. Shared mode assigns authority over objects to different clients: each client owns and drives its own objects, and Photon relays state to others. This is fast to build, but the server holds no authority over the objects. For real server authority, Photon requires the developer to run a dedicated headless Unity server build, manage hosting and orchestration for it, and pay those infrastructure costs separately on top of Photon’s per-CCU fees.
Coherence uses the same pattern. Shared mode assigns object authority to clients. For server authority, a headless Unity instance runs alongside Coherence and handles authoritative logic. Coherence manages some of the synchronization, but the authority layer is something the developer constructs.
Reactor’s room is itself the authoritative server. It runs PhysX physics simulation server-side, handles raycasts, sweeps, and overlap queries, and can be configured with complete authority over all entity state. Client updates are validated before they change state. Reactor also supports a shared authority model where the server assigns ownership of entities to Unity clients or headless instances, providing flexibility for games that do not need full server-side physics. The distinction from Photon and Coherence is that Reactor’s server authority is built in rather than constructed from a headless Unity process running alongside a sync layer.
Bandwidth efficiency
Reactor publishes its bandwidth numbers. In a head-to-head comparison against Photon Fusion 2, Netcode for GameObjects, FishNet, Mirror, PurrNet, and SFS2X, Reactor used about 15 kB/s per client syncing 250 physics objects at 30 Hz. Photon Fusion 2 used about 112 kB/s under the same conditions. The full methodology, scene configuration, and source are available on GitHub.
Photon applies compression and delta updates.
Coherence does not publish bandwidth benchmarks.
Reactor’s bandwidth efficiency comes from data models generated from game state. The developer does not write serialization code. Real deployments have achieved under 1 byte per transform update in games with 100 players and 150 physics objects at 30 Hz.
Hosting costs
Four inputs set the monthly bill: how compute is charged (per CCU or per CPU-hour), how bandwidth is metered, how much bandwidth the framework uses, and whether server authority requires separate infrastructure. A framework that is cheap at 50 players can become the dominant cost at 500. The three solutions charge for different things.
Photon Fusion 2 charges per CCU for its cloud relay service (pricing). A CCU in Photon’s model is a player slot connected to the relay infrastructure: it covers message passing between clients but not server-side computation, since Photon’s relay does not execute game logic. Plans are structured as CCU tiers (500 CCU, 1,000 CCU, 2,000 CCU), and each tier includes 3 GB of bandwidth per CCU per month. At Photon’s overage rate of $0.05 per GB in standard regions, that bundled bandwidth represents $0.15 of included value per CCU. In premium regions (Asia, Middle East, South America) at $0.10 per GB, it represents $0.30. Unused fees are credited back. Monthly plans include burst capacity with a 48-hour window to upgrade before throttling. The annual 100 CCU plan does not include burst. For server authority, the developer runs their own dedicated Unity server build on their own infrastructure, paying those hosting costs separately and on top of Photon’s CCU fees.
Coherence charges via a credit system that covers relay and compute (pricing). Unlike Photon, which charges only for CCU relay slots, or Reactor, which charges only for CPU time, Coherence charges for both: CCU connections to the relay and CPU time consumed by simulators, in addition to bandwidth. CCU time is billed at $0.01 per 10 hours, which works out to $0.72 per CCU per month for a player connected around the clock. Bandwidth is priced at 200 credits per GB, with credits costing $0.99 to $1.60 per 1000, working out to $0.20 to $0.32 per GB. The credit abstraction bundles these costs together, which makes the monthly cost of a given player count difficult to estimate in advance.
Reactor Cloud charges for CPU time: rooms are billed by the minute based on the compute size you choose, from $0.02 per hour for a 0.25 vcore room to $0.50 per hour for a 4 vcore room. There is no per-CCU cost as there is for Coherence or Photon. You are paying for actual server-side computation running your game logic and physics simulation, not for player slots connected to a relay. Every paid Reactor tier includes a usage credit equal to the monthly subscription cost, so the fixed fee covers the first equivalent amount of room and bandwidth usage each month. Bandwidth is $0.05 per GB in North America and Europe, $0.10 per GB elsewhere.
For small games, developers can use Reactor’s sync groups and Unity ownership components to divide a connected playerbase into isolated subsets within a single room, creating virtual sub-rooms. Each sync group controls which state is visible to which clients, and ownership components handle data replication between them. The smallest room size supports 100 or more CCU, so a single room instance can carry multiple concurrent game sessions during early growth before scale justifies dedicated rooms per match.
The bandwidth rate gap between Reactor and Coherence is 4 to 6 times. For simple games with few dynamic objects, that rate difference is the main factor. For action games with hundreds of dynamic objects, bandwidth usage scales with entity count, and without an efficiency story Coherence has no mechanism to contain that growth. The rate gap and the volume gap compound: the total bandwidth bill on Coherence for an entity-heavy game can be an order of magnitude higher than the same game on Reactor.
Photon and Reactor charge similar bandwidth rates. At the same object count and tick rate, Reactor’s egress volume is about 7x lower. The 3 GB per CCU inclusion softens Photon’s bandwidth bill for games with low average playtime, but at 112 kB/s per client it covers about 7.5 hours of play per CCU per month before overage. For any game with regular engagement, the inclusion covers only a fraction of actual usage. And for Photon in server authority mode, the dedicated server infrastructure costs are separate from and in addition to the CCU fees.
Room customization and game types
Photon Fusion 2 and Coherence are well-suited to a defined range of game types: action games, social games, casual multiplayer. Both become harder to work with as the game’s requirements move toward physics simulation, large entity counts, or demanding server-side logic.
Coherence’s documentation does not state what compute resources a simulator provides, whether processing is shared or dedicated, or how to capacity-plan against it. Coherence also caps simulator frame rates at 30 Hz, which limits physics simulation fidelity and rules the platform out for competitive games where tick rate affects hit registration and input responsiveness.
Reactor rooms are a full processing timeslice: dedicated, predictable compute with defined CPU and memory allocations. The developer knows what the room runs on and can tune for it. Reactor supports tick rates up to 120 Hz, giving developers control over the tradeoff between server load and latency. A card game runs at a low tick rate to minimize cost; a competitive shooter runs at a high tick rate for tight input responsiveness. The same room infrastructure handles both.
Reactor rooms are open to the developer in other respects as well. The server supports physics simulation, scene queries, scripted game logic, and room-to-room communication via the Cluster API. The framework does not limit what the server code can run.
In Photon, a player occupies one room at a time. In Reactor, a player can hold connections to any number of rooms at once. This enables server topologies that are not practical with a single-room model. A large world can be sharded across multiple zone instances, with players connected to the zones around them. Zones can be replicated to distribute concurrent players across instances for load balancing. Separate rooms can run dedicated microservices (global chat, matchmaking, leaderboards, guild systems) that any connected client can interact with independently of their game room. These patterns require the multi-room connection model.
Which to use
Photon Fusion 2 is the right starting point if community size, documentation quality, and ecosystem familiarity are your top priorities. For games of low to moderate complexity where server authority is not critical, the shared mode is quick to build on. The cost structure becomes complicated if you need true server authority, since you are then paying for both Photon and your own dedicated server infrastructure.
Coherence suits developers for whom developer experience and speed to a working prototype are the primary concern, and whose game type does not require bandwidth efficiency or physics simulation. The bandwidth cost structure is the main tradeoff.
Reactor is the choice when technical requirements are the binding constraint: server-authoritative physics, large crowds, high entity counts, competitive games, or persistent online worlds. The result is lower bandwidth cost at scale and server capabilities the other two provide only with separate infrastructure.
Reactor is free to develop locally and free to self-host the server runtime up to 32 CCU. Cloud hosting starts at $20 a month. Get started here.