heartbeat loads local model several times | Friends of the Crustacean 🦞🤝 | Page 1

gilded ermine Apr 18, 2026, 12:59 AM

#

since the last couple of updates, whenever heartbeat runs, the local model assigned to it (qwen3.5 9b) gets loaded multiple times. is this a bug, a temporary bad state, or something else? i need help debugging and fixing this.

hexed furnaceBOT Apr 18, 2026, 12:59 AM

#

lethal condorBOT Apr 18, 2026, 12:59 AM

#

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

hexed furnaceBOT Apr 18, 2026, 12:59 AM

#

gilded ermine Apr 18, 2026, 1:00 AM

#

forgot to mention: local model is run via LM Studio, anthropic api

indigo voidBOT Apr 18, 2026, 1:03 AM

#

Not expected for a plain heartbeat.

I checked the current docs/source, and a single heartbeat turn should make one reply call. So if qwen is loading several times, it’s usually one of these:

more than one heartbeat-enabled agent
extra wake sources firing heartbeats (cron, exec-event, hook, task completion)
retry loops inside one turn (transient HTTP, context overflow, empty response, reasoning-only/planning-only retry)
the local backend itself unloading/reloading between requests

First, what does this show?

openclaw --version

Then please paste:

#

openclaw status --all
openclaw system heartbeat last
openclaw config get agents.defaults.heartbeat
openclaw config get agents.list

And during one heartbeat run:

openclaw logs --follow

Look for lines with:

heartbeat
reason=exec-event, reason=wake, reason=hook:, reason=cron:
Retrying once

#

context overflow
empty response detected
reasoning-only ... retrying
planning-only ... retrying

If the logs show retries, the quickest mitigation is usually:

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

#

That shrinks heartbeat context a lot and often stops retry churn with local models.

Also tell me whether the local backend is Ollama or LM Studio.

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/heartbeat
https://docs.openclaw.ai/gateway/troubleshooting

Paste the version and those outputs, and I can narrow it down pretty fast.

#

That helps, yeah.

If normal chats are on Anthropic and heartbeat overrides to a local LM Studio model, I’d look at the LM Studio leg first, not heartbeat scheduling itself.

Two important bits:

A single heartbeat turn should normally make one reply call.
If the model reloads several times, it’s usually either:
1. OpenClaw is retrying the turn, or
2. LM Studio is JIT/TTL auto-unloading and reloading the model.

The big check here is how LM Studio is wired. The documented OpenClaw path is an lmstudio/... provider on the OpenAI-style /v1 endpoint, usually with api: "openai-responses" or api: "openai-completions". If you’re going through an Anthropic-compatible shim for LM Studio, that’s the first thing I’d suspect.

Can you paste these?

#

openclaw --version
openclaw system heartbeat last
openclaw config get agents.defaults.heartbeat
openclaw config get models.providers.lmstudio

And during one heartbeat run:

openclaw logs --follow

What I’d look for:

If OpenClaw logs show Retrying once, empty response detected, reasoning-only ... retrying, or planning-only ... retrying:
- that’s a retry loop, which explains multiple LM Studio loads.

#

If OpenClaw shows just one heartbeat run and no retry lines:
- that points more to LM Studio JIT/TTL/auto-evict reloading the model.

If you want the fastest A/B test, try making the heartbeat model use the native LM Studio provider path directly, not an Anthropic-compatible route, then rerun one heartbeat.

Docs:
https://docs.openclaw.ai/providers/lmstudio
https://docs.openclaw.ai/gateway/local-models

Paste those outputs and I can narrow it down pretty cleanly.

gilded ermine Apr 18, 2026, 1:15 AM

#

I'll give you the results one message at a time. please wait

indigo voidBOT Apr 18, 2026, 1:16 AM

#

Yep, perfect. Send them one at a time and I’ll hold context.

gilded ermine Apr 18, 2026, 1:20 AM

#

openclaw --version
OpenClaw 2026.4.14 (323493f)

OpenClaw status --all

│ Version │ 2026.4.14
│ OS │ linux 6.12.75+rpt-rpi-2712 (arm64)
│ Node │ 24.14.1
│ Config │ ~/.openclaw/openclaw.json
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale │ serve · unknown · [redacted]
│ Channel │ stable (config)
│ Update │ pnpm · npm update 2026.4.15
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 50ms · auth token ·[redacted] app 2026.4.14 linux 6.12.75+rpt- rpi-2712
│ Security │ Run: openclaw security audit --deep
│ Gateway self │ unknown
│ Gateway service │ systemd installed · enabled · running (pid 3633952, state active)
│ Node service │ systemd not installed
│ Agents │ 2 total · 0 bootstrapping · 0 active · 60 sessions
│ Secrets │ none

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/[redacted]/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/[redacted]/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 3633952 redacted: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: serve · unknown · [redacted]
✓ Skills: 17 eligible · 0 missing · /home/[redacted]/.openclaw/workspace
! Plugin compatibility (1)
[info] voice-mode is hook-only. This remains a supported compatibility path, but it has not migrated to explicit capability registration yet.
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.

#

🦞 OpenClaw 2026.4.14 (323493f) — Running on your hardware, reading your logs, judging nothing (mostly).

│
◇
{
"ts": 1776468032372,
"status": "skipped",
"reason": "target-none",
"preview": "Backup complete.",
"durationMs": 14203,
"hasMedia": false
}

#

🦞 OpenClaw 2026.4.14 (323493f) — Pairing codes exist because even bots believe in consent—and good security hygiene.

{
"every": "4h",
"model": "lmstudio/qwen3.5-9b"
}

#

🦞 OpenClaw 2026.4.14 (323493f) — Your personal assistant, minus the passive-aggressive calendar reminders.

[
{
"id": "main",
"tools": {
"alsoAllow": [
"agents_list",
"gateway",
"tts",
"browser"
],
"deny": [
"video_generate",
"music_generate",
"image_generate",
"image"
]
}
},
{
"id": "sootsayer",
"name": "sootsayer",
"workspace": "/home/neocharvaka/.openclaw/agents/sootsayer/workspace",
"agentDir": "/home/neocharvaka/.openclaw/agents/sootsayer/agent",
"model": {
"primary": "lmstudio/qwen/qwen3.5-35b-a3b",
"fallbacks": [
"lmstudio/google/gemma-4-26b-a4b",
"anthropic/claude-haiku-4-5",
"anthropic/claude-sonnet-4-6",
"anthropic/claude-opus-4-6"
]
},
"skills": [
"coding-agent",
"discord",
"obsidian",
"session-logs",
"weather"
],
"tools": {
"alsoAllow": [
"agents_list",
"sessions_send",
"sessions_list",
"sessions_history",
"browser"
],
"deny": [
"canvas",
"message",
"tts",
"image_generate",
"cron",
"image",
"music_generate",
"video_generate",
"nodes"
]
}
}
]

indigo voidBOT Apr 18, 2026, 1:20 AM

#

Nice, thanks, that helps.

Nothing in that screams “ancient broken install”. 2026.4.14 is recent enough, and the main thing that jumps out is:

Agents: 2 total

So the first thing I want to rule out is multiple heartbeat-enabled agents, which would absolutely look like “heartbeat loads the local model several times”.

Next best output:

openclaw system heartbeat last

After that, the most useful ones are:

#

openclaw config get agents.defaults.heartbeat
openclaw config get agents.list

Send the next one when ready.

#

Thanks, this part mostly says the gateway is healthy.

Also, the Port 18789 is already in use line is normal here. It’s just seeing the running openclaw-gateway, so that’s not the bug.

So far I don’t see evidence of a bad gateway state.

The next outputs I really need are the heartbeat ones:

openclaw system heartbeat last

and then:

openclaw config get agents.defaults.heartbeat

#

openclaw config get agents.list

Those will tell us whether this is:

one heartbeat with retries, or
multiple heartbeat-enabled agents firing.

gilded ermine Apr 18, 2026, 1:21 AM

#

4e3850f2b3d1","stage":"assistant","decision":"surface_error","failoverReason":"timeout","profileFailureReason":"timeout","provider":"lmstudio","model":"qwen/qwen3.5-9b","sourceProvider":"lmstudio","sourceModel":"qwen/qwen3.5-9b","fallbackConfigured":true,"timedOut":true,"aborted":true} embedded run failover decision
11:21:36+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=2cbf17fb-b47c-463a-a122-c79075580c0c sessionId=b0a876f6-e78a-4b67-9ea9-c925e3d31f1a stopReason=stop payloads=0 — surfacing error to user
13:10:14+00:00 warn extensions/lmstudio/stream {"subsystem":"extensions/lmstudio/stream"} LM Studio inference preload failed for "qwen3.5-9b"; continuing without preload: Error: LM Studio model load failed (500): {
"error": {
"type": "model_load_failed",
"message": "Failed to load LLM 'qwen3.5-9b': Error: Model loading was stopped due to insufficient system resources. Under the current settings, this model requires approximately 10.62 GB of memory, and continuing to load it would likely overload your system and cause it to freeze. If you think this is incorrect, you can adjust the model loading guardrails in settings."
}
} <- repeated twice more

indigo voidBOT Apr 18, 2026, 1:21 AM

#

Ah, this is actually a useful clue.

That says the heartbeat really did run for about 14s, and then got skipped only at delivery time because target-none.

Two interesting parts:

preview: "Backup complete."
reason: "target-none"

So this was not just an idle interval heartbeat doing nothing. It looks like heartbeat was processing a system event or completion message, probably something backup-related, then decided not to deliver it anywhere.

That means at least some of the model loads you’re seeing may be event-driven heartbeat wakes, not just the normal periodic tick.

I still need these to pin it down:

#

openclaw config get agents.defaults.heartbeat
openclaw config get agents.list

And if you can catch one live:

openclaw logs --follow

What I want to see in logs is whether the run is waking with:

reason=interval
reason=exec-event
reason=cron:...
reason=hook:...
or retry lines like empty response detected / reasoning-only ... retrying

#

So far, I’m leaning away from “temporary bad state” and more toward:

extra wake sources, and/or
retry behavior on the LM Studio leg.

gilded ermine Apr 18, 2026, 1:22 AM

#

openclaw system heartbeat last

🦞 OpenClaw 2026.4.14 (323493f) — I'm the reason your shell history looks like a hacker-movie montage.

│
◇
{
"ts": 1776468032372,
"status": "skipped",
"reason": "target-none",
"preview": "Backup complete.",
"durationMs": 14203,
"hasMedia": false
}

indigo voidBOT Apr 18, 2026, 1:22 AM

#

Good, that helps a lot.

So heartbeat defaults are just:

every 4h
model override lmstudio/qwen3.5-9b

Nothing weird there by itself.

What is notable is what’s missing:

no isolatedSession: true
no lightContext: true

So heartbeat is likely running as a full main-session turn. On a small local model, that makes retry / overflow / empty-response churn much more plausible.

I still want one more config check to rule out duplicate heartbeat agents:

#

openclaw config get agents.list

If that comes back clean, my current best guess becomes:

heartbeat is using full session context,
LM Studio/qwen3.5-9b is struggling with that prompt shape,
OpenClaw retries, which looks like multiple model loads.

If agents.list does not show another heartbeat-enabled agent, I’d try this next:

agents: {
  defaults: {
    heartbeat: {

#

      every: "4h",
      model: "lmstudio/qwen3.5-9b",
      isolatedSession: true,
      lightContext: true
    }
  }
}

That’s the fastest way to test whether this is context/retry pressure instead of duplicate scheduling.

#

Perfect, this rules out the multi-agent heartbeat theory.

Only main is inheriting the default heartbeat. sootsayer does not have its own heartbeat block, so this is not “2 agents both running the 4h heartbeat”.

So my read now is:

probably not a temporary bad state
probably not duplicate scheduling from multiple agents
most likely a single heartbeat doing extra LM Studio requests because it’s running against full session context, and/or getting event-driven wakes

The strongest clue is still that your heartbeat config is just:

every: "4h"
model: "lmstudio/qwen3.5-9b"

with no:

#

isolatedSession: true
lightContext: true

That means heartbeat is using the full main-session context, which is exactly where a smaller local model can start doing retry-ish behavior.

Fastest test / likely fix

Try this:

agents: {
  defaults: {
    heartbeat: {
      every: "4h",
      model: "lmstudio/qwen3.5-9b",
      isolatedSession: true,

#

      lightContext: true
    }
  }
}

then restart:

openclaw gateway restart

If the extra model loads disappear after that, the root cause was context/retry pressure, not a broken heartbeat scheduler.

If it still happens after that, the next thing I want is the matching:

#

openclaw logs --follow

around one heartbeat run, to see whether it’s:

reason=interval plus extra wakes, or
empty response detected / reasoning-only ... retrying / similar retry lines.

So, short version: this is looking more like “single heartbeat + local-model pressure” than “bad state” or “two heartbeats by accident.”

Also, I’d update to 2026.4.15 when convenient, but based on what you’ve pasted so far, I don’t think update-state is the main culprit.

gilded ermine Apr 18, 2026, 1:23 AM

#

openclaw config get agents.list shows only two agents, main and another one

indigo voidBOT Apr 18, 2026, 1:24 AM

#

Okay, we found the real culprit.

This does not look like a heartbeat scheduling bug or a weird temporary state.

Your logs show:

the embedded run is timing out
LM Studio preload is failing with:
- model_load_failed
- insufficient system resources
- model needs about 10.62 GB
then OpenClaw surfaces an incomplete turn

So the “multiple loads” are most likely repeated LM Studio load/preload attempts, not multiple heartbeat agents.

What this means

#

Heartbeat is trying to use lmstudio/qwen3.5-9b, and LM Studio is saying:

I can’t load that model under the current memory guardrails / available RAM

Then OpenClaw keeps going without preload, but the actual run still times out.

Best fix order

Fix the LM Studio side first
- lower the model’s load context length / contextWindow
- or use a smaller / lighter variant
- or relax LM Studio guardrails only if the host really has the RAM
Make heartbeat lighter
```
agents: {
```

#

     defaults: {
       heartbeat: {
         every: "4h",
         model: "lmstudio/qwen3.5-9b",
         isolatedSession: true,
         lightContext: true
       }
     }
   }

Restart gateway
```
openclaw gateway restart
```

#

Test the model directly before waiting 4h

openclaw infer model run --model <same lmstudio model ref heartbeat uses> --prompt "Reply with exactly: smoke-ok" --json

If that tiny direct run still fails or times out, heartbeat was never the real problem, it was the LM Studio load path.

So, direct answer

This looks like something else, specifically:

LM Studio resource/load failure
plus heartbeat using a full session context, which makes the local run heavier

Docs:
https://docs.openclaw.ai/providers/lmstudio
https://docs.openclaw.ai/gateway/local-models

#

https://docs.openclaw.ai/gateway/troubleshooting#local-openai-compatible-backend-passes-direct-probes-but-agent-runs-fail

If you want, send the LM Studio model config next, especially the model’s contextWindow / preferred load context length. That’s the next place I’d look.

#

Yep, this lines up with the diagnosis.

That heartbeat:

did run for ~14s
produced a real preview ("Backup complete.")
then got skipped only because target-none

So this still does not look like duplicate heartbeat scheduling.

The smoking gun remains the LM Studio side:

model_load_failed
insufficient system resources
timeout + incomplete turn

At this point I’d move straight to:

#

lower LM Studio load context / preferred context length

enable

isolatedSession: true,
lightContext: true

retest the model directly with openclaw infer model run ...

If you want, paste the LM Studio model config next, especially the model’s context length. That’s the next thing most likely to explain the 10.62 GB requirement.

gilded ermine Apr 18, 2026, 1:25 AM

#

lm studio is fine, i'm using bigger models in the chat. it's specifically heartbeat that has been breaking

indigo voidBOT Apr 18, 2026, 1:26 AM

#

Yep, and that’s consistent with what we already found.

The important part is not “there are two agents”, it’s:

only main is inheriting heartbeat
the other agent does not have its own heartbeat block

So the second agent is not why the model gets loaded multiple times.

At this point I’m pretty confident the chain is:

single heartbeat runs on main
it uses lmstudio/qwen3.5-9b
LM Studio tries to preload/load it
LM Studio rejects or stalls because of resource / memory guardrails
OpenClaw times out, which makes it look like repeated loads/retries

#

So I would stop chasing “duplicate heartbeat bug” and focus on:

LM Studio memory / load settings
heartbeat context size

Most useful next change

agents: {
  defaults: {
    heartbeat: {
      every: "4h",
      model: "lmstudio/qwen3.5-9b",
      isolatedSession: true,
      lightContext: true
    }

#

}
}

Then restart:

openclaw gateway restart

And test the same model directly before waiting for heartbeat again.

If you want, paste the LM Studio model’s context length / load settings next, and I can help tune that part.

gilded ermine Apr 18, 2026, 1:26 AM

#

is there a way to force a heartbeat run?

indigo voidBOT Apr 18, 2026, 1:27 AM

#

Yep, that can still be true.

I’m not saying LM Studio is broken globally. I’m saying the heartbeat path is different from your normal chat path, and that is what the logs show failing.

What the logs specifically say is:

heartbeat is using lmstudio/qwen3.5-9b
that path hits LM Studio preload/load
LM Studio returns model_load_failed / insufficient resources
then the heartbeat run times out

So, bigger chat models working does not contradict this. Heartbeat differs in a few important ways:

it uses a different model override
it often hits after hours of idle time, so the model may be cold/unloaded
it uses the full main session context unless you set isolatedSession / lightContext
it can be woken by system events like your "Backup complete." one

#

Best A/B test now

Use your working chat model as the control.

Option A

Temporarily point heartbeat at the same exact LM Studio model ref that works in chat.

Option B

Keep lmstudio/qwen3.5-9b, but add:

isolatedSession: true,
lightContext: true

If A works, or B fixes it, then the problem is heartbeat-specific prompt/load behavior, not “LM Studio is broken”.

#

So I’d phrase it like this:

not a general LM Studio failure
not multiple heartbeat agents
yes, likely a heartbeat-specific load/timeout path

If you paste the exact LM Studio model ref you use successfully in chat, I can tell you which A/B test I’d run first.

gilded ermine Apr 18, 2026, 1:27 AM

#

i've already made the isolation changes you suggested

indigo voidBOT Apr 18, 2026, 1:28 AM

#

Yep. The supported way is:

openclaw system event --text "Heartbeat smoke test" --mode now

That:

enqueues a system event on the main session
triggers heartbeat immediately

Then watch it with:

openclaw logs --follow
openclaw system heartbeat last

#

If heartbeats were disabled for some reason, re-enable first:

openclaw system heartbeat enable

So there isn’t really a separate run heartbeat now command, but system event --mode now is the “force a heartbeat right now” path.

gilded ermine Apr 18, 2026, 1:28 AM

#

qwen-9b for heartbeat has been loading perfectly fine in previous openclaw versions

indigo voidBOT Apr 18, 2026, 1:28 AM

#

Nice, that’s exactly the right next step.

If you already changed isolatedSession + lightContext, then the cleanest thing now is a forced repro.

If you haven’t restarted yet, do that first:

openclaw gateway restart

Then run:

openclaw logs --follow

and in another shell:

#

openclaw system event --text "Heartbeat smoke test" --mode now

Then paste the log lines from that one run, especially anything containing:

reason=
timeout
empty response
LM Studio inference preload
embedded run failover decision
incomplete turn detected

That’ll tell us pretty quickly whether the isolation change fixed the context-pressure part, or whether the remaining problem is still the LM Studio preload/load path.

gilded ermine Apr 18, 2026, 1:29 AM

#

openclaw system event --text "Heartbeat smoke test" --mode now

🦞 OpenClaw 2026.4.14 (323493f) — Powered by open source, sustained by spite and good documentation.

│
◇
ok

indigo voidBOT Apr 18, 2026, 1:29 AM

#

That’s a really good data point, and honestly it changes the read a bit.

If the same heartbeat model worked on older OpenClaw versions, then I agree, this starts to smell less like “your LM Studio setup is fundamentally too weak” and more like a regression in the newer heartbeat / LM Studio load path.

The logs still matter though. They’re pointing at the LM Studio inference preload path, so my updated take is:

not duplicate heartbeat agents
not just a random bad state
possibly a recent regression in how newer OpenClaw builds preload/run the heartbeat LM Studio model

Also, you’re on 2026.4.14 and status already showed 2026.4.15 available. Since the LM Studio preload path has had recent churn, I’d definitely test the next patch version too.

What I’d do next

Keep your isolation changes in place
Force one clean heartbeat repro
If it still fails, update to 2026.4.15

#

Re-test

If the same failure survives that, I think you’ve got a pretty solid bug report / regression report.

The key report details would be:

heartbeat model: lmstudio/qwen3.5-9b
worked in older OpenClaw versions
breaks in recent versions
only main heartbeat is active, no duplicate heartbeat agent
logs show LM Studio inference preload failed + timeout/incomplete turn

If you want, send the forced-run logs after the isolation change, and I’ll help you decide whether this is ready for a GitHub issue:
https://github.com/openclaw/openclaw/issues

#

Perfect, that means the forced wake was accepted.

Now the useful part is what happened right after that.

Please paste:

openclaw system heartbeat last

and, if you had it open, the matching chunk from:

openclaw logs --follow

for that forced run.

#

That’ll tell us whether the isolation change helped, or whether the same LM Studio preload/timeout path is still firing.

gilded ermine Apr 18, 2026, 1:32 AM

#

from the logs:
01:28:54+00:00 info ok

openclaw system heartbeat last
{
"ts": 1776475871695,
"status": "skipped",
"reason": "target-none",
"preview": "⚠️ Agent couldn't generate a response. Please try again.",
"durationMs": 10470,
"hasMedia": false
}

indigo voidBOT Apr 18, 2026, 1:33 AM

#

Yeah, that’s a strong signal.

Even after isolation, the forced heartbeat still ends with:

⚠️ Agent couldn't generate a response
in about 10s
with target-none only because heartbeat isn’t delivering anywhere

So isolation did not fix it. That makes the “full-session context is too big” theory weaker.

At this point, with everything you’ve shared, I’d call this:

not duplicate heartbeat agents
not a random bad state
likely a real regression in the heartbeat + LM Studio preload/timeout path

What I’d do next

#

Update to 2026.4.15
- you already have that update available
- then rerun the same forced smoke test
If it still fails, file a bug:
https://github.com/openclaw/openclaw/issues

Minimal repro to include

version: 2026.4.14
heartbeat model: lmstudio/qwen3.5-9b
worked on older OpenClaw versions
only main heartbeat is active

forced repro:

openclaw system event --text "Heartbeat smoke test" --mode now

#

  openclaw system heartbeat last

result:

{
  "status": "skipped",
  "reason": "target-none",
  "preview": "⚠️ Agent couldn't generate a response. Please try again."
}

earlier logs showed:
- LM Studio inference preload failed
- model_load_failed
- timeout / incomplete turn

Short-term workaround

gilded ermine Apr 18, 2026, 1:33 AM

#

actually the logs came in delayed:
01:29:01+00:00 warn tools {"subsystem":"tools"} tools.profile (coding) allowlist contains unknown entries (gateway). These entries are shipped core tools but unavailable in the current runtime/provider/model/config.
01:29:01+00:00 warn tools {"subsystem":"tools"} agents.main.tools.allow allowlist contains unknown entries (gateway). These entries are shipped core tools but unavailable in the current runtime/provider/model/config.
01:29:24+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=149a9db0-f704-4f7a-b73a-30227425e94c sessionId=8d8527ff-cde0-4443-8a63-2bf0fb425add stopReason=stop payloads=0 — surfacing error to user
01:31:00+00:00 info ok
01:31:11+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=d65d80ad-2902-448e-87cd-eaa143897ef0 sessionId=ab3c8da9-5634-4e8a-9df8-7acf915580f2 stopReason=stop payloads=0 — surfacing error to user
01:32:22+00:00 info ok
01:32:24+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 238ms conn=2a632c0e…e408 id=3b6978d4…2d2f
01:32:25+00:00 warn extensions/lmstudio/stream {"subsystem":"extensions/lmstudio/stream"} LM Studio inference preload failed for "qwen3.5-9b"; continuing without preload: Error: LM Studio model load failed (500): {
"error": {
"type": "model_load_failed",
"message": "Failed to load LLM 'qwen3.5-9b': Error: Model loading was stopped due to insufficient system resources. Under the current settings, this model requires approximately 10.62 GB of memory, and continuing to load it would likely overload your system and cause it to freeze. If you think this is incorrect, you can adjust the model loading guardrails in settings."
}
} repeated three more timse

indigo voidBOT Apr 18, 2026, 1:33 AM

#

If you need heartbeat working right now, I’d temporarily:

point heartbeat at the same LM Studio model that works in chat, or
disable heartbeat until the regression is sorted

If you want, I can help you draft the exact GitHub issue text from what you already collected.

gilded ermine Apr 18, 2026, 1:33 AM

#

there's plenty of memory

#

multiple instances of the model got loaded so obviously the model itself is loading and is loadable and is not subject to memory pressure

indigo voidBOT Apr 18, 2026, 1:34 AM

#

Yep, that’s the smoking gun.

The real cause is this line:

extensions/lmstudio/stream
LM Studio inference preload failed
model_load_failed
insufficient system resources
repeated multiple times

So the “multiple loads” are repeated preload/load attempts for the heartbeat model, and LM Studio is rejecting them.

A couple of clarifications:

the gateway allowlist warnings are separate noise, not the heartbeat failure
the heartbeat failure itself is the LM Studio preload path
because you said older OpenClaw versions worked, I’d now describe this as a heartbeat/LM Studio preload regression, not a duplicate-heartbeat bug

#

My best current read

scheduler is fine
only one heartbeat agent is active
heartbeat is hitting a newer LM Studio preload behavior
that preload path is trying to load qwen3.5-9b
LM Studio refuses the load, then the run ends as an incomplete turn

What I’d do now

Update to 2026.4.15
- there’s been recent churn in the LM Studio preload path
- this may at least stop the repeated preload spam / improve behavior
If it still reproduces, file a bug:
https://github.com/openclaw/openclaw/issues

#

Temporary workaround:
- use the same model that already works in chat for heartbeat, or
- keep qwen preloaded / reduce its LM Studio load context

One extra cleanup

You should also remove the stale gateway entry from your tool allowlist at some point, since OpenClaw is warning it’s unknown in your current runtime. That’s probably unrelated, but it’s worth cleaning up.

If you want, I can turn everything you collected into a tight GitHub issue template you can paste.

#

Yep, and that’s a fair pushback.

The log does not prove the machine is actually out of RAM. What it proves is:

LM Studio’s own guardrail is rejecting the preload request
it thinks that load would need about 10.62 GB
so it refuses to load it

Those are different things.

So I’d refine the diagnosis to:

not “your box has no memory”
yes “newer OpenClaw heartbeat/preload behavior is making LM Studio reject this specific load request”

That actually makes the regression theory stronger.

#

Most likely possibilities now are:

heartbeat is asking LM Studio to preload qwen-9b with a different context length / load shape
LM Studio’s guardrail estimate is being tripped on that path
older OpenClaw versions didn’t hit the same preload path, or didn’t ask for the same load shape

Best next config check

Please paste:

openclaw config get models.providers.lmstudio

What I want to see is the qwen3.5-9b entry, especially its:

contextWindow

#

any load/context-related settings

If heartbeat is requesting a much larger context than you expect, that would fit the logs perfectly.

gilded ermine Apr 18, 2026, 1:35 AM

#

You should also remove the stale gateway entry from your tool allowlist at some point, since OpenClaw is warning it’s unknown in your current runtime. That’s probably unrelated, but it’s worth cleaning up.
i don't know how to do this and where this is

indigo voidBOT Apr 18, 2026, 1:35 AM

#

Yeah, that’s a fair correction.

If you’re actually seeing multiple instances load, then I agree, the model is loadable and the “insufficient resources” message is probably not the real root cause. It’s more likely a bad/misleading side-effect of the repeated preload attempts.

So I’d tighten the diagnosis to this:

the bug is not “qwen-9b can’t load”
the bug is heartbeat is triggering repeated LM Studio preload/load attempts
that repeated preload path is what’s breaking the run

Given everything you’ve shown, I think this is now best described as a regression in the heartbeat → LM Studio preload path.

That also matches:

worked in older OpenClaw versions
only heartbeat is broken
forced heartbeat repros it
only one heartbeat agent is active

#

What I’d do now

test 2026.4.15
if it still happens, file a GitHub issue framed like this:
- “heartbeat repeatedly triggers LM Studio preload/load attempts for an otherwise loadable model”
- “results in incomplete turn / no response”
- “regression from older OpenClaw versions”

If you want, I can draft the exact issue text now so you can just paste it into:
https://github.com/openclaw/openclaw/issues

gilded ermine Apr 18, 2026, 1:36 AM

#

if it helps, openclaw makes LM studio load much larger models automatically when switching models in the chat. so something specific to the heartbeat path is broken

#

i'm updating openclaw to latest now

indigo voidBOT Apr 18, 2026, 1:38 AM

#

Yep, that part is in your config file.

OpenClaw reads config from:

~/.openclaw/openclaw.json

Quickest way to find it:

grep -n '"gateway"' ~/.openclaw/openclaw.json

You’re looking for "gateway" inside a tool allowlist, usually in one of these spots:

top-level tools.allow or tools.alsoAllow

#

the main agent under agents.list[].tools.allow or agents.list[].tools.alsoAllow

What to do

If you see something like:

tools: {
  alsoAllow: ["browser", "gateway"]
}

change it to:

tools: {
  alsoAllow: ["browser"]

#

Or if it’s under the main agent:

agents: {
  list: [
    {
      id: "main",
      tools: {
        allow: ["read", "write", "gateway"]
      }
    }
  ]

#

remove just "gateway" from that array.

Then save the file. OpenClaw usually hot-reloads config, but if the warning keeps showing, restart once:

openclaw gateway restart

If you want, paste the output of:

grep -n '"gateway"' ~/.openclaw/openclaw.json

#

and I’ll tell you exactly what to remove.

Docs for config location/editing: https://docs.openclaw.ai/gateway/configuration

#

Yeah, that helps a lot.

That makes the picture much cleaner:

normal chat path can switch/load even larger LM Studio models
heartbeat path is the one that repeatedly loads / fails

So I’d consider generic LM Studio loading issues mostly ruled out now.

At this point, the most likely read is:

heartbeat-specific regression
probably in the embedded/preload path heartbeat uses
not just RAM pressure, and not “LM Studio can’t load the model”

Honestly, that’s strong bug-report material now.

#

If you want, I can draft a tight GitHub issue that says exactly that, with the repro steps and the evidence you already gathered.

#

Nice, that’s the right next step.

After it updates, I’d do a clean retest:

openclaw gateway restart

then in one shell:

openclaw logs --follow

and in another:

#

openclaw system event --text "Heartbeat smoke test" --mode now
openclaw system heartbeat last

Paste the heartbeat last output plus the matching log chunk from that run.

If 2026.4.15 fixes it, great. If not, we’ve got a pretty solid heartbeat-specific regression case.

gilded ermine Apr 18, 2026, 1:45 AM

#

a slight difference after restart but no effective difference in the result. it got loaded 4 times still. model context is set to 64k, which should be plenty for an isolated session.

logs:
01:42:00+00:00 info ok
01:42:31+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=0bccb4a0-c633-4257-9fe8-603db724499a sessionId=a8e3427f-dba2-47a6-bc1f-1515dc63621c stopReason=stop payloads=0 — surfacing error to user

commands output:
openclaw system event --text "Heartbeat smoke test" --mode now

🦞 OpenClaw 2026.4.15 (041266a) — Greetings, Professor Falken

│
◇
ok

openclaw system heartbeat last

🦞 OpenClaw 2026.4.15 (041266a) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

│
◇
null

#

it takes the model less than 2s to load

#

i think this is a bug, i'd appreciate help filing the issue

indigo voidBOT Apr 18, 2026, 1:51 AM

#

Absolutely. I can’t open it for you, but here’s a paste-ready draft for:

https://github.com/openclaw/openclaw/issues/new

Title

Heartbeat with LM Studio repeatedly loads model multiple times, ends in incomplete turn, and does not persist heartbeat result

Body

## Summary

Since the last couple of OpenClaw updates, heartbeat appears to trigger repeated LM Studio model loads for my heartbeat model instead of performing a single run.

The configured heartbeat model is `lmstudio/qwen/qwen3.5-9b`.

#


What makes this seem heartbeat-specific is that normal OpenClaw chat/model switching via LM Studio works fine on the same machine, including larger models. The repeated loads only happen on the heartbeat path.

## Versions

- OpenClaw 2026.4.14 (`323493f`) - reproduced
- OpenClaw 2026.4.15 (`041266a`) - still reproduced after update
- OS: Linux `6.12.75+rpt-rpi-2712` (`arm64`)
- Node: `24.14.1`

## Heartbeat config

```json5
{
  "heartbeat": {
    "every": "4h",

#

"model": "lmstudio/qwen/qwen3.5-9b"
}
}


Additional relevant info:

- LM Studio model context is set to `64k`
- I already tried the suggested isolation changes:
  - `isolatedSession: true`
  - `lightContext: true`
- Those changes did not fix the issue

## What I expected

Heartbeat should run once, load the model once if needed, generate a response, and persist the heartbeat result.

#


## What actually happens

- LM Studio loads the heartbeat model multiple times (I observed 4 loads on the latest repro)
- Heartbeat does not complete successfully
- OpenClaw logs show the embedded run stopping without payloads
- On the latest repro, `openclaw system heartbeat last` returned `null`

## Why this seems heartbeat-specific

On this same setup:

- OpenClaw can switch models in normal chat through LM Studio
- Larger LM Studio models also load fine in normal chat/model switching
- The repeated load behavior appears specific to the heartbeat path

#


So this does not look like a generic “LM Studio cannot load models” problem.

## Repro steps

1. Configure heartbeat to use `lmstudio/qwen/qwen3.5-9b`
2. Restart the gateway:
   ```bash
   openclaw gateway restart

Watch logs:
```
openclaw logs --follow
```
Force a heartbeat:

#

openclaw system event --text "Heartbeat smoke test" --mode now

5. Check the last heartbeat result:
```bash
openclaw system heartbeat last

Latest observed output

Forced run:

openclaw system event --text "Heartbeat smoke test" --mode now

Result:

#


```text
ok

Heartbeat last:

openclaw system heartbeat last

Result:

null

#


Relevant log line from the same run:

```text
warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=0bccb4a0-c633-4257-9fe8-603db724499a sessionId=a8e3427f-dba2-47a6-bc1f-1515dc63621c stopReason=stop payloads=0 — surfacing error to user

Earlier related logs from the same issue

Before updating to 2026.4.15, I also saw logs like:

embedded run failover decision
failoverReason":"timeout"
provider":"lmstudio"
model":"qwen/qwen3.5-9b"

#

timedOut":true
aborted":true


and repeated LM Studio preload failures like:

```text
LM Studio inference preload failed for "qwen3.5-9b"; continuing without preload
type: "model_load_failed"
message: "Failed to load LLM 'qwen3.5-9b': Error: Model loading was stopped due to insufficient system resources..."

However, that LM Studio message may be secondary/misleading, because on this same setup:

the model is loadable
larger models load in normal chat/model switching

#

- heartbeat is the path that repeatedly triggers multiple loads

## Other things already ruled out

- This does not appear to be duplicate heartbeat agents/scheduling
- Isolation changes did not help
- A 64k context window should be more than enough for an isolated heartbeat session

## Question / suspected area

This looks like a regression in the heartbeat-specific embedded/preload LM Studio path.

It would be especially helpful to know whether heartbeat is taking a different load/preload path from normal chat LM Studio runs, because normal chat switching works while heartbeat repeatedly reloads the model and fails.

If you want, I can also make that a shorter maintainer-friendly version before you post it.

#heartbeat loads local model several times

openclaw --version OpenClaw 2026.4.14 (323493f)

Fastest test / likely fix

What this means

Best fix order

So, direct answer

Most useful next change

Best A/B test now

Option A

Option B

What I’d do next

What I’d do next

Minimal repro to include

Short-term workaround

My best current read

What I’d do now

One extra cleanup

Best next config check

What I’d do now

What to do

Latest observed output

Earlier related logs from the same issue

openclaw --version
OpenClaw 2026.4.14 (323493f)