#api billing error?

1 messages · Page 1 of 1 (latest)

ancient questBOT Feb 8, 2026, 9:06 AM

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

icy plazaBOT Feb 8, 2026, 9:07 AM

That error is almost always Anthropic API billing/quota, and it’s easy to hit if you’re mixing up Claude subscription vs Anthropic API:

Claude Pro/Max subscription (claude.ai) does not automatically give you Anthropic API credits.
OpenClaw calling anthropic/* models is using the Anthropic API, which normally requires an API key + billing in the Anthropic Console.

If you don’t want an Anthropic Console API key, the only “subscription” path OpenClaw supports is Claude Code’s setup-token (not a random “subscription token” from the web UI):

Fix options

Option A (recommended / most supported): use an Anthropic API key

Create a key in https://console.anthropic.com
Put it on the gateway host as ANTHROPIC_API_KEY (or in ~/.openclaw/.env)
Restart the gateway and run: openclaw models status

Docs: https://docs.openclaw.ai/gateway/authentication#recommended-anthropic-setup-api-key

Option B: use Claude subscription via setup-token

Run: claude setup-token (Claude Code CLI)
On the gateway host: openclaw models auth setup-token --provider anthropic
(or openclaw models auth paste-token --provider anthropic)

Docs:

Quick debug (so we can tell which case you’re in)

Paste (no secrets) the output of:

openclaw --version
openclaw models status

And if you can, the HTTP status/code from the gateway log line right around the error (redact any tokens).

Yes — setup-token is different from an Anthropic Console API key.

What “setup-token” means (and how it differs from API key)

Anthropic API key (from console.anthropic.com) = standard API billing (pay-per-token). This is the most supported/reliable path.
Claude setup-token = a long‑lived token generated by the Claude Code CLI (claude setup-token) that lets OpenClaw authenticate as a Claude Pro/Max subscription. OpenClaw stores/uses it basically “like an API key”, but it’s not the same thing and can have different limits/behavior (and it can be revoked/expire; no auto-refresh).

Docs:

About that GitHub issue you linked (#11722)

That issue is specifically about OpenClaw sometimes showing the wrong generic message (“API billing error…”) when the real problem is a local tool exec getting killed (SIGPIPE/SIGKILL), not Anthropic billing.

So it could be your case — but only if this error pops up right after OpenClaw runs a local command/tool (e.g., exec, piped output, | head, etc.). If you’re just chatting normally and it fails before any tools run, it’s more likely a real Anthropic error.

To figure out which one you’re hitting (paste outputs, no secrets)

Please paste:

openclaw --version
openclaw models status
The few log lines around the failure from: openclaw logs --follow (or run it, reproduce once, then copy the relevant block)

What we’re looking for in the logs:

If you see exit codes/signals like SIGPIPE, SIGKILL, exit 141 → it’s the #11722 “misleading error text” situation.
If you see an HTTP status from Anthropic (401/403/402/429) → it’s a real provider response, and the status tells us the fix (re-paste token vs rate-limit window vs needing an API key).

Also quick sanity check: did you generate the token via claude setup-token (Claude Code CLI), not from the web UI/cookies?

That output is the key clue: openclaw models status normally prints a model/auth status table. It should not just print the “API provider returned a billing error…” paragraph.

So what you’re seeing there is very likely OpenClaw’s generic error normalization kicking in because the command execution failed/was terminated, not because Anthropic actually said “out of credits”. That’s exactly what issue #11722 is about (SIGPIPE/SIGKILL/exec terminated → misreported as “billing error”).

Why your openclaw logs --follow looks “normal”:

if the failure is a local exec termination, there may be no Anthropic HTTP error to log at all.

To confirm in 30 seconds, I need one detail:

Are you running these commands in a real terminal on the gateway host, or are you sending openclaw models status as a Discord message to the bot (and it’s running it via tools)?

If it’s the Discord-bot-running-the-command case: workaround is to run the command in a real shell (SSH/local) instead, or update to a newer OpenClaw build (you’re on 2026.2.6-3, same version mentioned in the issue).

If you can run a real terminal command, please paste:

openclaw status --all (safe, redacts tokens)
and then run openclaw models status --plain

If that prints the normal table, then your Anthropic billing is probably fine and you’re just hitting the misleading exec error message bug from #11722. If it still errors, we’ll look for the actual Anthropic HTTP status code in logs (402/403/429/etc) and fix based on that.

Got it — that explains it.

When you run openclaw ... as a Discord message, OpenClaw is executing it via the bot/tooling layer, and that layer can mislabel local exec terminations as “API billing error” (the #11722 bug). It’s not reliable evidence of Anthropic credits.

Do this on the gateway host terminal (SSH/local):

openclaw --version
openclaw models status --plain
openclaw models status --probe --plain

If models status --plain shows the normal model/auth table → your setup-token is fine; the Discord “billing error” was just misleading normalization.
If --probe fails, paste the exact error line (it should include a real HTTP status / Anthropic message).

Also, if you can, paste openclaw status --all from the terminal (it’s the best “redacted debug bundle”).

Once you confirm terminal works, the practical fix is:

Don’t run CLI commands by sending them as chat messages (use terminal), and/or
update OpenClaw once the #11722 fix lands (you’re on 2026.2.6-3, which is the version mentioned in that issue).

That screenshot is good news: there’s no Anthropic “billing error” there at all.

What it shows:

openclaw models status --plain is working in a real terminal, and it’s just printing the resolved default model:
- anthropic/claude-opus-4-6
Your --probe attempt failed because --probe can’t be used with --plain:
- Error: --probe cannot be used with --plain output.
The (punycode) DeprecationWarning is harmless noise from Node, you can ignore it.

To actually verify the setup-token/auth (and catch real HTTP errors), run these on the gateway terminal:

openclaw models status
openclaw models status --probe

(--probe does a real request, so it can consume a tiny bit of usage.)

One quick question so we don’t chase the wrong thing:

Do you still get the “⚠️ API provider returned a billing error…” when the bot tries to reply to your messages,
or was it only happening when you were typing CLI commands as Discord messages?

If it’s only from typing CLI commands into Discord, that’s consistent with issue #11722 (misleading error text from the exec/tool layer). If it happens during normal replies, paste the first actual Anthropic error line from openclaw logs --follow right when it fails (it’ll include an HTTP status / message).

Those screenshots show your Anthropic setup-token is working.

openclaw models status shows anthropic:default (token) is present
openclaw models status --probe returns: ok · 2.1s

So this is not an Anthropic “out of credits” situation.

What happened earlier is consistent with #11722: when you typed CLI commands as Discord chat messages, OpenClaw’s tool/exec layer can fail/terminate and then incorrectly surface the generic “API billing error” text.

What to do

Ignore the “billing error” if it only appears when you type CLI commands into Discord.
Run diagnostics from the terminal (as you just did). If you want a deeper check:
- openclaw status --all
If you ever see the “billing error” during normal bot replies (not you typing CLI commands), paste the first real error line from openclaw logs --follow at the moment it fails (it should include an HTTP status / provider message).

If this cleared it up, please mark the solution message in Discord (right-click → Apps → Mark Solution) so it’s indexed for others.

It will respond — the “billing error” you’re seeing is a misleading error message (issue #11722) that can show up when the bot is trying to run something like a local command/tool from a chat message and that run fails/gets cut off. Your Anthropic setup-token is fine (your models status --probe is ok).

The practical fix (so it replies normally)

Don’t type CLI commands as chat messages (like openclaw models status).
That makes the agent try to “helpfully” execute them, which is where the misleading error can happen.
In Discord, use the built-in chat commands instead:
- /status (basic health/info)
- /model status (model/auth status)
If you want to stop it from trying to run commands/tools from your messages entirely, set it to require approval:
- run: /exec ask=always security=allowlist
- (or turn off elevated mode if you enabled it: /elevated off)

Quick test

Send a normal message like: “hi” or “what model are you using?”
If it still replies with “billing error” on normal chat (not CLI-looking text), then we need the exact error line from openclaw logs --follow at that moment.

(But based on your probe screenshots: your Claude auth is working; this is about command/tool execution + the misleading message.)

Your Anthropic setup-token is not the problem (your openclaw models status --probe = ok). So if the bot still replies “billing error” to normal questions, that message is being used as a generic fallback for some other failing request.

The most common culprit (and it matches your “memory embeddings running” observation) is: memory embeddings are using a different provider (often OpenAI/Gemini) that has no credits, and the failure is getting mislabeled.

Fastest workaround (make it reply again)

Temporarily disable memory plugins, restart gateway:

Edit ~/.openclaw/openclaw.json and add:

{
  plugins: { slots: { memory: "none" } },
}

Restart:

openclaw gateway restart

This disables semantic memory search (embeddings), but the bot should respond normally again.

Docs: https://docs.openclaw.ai/concepts/memory (mentions plugins.slots.memory = "none")

Then find the real cause (so you can re-enable memory later)

Run this on the gateway terminal and paste the output:

openclaw memory status --deep
openclaw status --all

If memory status --deep shows it’s using OpenAI or Gemini embeddings, you fix it by either:

adding a working key/credits for that embedding provider, or
configuring local embeddings (no remote billing), or
leaving memory disabled if you don’t care about semantic recall.

If you paste openclaw memory status --deep, I’ll tell you exactly which one you’re on and the cleanest fix.

Your Anthropic auth is fine. Screenshot 4/5 show openclaw models status --probe = ok, so Claude isn’t “out of credits”.

What is suspicious in screenshot 6 is this:

openclaw memory status --deep
Sources: memory, sessions
Indexed: 46/733 files … Dirty: yes
Lots of background embedding/indexing work

That means you have experimental session transcript indexing enabled (sources: ["memory","sessions"]). With hundreds of session files, that can hammer the box and (in this version) failures can get surfaced as that misleading “billing error” message.

Fix (recommended): turn off session transcript indexing

Edit ~/.openclaw/openclaw.json and change your memory config to memory-only:

agents: {
defaults: {
memorySearch: {
// turn off the experimental feature:
experimental: { sessionMemory: false },
// and/or just index memory files:
sources: ["memory"],
},
},
},
}

Then restart:

openclaw gateway restart

If you want the fastest “make it reply now” test

Disable memory entirely (temporary):

{ plugins: { slots: { memory: "none" } } }

Restart gateway, test replying in Discord. If that fixes it, we’ve confirmed it’s the memory indexing path causing the misleading error.

If it still happens after that

Run openclaw logs --follow in a terminal, send one normal Discord message that triggers the “billing error”, and paste the first error log line that appears right then — that will show the real underlying failure (right now we only see background indexing in the logs/status output).

Turning off memory search won’t make the model “dumber” in the moment, but it will reduce its ability to recall your saved notes (MEMORY.md + daily memory files) semantically.

Think of it like this:

Memory files (Markdown) = what it can “remember” long‑term (because it’s on disk).
Memory search (embeddings/index) = how well it can find the right memory when you ask later.

If you disable memory search, it can still write to MEMORY.md / memory/YYYY-MM-DD.md, but it’ll be worse at finding older, relevant bits unless you’re very explicit.

Optimal setup (recommended)

1) Keep memory search ON, but keep it lightweight

Use local embeddings (no billing, no external API). Your openclaw memory status --deep already shows:
- Provider: local
- model embeddinggemma-300M…
  So you’re already on the best-cost path.

2) Don’t index session transcripts (that’s the heavy part)

Your output showed Sources: memory, sessions and ~733 files. That’s a lot and it’s experimental.

Best practice config:

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "local",
        sources: ["memory"],              // key change
        experimental: { sessionMemory: false }, // key change
        fallback: "none",                 // avoids surprise remote calls
      },
    },
  },

Then restart: openclaw gateway restart

That gives you:

Good “real memory” via your Markdown files
Good retrieval of those memory files
No huge background indexing of session logs
No accidental fallback to a remote embeddings provider

When should you fully disable memory search?

Only if you don’t care about recall at all, or you’re debugging something and want the bot replying ASAP. It’s fine as a temporary switch, but I wouldn’t run that way long-term.

If you paste your current memorySearch section from ~/.openclaw/openclaw.json (redact nothing needed—there shouldn’t be secrets there), I can tell you the exact minimal change to make it “optimal”.

It’s probably not “crashing because local embeddings can’t handle it” — your openclaw memory status --deep says Embeddings: ready and your models status --probe says Anthropic is ok.

What is very likely: you’ve enabled session transcript indexing for memory search:

Sources: memory, sessions
12/698 session files and Dirty: yes

That “sessions” mode is experimental and can cause a ton of background indexing work. On smaller boxes it can lead to timeouts / the process getting killed (OOM), and then you see that misleading generic “billing error” message.

Fix (optimal + stable): keep memory search, disable session indexing

Edit ~/.openclaw/openclaw.json:

{
  agents: {
    defaults: {

      memorySearch: {
        provider: "local",
        sources: ["memory"],                 // disable session transcript indexing
        experimental: { sessionMemory: false },
        fallback: "none",                    // prevent any surprise remote fallback
      },
    },
  },
}

Then:

openclaw gateway restart

This keeps “good memory” (search over MEMORY.md + memory/YYYY-MM-DD.md) without the huge sessions backfill.

If it still throws “billing error” after that

We need to confirm whether the gateway is getting OOM-killed or if something else is failing.

Run:

openclaw gateway status
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
journalctl -k -n 200 --no-pager | rg -i "oom|killed process|out of memory" || true

Paste the first error-looking chunk. If you see OOM kills, the fix is either: disable sessions indexing (above), or move to a box with more RAM.

If you want, paste just your current memorySearch section from openclaw.json and I’ll tell you the smallest edit to get you to the stable setup.

Yes — right now the best move is to disable session indexing. It’s experimental, it creates a lot of background embedding work (your 698 session files is huge), and when it misbehaves you get that misleading “billing error” wrapper.

Can you keep it without issues?

Sometimes, but only if you make it lighter. Options (from “most reliable” → “most work”):

Disable session indexing (recommended stable default)
- Keep sources: ["memory"]
- You still get great recall for anything you intentionally wrote to MEMORY.md / memory/YYYY-MM-DD.md.
Keep session indexing, but reduce the workload
- Increase the thresholds so it indexes sessions less often (bigger deltaBytes / deltaMessages)
- Reduce retention (fewer session logs to index)
- Make sure you have enough RAM/CPU (session indexing + embeddings can spike)
Move session indexing to a beefier machine
- If this is a small VPS / low-RAM box, session indexing will always be annoying at scale.

My recommendation

Disable session indexing now to stop the errors.
If you really want “search old chats”, re-enable later once everything’s stable and you’ve trimmed sessions/raised thresholds.

If you paste your current agents.defaults.memorySearch config from ~/.openclaw/openclaw.json, I can give you the exact minimal patch for option (1), and a “lightweight” config for option (2).

If you’re still seeing the “billing error” after disabling session memory, one of these is happening:

The config change didn’t actually take effect (still indexing sessions), or
You’re talking to a different OpenClaw instance than the one you’re editing in terminal, or
It’s a different underlying error (and the message is just the misleading wrapper).

Do this in order:

1) Confirm Discord is hitting the same gateway you’re editing

In Discord, run /status and check the version/commit matches your terminal (2026.2.6-3 (85ed6c7)).

If it doesn’t match → you’re debugging the wrong machine/process.

2) Verify session indexing is truly off

On the gateway terminal, run:

openclaw memory status --deep

It must say Sources: memory (NOT memory, sessions).

If it still says memory, sessions, then paste just your agents.defaults.memorySearch section from ~/.openclaw/openclaw.json and I’ll tell you exactly what to change.

Minimum “sessions OFF” config is:

agents: {
  defaults: {
    memorySearch: {
      sources: ["memory"],
      experimental: { sessionMemory: false },

    }
  }
}

Then restart:

openclaw gateway restart

3) Quick isolate: disable memory completely (just to confirm the cause)

Temporarily set:

{ plugins: { slots: { memory: "none" } } }

Restart gateway and test a normal Discord message.

If that fixes replies → the issue is in memory/indexing path.
If it still happens → it’s not memory; we need logs.

4) Capture the real error (the billing message is hiding it)

Run in terminal:

openclaw logs --follow

Then send ONE normal Discord message that triggers the “billing error”, and immediately copy/paste the first error log lines that appear right then (not the earlier “embeddings running” stuff).

That log snippet will tell us what’s actually failing.

Screenshot 9 confirms you did disable session indexing correctly:

Sources: memory (good)
Provider is local
Embeddings are ready
So no, you don’t need to “reset” anything just because of that.

But you are still getting the misleading “billing error”, so the next step is: catch the real underlying error in logs.

Do NOT “reset” yet. Do this instead (in the terminal):

Start live logs:

openclaw logs --follow

While that is running, send one normal Discord message to the bot (like “hi”) that triggers the billing error.

Immediately copy/paste here the first ERROR/WARN lines that appear in the terminal log right when it happens.

That will tell us what’s actually failing (network, tool exec, OOM, Discord send failure, etc.). The “billing error” text is just a bad wrapper.

One more quick sanity check

In Discord, run /status and make sure it shows the same gateway/version (2026.2.6-3 (85ed6c7)). If it’s different, you’re talking to another instance.

Once you paste the log snippet from step (3), I can tell you the exact fix.

Don’t do --reset yet. That’s the nuclear option (wipes sessions/credentials/workspace depending on how you run it) and it won’t teach us what’s actually failing.

From your screenshots 12–17 I can see:

The gateway is up and processing runs: provider=anthropic model=claude-opus-4-6
No Anthropic billing/402 errors appear in what you captured
Memory is now Sources: memory (good) and Anthropic probe = ok (so auth/billing is not the blocker)

So the “billing error” message is still just a misleading wrapper, but we still haven’t captured the real underlying error line yet (it’s not in those screenshots).

Do this (terminal) to extract the real error automatically

Run:

rg -n "level\":\"error|level\":\"warn|SIGPIPE|SIGKILL|exitCode|DiscordAPIError|EPIPE|ECONNRESET|anthropic" /tmp/openclaw/openclaw-2026-02-08.log | tail -n 120

Paste the output. That will show the actual failure that’s being mislabeled.

Quick “make it stop trying tools” workaround (Discord)

If the model is triggering some tool and that tool is what’s failing, force approvals so it can’t silently trip the bug:

/elevated off
/exec ask=always security=allowlist

Then send a simple “hi” again. If it now asks permission / behaves differently, we’ve confirmed it was tool-triggered.

Optional: Discord-specific log view (much easier to read)

Run:

openclaw channels logs --channel discord

Then reproduce once and screenshot/copy the first error block.

Once you paste the rg ... output (or the discord channel logs), I can tell you the exact fix (permissions, message-length, tool failure, OOM, etc.). Right now we only see “runs happened”, not the line that actually failed.

Yep — do them in this order (so we catch the failure cleanly):

1) Start live Discord logs (terminal)

openclaw channels logs --channel discord

2) Reproduce once

In Discord, send ONE normal message to the bot (“hi”).

3) Immediately run the `rg` grep on the file log (new terminal tab/window, or stop the live view)

rg -n "level\":\"error|level\":\"warn|SIGPIPE|SIGKILL|exitCode|DiscordAPIError|EPIPE|ECONNRESET|anthropic" /tmp/openclaw/openclaw-2026-02-08.log | tail -n 120

4) Paste results here

Paste the chunk of Discord logs around the time it failed (the few lines before/after).

Paste the rg ... | tail output.

Those two together will show the real underlying error that’s being mislabeled as “billing”.

If you want the quickest single thing to paste: paste the rg ... tail -n 120 output.

That screenshot explains the confusion: you’re still pasting the rg ... grep into Discord, so OpenClaw is answering you with “logs look clean…” as a chat reply — it’s not actually running ripgrep and showing you terminal output.

Don’t run any kind of “reset” from the terminal yet (especially not openclaw gateway ... --reset). If you want to reset the chat session, use /reset in Discord (safe).

Do this in the gateway terminal (SSH/local), not Discord

Run these two commands and paste the output:

rg -n "API provider returned a billing error|billing error|insufficient balance|402|SIGPIPE|SIGKILL|EPIPE|ECONNRESET|DiscordAPIError|Missing Permissions|Missing Access" /tmp/openclaw/openclaw-2026-02-08.log | tail -n 200

and:

journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Those will surface the real underlying error (Discord send failure, process kill, network error, etc.) that is being mislabeled as “billing”.

Quick “make it reply” workaround while we debug

In Discord, send these as standalone messages:

/reset
/elevated off

Then send “hi” again.

Paste the terminal outputs above and we can point to the exact fix instead of guessing.

Put it in the terminal (on the machine where the gateway is running).

Anything you type into Discord is treated as a message to the bot, not a shell command, so you won’t get real rg output there.

So:

SSH/open a terminal on the gateway host
Run the rg ... /tmp/openclaw/... command there
Copy/paste the terminal output back into Discord here

icy plazaBOT Feb 8, 2026, 10:42 AM

I’m here.

Yes — run it in the terminal on the gateway host, not in Discord.

1) Get the real error (terminal)

Run:

rg -n "\"level\":\"(error|warn)\"|billing error|insufficient balance|DiscordAPIError|Missing Permissions|EPIPE|ECONNRESET|SIGPIPE|SIGKILL|anthropic" \
  /tmp/openclaw/openclaw-2026-02-08.log | tail -n 200

Paste whatever that prints.

2) Quick “make it reply even if tools are failing”

Right now your /status shows elevated is ON. If the model is trying to run tools (exec/browser/etc) and those are failing, you can stop that:

In Discord, send:

/elevated off

If you want to hard-block shell runs (so it can’t trip the misleading “billing error” wrapper), add this to ~/.openclaw/openclaw.json and restart:

{
  agents: {
    defaults: {
      tools: { deny: ["exec", "process"] }
    }
  }
}

Then:

openclaw gateway restart

Why this helps

Your Anthropic token is confirmed good (models status --probe: ok). So the “billing error” is almost certainly OpenClaw mislabeling some other failure — most commonly a tool/exec failure when elevated is on.

Paste the terminal rg output and we’ll pinpoint the exact cause.

If the TUI/logs show clean Anthropic runs (and your models status --probe is ok) but Discord keeps receiving the “billing error” message, that almost always means:

the model run is fine, but something in the Discord “reply back” path (or a tool call) is failing, and OpenClaw is mislabeling that failure as “billing”.

Two concrete things to do that usually fix it immediately:

1) Turn off elevated (Discord)

Your /status screenshot earlier showed elevated is ON. Turn it off so the model stops trying risky tools automatically:

send: /elevated off
then: /reset
then try a normal message again (“hi”).

2) Hard-disable exec/process tools (config + restart)

In ~/.openclaw/openclaw.json, add:

{
  agents: {
    defaults: {
      tools: { deny: ["exec", "process"] }
    }
  }
}

Then restart:

openclaw gateway restart

This prevents “helpful” shell/tool attempts that can trigger the misleading wrapper.

If it STILL happens: capture the actual error line (terminal)

Right after you trigger the bad Discord reply, run in the terminal:

openclaw logs --limit 200 --plain

…and paste that output here. (The earlier screenshots didn’t include any level=error lines around the moment it replied, so we still don’t have the real cause.)

Once we see the real error (DiscordAPIError, missing perms, EPIPE, etc.), the fix will be specific and quick.

That’s normal: heartbeats (and a bunch of other background stuff you see in the TUI/logs) are not supposed to show up in Discord.

Heartbeat = internal “are we alive / keep things warm” check. It logs, but it does not send chat messages.
Memory indexing / embeddings = background maintenance. Also logs only.
Some internal runs (like config reload, memory flush, etc.) are intentionally silent.

So: TUI/logs ≠ “things that should appear in Discord”.

What’s not normal is the bot replying to your normal questions with that misleading “billing error” message.

To fix that, we still need the real error line (because Anthropic auth is confirmed OK). Please run this in the terminal (not Discord) and paste the output:

rg -n "billing error|insufficient balance|\"level\":\"error\"|DiscordAPIError|Missing Permissions|Missing Access|Cannot send messages|EPIPE|ECONNRESET|SIGPIPE|SIGKILL" \
  /tmp/openclaw/openclaw-2026-02-08.log | tail -n 200

Also: your /status earlier showed elevated. Turn that off so it stops trying tools that can trigger this bad error wrapper:

In Discord: /elevated off
Then: /reset
Then try “hi” again.

Paste the rg output and we can point to the exact fix (it’s usually a Discord send permission issue, a tool failure, or a killed subprocess — just mislabeled as “billing”).

What you’re seeing (“it shows in TUI but not in Discord”) means:

The agent run completed, but the outbound send to Discord failed.

From your earlier screenshot text, the real underlying error is very likely:

DiscordAPIError: Unknown interaction (code 10062)

That happens when the thing you used to talk to the bot is a Discord interaction (slash command / app command / button), and Discord requires an ACK/defer within ~3 seconds. If the model run (or queueing) takes longer and OpenClaw doesn’t defer in time, Discord drops the response — so you only see it in TUI/logs.

Fix (pick one)

Option A (best workaround): stop using interactions for “normal chat”

Use regular messages to the bot (mention it / DM it), not a slash/app command.

If you want to avoid native interactions entirely, disable them:

In ~/.openclaw/openclaw.json:

{
  commands: { native: false }
  // or per-channel:
  // channels: { discord: { commands: { native: false } } }
}

Then:

openclaw gateway restart

You’ll lose Discord slash commands, but normal message replies won’t hit the 3‑second interaction window.

Option B: keep slash/app commands, but make replies faster

Run /reset (new session = smaller context = faster)
Switch to a faster model via /model (pick a “sonnet/fast” option if available)

Option C: update OpenClaw once a fix lands

This looks like a known rough edge in this version’s Discord interaction deferral.

Confirm it’s really “Unknown interaction”

Run on the gateway terminal and paste output:

rg -n "Unknown interaction|DiscordAPIError|10062" /tmp/openclaw/openclaw-2026-02-08.log | tail -n 50

That single snippet will let me tell you which option is the cleanest for your setup.

You’re right to call that out — normal chat messages are not slash commands. The reason I brought up “commands/interactions” earlier is because I saw at least one ephemeral “Only you can see this” message in your screenshots (that is an interaction, e.g. /status). But your normal messages should still work.

When it “shows in TUI but not in Discord”, that means:

the agent run finished, but the outbound Discord send failed.

OpenClaw is then (buggily) wrapping that as the generic “API billing error” message.

The fastest way to fix: find the real Discord error

Run this in the gateway terminal and paste the output (it won’t include secrets):

rg -n "DiscordAPIError|Missing Permissions|Missing Access|Unknown interaction|10062|50013|50001|Cannot send messages" \
  /tmp/openclaw/openclaw-2026-02-08.log | tail -n 80

Those codes usually map to:

50013 = Missing Permissions
50001 = Missing Access
10062 = Unknown interaction (only if it was triggered by an interaction)

Also run a permission probe for the exact channel

Since you’re in channel 1469982677594673314, run:

openclaw channels capabilities --channel discord --target channel:1469982677594673314

If this is a forum/thread, the most common “it works sometimes / then doesn’t” fix is giving the bot role:

View Channel
Send Messages
Send Messages in Threads
Read Message History

#api billing error?

Fix options

Quick debug (so we can tell which case you’re in)

What “setup-token” means (and how it differs from API key)

About that GitHub issue you linked (#11722)

To figure out which one you’re hitting (paste outputs, no secrets)

What to do

The practical fix (so it replies normally)

Quick test

Fastest workaround (make it reply again)

Then find the real cause (so you can re-enable memory later)

Fix (recommended): turn off session transcript indexing

If you want the fastest “make it reply now” test

If it still happens after that

Optimal setup (recommended)

1) Keep memory search ON, but keep it lightweight

2) Don’t index session transcripts (that’s the heavy part)

When should you fully disable memory search?

Fix (optimal + stable): keep memory search, disable session indexing

If it still throws “billing error” after that

Can you keep it without issues?

My recommendation

1) Confirm Discord is hitting the same gateway you’re editing

2) Verify session indexing is truly off

3) Quick isolate: disable memory completely (just to confirm the cause)

4) Capture the real error (the billing message is hiding it)

Do NOT “reset” yet. Do this instead (in the terminal):

One more quick sanity check

Do this (terminal) to extract the real error automatically

Quick “make it stop trying tools” workaround (Discord)

Optional: Discord-specific log view (much easier to read)

1) Start live Discord logs (terminal)

2) Reproduce once

3) Immediately run the rg grep on the file log (new terminal tab/window, or stop the live view)

4) Paste results here

Do this in the gateway terminal (SSH/local), not Discord

Quick “make it reply” workaround while we debug

1) Get the real error (terminal)

2) Quick “make it reply even if tools are failing”

Why this helps

1) Turn off elevated (Discord)

2) Hard-disable exec/process tools (config + restart)

If it STILL happens: capture the actual error line (terminal)

Fix (pick one)

Option A (best workaround): stop using interactions for “normal chat”

Option B: keep slash/app commands, but make replies faster

Option C: update OpenClaw once a fix lands

Confirm it’s really “Unknown interaction”

The fastest way to fix: find the real Discord error

Also run a permission probe for the exact channel

3) Immediately run the `rg` grep on the file log (new terminal tab/window, or stop the live view)