I’m using clawdbot with z.ai glm 4.7 over WhatsApp.
However the bot only answers one message at a time. I wonder if we can make it more parallel. It locks on a reply and only replies the other replies after the previous reply is replied.
#Make the bot more parallel
cedar compass
unborn canopyBOT
Yeah, that's by design actually — Clawdbot serializes messages per session to keep conversation context coherent. If two messages raced through simultaneously, you'd get weird issues where responses reference the wrong thing or conflict with each other.
That said, there are a few options depending on what you're trying to solve:
1. Multiple sessions — If different users are messaging, they should each get their own session (different phone numbers → different sessions). Those run in parallel already.
2. sessions_spawn — For long-running tasks, the bot can spin up a sub-agent that works in the background while the main session stays responsive. The sub-agent reports back when done.
3. Quick-ack pattern — Some people configure the bot to immediately acknowledge "got it, working on that..." then do the actual work, so it feels more responsive even though it's still serial.
What's your actual use case? Is it:
- One user sending multiple messages quickly?
- Multiple users sharing one WhatsApp number?
- Long tasks blocking quick questions?
The right fix depends on what's causing the pain 🤔
cedar compass
One user sending messages quickly and long tasks blocking quick questions
unborn canopyBOT
Ah yeah, that's the classic case. Two things that help:
For long tasks → sub-agents
The bot can spawn background workers for heavy stuff. So if you ask "analyze this 500-page PDF" it can go:
- Main session: "On it, I'll ping you when done" (instant)
- Sub-agent: crunches in background
- Sub-agent: announces result when finished
Main session stays free for quick questions in the meantime. This is what sessions_spawn is for.
For rapid-fire messages → batching
There's a messageWaitMs config option that makes the bot wait a beat before responding, in case more messages are incoming. If you send 3 messages in 2 seconds, it processes them as one batch instead of three serial requests.
messageWaitMs: 2000 # wait 2s to collect messages
Trade-off: adds latency to single messages. But if you're the type to send:
"hey"
"can you check"
"the logs from yesterday"
...batching is a big win.
What you can't do (yet): true parallel processing of independent messages in the same session. The session state (memory, context window) is shared, so serialization prevents corruption.
Would either of those help your workflow? The sub-agent pattern is the more robust fix if your long tasks are genuinely long.
cedar compass
How do I configure trigger and control the subagents? Is clawd going to be smart enough to do it? I don’t think so
unborn canopyBOT
Fair skepticism lol. Honest answer:
Will it auto-spawn? Sometimes.
The model can decide "this looks heavy, I'll background it" — but it's not reliable. It might spawn for obvious stuff like "analyze this 100MB log file" but miss less obvious cases.
Explicit triggers work better:
Just tell it what you want:
- "do this in the background and ping me when done"
- "spawn a sub-agent for this"
- "don't block on this, work async"
The bot understands those and will use sessions_spawn.
You can also bake it into AGENTS.md:
## Task Handling
For tasks involving: file analysis, web scraping, code generation
over 100 lines, or anything you estimate takes >30s — spawn a
sub-agent instead of blocking the main session.
That gives the model a heuristic to follow. Still not perfect but better than hoping.
Checking on sub-agents:
- "what sub-agents are running?" → lists them
- "check on the PDF analysis task" → fetches status/history
- They auto-announce results when done