OpenClaw merged PR #167676, a worker-pool change that gives image-heavy bursts more breathing room without making operators tune new settings.
The issue was straightforward: concurrent image transforms queued behind a single worker. At the same time, Control UI asset reads could wait for shared compute permits that were occupied by unrelated work. That combination could make image generation feel slower and make simple UI reads wait behind heavier tasks.
What Changed
Image bursts can now use two workers inside the existing shared CPU budget. The second image worker is not permanent capacity. Surplus image workers retire after five idle seconds, while the first usable worker keeps its normal idle lifecycle.
Control UI reads also get clearer separation. They use their existing bounded file pool independently of compute admission, so file reads do not have to wait behind occupied shared compute permits in the same way.
The PR says no operator configuration or migration is needed. The worker-pool retirement owner handles surplus deadlines and promotion. A worker that is already stopping still counts against capacity until native exit, but it no longer qualifies as the retained idle worker.
Why This Matters
OpenClaw now has more workflows that touch image and file processing: generated media, previews, uploaded files, Control UI assets, and plugin outputs. A single-worker image lane can be fine for isolated tasks, but bursts quickly expose the queue.
The important part of this change is that it improves burst behavior without leaving extra workers sitting around indefinitely. That is a healthier tradeoff for self-hosted and local-first installations, where memory and CPU budget matter as much as peak speed.
Operators should expect the practical effect to show up in a few places:
- Image bursts can complete faster when multiple transforms arrive together.
- Control UI file reads are less tied to shared compute pressure.
- Surplus worker capacity retires after idle time.
- No new configuration or schema migration is required.
This is not a rewrite of worker execution. The existing dispatch, FIFO admission, and native settlement machinery still own execution and cleanup.
The Measured Result
The PR reports a Linux benchmark with compiled production entrypoints processing two 1536x1536 JPEG encodes, six 64x64 JPEG encodes, and 24 uncached 256 KiB assets plus sidecars per burst. Warm results covered 12 bursts, and encoded-image plus asset byte digests matched across every comparison.
Warm image queue-wait p99 fell from 209.99 ms to 103.54 ms. Spaced image queue-wait p99 fell from 204.36 ms to 108.89 ms. The complete warm mixed workload improved from 2448.42 ms to 1287.70 ms, reported as 1.90x faster.
There is a tradeoff: warm ordinary file queue-wait p99 increased from 13.90 ms to 25.76 ms, and cold file queue-wait p99 increased from 112.99 ms to 153.02 ms in that four-CPU workload. But when two shared compute permits were held, file queue-wait p99 improved sharply from 207.04 ms to 19.01 ms.
Idle worker heap stayed essentially flat after about six idle seconds, at 47.20 MiB before and 47.23 MiB after. That supports the core design: add short-lived burst capacity, then retire it.
Bottom Line
PR #167676 is a focused throughput improvement for OpenClaw's media and file-heavy paths. It lets image work scale modestly during bursts, keeps Control UI reads from being dragged through the wrong queue, and avoids a permanent resource increase.
For users leaning on generated media or asset-heavy plugin workflows, this should make peak moments feel less clogged.