Cloud gaming
The GPU is somewhere else. You will stop noticing.
1440p at 120 frames per second, 45 Mbit/s, and 17 milliseconds of latency added between your input and the frame — measured, published, and lower than most wireless controllers add on their own.
How it stays playable
Frame pacing, not just frame rate
The encoder is locked to the game's presentation, so frames arrive evenly. A steady 60 feels better than a jittery 120 and we optimise for the first.
Network path chosen per session
We measure jitter to three regions before a session starts and pick the best, not the closest.
Adaptive without ugliness
Bitrate adapts on a 200 ms window; resolution drops before frame rate, because a soft image plays better than a stuttering one.
One GPU per session
No partitioning, no sharing. The machine you get is the machine you get for the whole session.
Nothing to install
A browser client for anything with a modern browser, plus native apps where they materially reduce latency.
Your library, your saves
Connect your existing stores. Saves sync back to them, so stopping the subscription does not strand your progress.
Latency
The whole budget, itemised
Everyone quotes one number. Here is the entire chain, measured at the 50th percentile from a wired connection 40 km from a region.
- Added latency excludes the game's own render time, which is the honest way to compare against local play
- Every number above is published per region and updated weekly
| Stage | p50 | p95 |
|---|---|---|
| Input capture to send | 1.2 ms | 2.4 ms |
| Network, client to region | 6.1 ms | 11.8 ms |
| Input to game engine | 1.8 ms | 3.1 ms |
| Render (game dependent) | 8.3 ms | 16.7 ms |
| Capture and encode | 3.9 ms | 6.2 ms |
| Network, region to client | 6.0 ms | 11.4 ms |
| Decode and present | 4.1 ms | 7.8 ms |