HEARTBEAT.md | Friends of the Crustacean 🦞🤝 | Page 1

swift hawk Apr 12, 2026, 8:50 PM

#

Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.
When reading HEARTBEAT.md, use workspace file /home/beto/.openclaw/workspace/HEARTBEAT.md (exact case). Do not read docs/heartbeat.md.
Current time: Sunday, April 12th, 2026 - 6:50 AM (Europe/Madrid) / 2026-04-12 04:50 UTC

glad rapidsBOT Apr 12, 2026, 8:50 PM

#

flint breachBOT Apr 12, 2026, 8:50 PM

#

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

glad rapidsBOT Apr 12, 2026, 8:50 PM

#

swift hawk Apr 12, 2026, 8:53 PM

#

what does it means?
Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.

What to write in that file?

swift karmaBOT Apr 12, 2026, 8:53 PM

#

It’s the periodic prompt OpenClaw sends to itself on heartbeat runs.

In plain English, that line means:

every heartbeat tick, read HEARTBEAT.md from the workspace
follow whatever tiny checklist is in there
don’t drag in old chat context or random past tasks
if there’s nothing worth reporting, just return HEARTBEAT_OK

What to put in HEARTBEAT.md:

Nothing, if you don’t want heartbeat to do anything
- empty/comment-only file = skip heartbeat model call
- or disable heartbeat entirely with config
A tiny checklist, for example:

#

# Heartbeat checklist

- Check if there are urgent unread emails.
- Check if a meeting is coming up soon.
- If nothing needs attention, reply HEARTBEAT_OK.

Or a tasks block if you want different intervals:

tasks:

- name: inbox-triage
  interval: 30m
  prompt: "Check for urgent unread emails."

#

- name: calendar-scan
  interval: 2h
  prompt: "Check for upcoming meetings."

# Extra rule
- If nothing needs attention, reply HEARTBEAT_OK.

A few good rules:

keep it short
put only stable recurring checks there
don’t put secrets in it

Docs:

https://docs.openclaw.ai/gateway/heartbeat

#

If you want, I can also suggest a good first HEARTBEAT.md for your setup.

swift hawk Apr 12, 2026, 8:58 PM

#

yes please, suggest a good first hearbeat.md

swift karmaBOT Apr 12, 2026, 8:58 PM

#

Yep, I’d start simple first, then only add more once it proves useful.

Good first HEARTBEAT.md:

# Heartbeat checklist

- Check for anything urgent that needs my attention soon.
- Prefer short, actionable alerts.
- Do not repeat old tasks unless they are still clearly urgent.
- If something is blocked, say what is missing in one sentence.
- If nothing needs attention, reply HEARTBEAT_OK.

If you want a slightly better version with built-in intervals, use this instead:

#

tasks:

- name: urgent-check
  interval: 30m
  prompt: "Check for anything urgent or time-sensitive that needs attention soon."

- name: followup-check
  interval: 2h
  prompt: "Check whether any important follow-up is overdue or blocked."

# Additional instructions

- Keep alerts short and practical.
- Do not invent work just because a heartbeat ran.
- Do not repeat stale items unless they are still urgent.

#

- If nothing needs attention, reply HEARTBEAT_OK.

My recommendation: start with the first one.
It’s easier to reason about, and you can add tasks: later.

Docs: https://docs.openclaw.ai/gateway/heartbeat

If you want, I can also give you:

a personal productivity version
an email/calendar assistant version
a developer/project monitoring version

swift hawk Apr 12, 2026, 9:37 PM

#

how to define a llm?

swift karmaBOT Apr 12, 2026, 9:37 PM

#

If you mean which LLM OpenClaw should use, define a model ref like provider/model.

Easiest way

Set the default model with:

pnpm openclaw models set provider/model

Example shape, not a recommendation:

pnpm openclaw models set openai/gpt-5.4

In config

Global default model:

#

{
  agents: {
    defaults: {
      model: {
        primary: "provider/model",
      },
    },
  },
}

If you want a different model just for heartbeat:

#

  agents: {
    defaults: {
      model: {
        primary: "provider/model",
      },
      heartbeat: {
        every: "30m",
        model: "provider/model",
      },
    },
  },
}

Optional, if you want `/model` picking

Add a model catalog / allowlist:

#

{
  agents: {
    defaults: {
      models: {
        "provider/model": { alias: "my-model" },
      },
      model: {
        primary: "provider/model",
      },
    },
  },
}

Useful commands

#

pnpm openclaw models status
pnpm openclaw models list

Docs:

Small gotcha: use agents.defaults.heartbeat.model, not top-level heartbeat.model.

If you want, paste your config and I’ll point to the exact place to add it.

swift hawk Apr 12, 2026, 9:42 PM

#

how to define gemma4:26b in local

swift karmaBOT Apr 12, 2026, 9:43 PM

#

If you’re using Ollama local, use the exact Ollama tag with the ollama/ prefix.

So if ollama list shows:

gemma4:26b

then in OpenClaw the model ref is:

ollama/gemma4:26b

Simplest setup

#

ollama pull gemma4:26b
export OLLAMA_API_KEY="ollama-local"
pnpm openclaw models set ollama/gemma4:26b

Or in config

{
  agents: {
    defaults: {
      model: {
        primary: "ollama/gemma4:26b",
      },
    },
  },

#

Important gotcha

If you do not define models.providers.ollama manually, OpenClaw can auto-discover local Ollama models, which is easiest.

So usually you only need:

Ollama running
the model pulled
OLLAMA_API_KEY set to any placeholder value
default model set to ollama/gemma4:26b

Check it

ollama list

#

pnpm openclaw models list
pnpm openclaw models status

Docs:

Tiny warning: local models can work, but for heavy agent/tool workflows they’re often less reliable than hosted ones.

If you want, paste your current config and I’ll show the exact snippet to add.

swift hawk Apr 13, 2026, 6:31 AM

#

consider the commands for a linux install

swift karmaBOT Apr 13, 2026, 6:32 AM

#

Yep, for a Linux install I’d do it like this:

ollama pull gemma4:26b
pnpm openclaw config set models.providers.ollama.apiKey "ollama-local"
pnpm openclaw models set ollama/gemma4:26b
pnpm openclaw gateway restart
pnpm openclaw models status

If you want to verify Ollama sees it first:

ollama list

A couple of notes:

#

In OpenClaw, the ref is ollama/gemma4:26b
On Linux, if OpenClaw runs as a service, config set is safer than export OLLAMA_API_KEY=..., because the service may not inherit your shell env
If you already manually defined models.providers.ollama, auto-discovery changes a bit, but the model ref is still ollama/gemma4:26b

If you installed OpenClaw globally instead of from source, the same commands are just:

openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw models set ollama/gemma4:26b
openclaw gateway restart

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

swift hawk Apr 13, 2026, 8:10 AM

#

I get this message: Discord inbound worker timed out.

swift karmaBOT Apr 13, 2026, 8:11 AM

#

That usually means the Discord event arrived, but the inbound worker didn’t finish in time.

First thing, please paste:

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

And if you can, grab the log line around it:

pnpm openclaw logs --follow

Common cause

#

This happens a lot when the run is slow, especially with:

large/slow local models
huge context/session history
long tool runs

Relevant timeout knobs

If the logs show discord inbound worker timed out after ..., check:

channels.discord.eventQueue.listenerTimeout
channels.discord.inboundWorker.runTimeoutMs

Good baseline:

{
  channels: {

#

    discord: {
      accounts: {
        default: {
          eventQueue: {
            listenerTimeout: 120000,
          },
          inboundWorker: {
            runTimeoutMs: 1800000,
          },
        },
      },
    },
  },
}

#

Quick read of the symptom

listenerTimeout = Discord listener budget
inboundWorker.runTimeoutMs = max time allowed for the queued agent run

So if you’re testing with a local model like Gemma, I’m a little suspicious that the model run is just taking too long.

Docs:

Paste the version + logs and I’ll help narrow it down fast.

swift hawk Apr 13, 2026, 8:12 AM

#

what is the best value free local model to run with openclaw?

swift karmaBOT Apr 13, 2026, 8:13 AM

#

Honestly, for OpenClaw specifically, I would not recommend chasing a “best value” local model as the default answer.

My short take:

For easiest free local setup: use Ollama
For real agentic work: cloud models are still the better value
If you insist on local: run the largest model your hardware can handle comfortably, and avoid tiny or aggressively quantized variants

Why I’m being a bit annoying here: OpenClaw stresses models with long context, tool calls, and prompt-injection resistance. Local models can technically work, but they often get flaky unless you have pretty serious hardware.

So my recommendation is:

Testing / hobby / offline experiments → local via Ollama
Reliable daily use → cloud
Fresh local model recommendations → ask in #models, because that changes constantly and hands-on reports matter more than stale lists

Docs:

#

If you want, tell me your GPU / RAM / CPU, and I can tell you what class of local model is realistic without pretending there’s one magic winner.

swift hawk Apr 13, 2026, 8:24 AM

#

32gb ram

swift karmaBOT Apr 13, 2026, 8:25 AM

#

With 32 GB RAM, I’d treat local as testing / tinkering tier, not “best OpenClaw experience” tier.

My practical take:

CPU-only or weak GPU: aim for roughly 7B to 14B class
Bigger quantized models might load, but they’ll often be slow or shaky for agent/tool use
I would not expect great OpenClaw performance from large local models on 32 GB alone

So the sensible setup is usually:

cloud primary model
local fallback or cheap heartbeat model
Ollama for the local side

If you’re trying to stay free/local anyway, I’d keep expectations to:

lighter chat
simple tests

#

short contexts
minimal tool pressure

If you want a real recommendation, the next important question is:

CPU only?
NVIDIA GPU?
Apple Silicon unified memory?

That changes the answer a lot.

For fresh current picks, I’d still ask in #models with your exact hardware, because local model winners change fast. Docs:

If you share CPU/GPU/VRAM, I can narrow it down to a realistic model size class.

swift hawk Apr 13, 2026, 8:26 AM

#

cpu only

swift karmaBOT Apr 13, 2026, 8:26 AM

#

Ah, 32 GB RAM + CPU only changes it a lot.

I’d be pretty conservative:

main agent: I would not run local as primary
local use case: heartbeat, fallback, light tests, short chats
realistic size class: roughly small models, around 7B-ish, maybe a bit higher if you’re patient
avoid: large models for normal OpenClaw agent use, they’ll usually be too slow and less reliable

So my honest recommendation is:

cloud primary
small local Ollama model for experiments / fallback / cheap heartbeat
keep contexts short and tool use limited

If you want fully local anyway, I’d ask in #models for current CPU-only picks, because that changes fast and benchmark hype lies a lot 😅

#

Docs:

If this helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

swift hawk Apr 13, 2026, 8:31 AM

#

what local model would you suggest for cheap heartbeat?

swift karmaBOT Apr 13, 2026, 8:32 AM

#

For a cheap local heartbeat, I’d use a very small local model, roughly 1B to 3B class.

That’s the sweet spot if the heartbeat is only doing stuff like:

read a tiny HEARTBEAT.md
decide “alert vs HEARTBEAT_OK”
maybe do one lightweight check

If you expect the heartbeat to do more reasoning, tool use, or longer context, step up a bit, but for CPU-only I’d keep it small.

I’d also pair it with heartbeat settings like:

{
  agents: {
    defaults: {

#

      heartbeat: {
        model: "ollama/<small-local-model>",
        lightContext: true,
        isolatedSession: true,
      },
    },
  },
}

That keeps it much cheaper.

I don’t want to give you a stale exact model name here, so for the current best small local picks, ask in #models. That changes fast.

Docs:

https://docs.openclaw.ai/gateway/heartbeat

#

If you want, I can help you design a heartbeat prompt that’s actually safe for a tiny local model.

swift hawk Apr 13, 2026, 8:42 AM

#

yes please

swift karmaBOT Apr 13, 2026, 8:42 AM

#

Nice, for a tiny cheap local heartbeat, I’d make it brutally simple.

Starter HEARTBEAT.md:

# Cheap heartbeat

- Only look for something clearly urgent or time-sensitive.
- Do not do deep analysis.
- Do not repeat stale items unless they are still urgent now.
- Keep replies to one short sentence.
- If nothing needs attention, reply HEARTBEAT_OK.

If you want a slightly more structured version:

#

tasks:

- name: urgent-check
  interval: 30m
  prompt: "Check only for clearly urgent or time-sensitive items. No deep analysis. If nothing needs attention, reply HEARTBEAT_OK."

# Additional instructions

- Keep replies very short.
- Do not invent work.
- Do not repeat old tasks unless they are still urgent now.
- If alerting, give only: problem + next step.
- If nothing needs attention, reply HEARTBEAT_OK.

And I’d pair it with config like:

#

{
  agents: {
    defaults: {
      heartbeat: {
        model: "ollama/<small-local-model>",
        lightContext: true,
        isolatedSession: true,
      },
    },
  },
}

Why this works

Tiny local models do better when the job is:

narrow

#

binary
short
not tool-heavy

So avoid prompts like:

“review everything”
“plan my day”
“summarize all pending work”

If you want, I can also give you:

a Discord-focused cheap heartbeat
an email/calendar cheap heartbeat
a developer alerts only cheap heartbeat

swift hawk Apr 13, 2026, 10:40 AM

#

now a days, what's the best value api model for multiple agent workflow?

swift karmaBOT Apr 13, 2026, 10:41 AM

#

I wouldn’t trust a static “best value” answer here, that changes way too fast.

For multi-agent workflows, I’d optimize for this order:

tool reliability
long-context stability
latency
cost

The pattern that usually wins is:

strong orchestrator model for routing / planning / synthesis
cheaper worker model for delegated subtasks
very cheap heartbeat/background model for routine checks

What I would not optimize for first is raw benchmark hype. Multi-agent systems punish flaky tool calling way more than normal chat does.

#

For the current exact API model picks, ask in #models. That’s where the fresh hands-on recommendations live.

Docs:

If you want, I can help you design a good model split for:

orchestrator
worker agents
heartbeat / cron
fallback chain

swift hawk Apr 13, 2026, 10:43 AM

#

I want to build a full team of agents, dev, seo, personal assistant, marketing, market research, sales

swift karmaBOT Apr 13, 2026, 10:44 AM

#

Nice, that’s a fun setup. I’d not start with 6 fully independent agents on day one though, that gets messy fast.

My recommendation:

Start with 4

main / orchestrator
routes work, synthesizes results, keeps context
dev
code, debugging, builds, browser/dev tooling
go-to-market
combine SEO + marketing + market research at first
personal assistant / ops
inbox, calendar, reminders, admin

#

Then add sales later, once you have clear CRM / outreach workflows.

Why

Sales, marketing, SEO, and research overlap a lot early on.
If you split too soon, you create handoff overhead instead of leverage.

Good boundaries

dev: read, write, edit, exec, browser
go-to-market: web_search, web_fetch, browser, docs/notes
personal assistant: calendar, docs, inbox-style workflows
sales: start very restricted, especially around outbound messaging

Important rule

Give each agent its own workspace and own agentDir. Don’t share agent state.

Basic flow

#

pnpm openclaw agents add main
pnpm openclaw agents add dev
pnpm openclaw agents add gtm
pnpm openclaw agents add ops

Then route with bindings, and let the main agent delegate.

Model strategy

strong orchestrator
cheaper worker agents
very cheap heartbeat/background model

Docs

#

https://docs.openclaw.ai/concepts/models

Also, this is the kind of thing that’s easier to design in a local agent than in a long Discord thread. Fastest path if you want to keep iterating: https://docs.openclaw.ai/help/faq#im-stuck-what’s-the-fastest-way-to-get-unstuck

If you want, I can sketch you a clean starter team config for:

main
dev
gtm
ops
optional sales

swift hawk Apr 13, 2026, 11:01 AM

#

I need your advise with the best value llm for this workspace

swift karmaBOT Apr 13, 2026, 11:02 AM

#

For this workspace, I’d optimize for cost per successful outcome, not lowest token price.

So my advice would be:

Best-value setup

main / orchestrator: your strongest reliable tool-calling model
dev: same tier as orchestrator, or one step cheaper if coding quality stays solid
gtm / research / marketing: a mid-tier fast model
ops / personal assistant: same mid-tier fast model
heartbeat / background checks: very cheap model (or tiny local model)

Why

In a multi-agent workspace, the expensive mistakes are:

bad tool calls
weak synthesis
retries
agents hallucinating handoffs

#

That’s why I’d spend money on:

orchestration
coding
everything else gets cheaper models

My practical split

premium model for main + dev
cheap fast model for gtm + ops + sales
cheapest model for heartbeat / cron / routine checks

What I would avoid

one cheap model for everything
local model as the main orchestrator
optimizing for benchmark scores instead of tool reliability

For the exact current model picks, ask in #models. That changes too fast for me to give a trustworthy static winner.

#

Docs:

If you want, I can turn this into a concrete team plan like:

main → premium
dev → premium
gtm → fast cheap
ops → fast cheap
sales → fast cheap
heartbeat → ultra cheap

swift hawk Apr 13, 2026, 12:26 PM

#

is kimi suitable for this agent setup?

swift karmaBOT Apr 13, 2026, 12:26 PM

#

Potentially yes, but I’d be more comfortable using it as a worker than as the sole orchestrator until you’ve tested it.

My rough take for your setup:

good first place to try it:
gtm, market research, maybe sales assist, maybe ops
be more cautious with:
main orchestrator and dev

Why: in multi-agent setups, the hardest jobs are:

routing work correctly
synthesizing outputs
reliable tool use
not getting weird under long context / retries

So if you want to use Kimi, I’d test it like this:

#

run it as a worker model
keep a stronger model for main
evaluate:
- tool-call reliability
- latency
- cost
- quality of summaries / handoffs
- failure rate under repeated runs

If it behaves well there, then maybe expand its role.

For the current real-world Kimi feedback, I’d still ask in #models. That’s where the freshest hands-on reports will be.

Docs:

#

If you want, I can sketch a Kimi-based team split with:

where to use it
where not to
how to stage the rollout safely

swift hawk Apr 14, 2026, 8:49 AM

#

I've update openclaw and got this message:
openclaw update
Updating OpenClaw...

│
◇ ✓ Updating via package manager (116.66s)
│
◇ ✓ Running doctor checks (10.27s)

Update Result: OK
Root: /home/beto/.npm-global/lib/node_modules/openclaw
Before: 2026.4.11
After: 2026.4.12

Total time: 127.26s

Updating plugins...
npm plugins: 0 updated, 0 unchanged, 1 failed.
Failed to update openclaw-web-search: Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/home/beto/.npm-global/lib/node_modules/openclaw/dist/install.runtime-DtmATpak.js' imported from /home/beto/.npm-global/lib/node_modules/openclaw/dist/install-BBkA8j5I.js

Restarting service...
Daemon restart completed.

swift karmaBOT Apr 14, 2026, 8:50 AM

#

That looks like the stale hashed dist/install.runtime-*.js updater bug.

Good news: your core OpenClaw update itself succeeded. The failure was in the plugin refresh step, not the main upgrade.

First, please confirm:

openclaw --version
openclaw status
openclaw gateway status

If those look healthy, I’d try this next:

openclaw plugins doctor

#

openclaw plugins update openclaw-web-search

If that still fails, reinstall just that plugin:

openclaw plugins install openclaw-web-search --force

Why I think this is the known issue: 2026.4.12 includes a fix for plugin refresh after self-update, but when you update from an older version into the fixed one, the old updater process can still be the one that trips over the stale hashed file.

So in short:

main update: probably fine
service restart: completed
broken part: plugin auto-update for openclaw-web-search

#

Docs:

Paste the output of openclaw --version and openclaw plugins doctor if you want, and I’ll help verify whether you can safely ignore it or need the reinstall.

swift hawk Apr 14, 2026, 8:57 AM

#

openclaw plugins doctor

🦞 OpenClaw 2026.4.12 (1c0672b) — If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

Diagnostics:

ollama: memory embedding provider already registered: ollama (owner: ollama)

Docs: docs.openclaw.ai/plugin

swift karmaBOT Apr 14, 2026, 8:58 AM

#

Nice, this tells us a lot.

What this means

You’re definitely on 2026.4.12, so the core update landed.

The doctor output is not complaining about openclaw-web-search anymore.
Instead, it’s reporting a separate plugin collision:

ollama: memory embedding provider already registered: ollama (owner: ollama)

That usually means Ollama is being loaded twice, often as:

bundled Ollama plugin
plus an extra installed Ollama plugin / duplicate registration

Next check

#

Please run:

openclaw plugins list --verbose

I want to see whether you have two Ollama entries or a bundled + npm-installed copy.

Likely fix

If plugins list --verbose shows an extra non-bundled/manual Ollama plugin, remove or disable the extra one.

About the original `openclaw-web-search` update error

At this point, I’m less worried about it. The main update looks good, and the plugin doctor is surfacing a different issue now.

So right now the priority is:

check for duplicate Ollama plugin registration
clean that up

#HEARTBEAT.md

Easiest way

In config

Optional, if you want /model picking

Useful commands

Simplest setup

Or in config

Important gotcha

Check it

Common cause

Relevant timeout knobs

Quick read of the symptom

Why this works

Start with 4

Why

Good boundaries

Important rule

Basic flow

Model strategy

Docs

Best-value setup

Why

My practical split

What I would avoid

What this means

Next check

Likely fix

About the original openclaw-web-search update error

Optional, if you want `/model` picking

About the original `openclaw-web-search` update error