Running multiple AI agents on a single machine is a resource nightmare. Most setups treat agents as isolated processes, but they share the same CPU and memory, leading to catastrophic out-of-memory (OOM) kills when a heavy build or test suite spikes. Developer josegarridodigio recently documented the evolution of Sluice, a queueing system for Linux agents, which moved from version 0.8.0 to 0.12.2 by solving these exact clashes. The core insight? You can't trust userspace guards to save you when the kernel is thrashing.

The OOM Kill Problem

In early tests, running 4 to 10 agents on a 30 GiB RAM machine resulted in 11 global OOM kills in just 37 hours. The issue wasn't just total memory usage, but the timing and accounting. When an agent retried a failed test with different flags, Sluice 0.8.0 treated it as a new command with no history, guessing low memory requirements for suites that actually needed 11-14 GiB. This led to aggressive memory admission that compounded errors. Version 0.9.0 fixed this by making retries inherit the memory estimate of their parent gate, preventing the 'guess-and-crash' loop that plagued earlier versions.

Kernel-Enforced Ceilings

Even with better admission, userspace daemons failed when the system hit swap limits. In one incident, the system journal went silent for up to 150 seconds during thrashing, meaning Sluice's own guard couldn't act fast enough. Version 0.10.0 shifted enforcement to the kernel using cgroup v2. By writing memory.max for each job every second, the kernel enforces ceilings even when the daemon is frozen. This change eliminated OOM kills entirely in subsequent tests, though it introduced a trade-off: jobs that previously passed by swapping are now killed immediately, forcing agents to retry or alert the user that the gate doesn't fit.

Containing Browser Escapes

A subtle bug involved Chromium-based tests, specifically Playwright. Browsers often escape their job's cgroup by creating new systemd scopes via the XDG desktop portal, rendering memory limits ineffective. On a development machine, this led to GNOME Shell lagging by 61-80 ms and requiring a hard reboot. Version 0.11.0 introduced reclaim_escaped, which walks each job's process tree every second and moves any escaped processes, like Chromium, back into the job's cgroup. This ensures that browser memory is accounted for and limited, preventing 'phantom' memory usage that bypasses the queue.

Protecting the Desktop and Environment

Sluice now includes a 'desktop guard' that pauses new jobs if the user's session is under memory pressure (above 10% avg10). This prevents agent tasks from making the interactive environment unusable. Additionally, version 0.11.0 added key_env to cache keys, ensuring that changes to variables like NODE_OPTIONS invalidate previous test results. Version 0.12.0 further hardened the daemon by stripping inherited environment variables, preventing one agent's API tokens from leaking into another's jobs.

Key Takeaways

  • Kernel > Userspace: When memory pressure is high, only kernel-enforced cgroup ceilings can prevent system-wide thrashing.
  • Browser Escapes Are Real: Chromium and Playwright processes often escape job cgroups via systemd scopes; explicit reclamation is required.
  • Desktop Priority: Agent queues must respect interactive session pressure to maintain usability.
  • Cache Hygiene: Environment variables like NODE_OPTIONS must be part of the cache key to avoid false-positive test passes.

The Bottom Line

Multi-agent orchestration isn't just about parallelism; it's about strict resource containment. If your agents are crashing your desktop, you need kernel-level cgroup enforcement, not just smarter scheduling.