Promptss are stopping

[normal juniper]

Im seeing these errors in the log

[vestal bay]

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

[lavish lodge]

Those logs are context-window pressure, not a Discord/channel error.

The important bits:

• estimatedPromptTokens=65934
• promptBudgetBeforeReserve=47616
• provider=lmstudio/qwen3.6-35b-a3b-mtp
• Context overflow: prompt too large for the model (precheck)
• then OpenClaw tries auto-compaction

So the agent session got too large for the effective context budget of that LM Studio model. The earlier lines with handled=true truncatedCount=... mean OpenClaw successfully trimmed tool results; the compact_then_truncate one means trimming was not enough, so it tried compaction.

First: what does this show?

openclaw --version

[lavish lodge]

Practical fixes to try:

/new

That starts a fresh session and is usually the fastest fix if prompts are stopping.

If it keeps happening on fresh sessions, the local LM Studio model/context setting is probably too small for this workflow. Either use a larger-context model/provider, reduce the amount of pasted/log/tool output going into the session, or lower how much recent history/tool output is retained. Relevant docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/reference/session-management-compaction
https://docs.openclaw.ai/gateway/configuration-reference

If /new does not clear it, paste openclaw --version plus:

[lavish lodge]

openclaw status --all
openclaw models status

and the next log lines after “attempting auto-compaction” — that will show whether compaction is completing or getting stuck.

[normal juniper]

But I've set the context much higher than 64K

[lavish lodge]

That’s the key clue: OpenClaw is still budgeting this run as about 64K.

promptBudgetBeforeReserve=47616 + effectiveReserveTokens=16384 = 64000 exactly. So even if LM Studio is set higher, this OpenClaw model entry/session is currently being treated as a 64K context model.

Things I’d check:

openclaw --version
openclaw models status

Then inspect the configured LM Studio model entry and look for contextWindow / contextTokens. In OpenClaw config, contextWindow is the native model metadata, while contextTokens is an optional runtime cap. If contextTokens is set to 64000-ish, it will cap the effective budget even when contextWindow is larger.

Docs for those fields: https://docs.openclaw.ai/gateway/configuration-reference

Also: changing LM Studio’s context setting does not necessarily update OpenClaw’s saved provider/model catalog for an already-added model. You may need to re-add/refresh the LM Studio model or explicitly update the models.providers.lmstudio.models[] entry so OpenClaw sees the larger contextWindow.

[lavish lodge]

One more nuance: OpenClaw reserves output/housekeeping headroom, so you will never get the full raw context as prompt budget. But the log math here is not “128K minus reserve”; it’s “64K minus reserve,” so the config/catalog is where I’d look first.

[normal juniper]

You can find the config here https://cl1p.net/4566

[lavish lodge]

I can read it, and first: that paste contains live-looking secrets/tokens. Please delete the cl1p and rotate anything that was in there: Telegram bot tokens, gateway auth token, Brave key, AgentMail key. Don’t leave that public.

On the context issue: your pasted config does not match the log behavior.

Your config says the active model should be:

contextWindow: 262144,
contextTokens: 200000

and compaction has:

reserveTokens: 48000,
reserveTokensFloor: 48000

[lavish lodge]

But the log says:

promptBudgetBeforeReserve=47616
effectiveReserveTokens=16384

That math points to a 64K effective context (47616 + 16384 = 64000) and the default-ish 16K reserve, not your 200K/48K config. So I don’t think LM Studio’s raw context setting is the immediate issue; OpenClaw/the running agent is not using the config values you pasted for that session.

Check these next:

openclaw --version
openclaw status --all
openclaw models status
openclaw config validate

[lavish lodge]

Also check whether the lead-scout agent has an older generated model catalog overriding/lagging behind the main config:

ls -la ~/.openclaw/agents/lead-scout/agent
sed -n '1,220p' ~/.openclaw/agents/lead-scout/agent/models.json

If that file shows the same LM Studio model with contextWindow/contextTokens around 64000, that explains the log. After fixing/removing stale model metadata, restart the gateway and start a fresh session with /new.

One more thing: your log is from sessionKey=agent:lead-scout:telegram:direct:..., so focus on the effective config for the lead-scout agent, not just the global config file.

[normal juniper]

Results can be found here https://cl1p.net/4567

[lavish lodge]

This output helps. The main issue is that models status inspected the sql agent, not lead-scout:

Agent dir: ~/.openclaw/agents/sql/agent

But the overflow log is from:

sessionKey=agent:lead-scout:telegram:direct:...

So we still need the effective model state for the agent that is actually failing:

openclaw models status --agent lead-scout

[lavish lodge]

If you can, also check the lead-scout model catalog directly:

sed -n '1,260p' ~/.openclaw/agents/lead-scout/agent/models.json

What I’m looking for is whether lmstudio/qwen3.6-35b-a3b-mtp resolves to contextTokens: 200000 there, or whether that agent has stale 64000 metadata.

Your status --all also shows 195 sessions total and lead-scout has 1 session, so a stale active session is still possible. After confirming/fixing the lead-scout model catalog, restart the gateway and start a clean lead-scout conversation with /new.

Also please avoid pasting full config dumps publicly. The previous paste included live-looking secrets; status --all is much safer because it redacts tokens.

[normal juniper]

Results here https://cl1p.net/4568

[lavish lodge]

This paste only shows the first 220 lines of models.json, and it stops before the lmstudio provider, so it doesn’t include the part we need.

Use a targeted command so you don’t have to paste the whole file:

openclaw models status --agent lead-scout

And either:

jq '.providers.lmstudio.models[] | select(.id == "qwen3.6-35b-a3b-mtp" or .id == "qwen/qwen3.6-35b-a3b-mtp") | {id, contextWindow, contextTokens, maxTokens}' ~/.openclaw/agents/lead-scout/agent/models.json

or, if jq is not installed:

[lavish lodge]

rg -n 'lmstudio|qwen3.6-35b|contextWindow|contextTokens|maxTokens' ~/.openclaw/agents/lead-scout/agent/models.json

The first command is the better one. It should tell us whether lead-scout’s stored LM Studio model is actually 200K, or if the agent catalog still has a 64K-ish entry.

If it does show 200K there too, then the next suspect is stale session/runtime state rather than the model catalog: restart gateway, then /new in the lead-scout Telegram chat, and watch whether the next overflow log still says promptBudgetBeforeReserve=47616.

[normal juniper]

OpenClaw 2026.5.22 (a374c3a) — Less clicking, more shipping, fewer "where did that file go" moments.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/lead-scout/agent
Default (agent): lmstudio/qwen3.6-35b-a3b-mtp
Fallbacks (0) (agent): -
Image model (defaults): -
Image fallbacks (0) (defaults): -
Aliases (2) : OpenRouter -> openrouter/free, lmstudio/google/gemma-4-31b -> local-gemma
Configured models (9): olama/kimi-k2.5:cloud, openrouter/free, local-gemma, openrouter/hunter-alpha, openrouter/meta-llama/llama-3.3-70b-instruct:free, openrouter/qwen3-coder:free, lmstudio/google/gemma-4-31b, lmstudio/qwen3.6-27bQ8-mtp, lmstudio/qwen3.6-35b-a3b-mtp

Auth overview
Auth store : ~/.openclaw/agents/lead-scout/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

• lmstudio effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | lmstudio:default=N...e | models.json=lm...io | source=models.json: ~/.openclaw/agents/lead-scout/agent/models.json
• openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...9f586087

OAuth/token status

• none

[lavish lodge]

Good, that confirms we’re now looking at the right agent.

This line is important:

source=models.json: ~/.openclaw/agents/lead-scout/agent/models.json

So lead-scout is reading its per-agent models.json. The remaining missing piece is the actual stored metadata for the LM Studio model inside that file. models status confirms the selected model, but it does not print contextWindow / contextTokens in this plain view.

Please run the targeted check:

jq '.providers.lmstudio.models[] | select(.id == "qwen3.6-35b-a3b-mtp" or .id == "qwen/qwen3.6-35b-a3b-mtp") | {id, contextWindow, contextTokens, maxTokens}' ~/.openclaw/agents/lead-scout/agent/models.json

If that prints nothing, run:

[lavish lodge]

rg -n 'lmstudio|qwen3.6-35b|contextWindow|contextTokens|maxTokens' ~/.openclaw/agents/lead-scout/agent/models.json

I’m specifically trying to reconcile this contradiction:

log budget: 47616 + 16384 = 64000
config you pasted: contextTokens 200000, reserveTokensFloor 48000

If lead-scout’s models.json shows 200K too, then the next move is: gateway restart + /new, because the active session/runtime was likely created with older 64K settings. If it shows 64K, then update/recreate that per-agent model entry.

[normal juniper]

{
"id": "qwen/qwen3.6-35b-a3b-mtp",
"contextWindow": 262144,
"contextTokens": 200000,
"maxTokens": 131072
}

[lavish lodge]

Found the mismatch.

Your selected OpenClaw model is:

lmstudio/qwen3.6-35b-a3b-mtp

But the model catalog entry is:

"id": "qwen/qwen3.6-35b-a3b-mtp"

Those are different model ids. OpenClaw strips the provider prefix, so lmstudio/qwen3.6-35b-a3b-mtp resolves with model id qwen3.6-35b-a3b-mtp, but your metadata is attached to qwen/qwen3.6-35b-a3b-mtp. Because it can’t match that metadata, it falls back to the default context budget, which is exactly what the log showed: 64K minus 16K reserve.

Fix either side so the ids match. I’d use the actual LM Studio id everywhere:

[lavish lodge]

agents: {
  defaults: {
    model: {
      primary: "lmstudio/qwen/qwen3.6-35b-a3b-mtp"
    },
    models: {
      "lmstudio/qwen/qwen3.6-35b-a3b-mtp": {}
    }
  }
}

Also update the lead-scout agent model if it has its own model field:

[lavish lodge]

{
  id: "lead-scout",
  model: "lmstudio/qwen/qwen3.6-35b-a3b-mtp"
}

Then restart the gateway and start a fresh lead-scout session with /new. After that, the overflow log should no longer show promptBudgetBeforeReserve=47616; with your 200K context cap and 48K reserve, it should be much closer to ~152K prompt budget.

Docs reference for model context metadata: https://docs.openclaw.ai/gateway/configuration-reference

[normal juniper]

I'm seeing this in the error log
05:41:27
warn
agent/embedded
[context-overflow-midturn-precheck] sessionKey=agent:lead-scout:telegram:direct:6938637819 provider=lmstudio/qwen3.6-35b-a3b-mtp route=compact_then_truncate estimatedPromptTokens=55713 promptBudgetBeforeReserve=47616 overflowTokens=8097 toolResultReducibleChars=47390 effectiveReserveTokens=16384 prePromptMessageCount=74 sessionFile=/home/admin/.openclaw/agents/lead-scout/sessions/2026-05-27T04-36-02-092Z_faff7b06-afc4-4eaf-a6ef-c798d7a3a984.jsonl

[lavish lodge]

That warning means OpenClaw caught the prompt getting too large before sending it to LM Studio.

In your numbers: estimated prompt is 55,713 tokens, but the usable prompt budget before reserved output headroom is 47,616, so it is about 8,097 tokens over. route=compact_then_truncate means it will try to compact the session, then trim large tool results if needed. The toolResultReducibleChars=47390 bit suggests bulky tool output/history is a big part of the pressure.

A few practical fixes:

• First, what does openclaw --version show?
• Try /compact in that session, or /new / /reset if you do not need the old context.
• If this keeps happening with that LM Studio model, increase the model context window in LM Studio if the model/server supports it, or use a larger-context model.
• If the agent is doing lots of tool reads/searches, shorten the task or start a fresh session so old tool results do not keep riding along.

Docs starting points: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/reference/session-management-compaction

[normal juniper]

This is the latest version 2025.5.22, I didn't have the issue before upgrading

[lavish lodge]

Assuming you mean 2026.5.22: that lines up with a newer preflight guard being stricter/noisier about context before the model call. So the warning itself may be new after upgrade, but the underlying condition is still: the existing session is too large for the LM Studio model’s available context.

Two useful checks:

• Does it happen in a brand-new session with the same model, or only this upgraded/older session?
• When it stops, do you also get the user-facing Context overflow: prompt too large for the model... message, or only this warning in logs?

For immediate recovery I’d try /new first for that Telegram session. If you need to preserve it, try /compact, then retry. If a fresh session on 2026.5.22 still quickly hits this with normal prompts, grab openclaw status --all plus the surrounding openclaw logs --follow lines and file it as a regression: https://github.com/openclaw/openclaw/issues

Docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/reference/session-management-compaction

[normal juniper]

I did /status in telegram and it said there were no compactions, however the prompt was incorrectly restarting suggesting there was

[lavish lodge]

That distinction matters. /status showing no compactions means OpenClaw does not think a completed compaction was recorded for that session. The log line you pasted can still happen before any completed compaction: it is a pre-send overflow check deciding “this prompt is too big, recover before sending”.

If the prompt is “restarting” but /status still says no compactions, I’d treat that as either:

• precheck recovery retrying the prompt without a successful compaction being recorded, or
• a regression in the new overflow/precheck path after the upgrade.

Can you grab the surrounding log lines for that same session, especially anything containing these strings?

openclaw logs --follow

Look for:

context-overflow-precheck
auto-compaction succeeded
auto-compaction failed
early recovery

[lavish lodge]

post-compaction tool-result truncation

Also, try one clean test: send /new in Telegram, then one normal prompt. If that works, it’s likely the upgraded old session/history/tool results. If /new still immediately restarts or stalls, that’s much more likely a 2026.5.22 regression and worth filing with openclaw status --all plus those log lines: https://github.com/openclaw/openclaw/issues

[normal juniper]

I'm also seeing these

05:44:07
error
diagnostic
lane task error: lane=main durationMs=892675 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/admin/.openclaw/agents/lead-scout/sessions/2026-05-27T04-44-02-934Z_5ed02805-d157-4a81-a6a5-649956644253.jsonl"
05:44:07
error
diagnostic
lane task error: lane=session:agent:lead-scout:telegram:direct:6938637819 durationMs=892686 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/admin/.openclaw/agents/lead-scout/sessions/2026-05-27T04-44-02-934Z_5ed02805-d157-4a81-a6a5-649956644253.jsonl"

[lavish lodge]

That one is more serious than the context warning. It means the embedded run released its session lock while waiting/recovering, then saw the JSONL session file had changed underneath it before the prompt finished. The ~892s duration is almost 15 minutes, so this looks like a long stuck/retry/compaction path plus another write to the same Telegram session.

Common triggers would be sending another Telegram prompt while the first one is still running, /status or /compact touching the same active session during recovery, or the new precheck path retrying while session state changes.

What I’d do now:

• Stop sending messages to that Telegram thread for a minute so the lane drains.
• Restart the gateway once, then send /new in Telegram and test one normal prompt.
• If it happens again on a fresh session, this is very likely a regression in 2026.5.22 around precheck/compaction/session locking.

For the issue, include both errors together: the context-overflow-midturn-precheck line and this EmbeddedAttemptSessionTakeoverError, plus openclaw status --all and a small log window around the same timestamp. That gives maintainers the lock + overflow path in one report: https://github.com/openclaw/openclaw/issues

[normal juniper]

I did a restart and can see lots of these

05:54:14
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-default
05:54:14
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-sql
05:54:14
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-lead-scout
05:54:14
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-portfolio-guardian
05:54:14
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-default
05:54:14
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-sql
05:54:14
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-lead-scout

[lavish lodge]

Those look like Telegram polling workers starting, one spool per Telegram surface/account/agent. The error level is probably misleading because the message itself says diag ... started.

The duplicate set is the part I’d check. Seeing default, sql, lead-scout, portfolio-guardian once can be normal if you have those Telegram-bound agents. Seeing default/sql/lead-scout start again at the same second can mean either the gateway initialized Telegram twice, or you still have more than one gateway process alive after restart.

Please check this next:

openclaw gateway status
pgrep -af 'openclaw|node' | grep -i openclaw

If there is more than one gateway process, stop the extras cleanly and restart only one gateway. If there is only one process and these duplicate startup lines keep appearing, include this with the earlier EmbeddedAttemptSessionTakeoverError in the GitHub issue because duplicate Telegram ingress could explain the session file changing underneath the active prompt.

For a clean test after confirming one gateway: send /new once in Telegram, wait for the reply, then send one normal prompt. Avoid /status/extra messages while it is running so we can rule out self-overlap.

[normal juniper]

Only one gateway running

[lavish lodge]

Good, that rules out the obvious double-gateway cause.

With only one gateway, the duplicate Telegram ingress lines are probably coming from inside the gateway: multiple Telegram surfaces/agent bindings starting isolated pollers, or a startup/reconnect path starting some pollers twice. Combined with EmbeddedAttemptSessionTakeoverError, that is suspicious enough that I’d treat it as a bug/regression unless /new fully clears it.

Next best signal:

openclaw status --all
openclaw logs --follow

Then after restart, send exactly one /new in Telegram, wait for it to finish, then one normal prompt. If the duplicate ingress lines or session-takeover error happens without you sending overlapping messages, file it with:

• version 2026.5.22
• “only one gateway process running”
• the duplicate isolated polling ingress started lines
• the EmbeddedAttemptSessionTakeoverError
• the earlier context precheck line

Issue link: https://github.com/openclaw/openclaw/issues

[lavish lodge]

This is past normal context overflow troubleshooting now; the session file changing under a single gateway is the key symptom.

[normal juniper]

05:59:34
warn
fetch-timeout
fetch timeout reached; aborting operation
05:59:34
warn
fetch-timeout
fetch timeout reached; aborting operation

[lavish lodge]

Those are generic HTTP fetch aborts. By themselves they do not identify the subsystem; they could be model/provider calls, media download, update/pricing checks, Telegram API calls, or another plugin/network request. The duplicate timestamp usually just means two fetches timed out together.

The important bit is the log lines immediately before/after them. Can you filter a 1-2 minute window around 05:59:34 and look for the component/request nearby?

openclaw logs --since 10m | grep -C 8 'fetch timeout reached'

If --since is not available in your build, use:

openclaw logs --follow

Given your earlier symptoms, I’d especially look for whether these happen right before EmbeddedAttemptSessionTakeoverError or right after a Telegram ingress line. If yes, add them to the same regression issue. If they’re from update/pricing/model metadata checks, they may be noisy but unrelated.

[normal juniper]

06:16:35
warn
agent/embedded
[context-overflow-diag] sessionKey=agent:lead-scout:telegram:direct:6938637819 provider=lmstudio/qwen3.6-35b-a3b-mtp source=promptError messages=21 sessionFile=/home/admin/.openclaw/agents/lead-scout/sessions/37392e6c-651e-42d5-8e63-d23f674005b6.jsonl diagId=ovf-mpnm3a7p-tDUpQg compactionAttempts=0 observedTokens=unknown error=Context overflow: prompt too large for the model (precheck).
06:16:35
warn
agent/embedded
context overflow detected (attempt 1/3); attempting auto-compaction for lmstudio/qwen3.6-35b-a3b-mtp
06:16:34
warn
agent/embedded
embedded run agent end
06:16:34
warn
agent/embedded
[context-overflow-midturn-precheck] sessionKey=agent:lead-scout:telegram:direct:6938637819 provider=lmstudio/qwen3.6-35b-a3b-mtp route=compact_then_truncate estimatedPromptTokens=65150 promptBudgetBeforeReserve=47616 overflowTokens=17534 toolResultReducibleChars=70195 effectiveReserveTokens=16384 prePromptMessageCount=0 sessionFile=/home/admin/.openclaw/agents/lead-scout/sessions/37392e6c-651e-42d5-8e63-d23f674005b6.jsonl
06:16:35
warn
agent/embedded
[context-overflow-diag] sessionKey=agent:lead-scout:telegram:direct:6938637819 provider=lmstudio/qwen3.6-35b-a3b-mtp source=promptError messages=21 sessionFile=/home/admin/.openclaw/agents/lead-scout/sessions/37392e6c-651e-42d5-8e63-d23f674005b6.jsonl diagId=ovf-mpnm3a7p-tDUpQg compactionAttempts=0 observedTokens=unknown error=Context overflow: prompt too large for the model (precheck).
06:16:35
warn
agent/embedded
context overflow detected (attempt 1/3); attempting auto-compaction for lmstudio/qwen3.6-35b-a3b-mtp

[lavish lodge]

This confirms the same failure path, and the numbers are pretty telling:

• estimatedPromptTokens=65150
• usable budget is 47616
• so it is now 17534 tokens over
• toolResultReducibleChars=70195 strongly points at large tool results / generated context being carried in the session
• compactionAttempts=0 means this diagnostic is before the first auto-compaction attempt is counted, so it can still show “no compactions” in /status if the recovery never completes cleanly

The weird bit is prePromptMessageCount=0 paired with messages=21. That suggests the overflow check is happening during/around the active run after messages/tool output have accumulated, not just from old Telegram history. That matches your “prompt restarting” observation and the earlier session-takeover error.

At this point I’d do one of these:

1. Fast recovery: /new for lead-scout, then avoid long/broad tool-heavy prompts on that LM Studio model.
2. If you need the same session: try /reset; /compact may be the path that is failing here.
3. For regression reporting: file this as a 2026.5.22 issue. Include exactly these lines plus the earlier EmbeddedAttemptSessionTakeoverError. The key claim is: precheck overflow triggers auto-compaction/retry, /status reports no compactions, then the prompt appears to restart / session file changes under lock.

Issue link: https://github.com/openclaw/openclaw/issues

[normal juniper]

/new makse zero difference

[lavish lodge]

If /new makes zero difference, then it’s probably not old session history anymore. That points back to the runtime still seeing this model as ~64K context, or the 2026.5.22 embedded/precheck path ignoring the LM Studio metadata.

The quick sanity check is the next fresh log line after /new:

promptBudgetBeforeReserve=47616

If it still says that, OpenClaw is definitely not running lead-scout with the 200K context you expect. As a blunt workaround, set an explicit agent cap in config and restart the gateway:

agents: {
  defaults: {
    contextTokens: 200000
  }
}

[lavish lodge]

Then /new again and check the next overflow line. You want the budget to stop being ~47K. If it stays at 47616 even after that explicit override + restart, I’d stop chasing local fixes and file it as a regression with the exact before/after logs plus openclaw status --all: https://github.com/openclaw/openclaw/issues

Docs reference: https://docs.openclaw.ai/gateway/configuration-reference

[normal juniper]

Let me try a different model as this is lmstudio with a new MTP model

[lavish lodge]

Yeah, that’s a good isolation test.

I’d try a known-stable non-MTP model first, ideally one where LM Studio reports ordinary context metadata. After switching, restart the gateway, send /new, then watch the next overflow/precheck line.

The key comparison is:

provider=...
promptBudgetBeforeReserve=...
estimatedPromptTokens=...

If a different model stops the restart loop, this is probably either LM Studio’s metadata for that new MTP model or OpenClaw’s handling of that specific model id/cap. If it still happens across models, then it’s more likely the 2026.5.22 embedded compaction/session-lock path.

[normal juniper]

I got it again with non mtp model

06:50:10
warn
agent/embedded
embedded run agent end
06:50:10
warn
agent/embedded
[context-overflow-midturn-precheck] sessionKey=agent:lead-scout:telegram:direct:6938637819 provider=lmstudio/qwen/qwen3.6-35b-a3b route=truncate_tool_results_only estimatedPromptTokens=188195 promptBudgetBeforeReserve=183616 overflowTokens=4579 toolResultReducibleChars=264832 effectiveReserveTokens=16384 prePromptMessageCount=0 handled=true truncatedCount=21 sessionFile=/home/admin/.openclaw/agents/lead-scout/sessions/8e860b57-3fef-40bd-ba12-988e99548688.jsonl

[lavish lodge]

That’s useful: the model metadata problem is fixed now.

This line means OpenClaw is seeing roughly the expected 200K context:

promptBudgetBeforeReserve=183616
effectiveReserveTokens=16384

So the non-MTP model is not falling back to 64K. The remaining issue is that the run is genuinely huge:

estimatedPromptTokens=188195
toolResultReducibleChars=264832
route=truncate_tool_results_only
handled=true

[lavish lodge]

truncatedCount=21

Because handled=true, this specific line is not necessarily fatal by itself. It says OpenClaw trimmed 21 tool results and should continue. The important question is: after this line, does the Telegram prompt still restart/stall, or does it complete?

If it restarts/stalls even with handled=true, file that as the regression. The tight bug report is:

2026.5.22, LM Studio qwen/qwen3.6-35b-a3b
context-overflow-midturn-precheck route=truncate_tool_results_only handled=true truncatedCount=21
prompt then restarts/stalls instead of continuing
prePromptMessageCount=0
earlier also saw EmbeddedAttemptSessionTakeoverError

Issue link: https://github.com/openclaw/openclaw/issues

[lavish lodge]

For immediate work: start a fresh /new and make the lead-scout task narrower, because 264K reducible tool chars means the agent is hauling a lot of tool output through the turn.

[normal juniper]

ok, so sounds like MTP model is the issue

[lavish lodge]

Partly, yeah, but I’d split it into two issues:

1. The MTP setup/model id looked bad because OpenClaw was budgeting it like ~64K. That’s why the earlier promptBudgetBeforeReserve=47616 was suspicious.

2. The non-MTP model fixed the context budget, but the task is still enormous: 188195 estimated prompt tokens and 264832 reducible tool chars. So even with the model fixed, lead-scout can still hit the truncation path.

So: avoid that MTP model for now, but if the non-MTP run still restarts/stalls after handled=true, that’s a separate 2026.5.22 truncation/embedded-session regression worth filing.

[normal juniper]

So what setting in lmstudio would result in that 64K limit

[lavish lodge]

In LM Studio, the setting to check is the loaded model’s Context Length / n_ctx. If that is set to 65536, OpenClaw can end up budgeting it as:

65536-ish context - 16384 reserve = ~49152 prompt budget

Your earlier 47616 is close enough to say “OpenClaw thought this was about a 64K-context runtime.”

But in your case there are two likely ways to get that:

• LM Studio actually loaded the MTP model with ~64K context length.
• OpenClaw matched the wrong/partial model metadata because the model id differed: lmstudio/qwen3.6... vs lmstudio/qwen/qwen3.6..., then fell back to a smaller discovered/default entry.

So I’d check both:

1. In LM Studio: model load settings → context length / n_ctx.
2. In OpenClaw: make the configured id exactly match what LM Studio exposes, including the qwen/ prefix if present.

[lavish lodge]

The non-MTP log with promptBudgetBeforeReserve=183616 proves the 200K-ish path works when the model id/runtime metadata lines up.

[normal juniper]

It's a known issue with MTP, I'll have to turn if off until llamma.cpp is fixed

[lavish lodge]

That tracks with what your logs showed. Turning MTP off is the right move for now, especially since the non-MTP run picked up the expected ~200K budget.

I’d keep the non-MTP model id exactly as LM Studio exposes it, restart gateway after switching, then use /new so lead-scout doesn’t keep carrying the old bad-runtime session state.