OpenClaw merged a P1 Gateway performance fix today aimed at large agent fleets. PR #150188, "fix(gateway): reduce long fleet startup maintenance waits," changes how startup certification work is scheduled for already-migrated agent databases.
The practical result: startup maintenance in a paired 200-agent measurement dropped from 98.092 seconds to 67.878 seconds. The PR summarizes that as a 30.8% reduction.
The Problem
Large OpenClaw fleets can carry many agent databases. Startup maintenance needs to certify those databases before downstream work depends on them, but the previous path could serialize too much work through shared worker admission.
The motivating issue reported maintenance times of 475 to 489 seconds for a 632-agent fleet. That report found the main thread mostly idle, with time going into identity resolution, SQLite user-version reads, schema-contract checks, and related certification work.
This was not a schema migration story. The PR is specifically about long startup waits on fleets that are already migrated.
What Changed
Gateway startup now certifies two agent databases concurrently while preserving each database's required first-admission proof. Each agent retains one scoped worker across its certification batches, and the worker joins native close before later worktree detection, orphan recovery, and transcript reconciliation.
That concurrency bound matters. The fix does not simply open the floodgates. It reuses OpenClaw's existing preflight bound of two agents and keeps the per-database writer FIFO, physical-owner checks, commit authorization, and lease settlement intact.
The PR also keeps legacy-main and managed-worktree repairs detection-only at startup. Instead of writing repairs automatically, startup emits a Doctor hint when repair is needed.
Measured Impact
The primary comparison in the PR used the same isolated state, Node 26.8.2, a 2560 MiB heap cap, and a free loopback port for each run.
Results:
- Current main baseline: 98.092 seconds in
startup.maintenance - Candidate: 67.878 seconds in
startup.maintenance - Both runs reached readiness and exited cleanly
- The candidate preserved all 200 sessions
- Pending validation rows and agent leases were both zero after shutdown
Peak RSS rose in the sample, from 1208 MiB to 1287 MiB. The longest sampled main-thread timer delay also increased, so this is not a free lunch. But for operators waiting on a large fleet to become ready, the maintenance-phase reduction is meaningful.
Why Operators Should Care
OpenClaw has been adding more durable agent and session infrastructure over time. That makes correctness at startup more important, but it also makes startup cost more visible for people running many agents.
This change is a good example of the right optimization target: keep the first-admission proof, keep repair boundaries conservative, and reduce idle time by using bounded concurrency where the ownership model already allows it.
The PR includes install-transition proof as well as the 200-agent measurement. A clean candidate install with main, followed by adding a second agent and restarting once, passed with both databases certified and both sessions retained.
Bottom Line
For small OpenClaw setups, this may be invisible. For large fleets, it should make Gateway restarts less painful without weakening the startup certification model.
Source: OpenClaw PR #150188.