#Heartbeat

1 messages · Page 1 of 1 (latest)

pastel sluiceBOT
#

Yeah — this is expected with current queue behavior.

Heartbeat using a different model does not make it independent of chat flow.
It still runs as an agent turn on the same gateway queue path, so if concurrency is low it can stall visible chat turns.

Most likely culprit: agents.defaults.maxConcurrent is set too low (often 1).

What to do

  1. First paste your version:
openclaw --version
  1. Tune config so heartbeat is cheaper + less blocking:
# 
{
agents: {
defaults: {
maxConcurrent: 4, // default is 4; avoid 1 unless you want strict serialization
heartbeat: {
every: "1h", // or "0m" to disable for testing
isolatedSession: true, // no full convo history each tick
lightContext: true // heartbeat mostly reads HEARTBEAT.md
}
}
}
}
  1. If heartbeat is doing real work, move that to cron isolated jobs instead of heartbeat.
lyric quest
#

maxConcurrent is already 4.

pastel sluiceBOT
#

Nice, that rules out global lane saturation.

If maxConcurrent is already 4, the usual next culprit is session-lane contention (per-session is still strictly 1).
So heartbeat and chat can still serialize if they hit the same session key.

What to check next

  • agents.defaults.heartbeat.session (or per-agent override)
  • if this points at your active chat session, it will block that flow.
  • session.scope
  • if set to "global", heartbeat + chats can collide more often.
  • thread focus/binding (/focus) to main session can also cause this pattern.

Best fix for your case

Enable isolated heartbeat runs (separate :heartbeat session key), plus light context:

# 
{
agents: {
defaults: {
heartbeat: {
isolatedSession: true,
lightContext: true
}
}
}
}

This usually removes the “heartbeat cuts my flow” feeling even when heartbeat model is different.

If you want, paste your session + agents.defaults.heartbeat blocks and I’ll sanity-check exact values.

lyric quest
#

yeah but my use case requires the heartbeat to be in the same main session with the current chat, so it will get full context. no way around it?

pastel sluiceBOT
#

Yeah — if heartbeat must run in the exact same session, then true parallelism is basically no right now.

That session has a single-writer lock by design (to avoid transcript races/corruption), so heartbeat and chat turns will serialize.

What you can do without giving up same-session context:

  1. Prioritize human messages over heartbeat
  • In that thread/session:
/queue interrupt
  • This makes new user messages abort the active run for that session.
  1. Make heartbeat cheap/fast so lock time is short
  • keep HEARTBEAT.md tiny
  • use tasks: intervals so not every tick does full work
  • increase heartbeat.every to reduce collision frequency
lyric quest
#

I use honcho, so can I expect heartbeat in isolated session will have knowledge over main session?

pastel sluiceBOT
#

Yes — with Honcho, isolated heartbeat can still have useful knowledge from your main session, but with an important caveat:

So: yes for memory-level/contextual knowledge, no for exact live token-by-token chat buffer.

If you need near-real-time continuity, this is the usual pattern:

  1. keep heartbeat isolated,
  2. use Honcho for recall,
  3. write critical “current state” to a workspace file (or MEMORY) that heartbeat can read directly.

Quick sanity check:

openclaw honcho status

If that’s healthy, your isolated heartbeat should still have cross-session awareness.

lyric quest
#

my agent doesn't seem to have access to honcho_session tool, how can I make it available

pastel sluiceBOT
#

Yep — usually one of these is missing:

  1. Plugin installed + enabled
openclaw plugins install @honcho-ai/openclaw-honcho
openclaw plugins enable openclaw-honcho
  1. Honcho configured
openclaw honcho setup
openclaw honcho status
  1. Gateway restarted after plugin/config changes
# 
openclaw gateway restart
  1. Tool policy not blocking plugin tools
  • If you use tools.allow/agent tool allowlists, make sure honcho_session (and friends) are allowed.
  • Quick runtime check in chat:
/tools verbose
  1. If this is an ACP (Codex/Claude Code) session: plugin tools are off by default there.
    Enable bridge:
openclaw config set plugins.entries.acpx.config.pluginToolsMcpBridge true
openclaw gateway restart
lyric quest
#

this is my agent's finding

Honcho passes a function to registerTool() (a factory that takes toolCtx), but OpenClaw's registerTool silently drops functions — if (typeof tool !== "function") tools.push(tool). It only accepts plain tool objects.

So every Honcho tool registration is being silently ignored. That's why you have zero honcho tools.

pastel sluiceBOT
#

Great find — but that specific snippet is a capture/introspection path, not the normal runtime registration path.

In runtime, registerTool does support function factories (it wraps them as factory), so “functions are silently dropped” is not generally true for loaded plugins.

So you’re likely hitting one of these instead:

  1. plugin not actually enabled/loaded,
  2. plugin config invalid,
  3. tool allowlist blocking honcho_*,
  4. ACP session without plugin-tools bridge.

Quick checks:

openclaw --version
openclaw plugins inspect openclaw-honcho
# 
openclaw plugins doctor
openclaw honcho status
openclaw gateway restart

Then in chat:

/tools verbose

If you’re using ACP sessions, also set:

openclaw config set plugins.entries.acpx.config.pluginToolsMcpBridge true
openclaw gateway restart
#

Perfect, this output is super useful.

You’ve basically proven Honcho is loaded correctly and its tools are registered.
So the issue is not registration — it’s tool policy visibility.

Your config has:

tools: { profile: "coding" }

coding is a restrictive profile focused on core tools. Plugin tools (like honcho_session) won’t necessarily be exposed unless explicitly allowed.

Fix (agent-scoped, recommended)

Add alsoAllow for the agent handling that Discord chat:

# 
{
agents: {
list: [
{
id: "main",
tools: {
alsoAllow: [
"honcho_session",
"honcho_context",
"honcho_search_messages",
"honcho_search_conclusions",
"honcho_ask"
]
}
}
# 
]
}
}

(If that chat is routed to assistant, add the same block there too.)

Then:

openclaw gateway restart

And confirm in the same chat:

# 
/tools verbose

If you want, paste your full agents.list block and I’ll give you an exact merged patch.

lyric quest
#

accidentally pasted guid id, can you delete this thread

pastel sluiceBOT
#

I can do that — deleting the thread now.

#

I tried, but I don’t have permission to delete this thread (Missing Permissions from Discord).

Fastest path:

  • Right-click thread title → Delete Thread (if you have perms), or
  • Ask a server mod/admin to delete it.

If you want, I can still help clean up by deleting/redacting follow-up messages I can access.

lyric quest
#

did this go to answeroverflow