Performance & overhead
Modern teams are rightly sensitive to anything that could slow users down.
Multiplayer is designed to capture session-specific, targeted data (not always-on, wide-net data collection) without adding noticeable latency or chewing through bandwidth/CPU. This section explains how we do that—and what controls you have.
Design principles of how Multiplayer stays lightweight
-
Session-based by default Multiplayer is designed for targeted bug fixing: we capture and send data when only we identify a new issue and only for that specific session.
It's a session-first approach where the central artifact is a timeline that correlates:
• User interactions in the browser • DOM mutations and rendering state • Console errors • Network requests and responses • Backend traces and spans triggered by those requests
-
Local-first by default The Multiplayer debugging agent CLI runs locally next to your coding agent (either hosted or self hosted). We also cache all sessions locally before sending them.
-
Opt-in by default
The debugging agent CLI works in the background and starts a new debugging session only when it detects a new error or exception. You can further customize when an issue is created in the project setting.If you prefer to use the browser-extention or in-app widget for manual recording capture, there’s zero added runtime overhead when you're not recording.
-
Event-based, not video-based
On the frontend we record structured events (DOM mutations, inputs, clicks, network metadata), not pixel streams. That’s far smaller and cheaper to capture/upload. -
Asynchronous, batched I/O
We buffer and batch uploads in the background, off the critical path. No synchronous calls that block user interactions. -
Backend-agnostic via OpenTelemetry
OpenTelemetry lets you tune what’s instrumented and how much you emit. Think of it like adding structured logging: configurable and minimal when done right.
Recording modes & typical overhead
Many session replay tools either record every session (expensive, noisy; you end up sampling/filtering constantly), OR provide only on-demand video-style capture (you miss unexpected issues).
Multiplayer offers multiple recording modes, so that it can be adapted to all teams and use cases:
-
Automatic When using the debugging agent CLI, recordings of errors and exceptions are automatically captured, deduplicated, triaged, and fed to your preferred coding agent to generate an accurate fix.
Review this guide to for details on how the debugging agent works.
-
On-Demand (manual)
Nothing runs until a user explicitly starts a recording (browser extension button, widget toggle, or SDK call). Great for “no background footprint” policies. -
Continuous (rolling buffer)
Keeps a lightweight rolling window (e.g., ~2 minutes) of events/spans in memory/storage.- You can “Save recording” if something unexpected happens.
- We auto-save when we see frontend or backend errors/exceptions.
This avoids the heavy cost of recording every session while still catching elusive issues.
Overhead by install options
Multiplayer offers both a hosted (SaaS) and self-hosted (open source) version:
- Hosted version: Free 7-day trial
- Self-hosted version: Open source project, MIT license
Whichever option you choose we provide multiple install options, depending on your needs and overhead concerns:
- Install the debugging agent CLI
- Install our Chrome browser extension
- Install our JavaScript client library (including optional in-app widget)
- Install our React Native client library for mobile apps
What to expect in practice
- No recording = no overhead.
- Automatic = only bugs (automatic bug-to-fix for errors and exceptions)
- On-demand = minimal overhead while active (event capture + async batches).
- Continuous = lightweight footprint (rolling buffer + async) and automatic saves on exceptions/errors.
- Backend tracing = comparable to structured logging when instrumented sensibly; the big win is that you get complete session context without turning on “log everything” globally.
Quick checklist before enabling at scale
- Limit capture to non-prod first, verify timing/memory with your own RUM/APM.
- Set masking, ignoreUrls, and network capture rules.
- In OpenTelemetry, enable batching/memory_limiter; scope enrichments to active sessions.
- Use the debugging agent CLI to automatically capture exceptions/errors, limiting the number of on-demand recordings needed to reproduce ellusive, or hard-to-reproduce errors.
Next steps
🚀 If you’re ready to trial Multiplayer with your own app, you can follow the steps in the quickstart.
📌 If you have any questions shoot us an email! 💜