Resource allocation and performance

Speedwave isolates Claude Code and integration workers within independent container workloads, governing memory consumption and CPU scheduling with deterministic resource constraints.

Host hardware verification

1. Verify your workstation provides at least 16 GiB of physical RAM. Speedwave checks memory availability on startup on macOS, displaying a diagnostic warning if host resources are constrained.
2. Review the memory and CPU quota specifications below to plan multi-integration workloads.

Resource constraints are determined by the application architecture and cannot be adjusted via config.json. Any manual compose file adjustments take effect only upon container restart.

Memory detection on Windows

On Windows environments, host RAM is not inspected directly by Speedwave; memory allocation is managed dynamically by the underlying WSL2 subsystem. The 16 GiB physical RAM requirement remains applicable across both platforms.

Container memory allocations

Memory limits function as upper bounds rather than static upfront reservations: idle containers consume minimal memory regardless of assigned limits.

Container	Memory limit
Claude Code runtime	6 GiB
Tool Gateway (MCP Hub)	512 MiB
LLM Proxy	128 MiB
Standard service workers (Slack, GitLab, SharePoint)	128 MiB
GitHub worker	256 MiB
Office document worker	1 GiB
Playwright browser worker	2 GiB (plus 2 GiB shared /dev/shm)

Specific workers receive elevated allocations to accommodate heavy workloads:

• GitHub worker (256 MiB): Accommodates large JSON payloads when parsing complex repository changesets.
• Office worker (1 GiB): Supports background document rendering engines.
• Playwright worker (2 GiB): Manages headless Chromium process pools.

Worker resource limits apply only when their corresponding integration is active. Total theoretical limits across all workers may exceed virtual machine memory because idle containers operate far below ceiling thresholds.

CPU scheduling limits

CPU limits define scheduling quotas within a shared thread pool, preventing compute-heavy workers from starving adjacent containers:

Container	CPU quota
Claude Code runtime	Up to 2 CPUs
Playwright browser worker	Up to 2 CPUs
Tool Gateway (MCP Hub)	Up to 1 CPU
Office document worker	Up to 1 CPU
LLM Proxy	Up to 0.5 CPU
Standard service workers	Up to 0.5 CPU

Virtual machine sizing

macOS

On macOS, Speedwave provisions a Lima virtual machine scaled to host hardware: allocating half of physical RAM (clamped between 8 GiB and 32 GiB) and half of available CPU cores (4 to 8):

Host specifications	VM memory allocation	VM vCPUs
16 GiB RAM / 8 cores	8 GiB	4
32 GiB RAM / 16 cores	16 GiB	8
64 GiB RAM / 24 cores	32 GiB	8

Memory claimed by the virtual machine is retained throughout its lifecycle according to Apple Virtualization Framework conventions, releasing memory back to macOS when the virtual machine terminates.

Windows

On Windows, WSL2 dynamically allocates system memory (typically 50% of host RAM by default). Container quotas apply within this allocation.

Time zone synchronization

Speedwave detects host time zones and injects corresponding parameters into containers, ensuring timestamps in model outputs reflect local time. If time zone resolution fails, containers fall back to UTC.

For initial environment provisioning, consult Install Speedwave.