How to get claw to collect and respond once to multiple messages sent in succession | Friends of the Crustacean 🦞🤝 | Page 1

hybrid pawn Apr 18, 2026, 2:01 PM

#

and/or use new information sent while it's working/thinking. Version 2026.4.15.
Current queue settings: mode=collect, debounce=1000ms, cap=20, drop=summarize.
Right now it just responds to each message as if it were a completely separate question or request.

nimble sparrowBOT Apr 18, 2026, 2:01 PM

#

quiet streamBOT Apr 18, 2026, 2:01 PM

#

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

nimble sparrowBOT Apr 18, 2026, 2:01 PM

#

copper mangoBOT Apr 18, 2026, 2:03 PM

#

You’re missing the other half of it.

queue.mode: "collect" does not mean “merge a burst of fresh messages into one initial reply”.
It means:

if a run is already active, collect queued messages
then send one followup turn after the current run ends

So in 2026.4.15:

quick burst before run starts → use messages.inbound.debounceMs
messages arriving during an active run → use messages.queue
use new info in the current in-flight run → use steer, not collect

A good setup for “multiple quick Discord messages become one turn” is:

#

{
  messages: {
    inbound: {
      byChannel: {
        discord: 2500,
      },
    },
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
      byChannel: {
        discord: "collect",
      },

#

    },
  },
}

If you want “while it’s thinking, new info should affect the current answer”, switch queue mode to:

/queue steer

or config:

messages: {

#

  queue: {
    byChannel: {
      discord: "steer",
    },
  },
}

So the short version is: messages.inbound is probably the missing piece.
collect is followup coalescing, not initial burst batching.

Docs:

#

If you paste your full messages block, I can sanity check it.

hybrid pawn Apr 18, 2026, 2:08 PM

#

i don't actually have messages.queue at all in my openclaw.json. Assuming collect/1000ms/etc is the default. so i'll try just setting messages.inbound and see

copper mangoBOT Apr 18, 2026, 2:09 PM

#

Yep, that matches the docs, collect / 1000ms / 20 / summarize is the default queue behavior.

So your next test is the right one 👍

Something like:

{
  messages: {
    inbound: {
      byChannel: {
        discord: 2500,
      },
    },
  },
}

#

A couple gotchas:

text-only only: attachments/media flush immediately, they do not debounce
commands bypass inbound debounce
collect still only affects messages that arrive while a run is already active

So:

want one reply for a quick burst → messages.inbound
want new info to alter the current in-flight run → messages.queue.mode: "steer"

Docs:

If it still splits after adding messages.inbound, paste the exact block and I’ll help tune it.

hybrid pawn Apr 18, 2026, 2:09 PM

#

do i need the byChannel? can it be all channels?

copper mangoBOT Apr 18, 2026, 2:10 PM

#

Yep, it can be global.

Use:

{
  messages: {
    inbound: {
      debounceMs: 2500,
    },
  },
}

byChannel is only for overrides, for example if you want Discord at 2500ms but Slack at 1500ms.

So the rule is:

#

messages.inbound.debounceMs = default for all channels
messages.inbound.byChannel.<channel> = override for one channel

Same idea for messages.queue too.

Docs: https://docs.openclaw.ai/concepts/messages

hybrid pawn Apr 18, 2026, 2:14 PM

#

so i think i want steer + inbound debounce tbh, what are some of the other options for queue settings? like what's drop for example

copper mangoBOT Apr 18, 2026, 2:15 PM

#

Yeah, steer + inbound debounce sounds closer to what you want.

Queue settings in short:

mode
- steer: try to inject the new message into the current run
- followup: wait, then do a new turn after current run ends
- collect: merge queued messages into one followup turn
- steer-backlog: steer now and keep it for a followup too, can feel duplicative
- interrupt: abort current run, then run newest message
- queue: old alias for steer
debounceMs
- for queued followups, wait for a quiet period before starting them
- mainly matters for followup, collect, steer-backlog, and steer when it falls back
cap

#

max queued messages per session
drop
- what happens when the queue is full:
  - old: drop oldest queued messages
  - new: drop newest incoming message
  - summarize: drop overflowed messages but inject a short summary of them into the eventual followup prompt

So summarize is basically the safest “don’t totally lose context” option.

If you want a practical config, I’d start with:

{
  messages: {
    inbound: {

#

      debounceMs: 2500,
    },
    queue: {
      mode: "steer",
      cap: 20,
      drop: "summarize",
    },
  },
}

One nuance: with pure steer, cap/drop are more of a fallback safety net than the main behavior.

Docs: https://docs.openclaw.ai/concepts/queue

If you want, I can also suggest a “best UX” config for Discord specifically.

hybrid pawn Apr 18, 2026, 2:22 PM

#

I use telegram as my main

copper mangoBOT Apr 18, 2026, 2:23 PM

#

Ah, for Telegram I’d bias a little higher on inbound debounce, people tend to send thoughts in bursts there.

I’d start with:

{
  messages: {
    inbound: {
      byChannel: {
        telegram: 3000,
      },
    },
    queue: {
      byChannel: {
        telegram: "steer",
      },

#

      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
    },
  },
}

My practical recommendation for Telegram:

inbound: 2500-4000ms feels good
queue: steer if you want “oh wait, also…” messages to affect the current run
drop: summarize is the safest default

If you want a calmer / less jumpy feel, use:

#

queue: { byChannel: { telegram: "collect" } }

instead of steer.

So basically:

more responsive / adaptive → steer
more stable / one clean followup → collect

If you want, I can suggest a “Telegram feels natural” full config with streaming/reply settings too.

hybrid pawn Apr 18, 2026, 2:24 PM

#

so can i have messages.inbound.debouncems 2500 and messages.queue.mode steer and everything else will be default? or do i need to be explicit?

copper mangoBOT Apr 18, 2026, 2:25 PM

#

Yep, minimal is fine, you do not need to spell out the defaults.

This is valid:

{
  messages: {
    inbound: {
      debounceMs: 2500,
    },
    queue: {
      mode: "steer",
    },
  },
}

#

And the omitted queue fields stay at their defaults:

debounceMs: 1000
cap: 20
drop: "summarize"

Tiny correction, the key is debounceMs with a capital M.

If you want this only for Telegram, then do:

{
  messages: {
    inbound: {
      byChannel: {
        telegram: 2500,

#

      },
    },
    queue: {
      byChannel: {
        telegram: "steer",
      },
    },
  },
}

Docs: https://docs.openclaw.ai/gateway/configuration-reference

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

hybrid pawn Apr 18, 2026, 2:26 PM

#

copper mango Yep, minimal is fine, you do **not** need to spell out the defaults. This is va...

what's a good manual test for this

copper mangoBOT Apr 18, 2026, 2:27 PM

#

Yep, I’d do two separate text-only tests in a direct Telegram chat with the bot.

1) Test `messages.inbound.debounceMs`

Send these as 3 separate messages, about 1 second apart:

remember these items
apples
bananas

Then stop typing.

Expected: after ~2.5s of quiet, you get one reply that clearly sees all 3 messages together.
Fail: it answers each message separately.

2) Test `messages.queue.mode: "steer"`

Send a prompt that takes long enough to still be running, for example:

#

make me a detailed 15-step weekend trip plan for tokyo with budget notes

Then, while it’s still thinking/typing, send:

actually make that kyoto, and vegetarian

Expected with steer:

best case: the final answer already reflects Kyoto + vegetarian
possible fallback: if it isn’t streaming / can’t steer live, it may do a followup instead

Important gotchas

use text only, no media
don’t use slash commands for the test
for the steer test, the second message has to arrive before the first run finishes

If you want, I can give you a super obvious pass/fail test script with exact wording for Telegram.

hybrid pawn Apr 18, 2026, 2:30 PM

#

is it normal for gateway restart and "launch agents warm-up" to take minutes. I know i'm on an old laptop but it really feels like forever

copper mangoBOT Apr 18, 2026, 2:31 PM

#

A few seconds is normal. Minutes is not really normal, even on an older laptop.

OpenClaw’s own status text for that state is basically “launch agents can take a few seconds”, so if it’s taking multiple minutes every restart, I’d treat that as a thing to investigate.

What I’d check right away:

openclaw status
openclaw gateway status
openclaw logs --follow

Healthy baseline from the docs is:

Runtime: running
RPC probe: ok

#

If you’re seeing:

Runtime: running
but RPC probe: failed
plus that warm-up message for a long time

then the gateway is up, but something in startup / agent init is dragging.

A few things that can make it slower:

old hardware, sure
local model cold-loads
lots of channels/plugins/agents
network/auth/provider checks hanging a bit
something slightly stuck in startup

But again, multi-minute every time feels slower than it should.

#

If you want, paste:

openclaw status --all

and the first chunk from:

openclaw logs --follow

right after a restart, and I can help spot what it’s waiting on.

Docs:

hybrid pawn Apr 18, 2026, 2:34 PM

#

i'll open a new thread for that later

copper mangoBOT Apr 18, 2026, 2:34 PM

#

Sounds good, separate thread is probably cleaner for that one.

Glad we got the queueing part sorted 👍
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future folks.

hybrid pawn Apr 18, 2026, 2:35 PM

#

quick separate questions: how to remove a model/provider entirely from openclaw including auth profiels and othe artifacts

copper mangoBOT Apr 18, 2026, 2:35 PM

#

Please open a new thread for that one 🙂

This thread is about queueing, and mixing unrelated topics makes Answer Overflow indexing kind of useless later.

In the new thread, include:

openclaw --version
which provider/model you want to remove
whether you want to remove just config, or also auth profiles / cached artifacts

If you’re doing a bunch of cleanup/debugging locally, honestly the fastest path is usually a local coding agent that can inspect your machine:
https://docs.openclaw.ai/help/faq#i-am-stuck-fastest-way-to-get-unstuck

hybrid pawn Apr 18, 2026, 2:36 PM

#

copper mango 1. `make me a detailed 15-step weekend trip plan for tokyo with budget notes` T...

did this, got two fully differen itineraries one after another

copper mangoBOT Apr 18, 2026, 2:37 PM

#

Yep, that means it didn’t actually steer live. It basically behaved like a followup queue.

That lines up with the docs:

steer tries to inject into the current run
if not streaming, it falls back to followup

So on Telegram, I’d try enabling preview streaming and test again:

{
  channels: {
    telegram: {
      streaming: "partial",
    },
  },

#

  messages: {
    inbound: {
      debounceMs: 2500,
    },
    queue: {
      mode: "steer",
    },
  },
}

A couple notes:

for this test, use preview streaming (streaming: "partial")
don’t turn on block streaming too, that changes the behavior
use a longer prompt so there’s actually time to steer

#

If you still get two full answers after that, then honestly steer is probably not the UX you want on your setup, and I’d go with:

inbound.debounceMs
queue.mode: "collect"

That’s less “live adaptive”, but much more predictable.

Docs:

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
That helps Answer Overflow index it for future users.

hybrid pawn Apr 18, 2026, 2:44 PM

#

copper mango Yep, that means it **didn’t actually steer live**. It basically behaved like a f...

still did two different itineraries one after the other. does the second message have to be within the debounce range or specifically afterwards?

copper mangoBOT Apr 18, 2026, 2:45 PM

#

It depends which behavior you’re testing.

If you want inbound debounce

The second message should be sent within the debounce window, before the run starts.

With debounceMs: 2500:

send message 1
send message 2 within ~2.5s
then stop

That should become one turn.

If you want steer

The second message should be sent after the run has started, while it’s still active.

So:

#

send message 1
wait until the bot is clearly typing / preview streaming / actively running
then send message 2

That is not about being inside the debounce window.
It’s about landing while the first run is already in progress.

So the short version is:

within debounce = tests inbound
after run starts = tests steer

If you’re still consistently getting two full itineraries even when sending the second message during active preview/typing, then I’d treat that as “steer isn’t working the way you want on this setup/version” and stick with inbound + collect for reliable behavior.

hybrid pawn Apr 18, 2026, 2:45 PM

#

okay i did exactly that, and it still didn't work. but i've been using collect and it's basically identical behavior...

copper mangoBOT Apr 18, 2026, 2:46 PM

#

Yeah, at that point I’d stop treating it as “you’re testing it wrong.”

If steer and collect are behaving basically the same for you, even when:

Telegram preview streaming is on
the second message is sent while the first run is clearly active

then that sounds like either:

a current limitation in 2026.4.15, or
a bug / docs mismatch

So my honest recommendation is:

for now: use inbound + collect, since that’s at least predictable
for maintainer attention: file a GitHub issue with a minimal repro

#

Please include:

openclaw --version
channel: Telegram
whether it was DM or group/topic
your exact config blocks for messages and channels.telegram
exact repro:
1. send long prompt
2. wait for active preview/typing
3. send correction
4. got two separate itineraries instead of live steering

GitHub issues: https://github.com/openclaw/openclaw/issues

If this fixed the original queueing question, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

hybrid pawn Apr 18, 2026, 2:46 PM

#

can you check to see if other similar github issues already exist?

copper mangoBOT Apr 18, 2026, 2:48 PM

#

Yep, there are a few pretty similar ones already.

Closest matches I found:

#48003, Steer mode does not inject messages mid-turn for main sessions
https://github.com/openclaw/openclaw/issues/48003
This is the closest match to what you’re seeing. The summary is basically: messages.queue.mode: "steer" still queues the message until the current turn completes instead of actually steering it.
#30827, Priority interrupt channel for steering running agents from messaging surfaces
https://github.com/openclaw/openclaw/issues/30827
Telegram-specific angle, incoming Telegram messages get queued until the run finishes, so real-time steer/interrupt is ineffective.
#48814, Pre-send queue check — suppress stale replies when newer messages are pending
https://github.com/openclaw/openclaw/issues/48814
Very relevant to the “I got two itineraries one after another” UX, even if it’s framed as collect.
#10960, Mid-stream message injection (soft steer)

#

https://github.com/openclaw/openclaw/issues/10960
More of a feature request, but it describes the same missing behavior pretty well.

So, short version: yes, this seems like known territory, and #48003 looks especially on point.

If you open a new issue, I’d definitely link #48003 and #48814 and say your repro is on Telegram + 2026.4.15.

#How to get claw to collect and respond once to multiple messages sent in succession

1) Test messages.inbound.debounceMs

2) Test messages.queue.mode: "steer"

Important gotchas

If you want inbound debounce

If you want steer

1) Test `messages.inbound.debounceMs`

2) Test `messages.queue.mode: "steer"`