diff --git a/docs/guides/rendering.mdx b/docs/guides/rendering.mdx
index 6c7a480ad..a450d60d6 100644
--- a/docs/guides/rendering.mdx
+++ b/docs/guides/rendering.mdx
@@ -136,7 +136,7 @@ By default, Hyperframes uses **half of your CPU cores, capped at 4**:
 | 4-core laptop | 4 | 2 |
 | 2-core VM | 2 | 1 |
 
-This is intentionally conservative. Unlike tools that open multiple browser tabs in a single process, Hyperframes spawns separate Chrome processes per worker — the per-worker overhead is higher, so fewer workers avoids resource contention with FFmpeg encoding and your other applications.
+This is intentionally conservative. Each worker spawns its own Chrome process, so the per-worker overhead is significant. Fewer workers avoids resource contention with FFmpeg encoding and your other applications.
 
 ### Choosing a worker count
 
diff --git a/packages/cli/src/commands/render.ts b/packages/cli/src/commands/render.ts
index d81ff7ab0..3f9b14d80 100644
--- a/packages/cli/src/commands/render.ts
+++ b/packages/cli/src/commands/render.ts
@@ -17,10 +17,9 @@ const VALID_FORMAT = new Set(["mp4", "webm"]);
  * Calculate a conservative default worker count for CLI use.
  *
  * Uses half of available CPU cores, capped at 4. Each worker spawns a
- * separate Chrome browser process (~256 MB RAM each), so we default lower
- * than a production server would. Remotion uses a similar heuristic
- * (50% of CPU threads) but can use tabs within a single browser — we need
- * separate processes, so the per-worker cost is higher.
+ * separate Chrome browser process (~256 MB RAM each), so we keep the
+ * default low to avoid resource contention with FFmpeg encoding and
+ * other applications on the user's machine.
  *
  *   2-core laptop  → 1 worker
  *   4-core laptop  → 2 workers