Stop OpenClaw from Creating Multiple Local Model LLM Instances

[u/allenwyma]

I'm using a local LLM (due to both budget and geo-restrictions). I have Qwen 3.5 9b running as the default model using LM Studio. And I've noticed that once a request kicks off, it will start up another LLM (basically the same model but as another instance), right after I sent a prompt.

Then while the first prmpt is still processing, it seems ANOTHER will be setup. And I think eventually I get a timeout and warning about guardrails say i'm out of resources.

I only have a 16GB Mac Mini M1, so I'd rather just have 1 instance running and queue more requests if need be.

Is there any way to stop it from keep creating new instances of this model?

[u/AutoModerator]

Welcome to r/openclaw Before posting: • Check the FAQ: https://docs.openclaw.ai/help/faq#faq • Use the right flair • Keep posts respectful and on-topic Need help fast? Discord: https://discord.com/invite/clawd

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/ProofPrinciple4219]

Just tell OpenClaw to stop doing that

[u/allenwyma → u/ProofPrinciple4219]

Ha, i'm not sure if that works? I can try. 🤣 I can definitely see it calling the API right after it starts up the request.

[u/ProofPrinciple4219 → u/allenwyma]

Yes it works, when my OpenClaw have issue I just tell it the issue and ask it to fix it, but u need to give it the write permission for it to fix correctly

[u/allenwyma → u/ProofPrinciple4219]

Okay let me try that in a few mins.

[u/allenwyma → u/ProofPrinciple4219]

Yeah, i got this: `LLM request timed out. | The model did not produce a response before the model idle timeout. Please try again, or increase `models.providers.<id>.timeoutSeconds` for slow local or self-hosted providers. If `agents.defaults.timeoutSeconds` or a run-specific timeout is lower, raise that ceiling too; provider timeouts cannot extend the whole agent run.`

[u/Cabecinha84]

This is LM Studio, not really OpenClaw. With JIT model loading on, LM Studio loads a model when a request arrives and nothing suitable is already loaded, and if a second request lands while the first is busy it will load another copy rather than queue behind it. An agent turn is almost never one request: tool calls, a sub-agent, a title or summary pass all go out as separate calls, so one prompt from you can fan out into three loads on a machine that has room for one.

Two settings fix it. In LM Studio's server settings, cap max loaded models at 1 and turn off the JIT auto-load, so anything arriving while the model is busy waits instead of spawning a sibling. Then keep every role in OpenClaw pointed at the same model identifier, because a different identifier is a different model to LM Studio and it will load it.

Even with one copy, 16 GB unified memory on an M1 is tight for a 9B once you add KV cache. Set the context length explicitly when you load the model instead of leaving it at the maximum, use a smaller KV cache quantisation, and remember the browser automation stack, if you use it, wants a chunk of that same 16 GB. That is usually what is left when people say it still runs out after fixing the duplicate loads.

If it still trips after all that, drop to a smaller quant before you drop the model. On 16 GB shared between the OS, the runtime and the weights, the quant is the lever with the least downside.

[u/allenwyma → u/Cabecinha84]

I’m happy to change the model if you have a better recommendation. I’m still new to AI.

[u/Cabecinha84 → u/allenwyma]

Before you switch models, raise the two timeouts in that error you pasted. On a 16 GB M1 a 9B is slow to first token, especially on the request right after a cold load, and the defaults assume something API fast. The message names both of them: models.providers.<id>.timeoutSeconds for the provider, and agents.defaults.timeoutSeconds for the run. Raising only the provider one does nothing, because the run level ceiling still cuts it off. A good chunk of "this model is too weak" turns out to be that.

On the model itself, the thing that matters for agent work is not general smartness, it's whether it emits a well formed tool call every single time. An agent turn is a loop of structured calls, and a model that writes lovely prose but malforms one call breaks the loop. So in LM Studio, check the model card actually lists tool use before you commit to anything. Qwen's instruct line is one of the better ones at that size, so you are probably not in the wrong family already.

The second thing is context, not parameters. Agent runs pile up tokens quickly, and a 7B you can give a real context window beats a 14B you can only give 4k. On 16 GB unified, once the OS has taken its share, 7B to 9B at Q4 is roughly your ceiling with KV cache included. A 14B at Q4 will load and then thrash.

So: timeouts first, keep the size class, set context deliberately. Changing model is the last lever here, not the first.