#slowness after v2026.2.13

1 messages · Page 1 of 1 (latest)

wispy bough
#

hey guys any have felt molty more slower after 2.13 update?

halcyon treeBOT
#

I haven’t seen a general “2.13 is slower” pattern — when it feels slower after an update it’s usually one of these:

  • Model/provider latency (Anthropic/OpenAI/etc having a slow day, rate limiting, queueing)
  • Gateway/agent now using a different model than before (defaults/config change, fallback behavior)
  • Tool slowness (browser automation, filesystem, node, network/DNS) vs “thinking” time
  • Version mismatch (CLI updated but the running gateway is still older / restarted weirdly)

If you want, paste these and we can pinpoint it quickly:

  1. openclaw --version
  2. “Slow” = first token slow or tools slow (e.g. browser actions taking ages)?
  3. What provider/model are you using for the main agent?
  4. Where is it running (local / VPS / Raspberry Pi), and is CPU/RAM pegged when it’s “slow”?

Quick thing to try if you haven’t: restart the gateway (a stale process after upgrading can behave oddly), then re-test with the same prompt and share rough timings (e.g. “used to answer in 5s, now 25–40s”).

wispy bough
#

hey there,

1.[openclaw] 2026.2.14 âś…
2. particularly it would forget to finalize a task (i.e after spawning some subagents it will need a follow up for final summary)
3. opus 4.6
4. EC2 m7i-flex.large

  • 2 vCPUs
  • 8 GB RAM (1 GB used, 6.2 GB available)
  • 49 GB disk (13 GB used, 36 GB free — 26%)

he updated today and restarted the gateway

halcyon treeBOT
#

That symptom lines up with how sub-agents work right now: sessions_spawn is non-blocking, so the main agent often “moves on” and you end up needing a follow-up message to trigger the final consolidation.

Two quick clarifiers to see if this is expected behavior vs a Discord delivery bug:

  1. Do you actually see the sub-agent result announcements show up in the chat/thread reliably?
  • If yes → what’s missing is just the final combined summary, which usually requires you to ask once more (“ok summarize everything”).
  • If no / they show up in the wrong place (parent channel vs thread) → that’s a routing/delivery issue we should debug.
  1. When it “forgets to finalize”, is the main agent returning immediately after spawning (e.g. “I’ll wait”) and then never posting again unless you type something?

Best next step: reproduce once with logs open and paste the relevant excerpt (redact tokens):

openclaw logs --follow

Then run a prompt that spawns 1–2 subagents and wait for them to finish.

#

Docs for reference (the key bit is “non-blocking”): https://docs.openclaw.ai/tools/subagents

If you confirm the sub-agent announcements are arriving but you want “auto final summary after all subagents finish”, that may be a feature request (since the gateway generally won’t auto-trigger the main agent on its own messages to avoid loops).

wispy bough
#

ok thanks dude

QA report is in. Here's the summary:

Root cause: Gateway timeouts killing announcements

Sub-agents finish their work fine — the problem is the 60-second gateway timeout on the announcement delivery. Found multiple failures in the logs:

  • Feb 15 02:20 — announce failed (timeout 60s)
  • Feb 14 18:52 — announce failed (timeout 60s)
  • Feb 13 12:51 — announce queue drain failed (timeout 60s)

The test agent just now worked because conditions were clean. But under load (billing errors, concurrent sessions, WhatsApp reconnects), the announcement handoff times out and gets silently dropped.

So it's option 1 — sub-agents complete but announcements get lost. Not a Discord-specific thing, it's a gateway-level issue.

Fixes (in priority order):

  1. Gateway timeout increase for announcements (60s → 120s+)
  2. Retry logic with backoff for failed announces
  3. Better session state persistence (right now completed sub-agents vanish)

This could be worth a second issue on openclaw/openclaw — the announce timeout is too aggressive and there's no retry.

Will work on a feature PR