#Setup on vps

1 messages · Page 1 of 1 (latest)

brazen pond Mar 10, 2026, 8:31 PM

Got my server. I’m connected. How to setup openclaw on it?

vestal elkBOT Mar 10, 2026, 8:31 PM

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

radiant runeBOT Mar 10, 2026, 8:32 PM

On a VPS the usual setup is: install → run onboarding (as a daemon) → access the Dashboard via SSH tunnel or Tailscale.

1) Install OpenClaw on the server

SSH into the VPS, then run:

curl -fsSL https://openclaw.ai/install.sh | bash

(If you want a full git checkout for easier debugging/hacking: ... | bash -s -- --install-method git)

Docs: https://docs.openclaw.ai/help/faq#how-do-i-install-openclaw-on-a-vps
VPS hub: https://docs.openclaw.ai/vps

2) Run the onboarding wizard + install the service

openclaw onboard --install-daemon

This sets up config, models, channels, and installs the Gateway as a background service.

3) Open the Dashboard from your laptop (recommended: SSH tunnel)

Keep the Gateway bound to loopback on the VPS and tunnel it:

ssh -N -L 18789:127.0.0.1:18789 <user>@<your-vps-ip>

Then on your laptop open:

http://127.0.0.1:18789/

If the UI asks for auth, get the token from the VPS:

openclaw config get gateway.auth.token

Remote access docs: https://docs.openclaw.ai/gateway/remote

4) If anything doesn’t work, paste these outputs here

openclaw --version
openclaw status --all
openclaw gateway status

Also: what OS is your VPS (Ubuntu 22/24, Debian, etc.) and which chat surface do you want to use first (Discord / Telegram / WhatsApp / just the web UI)?

brazen pond Mar 10, 2026, 8:38 PM

im new to all this so i dont understand very well.

radiant runeBOT Mar 10, 2026, 8:39 PM

No worries — the easiest mental model is:

OpenClaw runs on your server (the “Gateway” service).
To actually talk to it, you connect it to:

a model (Anthropic/OpenAI/etc), and
a chat app (Discord/Telegram/etc).

The simplest “just make it work” path on a VPS is:

Step 1 — Install (copy/paste)

On the VPS (SSH terminal):

curl -fsSL https://openclaw.ai/install.sh | bash

Step 2 — Run the setup wizard (it asks questions)

brazen pond Mar 10, 2026, 8:39 PM

! Gateway restart failed; try: openclaw daemon restart

🦞 OpenClaw 2026.3.8 (3caab92)
I can't fix your code taste, but I can fix your build and your backlog.

Dashboard URL: http://127.0.0.1:18789/#token=7f42...
Copy to clipboard unavailable.
No GUI detected. Open from your computer:
ssh -N -L 18789:127.0.0.1:18789 root@
Then open:
http://localhost:18789/
http://localhost:18789/#token=7f4260e3fec9dfcda0c6597...
Docs:
https://docs.openclaw.ai/gateway/remote
https://docs.openclaw.ai/web/control-ui

FAQ: https://docs.openclaw.ai/start/faq

radiant runeBOT Mar 10, 2026, 8:39 PM

openclaw onboard --install-daemon

That wizard will guide you through models + channels and then keep OpenClaw running in the background.

Step 3 — Open the web Dashboard from your own computer (recommended)

In a new terminal on your computer (not the VPS), run:

ssh -N -L 18789:127.0.0.1:18789 <user>@<your-vps-ip>

Then open in your browser:

http://127.0.0.1:18789/

(That’s the “safe” way — you don’t expose the port publicly.)

If your goal is Discord

You’ll need to create a Discord bot token in the Discord Developer Portal and put it into OpenClaw (don’t paste the token into Discord chat — treat it like a password).
Guide: https://docs.openclaw.ai/channels/discord

If you get stuck, paste these outputs (safe)

Run on the VPS and paste the output here:

openclaw --version
openclaw status
openclaw gateway status

Two quick questions so I can tailor the next steps:

What VPS OS is it (Ubuntu 22/24, Debian, etc.)?
Do you want to talk to OpenClaw via Discord, or is the web Dashboard enough for now?

Nice — that output means OpenClaw is installed, and it’s telling you the next step: open the Dashboard through an SSH tunnel.

1) First: don’t share that `#token=...` publicly

That token is basically the “password” for your Control UI.

If you pasted the full token in this thread, assume it’s compromised and rotate it on the VPS:

openclaw config set gateway.auth.token $(openssl rand -hex 32)

(After changing it you need to restart the gateway — see step 3/4 below.)

2) Start the Gateway (so the dashboard can connect)

On the VPS, run:

openclaw gateway

Leave that running for now (this is the simplest “beginner mode”).

3) From your computer, make the SSH tunnel

Run this on your laptop/desktop (replace the IP/host):

ssh -N -L 18789:127.0.0.1:18789 root@YOUR_SERVER_IP

Then open in your browser:

http://localhost:18789/

If it asks for auth, use the token from the VPS:

openclaw config get gateway.auth.token

4) About “Gateway restart failed…”

That usually just means the background service isn’t set up yet (not a big deal). Once you have the dashboard working, we can make it run 24/7 as a service.

To see what state you’re in, paste this output:

openclaw gateway status

And tell me: are you logged in as root (looks like yes), and what OS is the VPS (Ubuntu/Debian/etc.)?

That error means: your ~/.openclaw/openclaw.json contains a config option your current OpenClaw version doesn’t understand (so it refuses to start).

Fast fix (copy/paste on the VPS): remove that one key, then re-validate:

openclaw config unset 'models.providers["kimi-coding"].models[0].compat.requiresOpenAiAnthropicToolPayload'
openclaw config validate

If validate is clean, start the gateway again:

openclaw gateway

If you get another “Unrecognized key …” error, paste the next error line here and we’ll remove that one too.

(Also: avoid pasting any #token=... URLs in the thread — treat those as passwords.)

You’re at the shell prompt — now just paste this command exactly (then press Enter):

openclaw config unset 'models.providers["kimi-coding"].models[0].compat.requiresOpenAiAnthropicToolPayload'

Then run:

openclaw config validate

Copy/paste whatever it prints back here (especially if it shows another “Unrecognized key…”), and we’ll do the next fix.

That message is expected: OpenClaw won’t start the Gateway until your config says it’s a local gateway.

Easiest (recommended): run the onboarding wizard

On the VPS:

openclaw onboard --install-daemon

Follow the prompts — it will set gateway.mode=local for you (and help with models/channels).

Quick manual fix (if you want)

openclaw config set gateway.mode local
openclaw gateway

If it errors again after that, paste the next error output (it’ll tell us exactly what config key to fix).

Perfect — that means your config is now in the “allowed to run” state.

Next two things to do:

1) Open the Dashboard from your computer

On the VPS, run (don’t paste the token here):

openclaw dashboard

On your computer, do the SSH tunnel it prints, then open http://localhost:18789/.

2) Make it stay running (so it doesn’t die when you close SSH)

If you want the Gateway to run 24/7 on the VPS, try:

openclaw gateway install
openclaw gateway start
openclaw gateway status

If gateway start/status complains about the service setup (common when running as root), paste the openclaw gateway status output and I’ll tell you the clean “VPS always-on” way (systemd service vs non-root user).

If this fixed your immediate problem, please right‑click the message that solved it → Apps → ✅ Mark Solution so Answer Overflow indexes it.

OpenClaw doesn’t “pick a random provider” or magically connect to some other bot — it uses whatever credentials/config it finds on disk (or in env vars) on this server.

So if it looks like it’s using your “old provider” or “old bot”, it’s almost always because your VPS already has one of these:

an existing config file: ~/.openclaw/openclaw.json
an env file: ~/.openclaw/.env
saved auth profiles (models): ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
saved channel tokens (Discord bot token etc.) in the config

Quick checks (run on the VPS)

These will show what it’s actually using (don’t paste any tokens back here):

openclaw config file
openclaw models status
openclaw channels status

If you want a totally fresh install (no old creds/config)

The safest way is to use a new profile (separate state dir), e.g.:

openclaw --profile fresh onboard --install-daemon

That uses a new folder like ~/.openclaw-fresh, so it cannot reuse your old bot/provider settings.

If you paste the output of openclaw models status (it redacts secrets), I can tell you exactly which provider it detected and where it’s coming from.

If you want to wipe everything (config, credentials, workspace/memory) and reinstall fresh, do this on the VPS.

1) Uninstall (recommended)

This removes the Gateway service + state + workspace + CLI:

openclaw uninstall --all --yes --non-interactive

(You can run openclaw uninstall without flags if you want it to ask questions interactively.)

Docs: https://docs.openclaw.ai/install/uninstall

2) Reinstall

curl -fsSL https://openclaw.ai/install.sh | bash

openclaw onboard --install-daemon

If uninstall complains / doesn’t remove everything

Run these and paste the output (no secrets):

openclaw gateway status
openclaw config file

Also: since you’re logged in as root, your state dir is probably /root/.openclaw — the uninstall command should handle that automatically, but it’s good to know where it lives.

radiant runeBOT Mar 10, 2026, 9:22 PM

That’s usually fine — openclaw uninstall --all … wipes state + services, but the CLI binary can still be on PATH if it was installed globally via npm/pnpm (or your shell is caching it).

Do this on the VPS and paste the output:

type -a openclaw
which -a openclaw
openclaw --version

If you do want the CLI gone too

Remove it with the package manager that installed it (most VPS installs are npm):

npm rm -g openclaw
# (or: pnpm remove -g openclaw) # if you installed with pnpm

Then refresh your shell’s command cache:

hash -r

And verify:

command -v openclaw

If command -v openclaw still prints a path, send me that path (just the path, no tokens) and I’ll tell you exactly what to remove.

Yep — if command -v openclaw shows nothing, the CLI is gone.

To reinstall from scratch on the VPS:

curl -fsSL https://openclaw.ai/install.sh | bash

Then open a new SSH session (or run source ~/.profile) and check:

openclaw --version

Then run setup again:

openclaw onboard --install-daemon

If after the install script you still get “openclaw: command not found”, paste the output of:

npm config get prefix
echo $PATH

Yep — that means the config file you’re using still contains that old compat.requiresOpenAiAnthropicToolPayload key, so the new install hits the same validation error again.

Fastest fix: let Doctor remove unknown keys automatically:

openclaw doctor --repair
openclaw config validate

Doctor will:

write a backup like ~/.openclaw/openclaw.json.bak
drop unknown config keys (including that one) and tell you what it removed

Then try starting again:

openclaw gateway

If it still comes back after that, run this and paste the path it prints:

openclaw config file

That’ll tell us exactly which config file is being picked up (sometimes there’s an old profile/custom path).

Run openclaw gateway first (that’s the “does it start and work?” step).

Order I recommend

Fix/validate config (once):

openclaw doctor --repair
openclaw config validate

Start it now (foreground):

openclaw gateway

Once the Gateway is running and you can open the dashboard via SSH tunnel, then we can do the “install” step to make it run 24/7 in the background.

If you tell me whether you’re running as root (looks like yes) and whether your VPS uses systemd (Ubuntu usually does), I’ll give you the exact “install as a service” commands that won’t fight you.

That just means your config still doesn’t have gateway.mode set (fresh installs often start “unconfigured”).

Quick fix (VPS):

openclaw config set gateway.mode local
openclaw gateway

Alternative (more guided): run the wizard, which sets this (and more) for you:

openclaw onboard --install-daemon

After the gateway starts, you can run openclaw dashboard to get the URL + SSH tunnel instructions.

You’re back to the same problem: your config still contains that compat.requiresOpenAiAnthropicToolPayload key, and your current OpenClaw build doesn’t accept it, so it refuses to start.

Do this on the VPS (copy/paste):

1) Auto-fix (recommended)

openclaw doctor --repair
openclaw config validate

2) If it still complains, remove the key manually

openclaw config unset 'models.providers["kimi-coding"].models[0].compat.requiresOpenAiAnthropicToolPayload'
openclaw config validate

3) Then start the gateway

openclaw config set gateway.mode local
openclaw gateway

If step (1) doesn’t remove it, paste the output of openclaw config file (just the path it prints). That’ll tell us which config file is being used.

radiant runeBOT Mar 10, 2026, 10:10 PM

Good news: the Gateway is already running (pid 8823) and is listening on 127.0.0.1:18789 — that’s why openclaw gateway won’t start a second copy.

What to do now

Check it’s healthy:

openclaw gateway status

Open the dashboard (it will print the SSH tunnel command + URL):

openclaw dashboard

If you need to restart it (after config changes)

Use the supervised commands (not openclaw gateway):

openclaw gateway restart
# or:
openclaw gateway stop
openclaw gateway start

(And yeah, since you’re on a VPS it’s normal that port 18789 is “in use” — that’s the running gateway.)

That “agent model: anthropic/claude-opus-4-6” is just the current default model setting — it doesn’t necessarily mean you’re already authenticated to Anthropic.

Check if it actually has credentials

Run on the VPS:

openclaw models status

If Anthropic isn’t configured, you’ll see an auth warning there (and runs will fail until you add a key/token).

Change the default model/provider

Easiest (guided):

openclaw configure --section model

Or directly set the default model id (replace with the one you want):

openclaw config set agents.defaults.model.primary "provider/model"
openclaw gateway restart

(You can also switch per-chat with /model inside the chat UI once you’re messaging the agent.)

If you paste the non-secret part of openclaw models status output (it redacts keys), I can tell you exactly what’s currently configured and what’s missing.

Yep — you run the CLI commands in an SSH terminal on the VPS, while the gateway keeps running.

If your terminal is not currently showing gateway logs, you can just run the check right there:

openclaw models status

If your terminal is busy because you started the gateway in the foreground (openclaw gateway and it’s printing logs), then:
leave that running, and
open a second SSH window/tab to the VPS and run:

openclaw models status

The gateway doesn’t need to be stopped to run openclaw models status / openclaw config get etc.

Yep — “default: anthropic” just means your OpenClaw config is currently set to use Anthropic/Claude as the primary model provider.

Now you have two options:

Option A) You want to use Anthropic (Claude)

You need to add Anthropic credentials (API key or setup-token). Easiest is the guided flow:

openclaw configure --section model

Then restart the gateway:

openclaw gateway restart

Anthropic docs: https://docs.openclaw.ai/providers/anthropic

Option B) You don’t want Anthropic

Use the same wizard (openclaw configure --section model) and pick a different provider you have a key for, then openclaw gateway restart.

If you tell me which provider you want to use (and whether you have an API key already), I’ll give you the exact minimal steps for that one.

You don’t connect to a PID — the PID (9193) is just the process id on Linux.

You connect to the Gateway via its port (usually 18789):

Dashboard (on the VPS itself): http://127.0.0.1:18789/
Gateway WebSocket URL (for CLI/TUI): ws://127.0.0.1:18789

From your own computer (recommended: SSH tunnel)

On your computer:

ssh -N -L 18789:127.0.0.1:18789 root@YOUR_SERVER_IP

Then open:

http://localhost:18789/

Tip: running this on the VPS prints the exact URL + auth info:

openclaw dashboard

If the UI asks for a token, get it on the VPS with:

openclaw config get gateway.auth.token

“Kimi” is just the LLM provider/model. It doesn’t change where you chat from.

To talk to your OpenClaw bot, you have 2 easy options:

Option 1 (fastest): talk in the Dashboard

If you already have the Control UI open, go to the Chat section and type there — that’s talking directly to your agent.

Option 2: talk to it on Discord (your own bot)

Right now you’re chatting in this support thread — that’s not your bot. To chat with your bot on Discord you need to connect a Discord bot token:

Create a Discord bot + invite it to your server (docs):
https://docs.openclaw.ai/channels/discord
On the VPS set the token (don’t paste the token in Discord):

openclaw config set channels.discord.enabled true

openclaw config set channels.discord.token "YOUR_BOT_TOKEN"
openclaw gateway restart

DM your bot in Discord → it replies with a pairing code → approve it:

openclaw pairing list discord
openclaw pairing approve discord <CODE>

Then you can just DM it normally.

If you tell me which you want (Dashboard chat vs Discord DM), I’ll walk you through that exact path.

BOOTSTRAP.md is a one-time “first run” file OpenClaw drops into a brand‑new workspace.

What it’s for:

It triggers the bootstrapping ritual the first time your agent runs (a short Q&A).
OpenClaw uses that to create/populate your workspace files like AGENTS.md, IDENTITY.md, USER.md, SOUL.md.
When bootstrapping finishes, OpenClaw removes BOOTSTRAP.md automatically so it should only happen once.

Where it lives (default):

~/.openclaw/workspace/BOOTSTRAP.md (on the gateway host, i.e. your VPS)

If you keep seeing bootstrapping happen over and over, it usually means BOOTSTRAP.md got left behind (or the workspace keeps getting reset). In that case, deleting/moving BOOTSTRAP.md and restarting the gateway typically stops the “perpetual bootstrapping” loop.

Docs: https://docs.openclaw.ai/start/bootstrapping

That “Phase 1 / hourly learning cycles / commit research to git” spiel is not something you should blindly enable — especially on a brand‑new setup. It’s basically your agent trying to become an autonomous “research daemon”, which will (a) burn tokens/money, and (b) do a bunch of stuff you probably didn’t ask for yet.

What I recommend (safe default)

Do NOT set up hourly anything yet. Get basic chat working first (model auth + your chat channel).
If you want to stop the bot from doing periodic runs, disable heartbeat for now:

openclaw config set agents.defaults.heartbeat.every "0m"
openclaw gateway restart

(You can re-enable later with something like "2h" / "24h" once you actually want it.)

About `BOOTSTRAP.md`

Yes — once bootstrapping is done, BOOTSTRAP.md is supposed to be deleted/removed. If it’s still sitting in your workspace and the agent is asking, it’s fine to delete it.

If you want, paste the first ~20 lines of your BOOTSTRAP.md (no secrets) — that “commit research to git” tone often comes from whatever got put in there.

To open the Control UI (Dashboard) when your Gateway is on a VPS:

1) On the VPS, print the dashboard URL + token instructions

openclaw dashboard

2) From your own computer, make an SSH tunnel to the VPS

ssh -N -L 18789:127.0.0.1:18789 root@YOUR_SERVER_IP

3) Open it in your browser

http://localhost:18789/

If it asks for auth, get the token on the VPS with:

openclaw config get gateway.auth.token

Docs: https://docs.openclaw.ai/web/dashboard and https://docs.openclaw.ai/gateway/remote

That’s normal — OpenClaw redacts secrets (tokens/keys) in a lot of CLI output so you don’t accidentally paste them into Discord.

You can still open the Control UI like this:

Make the SSH tunnel (from your computer):

ssh -N -L 18789:127.0.0.1:18789 root@YOUR_SERVER_IP

Open:

http://localhost:18789/

If the UI asks for the token, get it on the VPS (don’t paste it here):

openclaw config get gateway.auth.token

If that prints nothing / you truly don’t have a token yet, generate one:

openclaw doctor --generate-gateway-token
openclaw gateway restart

When you say “I don’t see it” — do you mean:

you don’t see the Control UI webpage at http://localhost:18789/ (browser can’t connect), or
you don’t see the gateway token (for auth)?

If the browser can’t connect

On the VPS run this and paste the output (safe; tokens are redacted):

openclaw gateway status

If the page loads but you don’t have a token

On the VPS, run:

openclaw config get gateway.auth.token

It should print a long string. Don’t paste it here. Just tell me “it printed a token” vs “it printed nothing”.

If it prints nothing, generate one + restart:

openclaw doctor --generate-gateway-token
openclaw gateway restart

Also confirm your SSH tunnel command is running on your computer (it should just “sit there” with no output):

ssh -N -L 18789:127.0.0.1:18789 root@YOUR_SERVER_IP

Yep — when ssh -N -L ... “just sits there”, the tunnel is up. Don’t close that terminal while you’re using the Control UI, because closing it will drop the tunnel.

If you want it not to “take” a window, you can:

keep it open in a second terminal tab, or
run it under tmux, or
use background mode: ssh -fN -L 18789:127.0.0.1:18789 root@<server-ip>

About “there is no token”

Your gateway is reachable (RPC probe is ok), so you just need to ensure dashboard auth is configured in a way you can use.

On the VPS, run these (don’t paste the token output here):

openclaw config get gateway.auth.mode

openclaw config get gateway.auth.token

If `gateway.auth.token` prints nothing

Set a fresh token + restart:

openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token $(openssl rand -hex 32)
openclaw gateway restart

Then open the UI at http://localhost:18789/ (through the SSH tunnel) and paste that token into the Control UI’s gateway auth field.

If you just want to avoid tokens (OK for loopback+tunnel while you’re learning)

openclaw config set gateway.auth.mode none
openclaw gateway restart

Tell me what openclaw config get gateway.auth.mode prints (just the mode), and whether the UI error says “unauthorized” vs “can’t connect”.

Nice — you did it correctly: you set gateway.auth.mode=token, generated a token, and restarted the systemd service.

Now the last step is purely in your browser:

Keep the SSH tunnel running on your computer:

ssh -N -L 18789:127.0.0.1:18789 root@<your-server-ip>

Open the Control UI:

http://localhost:18789/

If it says Unauthorized / asks for auth:

On the VPS run (don’t paste it here):

openclaw config get gateway.auth.token

Copy that token into the Control UI Gateway Token field (Control → Overview → Gateway Access), then Connect.

If you tell me what you see in the browser (“can’t reach”, “unauthorized”, or it loads), I’ll guide the exact next click.

No — the gateway token is not “words”. It’s usually a long random string (often hex: letters a–f + numbers), like:

a3f0c1... (example)

When you run:

openclaw config get gateway.auth.token

…copy the entire string it prints and paste it into the Control UI “Gateway Token” field.

Important: don’t paste that token into Discord (treat it like a password).

That __OPENCLAW_REDACTED__ is expected — openclaw config get always hides secrets (tokens/keys), so it won’t print the gateway token.

To get the token in a safe-ish way, use the dashboard helper (it can print a tokenized URL):

openclaw dashboard --no-open

It will print something like:

Dashboard URL: http://127.0.0.1:18789/#token=...

With your SSH tunnel running, open the same URL on your computer (swap to localhost):

http://localhost:18789/#token=...

Important: don’t paste that URL/token into Discord.

If you’d rather avoid tokens entirely while you’re learning, you can also do:

openclaw config set gateway.auth.mode none
openclaw gateway restart

…and then http://localhost:18789/ should work without auth.

Awesome — that’s the tricky part on VPS setups (tunnel + token) and you nailed it.

Next steps (pick one):

Talk to it right now: use the Control UI Chat tab.
Use it on Discord: follow https://docs.openclaw.ai/channels/discord (set channels.discord.token, restart, DM the bot, approve pairing).

If this solved your Control UI access issue, please right‑click the message that helped most → Apps → ✅ Mark Solution so it’s indexed on Answer Overflow.

Discord isn’t “better” — it’s just different.

Telegram is usually the easiest choice for a personal bot (DM-first, great on mobile, simple mental model).
Discord is great if you want a server with channels/threads, slash commands, and a “workspace” vibe.

If you want Telegram (recommended for personal use)

Create a bot token with @BotFather (/newbot).
On your VPS, set it (don’t paste the token into Discord):

openclaw config set channels.telegram.enabled true
openclaw config set channels.telegram.botToken "123:abc"
openclaw gateway restart

DM your Telegram bot → it will reply with a pairing code → approve it:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Docs: https://docs.openclaw.ai/channels/telegram

If you tell me whether you only want DMs (just you) or also groups, I’ll give you the minimal safe settings for that.

radiant runeBOT Mar 11, 2026, 12:17 AM

If your goal is “do research every 30 minutes”, you generally want Heartbeat, not cron.

What’s happening right now is probably:

Heartbeat is running, but not delivering anywhere (default target: "none"), so your agent tries to “fix it” by creating cron jobs that announce to Telegram.

1) Delete/stop the cron jobs your bot created

On the VPS:

openclaw cron list

Then remove the unwanted ones:

openclaw cron rm <job-id>

# (aliases: remove / delete)

2) Configure heartbeat to run every 30m and actually message you

The key is setting a delivery target:

openclaw config set agents.defaults.heartbeat.every "30m"
openclaw config set agents.defaults.heartbeat.target "last"
openclaw gateway restart

Then send your bot a Telegram DM once so “last” becomes Telegram.

(Optional but recommended: limit to active hours so it doesn’t spam you at night — can add heartbeat.activeHours later.)

3) Update `HEARTBEAT.md` to forbid cron creation

In your workspace (usually ~/.openclaw/workspace/HEARTBEAT.md), add a line like:

“Do not create/modify cron jobs. Use heartbeat only.”

Docs:

Heartbeat: https://docs.openclaw.ai/gateway/heartbeat
Cron vs Heartbeat: https://docs.openclaw.ai/automation/cron-vs-heartbeat

If you paste the output of openclaw cron list (it’s safe), I can tell you exactly which job IDs to remove.

Creating .md files isn’t inherently bad — it’s often good if you want the bot to persist research in your workspace (so you can review later, search it, etc.). research/02-server-audit.md sounds totally reasonable.

It becomes bad only if it starts spamming tons of files and you can’t find anything anymore (or if it accidentally writes secrets).

How to control it (recommended)

Update your HEARTBEAT.md to be explicit, e.g.:

“Do not create new files by default.”
“Write updates by appending to one rolling log instead.”

Example rule you can paste into HEARTBEAT.md:

“Append each run to research/heartbeat-log.md (add a timestamp header). Do not create new files unless I explicitly ask.”

That way you still get the benefit (saved learnings) without workspace clutter.

If you paste your current HEARTBEAT.md (or just the part about research), I can suggest a tight version that avoids cron + avoids file-sprawl.

radiant runeBOT Mar 11, 2026, 12:48 AM

In openclaw models status, the “auth probes” section is basically: “which providers have working creds, and which auth profile would be tried first.” Seeing one as default and one as manual is normal (it just reflects how the creds were configured / which profile is first).

Set Kimi as a fallback model

Fallbacks are controlled by:

agents.defaults.model.primary
agents.defaults.model.fallbacks (array, tried in order when the primary fails)

Do this on the VPS:

Find the exact Kimi model ref you have available:

openclaw models list

Set it as a fallback (replace the placeholder with the exact provider/model you saw):

openclaw config set agents.defaults.model.fallbacks '["<kimi-provider/model>"]' --strict-json
openclaw gateway restart

Verify:

openclaw models status

Two gotchas:

Fallback only kicks in when the primary errors (rate limit/auth/down), not “when it feels hard.” For switching intentionally, use /model.
If you use a model allowlist (agents.defaults.models), make sure your Kimi model is included there too, otherwise you’ll get “Model is not allowed.”

If you paste the non-secret output of openclaw models list (just the lines that show the Kimi refs), I’ll tell you exactly what to put in the fallbacks array.

If openclaw models list only shows Anthropic, it usually means your current model catalog/allowlist only contains Anthropic — even if you think you “set up Kimi”.

Two common reasons:

You set up Kimi for web search (tools), not as an LLM model provider.
Your Kimi provider config got removed during the earlier doctor --repair / config cleanup, so it’s no longer in agents.defaults.models / models.providers.

Quick check (safe to paste)

On the VPS, run:

openclaw models status
openclaw config get agents.defaults.model.primary

Add Kimi back as a model provider (recommended: wizard)

Use the onboarding auth choice for Moonshot/Kimi:

openclaw onboard --auth-choice moonshot-api-key
# or, for Kimi Coding:
openclaw onboard --auth-choice kimi-code-api-key

That will add the provider + model refs so openclaw models list can show them.

Docs: https://docs.openclaw.ai/providers/moonshot

If you paste the output of openclaw models status (it redacts secrets), I can tell you which of the two cases you’re in and the minimal fix.

Perfect — that output explains it:

You do have Kimi credentials (kimi-coding:default=...)
But your configured model allowlist only contains one model (Configured models (1): anthropic/...)

So Kimi is “available auth-wise”, but it’s not in your configured model catalog yet.

Add Kimi to your configured models + set it as a fallback (easy way)

See the Kimi-coding models from the full catalog:

openclaw models list --all --provider kimi-coding

Pick the one you want, then add it as a fallback (this also auto-adds it to agents.defaults.models):

openclaw models fallbacks add kimi-coding/<model-id>
openclaw gateway restart

Verify:

openclaw models status

You should then see Fallbacks (1): ... and Configured models (2): ....

If you paste just the output of openclaw models list --all --provider kimi-coding (model IDs only), I’ll tell you which exact string to plug into the fallbacks add command.

You don’t need JSON or nano for this — use the Control UI file editor.

Add prompts to Heartbeat (the easy way)

Open the Control UI.
Go to Files (workspace files).
Open (or create) a file named HEARTBEAT.md in your workspace.
Paste something like this and click Save:

# Heartbeat research (runs every 30 minutes)

Rules:
- Do NOT create cron jobs.
- Do NOT create lots of new files.
- Append notes to: research/heartbeat-log.md (add a timestamp header each run).

Task:
- Spend max 5 minutes researching: markets + tech + anything relevant to my environment/server.
- Output to Telegram:
- 5 bullet summary
- 1-3 useful links/sources
- 1 suggestion of what to do next
- If there’s nothing worth reporting, reply exactly: HEARTBEAT_OK

That’s it — the next heartbeat run will follow the updated HEARTBEAT.md (no restart needed).

If you tell me what exact “prompts” you want (markets/AI news/server health/etc.), I can rewrite that template to match your goal and keep it low-noise.

Yep — you can just tell your bot to create/update HEARTBEAT.md for you. The trick is to be very explicit about:

which file to edit
what content to put in it
what not to do (no cron jobs, no file spam)

Here’s a solid copy/paste prompt you can send to your bot:

Prompt to your bot:
“Please update the file HEARTBEAT.md in your workspace (create it if missing).
Set its content exactly to the text below.
Important: do not create any cron jobs, and do not create lots of new files. Only edit HEARTBEAT.md (and if needed, create research/heartbeat-log.md). After saving, show me the final contents of HEARTBEAT.md.”
# Heartbeat research (every 30 minutes)

Rules:

Do NOT create or modify cron jobs.

Do NOT create many new files. Reuse existing ones.

Append notes to: research/heartbeat-log.md (add a timestamp header each run).

Task:

Spend max 5 minutes researching: AI/tools news + market updates + anything relevant to my current projects.

Send me a Telegram message with:

5 bullet summary

1–3 links/sources

1 recommended next action

If there’s nothing worth reporting, reply exactly: HEARTBEAT_OK
“Then stop.”

After it does that, quickly open the file in Control UI → Files and sanity-check it once.

If you don’t see a “Files” section in the Control UI, that’s normal — the Control UI is great for chat/config/status, but it’s not a general “browse/edit all workspace files” editor.

To edit HEARTBEAT.md without nano or JSON, you’ve got two easy options:

Option A (easiest): ask your bot to write the file

Use the prompt we discussed (“create/update HEARTBEAT.md with this exact content…”).

Option B (manual, no editor): copy/paste a one-liner on the VPS

SSH into the VPS and run:

cat > ~/.openclaw/workspace/HEARTBEAT.md <<'EOF'
# Heartbeat research (every 30 minutes)

Rules:
- Do NOT create or modify cron jobs.

- Do NOT create lots of new files.
- Append notes to: research/heartbeat-log.md (timestamp each run).

Task:
- Spend max 5 minutes researching: AI/tools news + market updates + anything relevant to my projects.
- Message me on Telegram with:
- 5 bullet summary
- 1–3 links/sources
- 1 recommended next action
- If nothing worth reporting: HEARTBEAT_OK
EOF

No restart needed — the next heartbeat run will read the updated file.

If you want, I can tailor that template to exactly what “research” means for you (server health, AI news, crypto, coding updates, etc.).

To sanity‑check what your bot wrote, look at the workspace file on the VPS.

Default location (most setups):

~/.openclaw/workspace/HEARTBEAT.md
(as root: /root/.openclaw/workspace/HEARTBEAT.md)

If you want to confirm the workspace path first:

openclaw config get agents.defaults.workspace

Then view the heartbeat file:

ls -la ~/.openclaw/workspace/HEARTBEAT.md

sed -n '1,200p' ~/.openclaw/workspace/HEARTBEAT.md

(Use sed so you don’t accidentally dump a huge file.)

Nice — that confirms the file exists in the right place.

Now print it so you can sanity‑check what it says:

sed -n '1,200p' ~/.openclaw/workspace/HEARTBEAT.md

If you paste the output here (it shouldn’t contain any secrets), I’ll review it and tell you if anything in it would cause the cron-job/file-spam behavior.

On the VPS, simplest manual edit options are:

Option A) `nano` (beginner-friendly)

nano ~/.openclaw/workspace/HEARTBEAT.md

Nano shortcuts:

Save: Ctrl + O (then Enter)
Exit: Ctrl + X

Option B) No editor at all (overwrite with copy/paste)

This replaces the whole file with whatever you paste:

cat > ~/.openclaw/workspace/HEARTBEAT.md <<'EOF'

# paste your new HEARTBEAT.md content here
EOF

Option C) Quick append (add lines to the end)

cat >> ~/.openclaw/workspace/HEARTBEAT.md <<'EOF'
# extra lines to append
EOF

Edits take effect on the next heartbeat run (no restart needed).

That HEARTBEAT.md looks solid. It has the two big guardrails that prevent the chaos you were seeing:

“Do NOT create cron jobs”
“Do NOT create many new files”

Two small things to double‑check so it actually messages you every 30 min:

1) Make sure heartbeat is set to 30m

openclaw config get agents.defaults.heartbeat.every

If it’s not 30m, set it:

openclaw config set agents.defaults.heartbeat.every "30m"
openclaw gateway restart

2) Make sure heartbeat delivery target isn’t “none”

By default, heartbeat can run but not deliver anywhere. Check:

openclaw config get agents.defaults.heartbeat.target

If it’s empty/none, set it to send to your last contact (after you DM it on Telegram once):

openclaw config set agents.defaults.heartbeat.target "last"
openclaw gateway restart

Optional improvement (later): add “only send if there’s something new since last run” so you don’t get repetitive updates every 30 minutes.

Cool — here’s a clean “anti-repeat / only send when new” upgrade you can paste into HEARTBEAT.md.

Replace your current file with this (or just copy the New anti-repeat rules section into yours):

# Heartbeat research (every 30 minutes)

## Rules:

- Do NOT create or modify cron jobs.
- Do NOT create many new files. Reuse existing ones.
- Append notes to: research/heartbeat-log.md (add a timestamp header each run).
- New anti-repeat rules:
- Before doing any research, read the last entry (or last ~200 lines) of `research/heartbeat-log.md`.
- If you cannot find at least **2 genuinely new items** (new links or updates not already in the log from the last ~24h),
then do NOT send me a message and do NOT write anything new to the log.

Reply exactly: HEARTBEAT_OK

## Task (only if you found >= 2 new items):

- Spend max 5 minutes researching: AI/tools news + market updates + anything relevant to my current projects.
- Send me a Telegram message with:
- 5 bullet summary (no fluff)
- 1–3 links/sources (prefer links you did NOT use last time)
- 1 recommended next action
- Then append the same summary + links to `research/heartbeat-log.md` under a timestamp header.
- If there's nothing worth reporting, reply exactly: HEARTBEAT_OK

Then stop.

If you want, I can also tweak it so the log rotates daily (e.g. research/heartbeat-log-YYYY-MM-DD.md) so it doesn’t grow forever.

Yep — it’s the right idea, but the Markdown formatting got mangled (a few bullets aren’t nested, and HEARTBEAT_OK ended up jammed onto the same line). The bot will probably still understand it, but it’s worth fixing so it’s unambiguous.

Here’s a cleaned-up version you can paste over the file:

# Heartbeat research (every 30 minutes)

## Rules

- Do NOT create or modify cron jobs.
- Do NOT create many new files. Reuse existing ones.
- Append notes to: `research/heartbeat-log.md` (add a timestamp header each run).
- New anti-repeat rules:
- Before doing any research, read the last entry (or last ~200 lines) of `research/heartbeat-log.md`.
- If you cannot find at least **2 genuinely new items** (new links or updates not already in the log from the last ~24h),
then do NOT send me a message and do NOT write anything new to the log.

Reply exactly: `HEARTBEAT_OK`

## Task (only if you found >= 2 new items)

- Spend max 5 minutes researching: AI/tools news + market updates + anything relevant to my current projects.
- Send me a Telegram message with:
- 5 bullet summary (no fluff)
- 1–3 links/sources (prefer links you did NOT use last time)
- 1 recommended next action
- Then append the same summary + links to `research/heartbeat-log.md` under a timestamp header.
- If there's nothing worth reporting, reply exactly: `HEARTBEAT_OK`

Then stop.

Key fix: make sure HEARTBEAT_OK is on its own line and the “Send me…” list is properly nested.

Fastest way (no editor skills needed) is to overwrite the file with a copy/paste block:

cat > ~/.openclaw/workspace/HEARTBEAT.md <<'EOF'
# Heartbeat research (every 30 minutes)

## Rules

- Do NOT create or modify cron jobs.
- Do NOT create many new files. Reuse existing ones.
- Append notes to: `research/heartbeat-log.md` (add a timestamp header each run).
- New anti-repeat rules:
- Before doing any research, read the last entry (or last ~200 lines) of `research/heartbeat-log.md`.
- If you cannot find at least **2 genuinely new items** (new links or updates not already in the log from the last ~24h),
then do NOT send me a message and do NOT write anything new to the log.
Reply exactly: `HEARTBEAT_OK`


## Task (only if you found >= 2 new items)

- Spend max 5 minutes researching: AI/tools news + market updates + anything relevant to my current projects.
- Send me a Telegram message with:
- 5 bullet summary (no fluff)
- 1–3 links/sources (prefer links you did NOT use last time)
- 1 recommended next action
- Then append the same summary + links to `research/heartbeat-log.md` under a timestamp header.
- If there's nothing worth reporting, reply exactly: `HEARTBEAT_OK`

Then stop.
EOF

Then sanity check:

sed -n '1,200p' ~/.openclaw/workspace/HEARTBEAT.md

Yep — that’s the idea:

The Gateway triggers a heartbeat run every agents.defaults.heartbeat.every (e.g. 30m).
On each heartbeat, the agent reads HEARTBEAT.md and follows it (your “do research” checklist).
If it finds ≥2 new items, it should message you on Telegram (assuming your heartbeat target is set to deliver, e.g. "last" and the last contact is Telegram).
If there’s nothing new, it replies HEARTBEAT_OK and you won’t get spammed.

Two quick requirements:

Gateway must be running 24/7 (heartbeats stop if it’s down).
Heartbeat delivery target must be set (otherwise it can run but not send).

If you want, paste:

openclaw config get agents.defaults.heartbeat.every
openclaw config get agents.defaults.heartbeat.target

…and I’ll confirm it’s wired to Telegram correctly.

It won’t “magically know” a goal — you give it the goal via the workspace files that get injected into its context.

For heartbeat runs specifically, the bot’s marching orders are:

The built-in heartbeat prompt: “Read HEARTBEAT.md… follow it strictly…”
Whatever you write inside HEARTBEAT.md (that’s effectively the goal)
Longer-term direction in USER.md / AGENTS.md (optional, but useful)

Practical tip

Add an explicit goal block at the top of HEARTBEAT.md, e.g.:

## Goal
Keep me up to date on AI/tools + markets that affect my projects, and suggest 1 concrete next step.

If you want a “forever goal” (not just heartbeat), put it in USER.md too, then have HEARTBEAT.md say “use the goals in USER.md”.

The more specific you are about what counts as success (topics, time budget, when to send vs HEARTBEAT_OK), the more consistent it’ll behave.

That’s a good way to use OpenClaw — just keep the expectations realistic:

The model doesn’t “train itself” or permanently get smarter.
What does happen is: it accumulates a better knowledge base in your workspace, so future heartbeats (and you) can reference it. That’s “smarter” in practice.

The clean pattern (so it doesn’t spiral into cron/jobs/file spam)

Create 2–3 stable files in your workspace:

GOALS.md (your phases/plan — mostly stable)
research/heartbeat-log.md (raw running log; append-only)
research/kb.md (curated knowledge base; edit in place)

Then update your HEARTBEAT.md to explicitly say:

“Read GOALS.md first”
“Append raw findings to research/heartbeat-log.md”
“Only if something is durable and truly new, update research/kb.md”

“Do NOT create cron jobs / do NOT change config / do NOT create lots of new files”

Example add-on you can paste near the top of HEARTBEAT.md:

## Long-term goal
Continuously build a useful knowledge base that supports my phases in GOALS.md.

## Knowledge base rules
- Read GOALS.md at the start of each run.
- Append raw notes to research/heartbeat-log.md.
- If (and only if) you learned something durable/new, update research/kb.md (curated bullets).
- Never create cron jobs or change config.

If you want, paste the “phases/plan” (high level) and I’ll turn it into a tight GOALS.md + HEARTBEAT.md combo that’s stable, low-noise, and won’t drift.

Copy/paste this to your bot (Telegram/Control UI chat). It tells it to set up the “GOALS + KB + log + heartbeat rules” system without cron:

Prompt to send to your bot:

Create a simple, durable “knowledge base” structure in my OpenClaw workspace and wire it into heartbeat.

Hard rules (must follow):

Do NOT create or modify cron jobs.

Do NOT change any config values.

Do NOT run git / do NOT commit anything.

Do NOT create lots of new files — only create the files listed below if missing.

Files to create (only if missing):

GOALS.md — summarize the phases/plan we already discussed into a clear outline (goal + phases + success criteria).

research/kb.md — a curated knowledge base (structured bullets, short, organized by topic).

research/heartbeat-log.md — an append-only running log (timestamped entries).

Update: HEARTBEAT.md

Add a “Long-term goal” section that says the heartbeat should continuously build knowledge in support of GOALS.md.

Add “Knowledge base rules”:

Read GOALS.md at the start of each heartbeat.

Append raw notes to research/heartbeat-log.md (timestamp each run).

Only if you found 2+ genuinely new items (not already in the last ~24h of the log), send me a Telegram message + update research/kb.md.

If not, reply exactly HEARTBEAT_OK and do not write anything.

Keep the existing constraints: max 5 minutes research, no file spam, no cron.

Output requirement:

After you’re done, print the final contents of GOALS.md, research/kb.md (just the headings/structure if it’s long), research/heartbeat-log.md (just the first lines), and the updated HEARTBEAT.md.

If you want, paste your current HEARTBEAT.md + a short description of your phases, and I’ll tailor the prompt so it matches your plan exactly.

Got it — “trading bot” is a perfect fit for phased goals.

One strong recommendation up front: keep execution hard‑gated. Let OpenClaw do research + paper trading + journaling, but don’t let it place real trades automatically until you’ve got risk controls + a review/approval step you trust.

If you paste that prompt to your bot, tell it your phases explicitly, e.g. add this to the top of the message:

Phase 1 (Research): gather signals/news, summarize, update KB.
Phase 2 (Paper trading): generate trade ideas + simulate entries/exits, log results.
Phase 3 (Execution): only after explicit approval, and with strict risk limits (position sizing, max daily loss, stop rules).

Also add a hard rule like:

“Never place real trades or connect to exchange APIs unless I explicitly tell you to (and always ask before executing).”

If you want, paste your current HEARTBEAT.md after your bot updates it, and I’ll sanity‑check that it won’t drift into “auto-trade” mode.

Read it. Two different verdicts:

What’s genuinely good

Your HEARTBEAT.md structure is strong:

“read GOALS.md + read kb.md first” (prevents duplicate work)
“no cron / no config changes / no git”
“5 min cap”
“only message if 2+ new items”
log + curated KB split

That part is exactly how to keep a 30‑min heartbeat useful instead of chaotic.

What I would change immediately (important)

The GOALS.md is written in a way that will push the agent toward unsafe / unwanted autonomy:

“operate without Eve”, “while Eve sleeps”, “nothing off limits if it’s profitable”

“surprising Eve”, “reduce dependence” in a way that encourages acting without consent
For a trading bot, that’s a fast path to bad outcomes (financial + ToS + legal).

Safer rewrite (recommended)

Keep the phased structure, but make the constraints explicit, e.g.:

No real-money execution without explicit approval (until you intentionally loosen that)
No illegal/unethical stuff, no ToS violations, no market manipulation
Risk limits (max daily loss, position sizing, stop conditions)
No secrets in markdown (no API keys in kb/log)

If you want, I can rewrite your GOALS.md into a “research → paper trading → live trading (approval gated)” plan that keeps the same vibe but removes the “nothing off limits / autonomous while you sleep” trap.

If you reply with: (1) what market you’re targeting (crypto only? Solana memecoins?), and (2) whether you ever want fully automatic execution or always human-confirmed, I’ll tailor the rewrite.

spark nexus Mar 11, 2026, 1:48 AM

s!unmute @brazen pond

marsh copperBOT Mar 11, 2026, 1:48 AM

spark nexus s!unmute <@1441431480038326394>

success @rft123456789 unmuted

Errors

DM not sent: User disabled DMs.

radiant runeBOT Mar 11, 2026, 2:56 AM

Use this one:

openclaw dashboard --no-open

It prints a Dashboard URL like http://127.0.0.1:18789/#token=... (token included in the #token= part).

openclaw config get gateway.auth.token will show __OPENCLAW_REDACTED__, so dashboard --no-open is the practical way.

Don’t paste the token into Discord.

radiant runeBOT Mar 11, 2026, 4:49 AM

Fallback helps after the primary model fails — it doesn’t prevent OpenClaw from first trying the primary and hitting a 429. So with frequent heartbeats (and research) you can still slam into rate limits even if Kimi is configured as fallback.

Two quick things to check + the usual fix:

1) Which provider is rate-limiting you?

Paste the exact error line (from logs). On the VPS:

openclaw logs --follow

Look for HTTP 429 / rate_limit_error and which provider it names (anthropic vs kimi-coding vs moonshot).

2) Confirm fallbacks are actually set

openclaw models status

Make sure it shows your Kimi model under Fallbacks.

3) Best fix for “heartbeats hit rate limits”: run heartbeats on Kimi directly

Instead of using Anthropic as primary and hoping fallback saves you, set the heartbeat model override to Kimi (use the exact Kimi model ref you already added as a fallback):

openclaw config set agents.defaults.heartbeat.model "kimi-coding/<your-model-id>"
openclaw gateway restart

That way your 30‑minute research loop won’t keep hammering Anthropic first.

If you paste the 429 error text (and the top of openclaw models status showing primary+fallbacks), I’ll tell you exactly which knob to turn (heartbeat model vs default model vs interval).

Those lines mean failover tried everything it had available and still hit rate limits, so the run ended with FailoverError. Having Kimi as a fallback doesn’t help if:

Kimi is also rate-limited (or out of quota), or
the run is pinned to a single model/provider, or
your heartbeat/research loop is simply too frequent for the quotas you have.

Stop the bot from hammering the APIs (recommended right now)

Temporarily slow/disable heartbeats so it stops retrying while you’re rate-limited:

openclaw config set agents.defaults.heartbeat.every "0m"
openclaw gateway restart

(Or set it to "1h" / "2h" instead of disabling.)

Find out which provider is rate-limiting you

Run this and paste the output (it redacts secrets):

openclaw status --all

That usually shows which model/provider got 429’d and whether it attempted the fallback.

Long-term fixes

Increase the interval (30m research loops can burn through quotas fast).
Set heartbeats to run on the cheaper/higher-quota provider directly:
agents.defaults.heartbeat.model = "<your kimi model>" (so it doesn’t hit Anthropic first).
Make sure you’re on a paid API key plan / sufficient quota for the provider(s) you’re using.

Paste openclaw status --all and I’ll tell you exactly what it tried and what to change.

Got the status --all dump — that one doesn’t include the model/provider error details, so it doesn’t tell us which API is rate-limiting you. It does confirm the gateway is up and you’ve got a running openclaw-gateway on 127.0.0.1:18789.

A couple key points about the rate limit issue:

Fallback only helps if the fallback provider isn’t also rate-limited.
With a 30‑minute heartbeat doing research, it’s very easy to hit limits on both Anthropic and Kimi.

1) First: pause the heartbeats so you stop hammering limits

(so your quotas can cool down)

openclaw config set agents.defaults.heartbeat.every "0m"
openclaw gateway restart

2) Then show me your model/failover setup again

Run and paste:

openclaw models status

3) Best long-term fix for your setup

Once we confirm which provider is limiting, set heartbeats to use the provider with more headroom directly, e.g.:

openclaw config set agents.defaults.heartbeat.model "<your-kimi-model-ref>"
openclaw config set agents.defaults.heartbeat.every "1h"
openclaw gateway restart

That avoids “Anthropic gets 429’d first, then Kimi also 429’s” on every heartbeat.

If you paste your current openclaw models status + the next 10–20 log lines above the FailoverError, I can tell you exactly which provider is rate-limiting and what to change.

Totally fine to keep Anthropic as your default and Kimi as fallback — but two realities:

Fallback doesn’t stop Anthropic from being hit first, so you can still slam into Anthropic 429s on a frequent heartbeat loop.
If you’re seeing a final FailoverError, that usually means either:

Kimi wasn’t actually attempted, or
Kimi was attempted but failed for some other reason (model/tool incompat, not allowed, etc.).

Quick verification (so we’re not guessing)

Paste this:

openclaw models status

In the next failure, grab ~20 lines above the 429 from your logs (openclaw logs --follow) so we can see if it tried Kimi after Anthropic.

Best practical setup (keeps Anthropic primary, avoids rate limits)

Keep Anthropic as your normal/chat model, but run heartbeats on Kimi (since you say Kimi has headroom). Heartbeat has its own model override:

openclaw config set agents.defaults.heartbeat.model "<your-kimi-model-ref>"
openclaw gateway restart

This preserves “Anthropic is my default”, while your 30‑minute research automation doesn’t constantly trigger Anthropic rate limits.

If you insist Anthropic must also be used for the 30‑minute research, the only real fix is: reduce frequency or upgrade/raise Anthropic quota (API key billing usually has better headroom than subscription tokens).

Your fallback config is correct:

Default = Anthropic
Fallbacks = kimi-coding/k2p5

The suspicious bit in your models status is this line:

source=env: KIMICODE_API_KEY

That often means: Kimi works in your interactive shell, but when the Gateway runs as a systemd service it may not have that env var → so failover can’t actually use Kimi when Anthropic 429s, and you end up with a FailoverError.

Fix: make the Kimi key available to the Gateway service

Put it in ~/.openclaw/.env on the VPS (this is specifically for “service doesn’t inherit my shell env”):

On the VPS, create/edit (don’t paste the key into Discord):

nano ~/.openclaw/.env

Add a line:

KIMICODE_API_KEY=sk-...

(KIMI_API_KEY=... also works for kimi-coding, but use the one you already have.)

Restart the gateway:

openclaw gateway restart

Alternative (no .env file): store it as an auth profile

Run:

openclaw models auth add

…and add the kimi-coding API key there (so it’s not dependent on env vars).

If you want, paste the next failure’s log lines above the FailoverError — we should see whether it’s failing with “missing auth for kimi-coding” right after the Anthropic 429.

Yep — you can do it without nano or JSON.

Option A (recommended): safe prompt, no key in shell history

Copy/paste this on the VPS:

umask 077
mkdir -p ~/.openclaw
read -s -p "Paste KIMICODE_API_KEY (input hidden): " KIMI; echo
printf 'KIMICODE_API_KEY=%s\n' "$KIMI" >> ~/.openclaw/.env
unset KIMI
openclaw gateway restart

That writes the key to ~/.openclaw/.env with safe file perms, then restarts.

Option B (interactive, also no JSON): store key in auth profiles

openclaw models auth add

Then pick provider kimi-coding and paste the key when prompted.

Either way: don’t paste the key into Discord.

Nice — openclaw models auth add is the cleanest fix, because it stores the key in the auth profile store that the gateway service can always read (no “shell env vs systemd env” mismatch).

Quick verification:

openclaw models status

You should see Kimi creds coming from auth-profiles.json (not only source=env), and your fallback should now actually work when Anthropic 429s.

If this fixed the failover/rate-limit issue, please right‑click the message that solved it → Apps → ✅ Mark Solution so it’s indexed.

That env=… source=env: KIMICODE_API_KEY line is not automatically a problem — it just means OpenClaw currently sees a KIMICODE_API_KEY value available in the environment (from your shell and/or ~/.openclaw/.env / config env block).

The important parts for “will fallback work?” are:

Fallbacks (1): kimi-coding/k2p5
Configured models (2): …, kimi-coding/k2p5
Kimi provider shows profiles=1 (it has a usable credential)

If you want to be 100% sure you’re not depending on your interactive shell env, do this quick check (don’t paste any outputs with secrets):

unset KIMICODE_API_KEY KIMI_API_KEY
openclaw models status

If Kimi still shows up → it’s stored/available independently (good).
If Kimi disappears → you were relying on env only, and you should put the key in ~/.openclaw/.env or re-add it via the proper auth flow for that provider.

But if your failover is now working in practice, you can also just ignore the env= line — it’s informational.

You don’t need to stop the gateway to connect to it — if it’s running, you can just grab a fresh dashboard URL/token and reconnect.

Step 1: See what’s actually running

Run and paste this output:

openclaw gateway status

If it says `RPC probe: ok` / `Listening: 127.0.0.1:18789`

Just reconnect:

openclaw dashboard --no-open

(Open the printed http://127.0.0.1:18789/#token=... via your SSH tunnel as http://localhost:18789/#token=....)

If the gateway is “stuck” and you can’t stop it

If openclaw gateway stop isn’t working, it usually means the running process isn’t being controlled by the service command (or the service state is confused). The safest “get me unstuck” command is to reclaim the port and start clean:

openclaw gateway --force

(That will kill the existing listener on the gateway port and start a fresh gateway.)

The “kimi profiles=2” bit is separate (auth profiles). It won’t lock you out of the gateway UI.

Paste your openclaw gateway status output and I’ll tell you exactly which branch you’re in (running-but-unauthorized vs not-running vs zombie process).

Two separate things here:

1) You’re not actually “locked out”

Your openclaw gateway status says RPC probe: ok and Listening: 127.0.0.1:18789 — so a gateway is running and reachable right now.

To reconnect to the dashboard, just do:

openclaw dashboard --no-open

…and open the printed #token=... URL through your SSH tunnel.

2) Why `openclaw gateway stop` “doesn’t work”

Your status output also shows:

Runtime: stopped (systemd service is inactive)

but still listening + probe ok

That means: the gateway that’s running is NOT the systemd service. It’s a stray/manual openclaw gateway process (or a leftover instance), so stopping the service won’t stop it.

Quick “make it sane again” fix:

openclaw gateway --force

That reclaims the port and starts a fresh gateway.

If you specifically want it running under systemd again afterwards:

openclaw gateway start

openclaw gateway status

About the Telegram bot paste

Ignore the advice in that paste about using crontab / “sending heartbeat prompts” manually — heartbeats are built into OpenClaw (configurable via agents.defaults.heartbeat.*). No OS cron needed.

If you tell me what you see when you try to open the dashboard (Unauthorized vs can’t reach vs pairing required), I’ll point you to the exact next step.

On a VPS, do it like this:

On the VPS, print the dashboard URL (with token):

openclaw dashboard --no-open

On your computer, open an SSH tunnel (leave this running):

ssh -N -L 18789:127.0.0.1:18789 root@<your-server-ip>

In your browser, open the URL from step 1, but with localhost, e.g.

http://localhost:18789/#token=...

(That’s it — openclaw config get gateway.auth.token is redacted, so dashboard --no-open is the right command.)

Here’s a good “reset expectations + correct the mistakes” message you can send your bot (copy/paste):

Message to your bot:

I read your Pastebin diagnosis. A few corrections:

Do not use OS crontab to trigger heartbeats. OpenClaw heartbeats are built-in and controlled by agents.defaults.heartbeat.*.

Do not create cron jobs unless I explicitly ask. My heartbeat loop should be driven by the built-in heartbeat + HEARTBEAT.md.

Don’t invent command outputs. If you say you ran a command, paste the real output. If you can’t run it, ask me to run it.

If GOALS.md is missing and HEARTBEAT.md references it, then create GOALS.md (ask me for the exact phase text if you’re unsure) — but don’t add any automation beyond heartbeat.

Next step: confirm heartbeat config + files are consistent (HEARTBEAT.md, GOALS.md, research/kb.md, research/heartbeat-log.md) and continue research runs without creating cron jobs.

If you want it even stricter, add: “If you’re unsure, reply HEARTBEAT_OK and ask me what to do next.”

Copy/paste this stricter version:

Message to your bot (strict):

I read your Pastebin diagnosis. Corrections + rules:

Do not use OS crontab to trigger heartbeats. OpenClaw heartbeats are built-in and controlled by agents.defaults.heartbeat.*.

Do not create cron jobs (OpenClaw cron or system cron) unless I explicitly ask.

Do not invent outputs. If you claim you ran a command, paste the real output. If you cannot run it, ask me to run it.

If HEARTBEAT.md references GOALS.md and it’s missing: create GOALS.md (ask me for the exact phase text if you’re unsure).

No side effects without permission: no config changes, no git, no trading, no connecting to exchange APIs, no “surprise” actions.

If you are unsure at any point, do this: reply exactly HEARTBEAT_OK and ask me a single clarifying question. Do not take alternative actions.

Next: verify heartbeat config + files (HEARTBEAT.md, GOALS.md, research/kb.md, research/heartbeat-log.md) and continue the research loop inside heartbeat only.

It does — but two important nuances:

HEARTBEAT.md only governs heartbeat runs.
The Pastebin “diagnosis” your bot gave you was a normal chat response (not a heartbeat tick), so it may not have been following the heartbeat contract.
The stricter message is less about “what to research” and more about behavioral guardrails:

don’t invent command outputs
don’t create cron/system cron
don’t take side effects without asking

If you want those guardrails to apply everywhere, put them in a more global file too (like AGENTS.md or GOALS.md), and you can also add one line to HEARTBEAT.md like:

“If you’re unsure, reply HEARTBEAT_OK and ask one clarifying question — no other actions.”

So yes: heartbeat is explicit. The extra message is just “hey, stop hallucinating / stop going off-script” for non-heartbeat moments.

This HEARTBEAT.md is actually pretty good — it already has the key guardrails (no cron, no config edits, no git, no file spam, time cap, “only message if 2+ new items”).

Two small tweaks I’d make:

1) Change “Send Eve…” → “Send me…”

That wording can confuse the agent (and you). Make it:

“Send me a Telegram message…”

2) Add a “when unsure” fail-safe

Right now it doesn’t say what to do if GOALS.md/kb.md is missing or it’s uncertain. Add one line under Hard Rules:

“If you are unsure, reply exactly HEARTBEAT_OK and ask me one clarifying question. Do nothing else.”

Also: quick sanity check that GOALS.md exists (since the heartbeat depends on it):

ls -la ~/.openclaw/workspace/GOALS.md

If it’s missing, create a minimal one so the heartbeat doesn’t derail.

Send your bot something short and concrete like this:

Message to your bot:

Thanks — I’m keeping the heartbeat approach (no cron). Please do these fixes:

In HEARTBEAT.md, replace “Send Eve…” with “Send me…”.

Add this rule under Hard Rules:
“If you are unsure, reply exactly HEARTBEAT_OK and ask me ONE clarifying question. Do nothing else.”

Make sure these files exist (create minimal scaffolds if missing): GOALS.md, research/kb.md, research/heartbeat-log.md.

Do not use OS crontab/system cron. Do not create OpenClaw cron jobs unless I ask.

If you claim you ran a command, show the real output (don’t guess).

After updating, show me the final contents of HEARTBEAT.md and confirm the other files exist.

That should get you back to a clean, predictable loop.

If you’re still hitting API limits, it’s almost certainly because you’re trying to do a heavy run (research) every 30 minutes on Anthropic Opus. That will rate-limit pretty quickly on many Anthropic setups (especially setup-token/subscription auth).

At this point you have 3 real options:

Option 1 (best): keep Anthropic as your default, but run heartbeats on Kimi

This preserves “Anthropic for normal chat/manual work”, while your automated 30‑min loop uses Kimi:

openclaw config set agents.defaults.heartbeat.model "kimi-coding/k2p5"
openclaw gateway restart

Option 2: slow down the heartbeat

openclaw config set agents.defaults.heartbeat.every "1h"
openclaw gateway restart

Option 3: increase Anthropic quota

Use an Anthropic API key + paid billing/limits, or upgrade whatever plan you’re on. Otherwise 30‑min automation + Opus will keep tripping limits.

If you tell me whether your Anthropic auth is API key or setup-token, I can suggest the least painful path.

If you can’t even send a normal message in the TUI, that’s not a heartbeat issue — it means your current active model (Anthropic) is rate-limited hard enough that basic chat requests are failing.

At that point the pragmatic move is: switch your current session (or default) to Kimi, so you can keep using the bot while Anthropic cools down.

Fastest fix (per-session, in the TUI)

Send this as a standalone message in the TUI:

/model kimi-coding/k2p5

(or just /model and pick Kimi from the list)

If you want to change the default (so everything uses Kimi for now)

Run on the VPS:

openclaw models set kimi-coding/k2p5
openclaw gateway restart

Then later, when Anthropic limits reset / you upgrade quota, you can switch back.

Also: your Anthropic auth shows as a token (sk-ant-o...) — that’s usually a setup-token/subscription flow and it can be much more rate-limited than a paid API key. If you want Anthropic reliably, you’ll probably need an Anthropic API key + billing.

You can ask, but I wouldn’t rely on the bot’s answer for this — better to verify from config + logs (bots can confidently hallucinate “yep it’s running”).

Quick verify (VPS)

openclaw config get agents.defaults.heartbeat.every
openclaw config get agents.defaults.heartbeat.target

Make sure:

every is not 0m
target isn’t none (for Telegram delivery, last is easiest)

Confirm it actually fires (logs)

tail -n 300 /tmp/openclaw/openclaw-2026-03-11.log | rg -i heartbeat

(or openclaw logs --follow and wait for the next tick)

So: you don’t need to ask the bot “are heartbeats running?”—you can prove it from the gateway logs. If you do ask it, ask it to point you to the exact log lines instead of just saying “yes”.

No worries — you don’t need rg. Use plain grep:

grep -i heartbeat /tmp/openclaw/openclaw-2026-03-11.log | tail -n 50

Or just watch live logs:

openclaw logs --follow

(Installing ripgrep is optional: apt install ripgrep, but not required for this.)

Your bot is wrong on this one.

Heartbeats are a built‑in Gateway scheduler feature. Nothing external has to “send a poll message”. The Gateway itself triggers a heartbeat run every agents.defaults.heartbeat.every and the model then reads HEARTBEAT.md (if present).

Docs (official):

How to prove it on your VPS

Check the interval + delivery target:

openclaw config get agents.defaults.heartbeat.every
openclaw config get agents.defaults.heartbeat.target

And confirm from logs:

grep -i heartbeat /tmp/openclaw/openclaw-2026-03-11.log | tail -n 50

If you want to reply to your bot, send:

“Heartbeats are triggered by OpenClaw’s built-in Gateway scheduler (see /gateway/heartbeat). HEARTBEAT.md is the instructions the heartbeat run reads; it doesn’t need external cron/polls. Don’t suggest OS crontab for this.”

Perfect — that log line is the proof your bot was wrong:

subsystem: gateway/heartbeat
intervalMs: 1800000 (= 30 minutes)
heartbeat: started

So the built-in heartbeat scheduler is running.

One nuance: “heartbeat: started” is the scheduler starting up, not necessarily a completed heartbeat run + message delivery yet.

Next things to check

Make sure heartbeat is allowed to deliver messages (otherwise it can run silently):

openclaw config get agents.defaults.heartbeat.target

If it’s none, set:

openclaw config set agents.defaults.heartbeat.target "last"
openclaw gateway restart

(Then DM your bot on Telegram once so “last” is Telegram.)

If you want to see actual heartbeat executions in logs, search for more heartbeat lines:

grep -i 'gateway/heartbeat' /tmp/openclaw/openclaw-2026-03-11.log | tail -n 100

If you paste what agents.defaults.heartbeat.target is currently set to, I can tell you whether it should be sending you Telegram messages or not.

Two common reasons it “used to message Telegram” but stopped (even though heartbeats are running):

1) Heartbeat delivery target drifted

If your heartbeat target is "last", the “last contact” might now be the Control UI (because you opened it), not Telegram. Then heartbeat messages won’t show up in Telegram.

Check:

openclaw config get agents.defaults.heartbeat.target
openclaw config get agents.defaults.heartbeat.to

Quick fix if target is `"last"`

Send your bot any Telegram DM right now (so Telegram becomes “last”), then wait for the next heartbeat.

2) You now told it to sometimes send `HEARTBEAT_OK`

With the “2+ new items” anti-repeat rule, it may be correctly deciding “nothing new” and sending nothing.

If you want it to ALWAYS deliver to Telegram (most reliable)

Set heartbeat target explicitly to Telegram + your chat id:

Find your Telegram user/chat id:

Run openclaw logs --follow
Send your bot a Telegram DM
Look for from.id / chat.id

Then set:

openclaw config set agents.defaults.heartbeat.target "telegram"
openclaw config set agents.defaults.heartbeat.to "<that-numeric-id>"
openclaw gateway restart

If you paste just the values of agents.defaults.heartbeat.target and agents.defaults.heartbeat.to (no secrets), I’ll tell you which of these cases you’re in.

Cool — right before the tick, send your bot a quick Telegram DM (even just “ping”) so Telegram is definitely the last contact.

Then watch for one of these outcomes:

You get a Telegram message → delivery target is fine.
You get nothing → either:
it replied HEARTBEAT_OK (so it intentionally didn’t deliver), or
“last” isn’t Telegram (or target is none).

If nothing arrives, run right after the tick:

grep -i heartbeat /tmp/openclaw/openclaw-2026-03-11.log | tail -n 80
openclaw config get agents.defaults.heartbeat.target

…and we’ll pinpoint which case it is.

Got it — your provider quota window just reset.

Now’s the best time to do two quick sanity tests:

Confirm Anthropic is usable again (in TUI or Telegram): send a simple “hi”.
Avoid immediately re-triggering the limit: don’t fire a bunch of manual heartbeats / long research runs back-to-back.

If you hit the limit again quickly, that’s a sign you need to either:

run the heartbeat on Kimi (agents.defaults.heartbeat.model = kimi-coding/k2p5), or
slow the heartbeat interval, or
move Anthropic to a paid API key with higher limits.

If you paste the exact 429 text next time it happens (sometimes it includes a “retry after” hint), I can tell you whether it’s request-rate vs token-rate.

brazen pond Mar 11, 2026, 6:05 AM

I. Summarize the main topic/solutions in a small concise message.

#Setup on vps

1) Install OpenClaw on the server

2) Run the onboarding wizard + install the service

3) Open the Dashboard from your laptop (recommended: SSH tunnel)

4) If anything doesn’t work, paste these outputs here

Step 1 — Install (copy/paste)

Step 2 — Run the setup wizard (it asks questions)

Step 3 — Open the web Dashboard from your own computer (recommended)

If your goal is Discord

If you get stuck, paste these outputs (safe)

1) First: don’t share that #token=... publicly

2) Start the Gateway (so the dashboard can connect)

3) From your computer, make the SSH tunnel

4) About “Gateway restart failed…”

Easiest (recommended): run the onboarding wizard

Quick manual fix (if you want)

1) Open the Dashboard from your computer

2) Make it stay running (so it doesn’t die when you close SSH)

Quick checks (run on the VPS)

If you want a totally fresh install (no old creds/config)

1) Uninstall (recommended)

2) Reinstall

If uninstall complains / doesn’t remove everything

If you do want the CLI gone too

Order I recommend

1) Auto-fix (recommended)

2) If it still complains, remove the key manually

3) Then start the gateway

What to do now

If you need to restart it (after config changes)

Check if it actually has credentials

Change the default model/provider

Option A) You want to use Anthropic (Claude)

Option B) You don’t want Anthropic

From your own computer (recommended: SSH tunnel)

Option 1 (fastest): talk in the Dashboard

Option 2: talk to it on Discord (your own bot)

What I recommend (safe default)

About BOOTSTRAP.md

1) On the VPS, print the dashboard URL + token instructions

2) From your own computer, make an SSH tunnel to the VPS

3) Open it in your browser

If the browser can’t connect

If the page loads but you don’t have a token

About “there is no token”

If gateway.auth.token prints nothing

If you just want to avoid tokens (OK for loopback+tunnel while you’re learning)

If you want Telegram (recommended for personal use)

1) Delete/stop the cron jobs your bot created

2) Configure heartbeat to run every 30m and actually message you

3) Update HEARTBEAT.md to forbid cron creation

How to control it (recommended)

Set Kimi as a fallback model

Quick check (safe to paste)

Add Kimi back as a model provider (recommended: wizard)

Add Kimi to your configured models + set it as a fallback (easy way)

Add prompts to Heartbeat (the easy way)

Option A (easiest): ask your bot to write the file

Option B (manual, no editor): copy/paste a one-liner on the VPS

Option A) nano (beginner-friendly)

Option B) No editor at all (overwrite with copy/paste)

Option C) Quick append (add lines to the end)

1) Make sure heartbeat is set to 30m

2) Make sure heartbeat delivery target isn’t “none”

Practical tip

The clean pattern (so it doesn’t spiral into cron/jobs/file spam)

What’s genuinely good

What I would change immediately (important)

Safer rewrite (recommended)

1) Which provider is rate-limiting you?

2) Confirm fallbacks are actually set

3) Best fix for “heartbeats hit rate limits”: run heartbeats on Kimi directly

Stop the bot from hammering the APIs (recommended right now)

Find out which provider is rate-limiting you

Long-term fixes

1) First: pause the heartbeats so you stop hammering limits

2) Then show me your model/failover setup again

3) Best long-term fix for your setup

Quick verification (so we’re not guessing)

Best practical setup (keeps Anthropic primary, avoids rate limits)

1) First: don’t share that `#token=...` publicly

About `BOOTSTRAP.md`

If `gateway.auth.token` prints nothing

3) Update `HEARTBEAT.md` to forbid cron creation

Option A) `nano` (beginner-friendly)

If it says `RPC probe: ok` / `Listening: 127.0.0.1:18789`

2) Why `openclaw gateway stop` “doesn’t work”

Quick fix if target is `"last"`

2) You now told it to sometimes send `HEARTBEAT_OK`