low leaf
I am trying to automate an HRMS system through OpenClaw, by running it on a local llm model through enterprise gpu, but so far I am not having any luck with the models, as they are not working. So far I have tried models:
Qwen2.5:14b-instruct
Qwen3:32b
Llama3:latest
Any suggestions? Need help urgently.
grave birchBOT
Let me verify the docs/source so I don’t make up model advice.
I found the live docs and I’m checking the troubleshooting section for local-model failures now.
The blunt answer: for HRMS/browser automation, the local model is probably the bottleneck.
Those checkpoints can be fine for plain chat, but OpenClaw automation needs tool calling + long context + stable browser reasoning. Local models often fall over there.
Fastest path to get unstuck:
First, verify it’s the model and not config
robust sluiceopenclaw --version
openclaw status
openclaw models status
openclaw logs --follow
Paste those if you want me to help narrow it fast.
If you’re using Ollama, do NOT point OpenClaw at /v1
Use:
baseUrl: "http://host:11434"
not:
baseUrl: "http://host:11434/v1"
OpenClaw docs explicitly warn that Ollama /v1 breaks tool calling.
If you’re using LM Studio / vLLM / another OpenAI-compatible /v1 backend
and direct probes work but OpenClaw fails, try:
compat.requiresStringContent: truecompat.supportsTools: falseagents.defaults.experimental.localModelLean: trueThat’s the main fix path for local backends that choke on OpenClaw’s full prompt/tool schema.
For urgent production work, test once with a strong cloud model
If it works there, you’ve confirmed the workflow is fine and the local model/backend is the issue.
I would not try to debug HRMS automation on a weak local checkpoint first.
Use the biggest full-size local model you can run
OpenClaw’s local-model docs are pretty opinionated here: heavily quantized or smaller local models are much less reliable for agentic work.
Docs:
If you reply with:
openclaw --versionopenclaw logs --follow…I can tell you the next fix pretty quickly.
low leaf
OpenClaw 2026.4.14 (7320dfc)
local llm (qwen3:32b)
baseurl is fine.
it just can not fetch tool calling
grave birchBOT
Got it. If plain chat works but tool calling doesn’t, this is usually backend mode, not just the model name.
Most likely cases:
If this is Ollama, check the URL path, not just the host
http://host:11434http://host:11434/v1For Ollama, /v1 is the OpenAI-compatible mode, and the docs explicitly say tool calling is not reliable there.
If it’s LM Studio / vLLM / another OpenAI-compatible /v1 server
then it may accept normal chat but still choke on OpenClaw’s tool schema.
That’s a known pattern with local backends.
For your use case, I’d be pretty direct: HRMS browser automation is one of the hardest cases for local models. A local 32B can still be too weak/unreliable for stable tool use.
/v1), orDo not set compat.supportsTools: false for this workflow unless you’re only trying to prove the backend is the problem, because that disables tool use.
If you want, paste just these 2 things and I can probably spot it quickly:
models.providers... config block:11434 or :11434/v1Docs:
If you’re on Ollama and it’s /v1, I’m pretty confident that’s the bug.
low leaf
its not v1, i think its the model workload and gpu, thats the problem.
grave birchBOT
Yep, that sounds plausible. For local/browser-heavy runs, GPU pressure and prompt size are a very common failure mode.
Yeah, that’s very believable.
For browser/tool-heavy automation, a local 32B model can still be underpowered once you add:
OpenClaw’s own local-model docs are pretty blunt here: local works best on very large rigs, and smaller / more quantized setups get brittle fast.
So the practical read is:
Use a hosted primary model, keep local as fallback.
That’s the fastest way to confirm your HRMS workflow is fine and the blocker is just local inference/tool reliability.
You’ll likely need some combination of:
You can try:
agents: {
defaults: {
experimental: {
localModelLean: true
}
}
}
But important: that is mostly a diagnostic pressure-release valve. It trims heavyweight default tools, so for actual browser automation it may prove the problem, not fully solve it.
So honestly, I think your diagnosis is probably right: model workload + GPU pressure.
If you want, send:
and I can tell you pretty quickly whether the setup is realistically enough for this use case.
Docs:
low leaf
what is openclaw json file format
grave birchBOT
It’s JSON5, not YAML.
Default file:
~/.openclaw/openclaw.json
That means you can use:
Example:
{
agents: {
defaults: {
model: { primary: "ollama/qwen3:32b" },
},
},
}
Useful commands:
openclaw config file
openclaw config validate
openclaw config schema
Two important gotchas:
json5 blocks for this reason.Docs:
If you want, paste your models.providers block and I’ll tell you if the JSON5 shape is correct.
low leaf
what to write in apibase url for openclaw model configuration\
grave birchBOT
apiBaseUrl is just the URL of your inference server, not the model name.
For the common local backends:
http://127.0.0.1:11434/v1http://127.0.0.1:1234/v1http://127.0.0.1:8000/v1If you’re using Ollama, this is the shape to use:
{
models: {
providers: {
ollama: {
apiKey: "ollama-local",
baseUrl: "http://127.0.0.1:11434",
api: "ollama",
},
},
},
agents: {
defaults: {
model: { primary: "ollama/qwen3:32b" },
},
},
}
So:
baseUrl = server addressprimary = model nameIf you want, paste your current models.providers block and I’ll correct it.
Docs:
low leaf
i am using openrouter model
grave birchBOT
Ah, if you’re using OpenRouter, then the base URL is:
https://openrouter.ai/api/v1
But honestly, with OpenRouter you usually don’t need to hand-write the provider block at all. The simpler setup is:
{
env: { OPENROUTER_API_KEY: "sk-or-..." },
agents: {
defaults: {
model: { primary: "openrouter/<provider>/<model>" },
},
},
}
Or default route:
{
env: { OPENROUTER_API_KEY: "sk-or-..." },
agents: {
defaults: {
model: { primary: "openrouter/auto" },
},
},
}