long time before answer | Friends of the Crustacean 🦞🤝 | Page 1

quasi boughBOT May 10, 2026, 10:09 PM

#

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

azure sealBOT May 10, 2026, 10:10 PM

#

This status points less to Telegram itself and more to the model run not finishing.

The big clue is:

🧠 Model: ollama/qwen2.5:14b
📚 Context: 33k/200k
🪢 Queue: steer (depth 0)

Queue depth 0 means messages probably are not waiting behind a backlog. The bot showing Typing... forever usually means OpenClaw accepted the Telegram message and is still inside the active agent/model turn. A local Ollama qwen2.5:14b turn with a large advertised context can stall badly on constrained hardware, and fallbacks usually only help after an error/timeout — not while the first model is slowly chewing.

I’d try these in order:

Quick test: switch that Telegram session to a cloud model temporarily and send a tiny prompt:
/model google/gemini-3.1-flash-lite-preview
then: reply exactly pong

If replies become instant, the problem is the Ollama model/runtime, not Telegram.

#

Cap the Ollama context so it does not try to run huge contexts:

{
  models: {
    providers: {
      ollama: {
        contextWindow: 32768,
        maxTokens: 4096,
        timeoutSeconds: 300,
        models: [
          {
            id: "qwen2.5:14b",
            name: "qwen2.5:14b",
            params: { num_ctx: 32768, keep_alive: "15m" }
          }
        ]

#

      }
    }
  }
}

Then restart the gateway.

If it still hangs, grab the evidence right after it starts “Typing…”:

openclaw status --all
openclaw logs --follow

Look for session.long_running, session.stalled, Ollama timeout/context errors, or provider fallback messages.

Docs that match this path: https://docs.openclaw.ai/concepts/queue and https://docs.openclaw.ai/providers/ollama#cold-local-model-times-out

dawn tangle May 10, 2026, 10:21 PM

#

sorry to be numb but /model google/gemini-3.1-flash-lite-preview replies with -bash: openclaw/model: No such file or directory
How do I write this command correctly?

azure sealBOT May 10, 2026, 10:21 PM

#

Not numb at all — I should’ve been clearer 🙂

/model google/gemini-3.1-flash-lite-preview is a chat command, not a bash/terminal command.

So type it directly in the Telegram chat with your OpenClaw bot, exactly like:

/model google/gemini-3.1-flash-lite-preview

Do not run it in your Linux shell.

If you want to change the default model from the terminal instead, the command shape is:

openclaw models set google/gemini-3.1-flash-lite-preview

#

But for your test, I recommend doing the /model ... command inside Telegram, because that switches just that chat/session and is easier to undo.

dawn tangle May 10, 2026, 10:30 PM

#

ok, I changed to cloud model, now answers is constantly No follow-up needed from me.

azure sealBOT May 10, 2026, 10:30 PM

#

Ah, that exact sentence is important. I checked the source: No follow-up needed from me. is OpenClaw’s visible fallback for a silent reply. In plain English: the model is probably returning the internal NO_REPLY token, and because you’re in a direct Telegram chat OpenClaw rewrites that into a visible message instead of staying silent.

That usually means the current Telegram session got into a weird/poisoned context, not that Telegram is broken.

Try this in the Telegram chat, as separate messages:

/reset

then:

/model google/gemini-3.1-flash-lite-preview

then:

#

Say exactly: PONG

If that works, your old session context was the problem. Then you can either keep the cloud model, or switch back later after capping Ollama context.

If it still replies No follow-up needed from me. after /reset, please run:

openclaw status --all
openclaw logs --tail 200

and paste the relevant output. That would smell like a bug or a bad prompt/config causing every direct message to be treated as “no reply needed.”

dawn tangle May 10, 2026, 10:36 PM

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback

✓ Config: /root/.openclaw/openclaw.json
✓ Secret diagnostics (0)
! Restart sentinel present
Gateway restart restart ok (gateway.restart) · 6m ago
! Port 18789
Port 18789 is already in use.

pid 3887802 root: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789 (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale exposure: off · daemon unknown
✓ Skills: 37 eligible · 0 missing · /root/.openclaw/workspace
✓ Plugin compatibility (none)
Gateway restart attempts (tail): /root/.openclaw/logs/gateway-restart.log
openclaw restart attempt source=update target=openclaw-gateway.service
openclaw restart done source=update
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.

azure sealBOT May 10, 2026, 10:37 PM

#

This report doesn’t show the actual failure yet — it mostly says the gateway is alive.

A couple notes:

Port 18789 is already in use is probably just “the Gateway is already running on that port”. Since the process shown is openclaw ... gateway --port 18789, that part is not the Telegram problem.
Restart sentinel present means OpenClaw has a recent restart handoff record from the update/restart. Usually not fatal by itself.
Config is under /root/.openclaw/openclaw.json, so make sure you run all diagnostic/config commands as the same user/root environment that runs the gateway.

The weird No follow-up needed from me. problem needs the gateway log lines from the moment you message the Telegram bot. Please do this:

In one terminal:

openclaw logs --follow

In Telegram, send:

#

/reset

then:

Say exactly: PONG

Paste the log lines that appear right after that.

If openclaw logs --follow is too noisy, use:

openclaw logs --tail 200

I’m specifically looking for whether the model is literally outputting NO_REPLY, whether the session is still poisoned after reset, or whether a Telegram/direct-message routing policy is misclassifying the turn.

dawn tangle May 10, 2026, 10:40 PM

#

22:37:22+00:00 warn gateway {"subsystem":"gateway"} still draining 2 active task(s) and 1 active embedded run(s) before restart
22:37:24+00:00 error telegram/api {"subsystem":"telegram/api"} telegram sendChatAction failed: Network request for 'sendChatAction' failed!

azure sealBOT May 10, 2026, 10:40 PM

#

Good, that log gives us two separate problems:

still draining 2 active task(s) and 1 active embedded run(s) before restart
- the gateway is trying to restart, but there are still active agent runs/tasks. That explains “typing forever” / delayed replies.
telegram sendChatAction failed
- that is only the Telegram “typing…” API call, not the final answer. But if it keeps happening, it points to VPS → api.telegram.org network/DNS/IPv6/proxy instability.

First, clear the stuck active run. In the Telegram chat with the bot, send this as a standalone message, no slash:

abort

Wait ~30 seconds, then run:

#

openclaw status

If it still says active embedded runs/tasks, do a real gateway restart:

openclaw gateway restart

Then test Telegram again with:

/reset

#

Say exactly: PONG

If you still see sendChatAction failed, check whether the server can reach Telegram reliably:

curl -I https://api.telegram.org

If that hangs/fails intermittently, the fix is network-side: force IPv4 / fix DNS / or configure a Telegram proxy. The relevant Telegram docs are here: https://docs.openclaw.ai/channels/telegram#polling-or-network-instability

Also: your agent runtime timeout default can be very long, so a bad Ollama turn can sit there for ages. Once this is unstuck, I’d still cap the Ollama provider context/timeout like above so one slow local turn can’t wedge your Telegram chats for hours.

dawn tangle May 10, 2026, 11:10 PM

#

it seems to be back ...

azure sealBOT May 10, 2026, 11:10 PM

#

Nice, glad it’s breathing again 🦞

I’d still do the prevention step when you have a quiet minute: cap the Ollama context/timeout, because the original 6-hour delay was very likely one slow/stuck local Ollama turn holding the session lane open.

If it happens again, the fastest recovery is:

abort

in Telegram, then if needed:

openclaw gateway restart

And if this solved it, please right-click the useful solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.

dawn tangle May 11, 2026, 2:31 AM

#

I don't recognise my agent.. Answering ⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session. all the time

azure sealBOT May 11, 2026, 2:31 AM

#

That message is OpenClaw’s generic “the agent crashed before it could produce a reply” wrapper — it’s not really your agent speaking.

Two likely causes after what we changed:

the session is still corrupted/out-of-sync from the stuck run
the cloud model you selected is failing auth/routing, but details are hidden

Try this in Telegram, as standalone messages:

/verbose on

then:

#

/new

then:

Say exactly: PONG

With verbose on, the next failure should include the real cause instead of only Something went wrong....

If it still errors, paste the new verbose error plus the matching log tail:

openclaw logs --tail 200

#

openclaw models status

Also, if you switched to google/gemini-3.1-flash-lite-preview but Google auth isn’t actually configured, switch back to a model you know is authenticated, or run:

openclaw models status

and check which providers show usable auth. The /model command can select a model even if that provider later fails during the run, so this may simply be “selected model has no/expired credentials.”

dawn tangle May 11, 2026, 4:54 AM

#

new model seems to work better but it is now hanging iin Typing again for 7 minutes now

#

and it just answered;;; Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

azure sealBOT May 11, 2026, 4:54 AM

#

dawn tangle new model seems to work better but it is now hanging iin Typing again for 7 minu...

That usually means the run is still active (or the provider stream/tool loop didn’t close), not just a cosmetic Discord typing bug.

First thing: what does openclaw --version show?

Then, while it’s stuck, please run:

openclaw status --all
openclaw logs --follow

If /status works in the thread, run that too — it should show whether the session is actively waiting on a model/tool call or wedged.

Two useful knobs while debugging:

azure sealBOT May 11, 2026, 4:54 AM

#

dawn tangle new model seems to work better but it is now hanging iin Typing again for 7 minu...

{
  agents: {
    defaults: {
      typingMode: "message"
    }
  }
}

or "never" if the typing indicator is too misleading. That only changes when Discord shows typing; it won’t fix the underlying hang.

Docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/concepts/typing-indicators

#long time before answer