#OpenClaw — high cold-boot cost for agent --local dispatches

1 messages · Page 1 of 1 (latest)

magic ravine
#

OpenClaw — agent --local cold-boot cost

Version: OpenClaw 2026.4.22 (00bd2cf), Windows 11. Three agents, model: openai-codex/gpt-5.4. Agents do almost no LLM work — on receipt of a JSON payload they immediately exec a local Python script.

openclaw agent --local --agent <slug> --session-id <fresh-uuid> --message '<json>' --json --timeout 1800

Fresh --session-id isolates from the operator's webchat session.

Problem: ~13 min latency before the agent acts

Measured run (DB-recorded events, UTC):

13:32:41 +0s poker writes task_claimed, shells openclaw agent --local …
13:45:58 +797s worker writes task_claimed + 3 more events (same second)

797s of pre-execution latency. Actual work runs in <1s.

There's also a 5–9 min hang after session.ended before the process exits (~519 MB node.exe lingers).

The same agent is instant via the gateway

Webchat through the gateway (127.0.0.1:18789, warm, multiple connections) → agent responds immediately. No cold-boot, no cleanup hang.

agent --help describes --local as "Run the embedded agent locally (requires model provider API keys in your shell)" — suggesting a fresh embedded runtime per invocation: Codex OAuth, MCP init, skill/identity load.

Proposed fix — drop --local

openclaw agent --agent <slug> --session-id <fresh-uuid> --message '<json>' --json --timeout <s>

Hypothesis: the warm gateway already has the agent runtime, MCP servers, and Codex auth loaded.

Questions

  1. Is ~13 min --local cold-boot expected on 2026.4.22 with openai-codex? Is the 5–9 min post-session.ended hang known?
  2. Does omitting --local route through the warm gateway as expected?
  3. With --session-id <new uuid> and no --deliver, does the dispatch + reply stay isolated, or are --reply-to / --reply-channel needed?
  4. Does --json return the reply to stdout the same way through the gateway?
brazen orbitBOT
#

I checked the current openclaw agent docs/source. Your proposed fix is the right direction.

  1. --local 13 min cold boot: not “expected” as a healthy baseline, but it’s plausible for --local because it forces an embedded one-shot runtime: plugin/provider setup, Codex auth/runtime init, MCP/tool setup, skills/bootstrap, then teardown. I would not use --local for high-frequency dispatch. Also, there are post-2026.4.22 fixes around one-shot embedded cleanup/MCP resources, so upgrade before chasing ghosts.

  2. Omitting --local: yes — default path is Gateway RPC. Important caveat: if Gateway RPC fails, CLI falls back to embedded. With --json, check for meta.transport: "embedded" / fallback diagnostics so you don’t silently re-enter the slow path.

  3. Isolation: with --agent <slug> --session-id <fresh-uuid>, it resolves to an explicit agent session, roughly agent:<slug>:explicit:<uuid>, not the operator WebChat main session. --reply-to / --reply-channel are delivery controls only; not needed unless you use --deliver.

  4. --json: yes, stdout stays parseable JSON through Gateway. Shape differs slightly: Gateway success is wrapped, so read reply from .result.payloads[], not top-level .payloads[].

Recommended command:

openclaw agent \
  --agent <slug> \
  --session-id <fresh-uuid> \