Hi Help | Friends of the Crustacean 🦞🤝 | Page 1

old dock Apr 20, 2026, 8:27 AM

#

Openclaw not working with qwen locally through ollama

pale frigateBOT Apr 20, 2026, 8:27 AM

#

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

drifting coralBOT Apr 20, 2026, 8:27 AM

#

storm pivotBOT Apr 20, 2026, 8:30 AM

#

Most common Ollama + Qwen gotcha: don’t point OpenClaw at Ollama’s /v1 endpoint.

Use:

baseUrl: "http://127.0.0.1:11434"
not http://127.0.0.1:11434/v1

OpenClaw’s Ollama integration uses the native Ollama API, and /v1 can break tool calling or make the model spit tool JSON as plain text.

Can you paste these so I can narrow it down:

openclaw --version
ollama list
openclaw models list --provider ollama
openclaw models status

#

And if you have explicit config, the relevant bits from:

agents.defaults.model
models.providers.ollama

Also, make sure the model name in OpenClaw matches the exact Ollama tag from ollama list, prefixed as ollama/<model>.

Docs:

One practical note: local Ollama models can work, but small/heavily quantized models are much shakier for tool-using agents. If you paste the outputs above, I can tell you whether this is a config issue or a model-capability issue.

old dock Apr 20, 2026, 11:35 AM

#

We're facing a couple of persistent issues with our OpenClaw setup and would greatly appreciate some guidance.

Issue 1: AccBot (Telegram Bot) Stability
We've set up a Telegram bot (MassnAccbot) that's intended to process PDF statements. We've encountered a recurring telegram.error.Conflict: terminated by other getUpdates request; make sure that only one bot instance is running.

Symptoms: Bot is intermittently responsive, especially after restarts or when handling PDFs. It might respond to /start once, then become unresponsive.
Troubleshooting done:
- Verified Telegram token.
- Simplified bot's main.py to bare minimum (echo, /start).
- Restarted OpenClaw Gateway multiple times.
- Attempted to aggressively terminate all python.exe processes.

#

Discovered and manually terminated a compiled Accounting_Bot.exe that was causing conflicts.
- Performed a complete reset of the accounting bot directory, recreated it, and created a new bare-minimum main.py.
- Latest status: Created a virtual environment for AccBot. We're about to install dependencies and run the bot within it.
Hypothesis: Still suspecting some lingering process interference or a deep-seated OpenClaw process management interaction causing multiple bot instances, even after aggressive termination.

storm pivotBOT Apr 20, 2026, 11:37 AM

#

That first issue looks separate from Qwen/Ollama. It’s a Telegram ingress conflict.

telegram.error.Conflict: terminated by other getUpdates request means the same bot token is being consumed by more than one listener:

two polling bot processes, or
one poller + one webhook setup, or
two OpenClaw instances, or
OpenClaw + your custom main.py bot on the same token

So the key fix is: one token, one active consumer, one mode.

What I’d check first:

Do OpenClaw and MassnAccbot use the same Telegram token?
If yes, that’s the problem. Give them separate bot tokens, or let only one of them own Telegram.
Are you running two OpenClaw gateways?

#

For example, a background service plus a terminal instance. Check:

openclaw --version
openclaw gateway status
openclaw status --all

Did you enable webhook mode?
OpenClaw defaults to long polling. If channels.telegram.webhookUrl is set anywhere, and something else is polling the same token, they’ll fight.
If you are testing with your Python bot, disable OpenClaw’s Telegram channel for that token, or vice versa.

My guess from your description: OpenClaw and your Python main.py are both trying to poll the same bot token. Simplifying main.py won’t help, because the conflict is at the Telegram API level.

If you want, paste these next:

openclaw --version

#

openclaw gateway status
openclaw status --all
whether MassnAccbot and OpenClaw share the same token
whether channels.telegram.webhookUrl is set

Docs:

If you send Issue 2 too, I’ll go through that one as well.

#

Nice, finding Accounting_Bot.exe is a big clue. I’m pretty skeptical this is a deep OpenClaw process-management bug at this point, it still looks more like duplicate Telegram consumers.

A few important bits before you run the venv bot:

If OpenClaw and AccBot share the same Telegram token, stop here.
Running the fresh Python bot will just recreate the conflict. Use separate bot tokens, or make sure only one of them is connected.
If Accounting_Bot.exe came back before, check what is relaunching it.
On Windows that is often:
- Task Scheduler
- a Windows service
- Startup folder / Run key
- another wrapper script
Test with exactly one listener active
- stop OpenClaw if it uses that token
- make sure the old EXE is not auto-restarting

#

run only the new minimal venv bot
- test /start

If that works cleanly, the issue was not the bot code, it was the extra consumer.

Useful checks:

openclaw --version
openclaw gateway status
openclaw status --all

And on Windows, read-only checks like:

#

Get-Process | Where-Object {$_.ProcessName -match 'python|openclaw|accounting|accbot'}
Get-Service | Where-Object {$_.Name -match 'OpenClaw|Accounting|AccBot'}
Get-ScheduledTask | Where-Object {$_.TaskName -match 'OpenClaw|Accounting|AccBot'}

One more gotcha, if that token ever had a webhook configured elsewhere, polling can still fight with it. So also confirm whether this bot token is supposed to be polling or webhook, not both.

If you want, paste:

whether OpenClaw uses the same token
output of openclaw gateway status
whether the minimal bot works when OpenClaw is fully stopped

That should tell us pretty quickly if this is a token collision or an auto-relaunch problem.

old dock Apr 20, 2026, 11:52 AM

#

Hello Krill,

Following up on our previous conversation regarding MassnAccbot on Telegram and the "Conflict" error.

Good News: We successfully identified and manually terminated a compiled Accounting_Bot.exe that was causing the telegram.error.Conflict. The initial setup of the Telegram bot (bare-minimum main.py with only /start and echo) now runs stably and responds correctly.

New Problem: After reintroducing the from statement_cleaner_module import StatementCleaner line and the handle_pdf placeholder into main.py (and ensuring statement_cleaner_module.py and accounting_bot_interface.py are in the same directory), the bot fails to start with a ModuleNotFoundError: No module named 'statement_cleaner_module'.

Steps taken to resolve this ModuleNotFoundError:

Confirmed statement_cleaner_module.py and accounting_bot_interface.py are present in M:\.openclaw\agents\accounting bot\. (Used dir).
Created a virtual environment (.venv) within the accounting bot directory.
Ensured all required packages (python-telegram-bot, pypdf, camelot-py[cv], numpy) are installed within this virtual environment.
Modified main.py to explicitly add the current directory to sys.path (sys.path.append('.')) at the very beginning.
We are executing the bot using the full path to python.exe within the virtual environment: "M:\.openclaw\agents\accounting bot\.venv\Scripts\python.exe" (after checking dir output, this is the correct path to the venv's python executable).

#

Despite these steps, the ModuleNotFoundError persists. It's as if Python cannot see the statement_cleaner_module.py file even when it's in the same directory and sys.path is updated.

**Question for Krill:**Given the ModuleNotFoundError despite the module being present, sys.path being updated, and a clean virtual environment, what could be preventing Python from finding statement_cleaner_module.py? Are there any specific environment variables, OpenClaw interactions, or Python interpreter nuances on Windows that could cause this?
Also, could this be related to how camelot-py or pypdf might interact with module loading, even if they are installed in the venv?

We're running on:

OS: Windows_NT 10.0.26100 (x64)
Python: C:\Program Files\Python312\python.exe (used to create venv), and then M:\.openclaw\agents\accounting bot\.venv\Scripts\python.exe (intended for running bot).

Thank you for your invaluable assistance!

storm pivotBOT Apr 20, 2026, 11:53 AM

#

Nice, glad you killed the ghost EXE 😅

This new error looks much more like a Python path / launch-context issue than an OpenClaw issue.

The big clue is this:

sys.path.append('.')

That only adds the current working directory, not the directory where main.py lives. If OpenClaw or your launcher starts the process from somewhere else, . points at the wrong place.

Try this at the very top of main.py, before the import:

from pathlib import Path
import sys

#

SCRIPT_DIR = Path(__file__).resolve().parent
sys.path.insert(0, str(SCRIPT_DIR))

from statement_cleaner_module import StatementCleaner

Also add a quick debug block once:

import os
print("cwd:", os.getcwd())
print("script_dir:", SCRIPT_DIR)
print("sys.path[0]:", sys.path[0])
print("module exists:", (SCRIPT_DIR / "statement_cleaner_module.py").exists())

#

Why I think this is the issue:

same-folder imports should work
your venv/packages are unrelated to a same-folder module import
using '.' is fragile
OpenClaw/Windows launchers often run with a different cwd than you expect

If that still fails, the next likely causes are:

filename is not exactly statement_cleaner_module.py
hidden extension like statement_cleaner_module.py.txt
the script is being launched in a weird way, not as python ...\\main.py

If you want the more robust cleanup after this, I’d turn that folder into a small package and run it with python -m ..., but the Path(__file__).resolve().parent fix is the first thing I’d try.

If you paste the exact traceback plus the output of those four debug prints, I can probably pinpoint it fast.

#

Short answer: no, camelot-py and pypdf should not cause this. They do not affect Python’s ability to find a sibling .py file. If they were the problem, the error would usually name their missing dependency, not statement_cleaner_module.

What can cause this, and what jumps out here, is the path:

M:\.openclaw\agents\accounting bot\...

On Windows, mapped drives / SUBST drives are often invisible to services or background processes. So you can dir that path in your interactive shell, but a process launched by OpenClaw, Task Scheduler, or a service may not actually see M: at all.

That would perfectly fit this kind of “the file is there, but Python can’t import it” behavior.

My strongest suspicion

This is not really module loading weirdness, it is process context + Windows drive mapping.

What I’d do next

Stop using M: for this test
Move the bot to a real local path like:

#

   C:\Users\<you>\.openclaw\agents\accounting-bot\

Recreate / reuse the venv there
Run it again from that real path

Important nuance

OpenClaw itself does not rewrite Python imports. But it absolutely can change:

the working directory
the user/session context
whether a mapped drive is visible

One decisive test

Run this with the exact interpreter you intend to use:

#

"M:\.openclaw\agents\accounting bot\.venv\Scripts\python.exe" -c "from pathlib import Path; import sys, importlib.util; p=Path(r'M:\.openclaw\agents\accounting bot'); print('dir exists:', p.exists()); print('file exists:', (p/'statement_cleaner_module.py').exists()); sys.path.insert(0, str(p)); print('spec:', importlib.util.find_spec('statement_cleaner_module'))"

If that prints False or None, the interpreter process cannot really see that path/module.

Other less likely causes

hidden filename issue, like .py.txt
running under a different user than the one who sees M:
rare Windows isolated Python setup (python312._pth), but that is much less likely here

So my recommendation is: treat this as a Windows path-context problem first, not a package/import-library problem.

If you paste the output of that one-liner, plus whether OpenClaw is running as a service, I can tell you pretty quickly if M: is the culprit.

old dock Apr 20, 2026, 12:06 PM

#

can you talk to my bot directly so that i dont have to keep copy pasting?

storm pivotBOT Apr 20, 2026, 12:07 PM

#

Not directly from this Discord thread, no. I only see what you paste here, and I shouldn’t start poking an external bot unless it’s explicitly wired into your own OpenClaw setup.

Honestly, for where you are now, the better move is a local agent on your machine so it can inspect the folder, run the exact interpreter, and see the real Windows environment without all the relay pain.

Fastest path:

run a local agent like Codex / Claude Code against that machine
point it at the bot folder
let it run the exact Python/import checks directly

OpenClaw FAQ for that route:
https://docs.openclaw.ai/help/faq#i-am-stuck-fastest-way-to-get-unstuck

If you want, I can help you set up the exact prompt to hand to a local agent so it debugs the bot end-to-end without more copy/paste.

old dock Apr 20, 2026, 12:13 PM

#

give me prompt the bot is running locally on my machine

storm pivotBOT Apr 20, 2026, 12:14 PM

#

Paste this into Codex / Claude Code on the Windows machine that’s running the bot:

You are debugging a local Windows Python Telegram bot. Do not guess, inspect and verify everything by running commands.

Context:
- The original Telegram `Conflict` issue was caused by a compiled `Accounting_Bot.exe`. That part is now fixed.
- A bare-minimum `main.py` works and the bot responds normally.
- After reintroducing `from statement_cleaner_module import StatementCleaner`, startup fails with:
  `ModuleNotFoundError: No module named 'statement_cleaner_module'`
- Expected bot folder:
  `M:\.openclaw\agents\accounting bot\`
- Expected files in that folder:
  - `main.py`
  - `statement_cleaner_module.py`
  - `accounting_bot_interface.py`

#

- Virtual environment:
  `M:\.openclaw\agents\accounting bot\.venv\`
- Intended interpreter:
  `M:\.openclaw\agents\accounting bot\.venv\Scripts\python.exe`
- OS: Windows 10.0.26100 x64
- Suspected causes:
  - wrong working directory
  - mapped drive / SUBST drive visibility issue with `M:`
  - different user/session context
  - hidden file extension like `.py.txt`
  - launch context from OpenClaw or service process

Your job:
1. Inspect the exact directory contents, including hidden extensions and the real path type for `M:`.
2. Determine whether `M:` is a mapped drive, network drive, or SUBST drive.

#

3. Run the exact venv interpreter and print:
   - `os.getcwd()`
   - `sys.executable`
   - `sys.path`
   - `__file__` if applicable
   - whether `statement_cleaner_module.py` exists from that process
4. Test import resolution directly with `importlib.util.find_spec("statement_cleaner_module")`.
5. Verify whether the process that launches the bot can actually see `M:\.openclaw\agents\accounting bot\`.
6. If OpenClaw is launching the process, inspect the launch context and whether it runs under a service/user context that cannot see `M:`.
7. Fix the problem with the smallest reliable change.
8. Prefer a real local path like `C:\Users\<user>\.openclaw\agents\accounting-bot\` if `M:` is the culprit.
9. At the end, give me:
   - root cause
   - exact fix
   - final command to run the bot

#

   - any minimal code changes made

Constraints:
- Do not rewrite the bot unnecessarily.
- Do not stop at theories. Prove the cause with commands/output.
- Keep changes minimal.
- Separate the root cause from any follow-on issues.

Start by showing me:
- the exact contents of the bot folder
- what `M:` actually is
- what the venv interpreter sees for the module path

If you want, I can also give you a shorter Codex-optimized version.

sour cliff Apr 20, 2026, 12:24 PM

#

Actually, I ran into the same issue when I migrated OpenClaw from DeepSeek to Ollama/Qwen. The WhatsApp output said, 'Request timed out before a response was generated.' Even though I had already set the timeout to 300 ms. it still failed. That’s why I moved back to DeepSeek

storm pivotBOT Apr 20, 2026, 12:25 PM

#

Yeah, that part makes sense, but one important correction:

300 ms is 0.3 seconds, so that would absolutely timeout.
OpenClaw’s relevant timeout knobs are in seconds, not milliseconds.

The two big ones are:

agents.defaults.timeoutSeconds = whole agent run budget
agents.defaults.llm.idleTimeoutSeconds = abort if the model goes quiet too long

Docs:

For slow local Ollama/Qwen runs, I’d check these first:

#

{
  agents: {
    defaults: {
      timeoutSeconds: 600,
      llm: {
        idleTimeoutSeconds: 300
      }
    }
  }
}

Or set idleTimeoutSeconds: 0 temporarily while debugging, to disable the idle watchdog.

Also, if you were pointing Ollama at:

#

http://host:11434/v1

that’s another common footgun. For OpenClaw + Ollama, use the native Ollama API:

http://host:11434

not /v1.

So the short version is:

300 ms was way too low
local Ollama/Qwen is often slower than cloud DeepSeek
bump both overall timeout and LLM idle timeout

#

make sure you are not using /v1

If you want, paste:

openclaw --version
openclaw status --all
openclaw models status

and I can help narrow down whether it was just timeout budget, idle timeout, or the Ollama endpoint config.

old dock Apr 21, 2026, 3:10 PM

#

Am looking for an model that is strong as Gemini 3 pro preview but cost less or can run locally

storm pivotBOT Apr 21, 2026, 3:10 PM

#

Honest answer, probably not locally, at least not on normal hardware.

If you want something in that class, you’re usually choosing between:

Best performance per dollar, cloud
- usually the practical choice
- use a strong hosted model, then cheaper fallbacks for routine stuff
Local / private
- doable, but not really “same as Gemini 3 Pro Preview” unless you have a serious GPU setup
- smaller / quantized local models are noticeably weaker for agentic/tool use

OpenClaw’s local-model docs are pretty blunt about this:
https://docs.openclaw.ai/gateway/local-models

For current model picks, don’t trust stale lists in chat, ask in #models and check:

https://docs.openclaw.ai/concepts/models

#Hi Help

My strongest suspicion

What I’d do next

Important nuance

One decisive test

Other less likely causes