Awesome OpenClaw Tips: The Complete Collection

This guide is a practical playbook for turning OpenClaw from a fun chatbot into a reliable operating system for recurring work. It covers messaging, Telegram integration, memory management, reliability, cost optimization, operations, automation, and architecture, drawing from hands-on use, official documentation, community setups, and deep dives into the OpenClaw codebase. By the end, you will have a set of actionable tips to make your agent more capable, cheaper to run, and less prone to failure.

What You Need

Before applying these tips, you need a working OpenClaw installation. The tips assume you have:

• OpenClaw installed and running. The exact version is not specified, but the tips target a recent build with support for Telegram, agents, subagents, cron, and tool loops.
• An OpenClaw configuration file. The default location is ~/.openclaw/openclaw.json, but your setup may vary. Many tips require editing this file.
• A Telegram bot token (for Telegram-specific tips). You will need a bot created via BotFather and the token configured in OpenClaw.
• Node.js (for SQLite memory search). The SQLite memory search scripts in MEM-03 require Node.js to run.
• Git (for workspace version control). OPS-02 recommends putting your workspace under git, and TEL-04 uses git for config management.
• Basic familiarity with JSON5 syntax. The OpenClaw config uses JSON5, which allows comments and trailing commas.

Messages

MES-01: Enable ack reactions by setting messages.ackReactionScope

Ack reactions are the small checkmark or other emoji reactions that appear on messages to confirm the agent has seen or processed them. By default, OpenClaw controls when these appear based on the messages.ackReactionScope setting. If you want acknowledgements to appear more broadly, set the scope explicitly instead of relying on the default.

Use all when you want broad ack reactions across chats instead of narrower behavior like direct messages only or group mentions only.

Set it like this in your config:

{
  messages: {
    ackReactionScope: "all"
  }
}

Valid values are:

• group-mentions: Only reacts when the bot is mentioned in a group.
• group-all: Reacts to all messages in groups.
• direct: Only reacts in direct messages.
• all: Reacts in all contexts (direct messages and groups).
• off: Disables ack reactions entirely.
• none: Same as off.

When to use each:

• all is the most responsive option, but it can be noisy in busy groups. Use it when you want immediate feedback that the agent has seen every message.
• group-mentions is a good middle ground for shared channels where the bot should only react when explicitly called upon.
• direct is useful if you only care about one-on-one conversations.
• off or none saves a tiny bit of API overhead and reduces visual clutter.

Community note: Some users report that setting this to all in very large groups can cause the bot to hit rate limits on the Telegram API. If you notice reactions not appearing, consider narrowing the scope.

Telegram

TEL-01: Use Telegram inline buttons for recurring actions

If Telegram users have to keep typing the same replies, approvals, or short commands, the workflow gets slower than it needs to be. OpenClaw supports Telegram inline buttons, so recurring actions can be one tap instead of another typed message.

The important distinction is that plain text option lists are not inline buttons. For real clickable Telegram buttons, the message must include a real inline-keyboard payload.

This is a good fit for approvals and review flows. It also works well for quick replies and common follow-up actions. Use it anywhere repeated choices are clearer as taps than typed messages.

Turn on inline buttons with Telegram capability scope in your config:

{
  channels: {
    telegram: {
      capabilities: {
        inlineButtons: "all"
      }
    }
  }
}

The supported scopes are:

• off: Disables inline buttons.
• dm: Only in direct messages.
• group: Only in groups.
• all: In all contexts.
• allowlist: Only for specific chats defined elsewhere.

How to send a message with inline buttons:

Use the OpenClaw CLI in this form:

openclaw message send --channel telegram --account <accountId> --target <chatId> --message "<text>" --buttons '<json>'

Ensure the --buttons payload is:

• Valid JSON.
• A top-level array of rows.
• Each row an array of button objects.
• Each callback button includes text and callback_data.

Example payload:

[
  [
    {"text": "Approve", "callback_data": "approve_order_123"},
    {"text": "Reject", "callback_data": "reject_order_123"}
  ]
]

Community note: If a style field is supported by your tooling, treat it only as a hint. Do not rely on Telegram per-button colors, as Telegram does not officially support colored buttons in inline keyboards.

TEL-02: Split conversations into threads so context stops bleeding across topics

One long OpenClaw conversation turns into a junk drawer. Coding, research, admin, and random questions all get mixed together, and every new turn drags that baggage forward. OpenClaw already has session boundaries you can use:

• Group chats isolate state by group.
• Telegram forum topics get their own :topic:<threadId> session keys.
• Slack and Discord threads are treated as thread sessions.
• Discord channels also get their own isolated sessions.

That means the practical fix is simple: split work by topic or channel. Keep one thread for coding, another for research, another for admin, another for personal operations. Focused threads give the agent focused context instead of one huge mixed transcript. This is one of the easiest memory fixes because it does not require a new memory system. It just uses OpenClaw's existing session isolation properly.

For Telegram specifically, BotFather has a setting for this now. Open BotFather, choose your bot from My bots, go to Bot Settings, and turn on Threaded Mode.

Once it is enabled, Telegram gives the bot separate tabs/topics in the chat UI. That is exactly what this tip needs: coding in one topic, research in another, admin in another, instead of one mixed transcript where everything contaminates everything else.

TEL-03: Set a system prompt per Telegram topic so /new resets noise without losing purpose

Telegram topics already isolate session history. Add a topic-specific systemPrompt and each thread can keep its own durable purpose too. This works well when one topic is for coding, another is for project operations, and another is for a specific client or team. Users can run /new inside the topic to clear the session, but the topic-specific prompt still loads again so the thread does not forget what it is for.

Use a topic-level override under the Telegram chat entry in your config:

{
  channels: {
    telegram: {
      groups: {
        "-1001234567890": {
          topics: {
            "1399171": {
              systemPrompt: "This topic is for showcasing awesome-openclaw-tips example how to set contexts per Telegram thread via system prompts"
            }
          }
        }
      }
    }
  }
}

Topic entries can also override keys like agentId, skills, and requireMention. Keep the thread-specific purpose in systemPrompt and keep broader defaults at the chat or group level.

If your Telegram setup is nested per account, apply the same topic override at that account's Telegram chat entry instead of the shared default path.

Community note: When testing, ask the agent for the current topic ID first (it can usually report it), then run /new, and then ask what the topic is for. If the configured topic prompt is still reflected after the reset, the setup is working.

TEL-04: Give OpenClaw its own Telegram topic for fast admin work

If OpenClaw config changes, repo checks, cron issues, and bot maintenance all happen in the same general chat, operational work gets mixed into everything else. A dedicated Telegram topic with its own systemPrompt gives OpenClaw a standing admin lane for config review, source inspection, and safe git follow-up.

This works well for things like checking repo status, reviewing changed files, suggesting .gitignore updates, or preparing commits for your OpenClaw config workspace without dragging product or client chatter into the same thread.

Use a topic-specific prompt under the exact Telegram account and chat path you already use. For account-nested Telegram config, it can look like this:

{
  channels: {
    telegram: {
      max: {
        enabled: true,
        direct: {
          "*": {
            topics: {
              "1398645": {
                systemPrompt: "This is the OpenClaw admin topic. In this topic, manage my OpenClaw config, inspect OpenClaw source when needed, review repo status, suggest what should be committed or ignored, and ask before making git commits. OpenClaw source code is in ~/.openclaw/ and my global config is in ~/.openclaw/openclaw.json. I do clean, git management of openclaw directory, trying to ingore not for source code useful stuff, and include everything for reproducable re-setup. Usually after making changes, I commit my config dir, for this you can report to me changed files, what's good to commit and what's to ignore, if igoring should we add in .gitinore too and if I approve, you can commit"
              }
            }
          }
        }
      }
    }
  }
}

Keep the prompt narrow and operational. Tell the topic what it is for, where the OpenClaw repo lives, where the active config lives, and what commit behavior you want. If you want approval before commits or .gitignore changes, say that directly in the topic prompt.

This is different from a generic project topic. The point is to have one permanent thread that OpenClaw treats as its own maintenance console.

Memory

MEM-01: Make your agent learn from its mistakes

By default, every session starts clean. Your agent has no memory of the last time it tried something and failed, or the last time you corrected it. Two weeks later, it is still repeating day-three mistakes.

The minimum fix is a .learnings/ folder in your workspace with two files:

• .learnings/ERRORS.md - command failures, breakages, exceptions
• .learnings/LEARNINGS.md - corrections, knowledge gaps, workflow discoveries

Add this to SOUL.md:

Before starting any task, check .learnings/ for relevant past errors.
When you fail at something or I correct you, log it to .learnings/ immediately.

Over time, repeated lessons can be promoted into SOUL.md itself so they apply automatically in future sessions.

Community note: For a fuller version with automatic hooks, structured entries, and a promotion workflow, install the self-improving-agent skill.

MEM-02: Flush important state before compaction eats it

Long OpenClaw sessions do not grow forever. Once context gets full, OpenClaw auto-compacts the session. That usually means a summary survives, plus recent turns. Anything important that only lives in chat is now at risk.

Treat compaction as a deadline. Important state should already be on disk before it happens. Turn on the built-in pre-compaction memory flush:

"agents": {
  "defaults": {
    "compaction": {
      "memoryFlush": {
        "enabled": true,
        "softThresholdTokens": 4000
      }
    }
  }
}

This watches context usage, triggers a silent flush before hard compaction, and writes durable state to the workspace. It runs once per compaction cycle and uses NO_REPLY, so it does not spam the user.

This pairs naturally with MEM-01. Chat is working memory. Files are memory.

Community note: The softThresholdTokens value of 4000 is a starting point. If your agent works with very long contexts, you may need to increase it. If compaction happens too often, decrease it.

MEM-03: Use SQLite memory search before you pay for embeddings

Most personal OpenClaw setups do not need a vector database just to find old notes. A local SQLite index with FTS5 is often enough.

This tip ships with supporting files that you can fetch from the awesome-openclaw-tips repository:

• tips/mem-03/rebuild-db.js
• tips/mem-03/relevant-memory.js

If needed, fetch them directly from:

• https://raw.githubusercontent.com/alvinunreal/awesome-openclaw-tips/main/tips/mem-03/rebuild-db.js
• https://raw.githubusercontent.com/alvinunreal/awesome-openclaw-tips/main/tips/mem-03/relevant-memory.js

Build the database:

node tips/mem-03/rebuild-db.js

Search it:

node tips/mem-03/relevant-memory.js "query about previous work"

The scripts scan markdown files, build a SQLite database, and use full-text search to surface likely matches quickly. No API costs, no embedding pipeline, no external service.

Community note: The scripts assume your workspace contains markdown files. If your notes are in other formats (like plain text or JSON), you may need to modify the scripts. Also, the database path is hardcoded in the scripts; you may want to change it to a location that persists across sessions.

MEM-04: Treat chat history as cache, not the source of truth

This tip is a conceptual one. Chat history is ephemeral. It gets compacted, summarized, and eventually lost. If you need to remember something permanently, write it to a file in your workspace. The .learnings/ folder from MEM-01 is a good place. So is a MEMORY.md file at the root of your workspace.

Community note: Some users create a state/ directory with JSON files for structured data (like order statuses or project milestones) and instruct the agent to read and write to those files instead of relying on chat context.

MEM-05: Periodically self-clean memory instead of letting it rot forever

Memory files grow over time. Old errors become irrelevant. Outdated learnings become noise. Set up a recurring task (using cron, see AUTO-01) that asks the agent to review its .learnings/ files and archive or delete entries that are no longer relevant. This keeps the signal-to-noise ratio high.

Community note: A simple approach is to add a cron job that runs once a week with a prompt like "Review .learnings/ERRORS.md and .learnings/LEARNINGS.md. Archive entries older than 30 days to .learnings/ARCHIVE.md, unless they are marked as permanent."