#Subagent spawns but LLM never invoked — accumulatedRuntimeMs = 0, 0 tokens in/out

7 messages · Page 1 of 1 (latest)

winged wyvern
#

INSTANCE: OpenClaw 2026.4.9 (Windows)
MODEL: minimax/MiniMax-M2.7

ISSUE: Subagents get accepted (status: accepted) but LLM is never actually invoked.

STEPS TO REPRODUCE:

  1. Spawn a subagent via sessions_spawn (any task, any timeout)
  2. Session is created, appears in ~/.openclaw/subagents/runs.json
  3. Session status shows "collect (depth 0)" — queued but never dispatched
  4. Eventually times out with 0 tokens in/out

EVIDENCE (from runs.json):

  • Subagent spawns: createdAt + startedAt both set (within ms)
  • accumulatedRuntimeMs: 0 (for ALL failed subagents)
  • Tokens in/out: 0
  • First subagent (void-runner-design, Apr14 13:21) DID work — accumulatedRuntimeMs: 109,683ms, full output
  • Subsequent batch of 3 subagents all failed with 0 runtime

CONFIG:
agents.defaults.subagents.maxConcurrent: tried 8 (default), now 2 (still fails)
Tried spawning 1 at a time (sequential), still fails

WORKAROUND: Writing files directly in main session works fine

zinc perchBOT
lucid patrolBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

waxen hearthBOT
#

This looks much more like a subagent queue/lifecycle wedge than a MiniMax prompt failure.

Why I think that:

  • collect (depth 0) is just status formatting from formatQueueDetails, basically “nothing queued behind it”, not proof of provider dispatch.
  • In src/agents/subagent-registry-run-manager.ts, subagent runs get startedAt stamped when they’re registered, before the real model run starts.
  • In src/gateway/server-methods/agent.ts, status: "accepted" is returned before execution.
  • The actual run happens later in src/agents/pi-embedded-runner/run.ts, where it has to acquire both:
    • a per-session lane, and
    • the global subagent lane.

So accepted + createdAt≈startedAt + 0 tokens fits “got queued/registered, never actually reached backend execution”.

Why I don’t think this is just maxConcurrent or MiniMax itself:

  • you already reproduced it with sequential single spawns
  • the main session using the same model still works
#
  • if MiniMax were the direct problem, I’d expect an actual child-run provider error, not repeated accepted → timeout with no token usage

Also, 2026.4.9 is behind a few relevant fixes that landed right after, including:

  • d6bb36730b fix(agents): stabilize subagent lifecycle
  • c146738996 fix: stabilize subagent cleanup retries
  • e777a2b230 fix(process): migrate legacy command-queue singleton missing activeTaskWaiters

My recommendation:

  1. Update first. I’d treat this as a likely runtime bug in 2026.4.9, not a config mistake.
  2. Then run:
    openclaw gateway restart
openclaw tasks audit
openclaw tasks maintenance --apply