OpenClaw Streaming and Chunking: Make Long Replies Readable Across Channels

Long AI-agent replies are not just a writing problem. They are an operations problem.

If an agent answers with one giant wall of text, people skim badly, miss the useful part, and start treating the agent as noisy. If it sends every tiny model fragment as a separate message, it becomes even worse: the channel turns into a slot machine of half-sent thoughts. OpenClaw streaming and chunking exist to land in the useful middle.

The documented model is deliberately practical. OpenClaw does not stream true token deltas into normal channel messages today. Instead, it has two layers: block streaming, which sends completed chunks as normal channel messages, and preview streaming, which updates a temporary draft/preview message while the run is still generating. Those sound similar, but they solve different problems.

The message path matters

OpenClaw routes inbound messages through a gateway-owned pipeline: inbound message, routing and bindings, session key, queue if a run is already active, agent run with tools and streaming, then outbound replies shaped by channel limits and chunking.

That means streaming is not a cosmetic afterthought bolted onto a chat app. It sits inside the same machinery that handles sessions, queues, tool calls, reasoning visibility, reply threading, and channel-specific delivery rules. If you are running an agent across Slack, Discord, Telegram, WhatsApp, Matrix, Mattermost, or Microsoft Teams, that distinction matters. A reply is not just text. It is text traveling through a transport with limits, edits, retries, previews, and human expectations.

There are three configuration zones to keep straight:

• messages.* controls prefixes, group behavior, inbound batching, and queueing.
• agents.defaults.* controls block streaming and chunking defaults.
• Channel overrides such as channels.telegram.*, channels.discord.*, or channels.slack.* control channel caps, preview modes, and per-account behavior.

My rule of thumb: tune message flow first, then tune reply shape. If the queue is wrong, beautiful streaming will still feel chaotic.

Block streaming is normal messages, not a live draft

Block streaming emits coarse chunks as the assistant writes. The docs describe a chunker sitting between model stream events and channel sends. With blockStreamingBreak set to text_end, chunks can flush as text blocks finish. With message_end, OpenClaw waits until the assistant message is complete, then flushes the buffered output. Even at message_end, a long reply can still become multiple messages if it exceeds configured chunk limits.

The important knobs live under agents.defaults:

{
  agents: {
    defaults: {
      blockStreamingDefault: "on",
      blockStreamingBreak: "text_end",
      blockStreamingChunk: {
        minChars: 900,
        maxChars: 2400,
        breakPreference: "paragraph"
      },
      blockStreamingCoalesce: {
        minChars: 1200,
        maxChars: 2800,
        idleMs: 1200
      }
    }
  }
}

Do not miss the location: the blockStreaming* defaults live under agents.defaults, not at the root of the config. Channel overrides can force block streaming on or off per channel or per account. The docs also call out that block streaming is off unless a channel explicitly enables it with a channel-level blockStreaming setting; non-Telegram channels need that explicit channel opt-in.

For an operator, this is the “multi-bubble reply” mode. It is useful when the content itself should arrive as separate durable messages: a long explanation, a step-by-step runbook, or a generated report that may exceed one platform’s text limit.

The chunker is there to protect readability

OpenClaw chunking is not just “split every 2,000 characters.” The documented chunker uses a low/high bound model. It waits until the buffer reaches minChars unless forced, prefers splitting before maxChars, and then chooses the least ugly boundary it can find: paragraph, newline, sentence, whitespace, then hard break.

That ordering is exactly what you want for agent replies. Paragraphs should stay together. Sentences should not be amputated unless the channel forces it. And code is special: OpenClaw avoids splitting inside fenced code blocks, and when a forced split at maxChars is unavoidable, it closes and reopens the fence so Markdown stays valid.

Channel caps still win. maxChars is clamped to the channel textChunkLimit. Channels can also use chunkMode: length by default, or newline to split on blank-line paragraph boundaries before length chunking. Discord also has channels.discord.maxLinesPerMessage, with a documented default of 17, to avoid tall replies getting clipped in the UI.

If your agent writes useful answers but people still ignore them, reply shape is probably part of the bug. Get ClawKit and copy the operator playbook I use to make agents readable, safe, and actually manageable.

Coalescing prevents single-line spam

When block streaming is enabled, OpenClaw can coalesce consecutive chunks before sending them. Coalescing waits for an idle gap, respects maxChars, and uses minChars to avoid tiny fragments. The final flush still sends what remains.

This is a small feature with a very human payoff. Without coalescing, “streaming” can become an excuse to interrupt the room constantly. With coalescing, the agent can feel alive without turning every sentence into a separate notification.

The docs also note a channel-aware default: coalesce minChars is bumped to 1500 for Signal, Slack, and Discord unless overridden. That is the right bias. Fast-moving team channels need fewer, better chunks.

Human delay is for block replies only

OpenClaw can add randomized pauses between block replies after the first block. The documented key is agents.defaults.humanDelay, with per-agent overrides via agents.list[].humanDelay. Modes are off, natural at 800–2500ms, or custom with minMs and maxMs.

I would not overdo this. Delay is not personality. It is pacing. Use it when multi-bubble answers feel too mechanical, but remember that it applies only to block replies, not final replies or tool summaries.

Preview streaming is the “working draft” layer

Preview streaming is separate from block streaming. Instead of sending chunks as normal messages, it updates a temporary preview message while the run is still in progress. The canonical channel setting is channels.<channel>.streaming, and current docs describe mode values under streaming.mode: off, partial, block, and progress.

• partial keeps one preview updated with the latest text.
• block updates the preview in chunked or appended steps.
• progress shows a status/progress draft during generation, then sends the final answer at completion.

Telegram and Discord use send/edit preview messages. Slack can use native streaming for partial mode when available, or draft preview posts and edits in cases like top-level DMs without a reply thread. Mattermost folds thinking, tool activity, and partial text into a single draft preview post. Matrix can finalize a draft preview in place when the final text can reuse it. Microsoft Teams uses native progress streaming in personal chats.

The operational lesson is simple: use preview streaming when you want the room to know the agent is working, but you do not want every intermediate fragment to become a permanent channel message.

Progress drafts are usually the best default for long work

For long tool-heavy turns, I prefer progress drafts over raw partial text. They communicate status without making the model’s unfinished answer feel like published output.

OpenClaw preview streaming can include tool-progress updates such as short “searching the web,” “reading file,” or “calling tool” style lines. The docs list Discord, Slack, Telegram, and Matrix as surfaces that stream tool-progress into live preview edits by default when preview streaming is active. Mattermost already folds tool activity into its draft preview post, and Microsoft Teams uses its native progress stream in personal chats.

If you want progress but not raw command text, the docs show policy knobs under streaming.preview or streaming.progress:

{
  "channels": {
    "telegram": {
      "streaming": {
        "mode": "progress",
        "progress": {
          "toolProgress": true,
          "commandText": "status"
        }
      }
    }
  }
}

That shape is available for compact progress channels such as Discord, Matrix, Microsoft Teams, Mattermost, Slack draft previews, and Telegram. The point is not to hide work. The point is to show the right abstraction: “reading file” is helpful; dumping every command line into a public channel usually is not.

Reasoning visibility and usage still count

Streaming can make an agent feel more transparent, but transparency is not free. OpenClaw can expose or hide model reasoning with /reasoning on, /reasoning off, or /reasoning stream. The messages docs are clear that reasoning content still counts toward token usage when the model produces it. Telegram can stream reasoning into a transient draft bubble, while /reasoning on is the path for persistent reasoning output.

For cost visibility, use /status, /usage off|tokens|full, or /usage cost. The token-use docs also remind operators that OpenClaw tracks tokens, not characters; most OpenAI-style English text averages around four characters per token, but the real accounting is model-specific.

This matters because streaming settings can change delivery shape without changing the underlying model work. A neatly streamed reply may still be expensive if it carries a huge system prompt, long conversation history, tool results, images, compaction summaries, or provider wrappers. Use /context list and /context detail when reply size and context growth start to matter.

My recommended setup

For most OpenClaw operators, I would start conservative:

1. Use preview progress mode in busy team channels so people see work without receiving draft fragments as permanent messages.
2. Enable block streaming only for channels where multi-message replies are actually useful.
3. Set chunk break preference to paragraph unless you have a reason not to.
4. Turn on coalescing before you complain that streaming is too noisy.
5. Keep raw command text out of public progress drafts unless the channel is explicitly technical and trusted.

Streaming is not about making the agent look busy. Good streaming makes long replies readable, makes long runs feel alive, and keeps channel history clean enough that humans can still use it. That is the bar. Anything else is notification spam with better branding.

Want the complete guide? Get ClawKit — $9.99