Discord is the BoxminingAI team's always-on team surface. Telegram is the on-the-go mobile surface — the one you check from the train, the one you message while the kids are at swimming. The headline behaviour change in this article is streaming replies: pre-OpenClaw 3.2 you sent a Telegram message and waited 30 seconds in silence before a wall of text arrived. The 3.2 update replaced that silence with token-by-token streaming, which is the difference between Telegram feeling like an old-school pager and feeling like a chat. This article walks through the bot build (BotFather, token, pairing codes), the streaming-vs-silence default, and the cross-platform reality (iOS / Android / Desktop / Web all use the same bot).

What you'll learn

  • Build the Telegram bot via BotFather (/newbot), copy the token once, paste into openclaw configure. The bot username must end in bot and be unique across all of Telegram.
  • Pair your Telegram account with openclaw tui — the bot will send a pairing code on first message, you paste it into the TUI to authorise.
  • The 30-second silence before a Telegram reply was the pre-3.2 default. Streaming shipped in 3.2 — watch the OpenClaw 3.2 update video for the exact changelog entry.
  • Streaming may look "chunky" rather than character-by-character depending on the model (Opus vs Sonnet vs cheaper backends) and network latency. That's normal.
  • Telegram works on iOS, Android, Desktop, and Web from the same bot. The pairing is per-account, not per-device.
  • Why Telegram's bot API is more permissive than Discord's — long polling vs WebSocket — and what that means for the gateway's resource footprint.
  • The pairing-code mechanic: a per-session, time-limited token that proves you're the one initiating the contact, not a man-in-the-middle.
  • How the 3.2 streaming change interacts with model choice: Opus streams smoothly, Minimax / Kimi stream in chunks, and the difference is visible in the chat UX.
  • The cross-platform reality: Telegram is the only major chat surface where the bot account and the personal account can co-exist on the same phone app.

Why Telegram: the mobile case in detail

Telegram occupies a different niche than Discord in the OpenClaw stack. Discord is the always-on team surface; Telegram is the on-the-go mobile surface. The argument for Telegram as the mobile pick is similar in shape to the Discord argument — Telegram's specific affordances match what an OpenClaw agent needs for "phone access."

One bot, every device. A Telegram bot is reachable from iOS, Android, Desktop, and Web clients with the same account. You don't have to maintain separate bot tokens per platform. The pairing is per-account (you pair your Telegram user ID with the OpenClaw install), so once paired, every Telegram client you log into can talk to the same bot. Discord has similar reach, but the bot install is per-server, and the mobile UX is heavier (more taps to navigate to the right channel).

Long polling vs WebSocket. Telegram's Bot API uses long polling — the bot periodically asks Telegram "any new messages?" — rather than the persistent WebSocket that Discord uses. For a personal OpenClaw install on a $3 VPS, this is a meaningful difference: long polling uses less RAM, less bandwidth, and survives network blips more gracefully. Discord's WebSocket drops the connection if it goes idle for too long; Telegram's long polling just resumes from the last polled message.

Inline keyboards and callback queries. Telegram's bot API has richer inline-interaction primitives than Discord's slash commands. A Telegram bot can send a message with buttons; the user clicks a button; the bot receives a callback with the user's choice. OpenClaw's pairing flow uses this for "approve this pairing code" interactions. Discord has buttons too, but the bot-author ergonomics are heavier.

Streaming-friendly. Telegram's sendMessage API supports a link_preview_options flag and (via editMessageText) lets the bot update a message as it streams. Pre-3.2, OpenClaw didn't use this — it buffered the full reply and sent it as one wall of text. Post-3.2, the bot edits the same message in place as tokens come in. This is the user-visible streaming behaviour the channel calls out.

Group chat vs DM. Telegram bots can operate in groups and channels as well as DMs. OpenClaw pairs per-user regardless of where the message comes from — a DM from a paired user and a mention in a group both go to the same agent instance. Discord's per-channel scope is more restrictive; the agent only sees messages from the channels it's bound to. For a personal mobile surface, the broader Telegram scope is more natural.

The economic case. Like Discord, Telegram is free for personal bots. The bot API is rate-limited but the limits are generous for low-volume personal use (30 messages per second across all bots, with burst tolerance). Streaming replies use the same editMessageText rate limit — well within bounds for any single bot.

The combination — cross-device pairing, long-polling efficiency, inline interactivity, streaming-friendly API, free tier — is what makes Telegram the right mobile surface. The BoxminingAI team's choice of Telegram isn't arbitrary; it's the surface where the phone-native UX maps onto an OpenClaw agent.

Video 1: OpenClaw Telegram Setup

This is the canonical Telegram setup. The file 35 duplicate is dropped — this is the one to use.

Step 1: Create the Telegram bot with BotFather

  1. Open Telegram and search for @BotFather (the official bot with the verified checkmark ✓). Confirm the username is exactly @BotFather — there are imposters.

  2. Start a conversation with BotFather.

  3. Send the command:

    /newbot

  4. BotFather asks for a display name. Enter something like "My OpenClaw Agent" or "BoxMining AI Bot." This is what users see.

  5. BotFather asks for a username. Rules:

    • Must end in bot (e.g. boxmining_ai_bot, my_openclaw_bot).
    • Must be unique across all Telegram.
    • Cannot contain spaces.

  6. BotFather responds with the bot token:

    Done! Congratulations on your new bot. You will find it at t.me/your_bot_name.

Use this token to access the HTTP API:
1234567890:ABCdefGHIjklMNOpqrsTUVwxyz1234567890

Keep your token secure and store it safely, it can be used by anyone to control your bot.

    Copy this token immediately. You won't see it again. Treat it like a private key.

Step 2: Configure OpenClaw

The recommended method is openclaw configure from the terminal (the same reliability argument as Discord — the agent path is a coin flip).

  1. SSH into your OpenClaw installation.

  2. Confirm version:

    openclaw --version

    You need 3.2 or later for streaming. Update if needed:

    openclaw update

  3. Run:

    openclaw configure

  4. Select Local → Channels → Configure → Telegram.

  5. Paste the bot token from BotFather.

  6. Configure pairing:

    • Allow DM pairing: Yes (recommended for personal use).
    • Pairing policy: Pick one — Open (anyone), Pairing codes (recommended), Allowlist (most secure).

  7. Select Finished → Continue.

Step 3: Restart the gateway

openclaw gateway restart

Wait for confirmation.

Step 4: Pair your Telegram account

  1. Open Telegram and find your bot. Either search for the username or click the link BotFather sent you.

  2. Click Start to begin the conversation.

  3. Send a message:

    hi

  4. The bot responds with a pairing code:

    To pair this Telegram account with OpenClaw, please run:
openclaw tui
And enter pairing code: ABC123

  5. In your terminal (the same VPS running OpenClaw), run:

    openclaw tui

  6. Paste the pairing code when prompted.

  7. The bot confirms:

    ✓ Paired successfully! You can now interact with your OpenClaw agent.

Step 5: Test the integration

Send a message:

Hello! Can you introduce yourself?

On OpenClaw 3.2+ with streaming on, you should see the response streaming in token-by-token. Pre-3.2 or with streaming off, you wait ~30 seconds and then see a wall of text.

The 30-second silence (the §4.4 anchor)

Before OpenClaw 3.2, the Telegram integration had a single user-facing problem that made the whole surface feel broken: you send a message, you wait ~30 seconds, you get a wall of text. No typing indicator, no progress, no way to interrupt. For a chat surface that's the difference between "feels like a chat" and "feels like an email server."

The 30-second number isn't arbitrary — it's the time it takes for a typical LLM response to fully generate, buffer through OpenClaw's output queue, and ship as a single sendMessage call to Telegram's Bot API. Three latency sources stacked:

  1. LLM generation time. A typical 500-token response from a fast model takes 5–15 seconds; from a slow model, 20–30 seconds. Streaming doesn't change the generation time; it changes when the user starts seeing tokens.
  2. OpenClaw's output queue. Pre-3.2, OpenClaw buffered the entire response before sending. The buffer added latency proportional to the response length — a 2,000-token response sat in the queue for ~30–60 seconds while the LLM finished generating.
  3. Telegram's sendMessage round-trip. Each sendMessage call is a single HTTPS POST to Telegram. The round-trip from VPS → Telegram → user's phone is ~200–500ms. Pre-3.2 this happened once, with the full response; post-3.2 it happens many times, with chunks.

The 3.2 fix is to use Telegram's editMessageText API in place of sendMessage for streaming. Instead of buffering the full response and sending it once, the bot sends an empty placeholder message immediately, then edits it in place as tokens arrive. The user sees the placeholder ("typing...") for ~1 second, then watches the response appear chunk-by-chunk.

OpenClaw 3.2 added streaming Telegram replies. The change is small on paper and large in feel:

  • Pre-3.2: You send a prompt. You see the Telegram "typing..." indicator for 30 seconds. Then a wall of text appears.
  • Post-3.2 (with streaming on): You send a prompt. You see the response appear chunk-by-chunk. You can interrupt mid-stream ("stop doing this") instead of waiting for a finished reply.

For long responses (stories, articles, code), streaming is the only mode that makes sense. For short queries, the difference is less visible. The host's framing: Telegram streaming works best for longer responses; for short queries you might not notice it.

Configuring streaming

If streaming isn't working as expected, you can configure it three ways:

Via the agent:

Hey, can you change the Telegram streaming setting from partial to on?

Via the TUI:

openclaw configure
# Channels → Configure → Telegram → Streaming → On

The three modes:

  • On — full streaming, every chunk visible.
  • Partial — default; some chunks visible, some buffered.
  • Off — pre-3.2 behaviour; 30-second silence then a wall of text.

Video 2: NEW OpenClaw 3.2 Update is a HUGE Improvement!

The 3.2 update is the release that shipped Telegram streaming. The video is short because the changelog is short, but the streaming entry is the load-bearing one for this article.

Other 3.2 changes worth knowing:

  • ACP enabled by default — Agent Communication Protocol is on out of the box, which makes the OpenClaw ↔ Claude Code / sub-agents loop more reliable.
  • Native PDF parsing for Google and Anthropic files — download a Google Scholar paper as a PDF and have the agent run a full analysis, skipping the old "paste text into a markdown file" workflow.
  • The doctor command — improved in 3.2 to flag missing dependencies. Run it after every upgrade from 3.2 forward.

Video 3: NEW OpenClaw Update is HUGE!

The v2.26 update is referenced here for two reasons. First, it's the release that shipped the external secrets management workflow that §4.4's .env advice depends on — keeping the bot token out of openclaw.json and in .env is the safer pattern, and v2.26 made it a first-class concept. Second, the v2.26 release fixed four cron bugs (double-fire, parallel-block, manual-trigger hang, schedule drift) and added config get redaction for sensitive values, both of which matter once you have a Telegram bot running scheduled jobs.

The headline of v2.26 for this article is the secrets management. Before v2.26, the bot token sat in the OpenClaw config file in plain text. The four commands audit, configure, apply, reload (hot reload, no gateway restart) are the v2.26 path. If you ran Telegram pre-v2.26 and the token leaked in a screenshot or a log scrape, the fix is to rotate via @BotFather → /revoke → /token, then store the new token in ~/.openclaw/.env, then restart the gateway.

Configuration patterns

Personal use (recommended)

Pairing Policy: Pairing codes
Allow DM: Yes
Streaming: Enabled

Use case: personal agent access from mobile device.

Team use

Pairing Policy: Allowlist
Allow DM: Yes
Streaming: Enabled
Allowlist: @user1, @user2, @user3

Use case: team members need access to shared agent.

Public bot (not recommended for OpenClaw)

Pairing Policy: Open
Allow DM: Yes
Streaming: Enabled

Only for demo purposes. Anyone can access your agent.

Token security

If your bot token is exposed:

  1. Revoke the old token. Message @BotFather, send /revoke, select your bot, confirm revocation.
  2. Generate a new token. Message @BotFather, send /token, select your bot, copy new token.
  3. Update OpenClaw. Edit ~/.openclaw/.env and set TELEGRAM_BOT_TOKEN=<new token>.
  4. Restart the gateway. openclaw gateway restart.
  5. Re-pair all users with new pairing codes (the old pairing is invalidated by the token rotation).

Streaming troubleshooting

Symptom Cause Fix
30-second silence then wall of text Streaming is off or you're on pre-3.2 Upgrade to 3.2+, set streaming to "On"
"Chunky" streaming Cheaper model or network latency Try with Opus or Sonnet for smoother streaming
Streaming stops mid-response Token limit hit mid-response Lower the model's max-tokens or shorten the prompt
Bot says "typing..." forever Gateway not paired or pairing expired Check openclaw tui for pairing status

The streaming ↔ model tradeoff

The model you pick determines how the streaming feels, even with the same 3.2+ code path. The difference comes from how often the model emits tokens:

  • Opus (Anthropic) — emits tokens at a high rate, ~50–80 tokens/second. Streaming appears as a smooth, character-by-character flow. The user sees the response "type out" in front of them.
  • Sonnet (Anthropic) — similar to Opus, slightly faster token rate. Streaming feels equally smooth.
  • Minimax / Kimi (Chinese backends) — lower token rate, ~20–40 tokens/second, and emit in larger chunks. Streaming appears as a paragraph appearing every 1–2 seconds rather than a character-by-character flow. Still feels like streaming, but "chunkier."
  • Local models (Ollama, etc.) — depends on hardware. A fast GPU can match Opus; a CPU-only inference might be slower than the chunky backends.

The chunkiness doesn't affect correctness — the user gets the same response either way — but it affects the feel. A user reading a long response on their phone will notice whether the response is typing out smoothly or appearing in paragraphs.

The host's recommendation, from the source videos: pair the model with the use case. Opus for "I want the smoothest experience and the highest quality," Sonnet for "I want good quality at a lower price," Minimax for "I want cheap and good-enough." The streaming UX degrades predictably with price, and the user can pick the trade-off.

A practical gotcha: if you switch backends mid-conversation, the streaming cadence changes immediately. The user will see "smooth streaming" become "chunky streaming" the next time the agent responds. Mention the backend switch in chat so the user knows what changed.

Pairing-code lifecycle

The pairing code that BotFather-equivalent (the OpenClaw pairing flow) sends on first message is a per-session, time-limited token:

  • The code is generated by OpenClaw when it receives a message from an unpaired Telegram user.
  • The code is a random 6-character string (e.g. ABC123).
  • The code expires after ~10 minutes.
  • The code is single-use — once entered into openclaw tui, it's invalidated.
  • After pairing, the Telegram user ID is recorded in OpenClaw's allowlist. Future messages from that user don't trigger a new pairing code.

If the pairing code expires before you enter it, send hi again to get a fresh code. The old code is invalidated by the new request. Pairing codes are case-sensitive — copy-paste rather than type.

Try it yourself

The hands-on goal: a Telegram bot that streams replies, paired to your Telegram account, working on iOS / Android / Desktop / Web.

  1. Confirm version. openclaw --version. You need 3.2 or later for streaming.
  2. Create the bot. Open Telegram, message @BotFather, send /newbot, pick a display name and a username ending in bot. Copy the token.
  3. Configure OpenClaw. openclaw configure → Local → Channels → Configure → Telegram → paste token → set pairing policy (Pairing codes recommended) → Finished → Continue.
  4. Restart the gateway. openclaw gateway restart.
  5. Pair your account. In Telegram, find your bot, click Start, send hi. Copy the pairing code. In terminal, run openclaw tui, paste the code.
  6. Test streaming. Send Tell me a short story and watch the response stream in. If it's silent for 30 seconds then a wall of text, streaming is off — set it to On via the TUI or ask the agent.
  7. Test from mobile. Install Telegram on your phone, log in, find the bot, send a message. Confirm the bot responds the same way as on desktop.
  8. Rotate the token (test). Send /revoke to @BotFather, generate a new token with /token, update ~/.openclaw/.env, restart the gateway, re-pair your account. Verify the bot still works.
  9. Check doctor. openclaw doctor. Should report no missing dependencies. If it does, address them before going further.
  10. Compare streaming across models. Send the same long prompt three times — once with Opus, once with Sonnet, once with Minimax. Watch how the chunks arrive. Opus is smoothest; Minimax is chunkiest. Pick the model whose streaming cadence matches your preference.
  11. Test the cron + timezone pinning. Set up a cron job to send a message at a specific local time. Verify it fires at the right hour. If it fires at UTC, pin the timezone explicitly via TZ=Asia/<your_city> in the cron job's environment.
  12. Test group-chat behaviour. Add the bot to a Telegram group, mention it with @botname hello. The bot should respond. Remove from the group — the bot should stop responding. This is the basic group-scope test.
  13. Audit secrets. cat ~/.openclaw/.env. Confirm the Telegram bot token is there, not in openclaw.json or in chat memory. If it's in either of those, move it.
  14. Time-box the streaming test. Send a 10-message sequence and watch the streaming behaviour. Confirm there's no "30-second silence then wall of text" failure. If there is, the streaming flag is off or you're on pre-3.2.

Common pitfalls

  • Running Telegram on OpenClaw pre-3.2. You get the 30-second silence. Upgrade to 3.2+ or accept the wall-of-text behaviour.
  • Using the wrong @BotFather. There are imposters. Confirm the username is exactly @BotFather with the verified checkmark ✓.
  • BotFather username not ending in bot. Telegram rejects any username that doesn't end in bot. The error message is unhelpful — just add bot to the end.
  • Asking the agent to wire Telegram for you. Same reliability argument as Discord: the host tested both and the chat path works ~75% of the time. Use openclaw configure from the terminal.
  • Skipping the gateway restart. Configuration changes don't apply until the gateway restarts. Skip this and nothing works.
  • Pairing code not pasting into openclaw tui. Pairing codes are case-sensitive. Copy-paste instead of typing.
  • Forgetting to re-pair after a token rotation. Rotating the token invalidates existing pairings. Re-run openclaw tui with the new pairing code.
  • Streaming off when you want it on. Default is Partial, which buffers some chunks. Set to On for full streaming.
  • Using a cheaper model and expecting character-by-character streaming. Cheaper models (Minimax, Kimi) have chunkier streaming because their token rate is lower. Opus or Sonnet gives smoother streaming.
  • Sharing the bot token in chat. The token is a private key. Rotate it immediately if it's exposed anywhere public.
  • Skipping openclaw doctor after the upgrade. Run it after every 3.2+ upgrade. Missing dependencies break streaming silently.
  • Not pinning the cron timezone for Telegram cron jobs. Telegram cron jobs run on UTC by default. If your morning brief should fire at 07:00 local, set the timezone explicitly. Otherwise it fires at the wrong hour.

Sources

  • OpenClaw Telegram Setup — video_id: -G2r_SanjoE (file 35 is a duplicate; drop it)
  • NEW OpenClaw Update is HUGE! — 9,677 views · video_id: xGFzVdp3Ch0 (v2.26 — external secrets management)
  • NEW OpenClaw 3.2 Update is a HUGE Improvement! — 4,451 views · video_id: dHQGpDJbN0w (Telegram streaming shipped in 3.2)
  • Supabase query (project ttxdssgydwyurwwnjogq): SELECT video_id, title, views, summary_content, summary_key_takeaways, transcript_content FROM public.videos WHERE video_id = ANY(ARRAY['-G2r_SanjoE', 'xGFzVdp3Ch0', 'dHQGpDJbN0w']);
  • External references: Telegram BotFather (@BotFather, /newbot, /token, /revoke), OpenClaw CLI (openclaw configure, openclaw tui, openclaw gateway restart, openclaw update, openclaw doctor).