OpenClaw Typing Indicators: Show Presence Without Breaking Queue Discipline

Typing indicators look like a tiny chat feature. In an AI-agent setup, they are much more than that.

A human typing bubble says, “I saw you, I am working on it.” An agent typing bubble says something subtler: a message was routed, a session run is active or waiting its turn, and the gateway believes this channel can receive a presence signal. That is useful, but only if you tune it honestly.

If typing appears too early, people think the agent is about to answer when it might still be waiting behind another run. If typing appears for silent replies, a group chat can see a “typing…” ghost and then no message. If typing appears too late, users send “?” and “are you there?” followups that create more queue pressure. OpenClaw gives you knobs for this because presence is part of operations, not decoration.

The message path comes first

OpenClaw’s documented message pipeline is: inbound message, routing and bindings, session key, queue if a run is already active, agent run with streaming and tools, then outbound replies shaped by channel limits and chunking.

Typing indicators sit inside that pipeline. They are sent to the chat channel while a run is active, and the command queue docs note that typing indicators can fire immediately on enqueue when supported by the channel. That means a typing bubble does not always mean “the model is currently producing final words.” It can mean “your run is accepted and waiting its lane.”

That distinction is the whole trick. Presence should calm people down, not mislead them.

The two knobs that matter

The typing-indicator docs name two core settings: agents.defaults.typingMode controls when typing starts, and typingIntervalSeconds controls how often the indicator refreshes while the run remains active.

The default refresh cadence is documented as 6 seconds. That cadence is not the start trigger. It is just the keepalive rhythm after typing has begun.

{
  agent: {
    typingMode: "thinking",
    typingIntervalSeconds: 6,
  },
}

The docs also show per-session overrides when a particular conversation needs different behavior:

{
  session: {
    typingMode: "message",
    typingIntervalSeconds: 4,
  },
}

In practice, I would treat global typing defaults like product UX and session overrides like exceptions. If one Slack support channel needs different presence behavior from a private DM, override the session or channel deliberately instead of bending the whole system around one surface.

Choose the right typing mode

typingMode accepts four documented values:

• never — do not show typing indicators.
• instant — start typing as soon as the model loop begins, even if the run later returns only the silent reply token.
• thinking — start typing on the first reasoning delta. This requires reasoningLevel: "stream" for the run.
• message — start typing on the first non-silent text delta and ignore the silent-only NO_REPLY token.

The docs order them from least eager to most eager as never, message, thinking, instant. That ordering is a useful mental model: every step to the right buys perceived responsiveness and risks more “typing with no visible answer.”

Use instant only when early reassurance matters

instant is the most human-feeling setting in direct chat. The user sends a message, and the assistant immediately appears present. For DMs, customer-support style chats, or hands-on operational work, that can be worth it.

But the docs are explicit: instant can fire even if the run later returns the silent token. That is not a bug. It is the tradeoff you asked for. In a group channel where the agent often reads context and intentionally says nothing, instant can create noisy phantom presence.

My recommendation: use instant for direct conversations where silence is rare and reassurance matters. Avoid it in mention-light group rooms where NO_REPLY is normal.

Use message when silence should stay silent

message mode starts only on the first non-silent text delta. The docs call out that it will not show typing for silent-only replies when the payload is the exact silent token, matched case-insensitively as NO_REPLY or no_reply.

That makes message the cleanest choice for group channels where the agent is expected to monitor, triage, and sometimes stay quiet. It reduces “typing…” events that end in no visible message.

The downside is obvious: if the model thinks for a while, calls tools, or waits behind the session queue before emitting user-visible text, people may not see presence right away. If your team interprets silence as failure, combine message with good progress previews or explicit long-work updates rather than making typing lie.

If your agent already works but feels awkward in real chats, this is exactly the layer ClawKit helps with: practical defaults for presence, queues, replies, and escalation. Get ClawKit and copy the operating playbook instead of tuning by vibes.

Use thinking only if reasoning streams

thinking mode is appealing because it starts after the model begins producing reasoning, not merely because a run exists. It can feel more honest than instant and earlier than message.

There is one hard requirement: the run must stream reasoning with reasoningLevel: "stream". If the model does not emit reasoning deltas, typing will not start. Do not choose thinking because it sounds philosophically correct. Choose it when your runtime and reasoning settings actually support the signal.

Also remember the messages docs: reasoning content still counts toward token usage when produced by the model. Typing mode does not make reasoning free. It only decides whether reasoning deltas can trigger presence.

Queue discipline keeps typing believable

OpenClaw serializes inbound auto-reply runs through a lane-aware FIFO queue. The queue docs describe per-session lanes so only one active run touches a session at a time, plus a global lane that caps overall parallelism through agents.defaults.maxConcurrent. Unconfigured lanes default to concurrency 1, while the docs list main and subagent defaults separately.

This is why typing indicators must be understood as a gateway signal, not a model-token signal. If a user sends a message while the session is already busy, OpenClaw can queue, steer, collect, follow up, or interrupt depending on the configured queue mode. Presence may say “accepted,” while queue discipline says “not colliding with the current run.”

The current command queue docs list these built-in defaults when unset: mode: "steer", debounceMs: 500, cap: 20, and drop: "summarize". The modes matter:

• steer injects messages into the active runtime when steering is available, otherwise it falls back to a followup queue entry.
• followup waits for the current run to finish, then starts a later agent turn.
• collect coalesces queued messages into one followup turn after the quiet window, while preserving routing when messages target different channels or threads.
• steer-backlog steers now and also preserves the same message for a later followup, which can look duplicate on streaming surfaces.
• interrupt aborts the active run for that session and runs the newest message.

Presence is much easier to trust when the queue mode matches the social contract of the room. In a high-chatter Discord, collect may be calmer. In a pair-programming DM, steer may feel more responsive. In an incident room, interrupt might be justified, but it should be a deliberate operational choice.

Do not confuse typing with streaming

Typing indicators, preview streaming, block streaming, chunking, and progress drafts are related, but they are not the same feature.

Typing says the agent is active. Preview streaming can edit a temporary draft or progress message while work continues. Block streaming can send coarse chunks as normal channel messages. Chunking keeps long final replies under platform limits without splitting code fences badly. If you want the delivery layer, read the companion post on OpenClaw streaming and chunking.

The mistake is trying to make typing solve every UX problem. If a task runs for minutes, typing bubbles are not enough. Use progress drafts, long-work updates, or explicit queue behavior. If delivery can fail, tune retry behavior separately; the retry policy guide covers that layer.

My default setup

For most production agents, I would start with this rule set:

1. Use instant in direct chats where users expect immediate acknowledgment.
2. Use message in group channels where silent monitoring is common.
3. Use thinking only after confirming reasoning deltas actually stream for that runtime.
4. Keep typingIntervalSeconds near the documented default unless a channel visibly drops indicators too soon.
5. Tune queue mode before blaming typing. Bad queue semantics make every presence mode feel wrong.

The goal is not to make the agent seem busier. The goal is to make its presence truthful. A good OpenClaw agent should feel responsive without pretending, quiet without seeming dead, and disciplined enough that two messages do not turn into two colliding runs.

That is what typing indicators are really for: not decoration, but trust.

Want the complete guide? Get ClawKit — $9.99