A Discord AI bot without giving your data to OpenAI

The default story for “Discord AI bot” in 2026 looks like this: sign up for some SaaS, hand them your Discord token, watch them route every message through OpenAI, pay $20/month plus token markup. There’s a better path.

Here’s how to host a Discord bot that uses whichever LLM you want — Claude, Gemini, a local Llama, anything — with all the conversation data living on your machine.

What you get

A Discord bot that responds to mentions and DMs in your server. The bot can:

• Use Pi’s full tool set (browser, code, files, memory, vector recall).
• Have per-guild and per-channel bindings (different Pi behaviour in different places).
• Send Components v2 buttons and selects when its reply benefits from interactive UI.
• React with ACK emoji so users know it’s working before the full reply lands.

Setup

1. Create a Discord app

Go to https://discord.com/developers/applications → New Application. Name it. Add a Bot. Copy the bot token.

Under Bot → Privileged Gateway Intents, enable Message Content Intent. (Required to read message bodies.)

Under OAuth2 → URL Generator, pick scopes bot and applications.commands. Pick permissions: Send Messages, Read Message History, Add Reactions, Manage Messages (for thread creation). Copy the URL.

Open that URL in a browser to invite the bot to your server.

2. Pair openclawOS

openclaw apps install discord

Paste the bot token when prompted. Or do it from the Control UI.

3. Choose a provider

In the Providers tab, drop in your Anthropic, Google, or local API endpoint. Anthropic Claude Opus 4.6 is what Pi is tuned for. Don’t have a key? OpenRouter is a single account that proxies most providers; openclawOS treats it as OpenAI-compatible.

4. Test

DM the bot. Or mention it in a channel: @yourbot, what is the binding system?. Pi responds within a few seconds.

Channel-scoped behaviour

Bindings scope by channel:

# Coding Pi in #engineering
trigger:
  channel: discord
  scope: { guildId: "111", channelId: "222" }
  match: { mentions: ["@pi"] }
agent: pi
system: "You are a senior engineer reviewer. Be concise."
session: { scope: thread }

# Moderation Pi everywhere else
trigger:
  channel: discord
  scope: { guildId: "111" }
agent: mod_pi
session: { scope: channel }
hooks:
  afterReceive:
    - call: classify_toxicity

Both live on the same Gateway, same bot identity, separate behaviour.

Thread auto-scoping

Discord threads make excellent session boundaries. The default openclawOS Discord binding creates a new session per thread, so a long conversation in a thread doesn’t bleed into other channels’ contexts.

ACK reactions

When Pi starts processing, it can immediately react with a 👀 (or whatever you pick). Replies follow when ready. This solves the “is the bot working or stuck?” UX problem without spamming a “typing…” indicator.

Components v2

Pi can emit interactive UI when responses benefit from structure. Examples:

• Multi-option poll: “I see three approaches; pick one” with buttons.
• Confirmation flow: “Run this command?” with Yes/No.
• Code-block + button: “Here’s a fix” with an Apply button that triggers a follow-up tool.

You don’t have to enable any of this — it’s automatic when Pi decides UI helps.

Privacy reality

The Discord platform sees your messages (it always has — you’re on their servers). The openclawOS Gateway is between Discord and your LLM. Pi sends only relevant turns to the LLM. There is no third-party SaaS in the path.

Why this beats hosted SaaS

You pick the model. You pick the system prompt. You don’t pay anyone’s markup. You can fork Pi, patch a skill, and run the patched version next minute. The whole stack is yours.