my AI is sometimes responding with <>

[strong solstice]

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

[paper bay]

krill?

[viral tide]

Yep — I’m here. What’s up?

[paper bay]

My AI sometimes responds with <> in telegram, also replies are some times taking 5m or longer how do I fix this?

[viral tide]

Two likely separate issues there:

1) Replies taking ~5 minutes (Telegram)

That pattern very often ends up being Telegram Bot API network calls hanging (common culprit: api.telegram.org resolving to IPv6 first when your host doesn’t have working IPv6 egress). OpenClaw/grammY’s default Telegram request timeout is 500s, so it “feels” like random 5–8 minute delays.

Checklist:

1. Run:

• openclaw --version
• openclaw channels status --probe
• openclaw logs --follow (watch timestamps when you send a Telegram message)

2. On the gateway host, check DNS:

• dig +short api.telegram.org A
• dig +short api.telegram.org AAAA

If you get AAAA records but your box can’t actually reach IPv6, fix by enabling IPv6 egress or forcing IPv4 for api.telegram.org, then restart the gateway.

Docs: https://docs.openclaw.ai/channels/telegram#troubleshooting

2) Bot sometimes replies with just <>

That usually comes from Discord/Slack-style formatting leaking into Telegram (e.g. wrapping links in < > to suppress Discord embeds, or emitting <#channelId> tokens). Telegram outbound is HTML-based, so angle brackets are special and can get mangled/stripped depending on what’s inside.

To debug: can you paste one exact example (your message + the bot’s <> reply), and also grab the log lines around that send (look for Telegram “parse entities” / “rejected HTML payload” / retry-as-plain-text)?

Quick log grab if you have it:

• openclaw channels logs --channel telegram

If you share openclaw channels status --probe + the example + the log snippet, we can usually pinpoint it fast.

This is usually two separate problems:

A) Random ~5 minute reply delays (Telegram)

That pattern very often means your Gateway can’t reliably reach api.telegram.org and a request is hanging until Telegram’s client timeout. In OpenClaw/grammY the Telegram Bot API timeout defaults to 500s, which looks like “5–8 minute delays”.

What to do:

1. On the gateway host, run:

• openclaw status --deep
• openclaw channels status --probe
• openclaw logs --follow (send a Telegram message while this is running and watch what it gets stuck on)

2. Check the common cause: IPv6 DNS vs no IPv6 egress

• dig +short api.telegram.org A
• dig +short api.telegram.org AAAA

If AAAA (IPv6) exists but your server/VPS can’t actually reach IPv6, force IPv4 for api.telegram.org (or enable IPv6 egress) and restart the gateway.

3. Optional “fail fast” mitigation: lower Telegram timeout
   Set channels.telegram.timeoutSeconds lower (so it errors quickly instead of hanging for ~500s), then restart.

Docs: https://docs.openclaw.ai/channels/telegram#troubleshooting

B) Replies showing up as just <> in Telegram

That’s almost always Discord/Slack-style angle-bracket tokens leaking into Telegram output (examples: <#channelId>, <@userId>, or wrapping links like <https://...>). Telegram outbound is HTML-ish, so those can get sanitized/stripped and you’re left with <>.

To pin it down quickly, paste:

• the exact message you sent
• the bot reply that became <>
• and the matching log lines around that send (openclaw logs --follow)

Quick workaround: add a system prompt rule like:

“When replying in Telegram, do not output Slack/Discord angle-bracket tokens like <#...>, <@...>, or wrap links in <>.”

If you share the example + log snippet, I can tell you which token is getting eaten.

[paper bay]

last night you help me get it running and we disabled IPV6 and are using IPV4

me: /new what does <> mean?
AI: In Markdown, <> is used to enclose text between angle brackets (<>). In this context, it's being used to group a comment, which includes the message ID followed by an arrow (>) and another message.

So, [message_id: 215]> means "this is a response to message #215" in other context.

[viral tide]

I don’t actually see the example content/attachment on my side (Discord sometimes doesn’t forward images/attachments into this relay). Can you re-post it as either:

• a screenshot upload again, or
• copy/paste the exact Telegram message your bot sent that showed up as just <> (and what you sent right before it)

Once I can see the exact text, I can tell you which of these it is:

Most common cause of <> on Telegram

Your model (or your prompts/templates) are emitting Slack/Discord angle-bracket tokens like:

• <https://example.com> (often used to suppress embeds on Discord)
• <#channelId> / <@userId>

Telegram outbound uses HTML parse mode, so those can get eaten/sanitized and you’re left with <>.

Fix (recommended): don’t use <> wrapping for Telegram. If your goal was “no link previews”, use Telegram’s setting instead:

{
channels: {
telegram: {
linkPreview: false
}
}
}

(then restart the gateway)

For the 5-minute delays (separate, but related)

If you can, paste output of:

• openclaw --version
• openclaw channels status --probe

And if you have a log snippet around a delayed reply, even better:

• openclaw logs --limit 200 | rg "telegram|HttpError|sendMessage|parse|entities|retry"

Re-send the <> example and I’ll point to the exact knob/prompt line to change.

[paper bay]

me:
So I shouldn't inject prompts into your memory I should ask you to research whatever I want you to do?
AI:
<>

[viral tide]

Thanks — that example strongly suggests your bot is literally sending the text <> (i.e. it’s not “Telegram stripping a longer message”, it’s actually what got sent).

1) Why would it send <>?

In practice it’s usually one of these:

• A prompt/memory/system instruction accidentally taught the model a sentinel (e.g. “respond with <> when …” / “use <> wrappers”), so sometimes you get just that.
• The model produced an empty/near-empty reply (or got interrupted) and what you see is the only remaining characters that made it into the final text.
• Less common: some custom formatting/template layer is emitting angle brackets.

The fastest way to confirm which one: check what the Gateway thought it was sending.

2) Get one clean debug log for the <> send

Enable Telegram diagnostics flags, reproduce once, then grep the log:

Config option (recommended):

{

diagnostics: {
flags: ["telegram.http", "telegram.payload"]
}
}

Restart the gateway after changing this.

Docs: https://docs.openclaw.ai/diagnostics/flags

Then reproduce the <> reply and paste the relevant log lines around it (from /tmp/openclaw/openclaw-YYYY-MM-DD.log or via openclaw logs --follow).

What I’m looking for in the log:

• whether outbound payload text is literally <>
• whether there was a Telegram HTML parse error / retry-as-plain-text
• whether the request hung (ties into your 5-minute delays)

3) Quick “likely fix” if you did inject prompts into memory

Use memory for stable facts/preferences, not “how to behave” instructions. If you added any instruction containing <> or “wrap links in <>”, remove it.

On your gateway host, search your workspace/config for angle bracket rules:

grep -R "<>" -n ~/.openclaw 2>/dev/null || true
grep -R "angle" -n ~/.openclaw 2>/dev/null || true

4) The separate 5-minute delay issue

That still smells like Telegram network calls hanging (often IPv6/DNS/egress). Once telegram.http diagnostics are on, the logs will usually make this obvious.

Also paste:

• openclaw --version
• openclaw channels status --probe

With those + the telegram.payload snippet from a <> event, we can pinpoint the exact root cause.

[paper bay]

where do I put this? {

diagnostics: {
flags: ["telegram.http", "telegram.payload"]
}
}

krill?

[viral tide]

Yep — still here.

If you can paste one of these, I can help you fix the <> + delays without guessing:

1. Output of:

• openclaw --version
• openclaw channels status --probe

2. And for the <> case, either:

• the log snippet right when it happened (openclaw logs --follow, or /tmp/openclaw/openclaw-YYYY-MM-DD.log), or
• tell me if you ever added anything to memory/system prompt that mentions <> / “wrap links in angle brackets”.

If you want the quickest path: enable diagnostics flags (then restart gateway), reproduce once, paste the few log lines:

{ diagnostics: { flags: ["telegram.http", "telegram.payload"] } }

Docs: https://docs.openclaw.ai/diagnostics/flags

[paper bay]

I added the diagnostics flags what do I need to do to generate a log for you?

[viral tide]

Nice. Two quick gotchas + next step:

1) Make sure you restarted the Gateway

Diagnostics flags only take effect after a restart. If you haven’t yet:

• openclaw gateway restart

2) Reproduce once while tailing logs, then paste the snippet

Run one of these on the gateway host:

Option A (best):

openclaw logs --follow

Then send a Telegram message that previously caused the <> reply (or a 5min delay). Copy/paste the log lines from when it receives the message through when it sends the reply (usually ~30–80 lines).

Option B (quick filter):

openclaw logs --limit 300 | rg "telegram|payload|http|parse|sendMessage|draft|retry|timeout"

3) Quick sanity check: do you have a responsePrefix accidentally set to <>?

If the model sometimes generates an empty reply, and your config prefixes every reply with <>, you’ll see exactly <>.

Check your config for this:

rg -n "responsePrefix" "${OPENCLAW_CONFIG_PATH:-$HOME/.openclaw/openclaw.json}"

If you see something like messages.responsePrefix: "<>" or channels.telegram.responsePrefix: "<>", remove it (or set it to ""), then restart.

---

Paste the log snippet after one <> event (or one delayed reply) and I’ll tell you exactly which path it is (actual outbound payload is <> vs Telegram parsing/network retry/hang).

[paper bay]

before restarting openclaw gateway I ran openclaw doctor and it came back with this: 🦞 OpenClaw 2026.2.6-3 (85ed6c7)
Turning "I'll reply later" into "my bot replied instantly".

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
🦞 OPENCLAW 🦞

┌ OpenClaw doctor
Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
│
◇ Update ───────────────────────────────────────────╮
│ │
│ This install is not a git checkout. │
│ Run openclaw update to update via your package │
│ manager (npm/pnpm), then rerun doctor. │
│ │
├────────────────────────────────────────────────────╯
│
◇ Security ─────────────────────────────────╮
│ │
│ - No channel security warnings detected. │
│ - Run: openclaw security audit --deep │
│ │
├────────────────────────────────────────────╯
│
◇ Skills status ────────────╮
│ │
│ Eligible: 4 │
│ Missing requirements: 45 │
│ Blocked by allowlist: 0 │
│ │
├────────────────────────────╯
│
◇ Plugins ──────╮
│ │
│ Loaded: 2 │
│ Disabled: 29 │
│ Errors: 0 │
│ │
├────────────────╯
│
◇
Telegram: ok (@Tr1nbot) (771ms)
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /home/jason/.openclaw/agents/main/sessions/sessions.json (1 entries)

• agent:main:main (161m ago)
  Run "openclaw doctor --fix" to apply changes.
  │
  └ Doctor complete.

[viral tide]

That openclaw doctor output is actually good news:

• Telegram: ok (@Tr1nbot) (771ms) → at least at doctor-time, the Gateway could reach Telegram quickly.
• The Ollama timeout is just “I tried to query a local Ollama on 127.0.0.1:11434 and it didn’t answer fast enough”. It’s usually not related unless your agent is configured to use Ollama models as a primary/fallback.

Next: restart + capture one <> event in logs

Since you added diagnostics.flags, you must restart the gateway for them to take effect:

openclaw gateway restart

Then reproduce the <> once and paste the log chunk:

openclaw logs --follow

I’m specifically looking for the telegram.payload lines that show the actual outbound text.

Quick check (very likely cause): do you have responsePrefix set to something that can become <>?

It’s surprisingly common to have a prefix template like <{identity.name}> or similar, and if the actual reply ends up empty/blocked you’re left with just <>.

Run:

rg -n "responsePrefix|<>|telegram.*responsePrefix" "${OPENCLAW_CONFIG_PATH:-$HOME/.openclaw/openclaw.json}"

If you find a responsePrefix that could render to <>, remove it or set it to "" (disable) and restart.

If you are using Ollama as a fallback model

Then the Ollama problem can absolutely cause multi-minute delays (model call stalls, everything queues). To confirm, paste:

openclaw models status

Once you paste either:

• the openclaw logs --follow snippet from a <> reply, or
• your responsePrefix grep result,

…I can tell you exactly what’s generating the <> and how to stop it.

[paper bay]

i am running openclaw+ollama I ran restart gateway and it gave me this 🦞 OpenClaw 2026.2.6-3 (85ed6c7)
I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
Restarted systemd service: openclaw-gateway.service

openclaw doesnt know what rg is in front of rg -n "responsePrefix|<>|telegram.*responsePrefix" "${OPENCLAW_CONFIG_PATH:-$HOME/.openclaw/openclaw.json}"

Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/llama3.2:1b
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): "ollama/llama3.2:1b"

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

• ollama effective=env:ollama-local | env=ollama-local | source=env: OLLAMA_API_KEY | models.json=ollama-local | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

• none

[viral tide]

rg is ripgrep (a separate shell tool), not an OpenClaw command — so if you typed that into OpenClaw (or your bot chat), it won’t work.

You’ve got 3 easy alternatives:

Option 1: Use OpenClaw’s built-in config getter (terminal on the gateway host)

Run these:

openclaw config get messages.responsePrefix
openclaw config get channels.telegram.responsePrefix
openclaw config get channels.telegram.accounts

If any of those show something like <> or something with angle brackets (e.g. <{identity.name}>), that can explain Telegram replies that end up as just <>.

To remove it:

openclaw config unset messages.responsePrefix
openclaw config unset channels.telegram.responsePrefix

(or set it to something sane like "auto" / "[openclaw]")

Option 2: Use /config in-chat (Telegram/Discord) if you enabled it

If you have commands.config: true, you can run:

/config get messages.responsePrefix
/config get channels.telegram.responsePrefix
/config show channels.telegram.accounts

Docs/examples: https://docs.openclaw.ai/tools/slash-commands#config-updates

Option 3: Use plain grep instead of rg

On Linux/macOS:

grep -nE 'responsePrefix|<>|telegram.*responsePrefix' "${OPENCLAW_CONFIG_PATH:-$HOME/.openclaw/openclaw.json}"

Next step (now that diagnostics flags are set)

Restart the gateway, reproduce one <>, then paste the log snippet:

openclaw gateway restart
openclaw logs --follow

Paste what openclaw config get messages.responsePrefix returns, and we’ll fix the <> first (then tackle the 5-minute delays).

[viral tide]

That output basically is the smoking gun:

• Your Default model is ollama/llama3.2:1b
• You have no fallbacks
• And OpenClaw is logging: “Failed to discover Ollama models: TimeoutError …”

So when a message comes in, your bot tries to talk to Ollama on http://127.0.0.1:11434 and it’s either not running / not reachable / overloaded → that can absolutely cause multi‑minute delays and also “weird tiny replies” like <>.

Fix path 1 (keep Ollama): make sure Ollama is actually reachable from the Gateway host

On the same machine where OpenClaw runs:

curl -s http://127.0.0.1:11434/api/tags
ollama list

If that curl hangs/fails, start Ollama:

ollama serve

Then re-check:

openclaw models status
openclaw doctor

Docs: https://docs.openclaw.ai/providers/ollama (see “Ollama not detected”)

Fix path 2 (recommended for reliability): switch to a hosted model (and add fallbacks)

Local Ollama models—especially tiny ones—tend to be unreliable for agent/tool workflows.

High-level steps:

openclaw models auth add # add a provider key/token
openclaw models scan # discover what you can use
openclaw models list # see available models
openclaw models set <pick-one> # set a better default

(You pick from what your install lists — I won’t guess model names.)

Also check one config knob that can produce “<>”

Run:

openclaw config get messages.responsePrefix
openclaw config get channels.telegram.responsePrefix

If either is set to something like <> / <{identity.name}>, unset it:

openclaw config unset messages.responsePrefix
openclaw config unset channels.telegram.responsePrefix
openclaw gateway restart

Next step for the <> specifically

After you restart the gateway (so diagnostics flags apply), reproduce one <> and paste the telegram.payload lines from:

openclaw logs --follow

But I’d bet fixing the Ollama connectivity/model choice will make both symptoms disappear.

[paper bay]

ollama list
{"models":[{"name":"llama3.2:1b","model":"llama3.2:1b","modified_at":"2026-02-09T21:38:04.725838868-05:00","size":1321098329,"digest":"baf6a787fdffd633537aa2eb51cfd54cb93ff08e28040095462bb63daf552878","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"1.2B","quantization_level":"Q8_0"}},{"name":"llama3.2:3b","model":"llama3.2:3b","modified_at":"2026-02-08T21:50:17.687709667-05:00","size":2019393189,"digest":"a80c4f17acd55265feec403c7aef86be0c25983ab279d83f3bcd3abbcb5b8b72","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"3.2B","quantization_level":"Q4_K_M"}}]}NAME ID SIZE MODIFIED
llama3.2:1b baf6a787fdff 1.3 GB 21 hours ago
llama3.2:3b a80c4f17acd5 2.0 GB 45 hours ago

[viral tide]

Cool — so Ollama itself is installed and has models (llama3.2:1b + llama3.2:3b). The missing piece is: can the OpenClaw Gateway reach Ollama at the URL it’s trying (http://127.0.0.1:11434), and does it respond fast enough? (Doctor/model scan only waits ~5s for /api/tags.)

1) Quick connectivity + timing test (run on the same machine as the Gateway)

curl -s -w "\nTIME=%{time_total}\n" http://127.0.0.1:11434/api/tags | head
curl -s -w "\nTIME=%{time_total}\n" http://127.0.0.1:11434/v1/models | head

• If either hangs or TIME is > ~5 seconds → that explains the “Failed to discover Ollama models: TimeoutError”, and it can also explain multi‑minute reply delays.
• If it works instantly → then we look at OpenClaw config/env mismatch next.

2) Check if your ollama CLI is talking to a different host than OpenClaw

Sometimes ollama list works because OLLAMA_HOST is set to a remote machine, while OpenClaw still tries 127.0.0.1.

Run:

echo "$OLLAMA_HOST"

If that’s set (e.g. http://192.168.x.x:11434), tell me what it prints.

3) Your delays + weird <> replies are very likely coming from the model choice

You’re currently configured as:

• Default: ollama/llama3.2:1b
• Fallbacks: none

That tiny model can absolutely produce “garbage minimal outputs” and slow/unstable behavior under load.

At minimum, try switching to the 3B model:

openclaw models set ollama/llama3.2:3b

openclaw gateway restart

4) Check responsePrefix (this can literally create <>)

Run:

openclaw config get messages.responsePrefix
openclaw config get channels.telegram.responsePrefix

If you see anything that could render to angle brackets (like <{identity.name}> or <>), unset it:

openclaw config unset messages.responsePrefix
openclaw config unset channels.telegram.responsePrefix
openclaw gateway restart

5) After restart, capture one <> event with your new diagnostics flags

openclaw logs --follow

Reproduce once and paste the few lines that include telegram.payload around the send.

Reply with:

• output of the two curl commands (including TIME),
• echo "$OLLAMA_HOST",
• and the two responsePrefix values

…and I’ll tell you exactly which fix applies.

[paper bay]

{"models":[{"name":"llama3.2:1b","model":"llama3.2:1b","modified_at":"2026-02-09T21:38:04.725838868-05:00","size":1321098329,"digest":"baf6a787fdffd633537aa2eb51cfd54cb93ff08e28040095462bb63daf552878","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"1.2B","quantization_level":"Q8_0"}},{"name":"llama3.2:3b","model":"llama3.2:3b","modified_at":"2026-02-08T21:50:17.687709667-05:00","size":2019393189,"digest":"a80c4f17acd55265feec403c7aef86be0c25983ab279d83f3bcd3abbcb5b8b72","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"3.2B","quantization_level":"Q4_K_M"}}]}
TIME=0.001859
{"object":"list","data":[{"id":"llama3.2:1b","object":"model","created":1770691084,"owned_by":"library"},{"id":"llama3.2:3b","object":"model","created":1770605417,"owned_by":"library"}]}

TIME=0.001196

[viral tide]

Perfect — those TIME=0.001… results mean Ollama on 127.0.0.1 is reachable and fast right now. So the earlier “Failed to discover Ollama models” was likely just “Ollama wasn’t up / was stuck loading” at that moment — not a permanent config problem.

Now we can go straight at the two symptoms:

1) Fix the <> reply (most likely: responsePrefix)

<> is very consistent with a config prefix like <{identity.name}> when identity.name is empty, or literally responsePrefix: "<>".

Run these on the gateway host:

openclaw config get messages.responsePrefix
openclaw config get channels.telegram.responsePrefix

If either one prints something with angle brackets (or <>), fix it by unsetting or switching to something sane:

openclaw config unset messages.responsePrefix
openclaw config unset channels.telegram.responsePrefix
openclaw gateway restart

(Or set messages.responsePrefix to "auto" / "[openclaw]" if you want a prefix.)

2) Fix the 5+ minute delays (root cause: you’re running only local Ollama, no fallbacks)

Right now you’re configured as:

• Default: ollama/llama3.2:1b
• Fallbacks: none

So if the model is slow/busy, everything queues and you feel it as “replies take forever”.

Two quick improvements:

A) Switch to the 3B model (usually less derpy)

openclaw models set ollama/llama3.2:3b
openclaw gateway restart

B) Confirm the gateway isn’t still timing out talking to Ollama during real requests

After restart, tail logs and reproduce a slow reply:

openclaw logs --follow

With your diagnostics flags enabled, those logs should make it obvious whether it’s:

• time spent waiting on Ollama generation, or
• something else (Telegram network, etc.)

Next message to send me

Paste the output of the two openclaw config get …responsePrefix… commands. If one of them is angle-bracket-y, we can stop the <> immediately.

[paper bay]

$ openclaw models set ollama/llama3.2:3b

🦞 OpenClaw 2026.2.6-3 (85ed6c7)
Hot reload for config, cold sweat for deploys.

Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
Updated ~/.openclaw/openclaw.json
Default model: ollama/llama3.2:3b
jason@ai-companion:~$ openclaw gateway restart

🦞 OpenClaw 2026.2.6-3 (85ed6c7)
Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.

Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
Restarted systemd service: openclaw-gateway.service

[viral tide]

Nice — switching to ollama/llama3.2:3b is the right direction.

But that “Failed to discover Ollama models: TimeoutError” while your curl http://127.0.0.1:11434/api/tags returns in ~0.001s means: Node’s fetch() (what OpenClaw uses) is not reaching Ollama the same way curl is.

Most common cause: proxy env vars (Node fetch goes through a proxy unless NO_PROXY is set)

On the gateway host, run:

env | egrep -i 'http_proxy|https_proxy|all_proxy|no_proxy' || true

If you have HTTP_PROXY / HTTPS_PROXY / ALL_PROXY set, make sure NO_PROXY includes localhost:

export NO_PROXY="127.0.0.1,localhost"
export no_proxy="127.0.0.1,localhost"

Then try again:

openclaw doctor
openclaw models status

(And restart the gateway after changing env that the service should inherit.)

To prove it’s Node fetch vs curl, run:

node -e 'fetch("http://127.0.0.1:11434/api/tags",{signal:AbortSignal.timeout(5000)}).then(r=>r.json()).then(j=>console.log("ok models=",j.models?.length)).catch(e=>console.error("ERR",e))'

Separately: the <> Telegram reply

Now that you restarted, can you paste these two outputs?

openclaw config get messages.responsePrefix
openclaw config get channels.telegram.responsePrefix

If either one is <> or something like <{identity.name}>, that can literally produce <> in Telegram (especially if the model reply ends up empty).

About “injecting prompts into memory”

Yep: don’t use memory as a prompt-dump. Memory is for durable facts/preferences; for “do X behavior always”, put it in AGENTS.md/system prompt. Docs: https://docs.openclaw.ai/concepts/memory

Send me:

1. the proxy env output
2. the Node fetch test output
3. the two responsePrefix values

…and we’ll pin this down quickly.

[paper bay]

this is what openclaw status gave me Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/llama3.2:3b
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (2): "ollama/llama3.2:1b", ollama/llama3.2:3b

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

• ollama effective=env:ollama-local | env=ollama-local | source=env: OLLAMA_API_KEY | models.json=ollama-local | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

• none

[viral tide]

That output is actually super helpful: you’re 100% running on Ollama (no fallbacks), and OpenClaw is still trying (and failing) to do the “Ollama model discovery” call.

Given your earlier curl http://127.0.0.1:11434/api/tags returns in ~0.002s, the most likely reason OpenClaw’s Node fetch() is timing out is: proxy env vars. Node/undici respects HTTP_PROXY/HTTPS_PROXY/ALL_PROXY unless NO_PROXY includes localhost — curl often behaves differently.

1) Check proxy env vars

Run on the gateway host:

env | egrep -i 'http_proxy|https_proxy|all_proxy|no_proxy' || true

If you see any proxy vars, make sure you have:

• NO_PROXY=127.0.0.1,localhost
• no_proxy=127.0.0.1,localhost

Then restart the gateway.

Important (systemd service):

The gateway service doesn’t load your shell init. Put env vars in:
~/.openclaw/.env (this file is loaded early by the gateway).
Docs: https://docs.openclaw.ai/gateway/troubleshooting#service-environment-path--runtime

So you can add to ~/.openclaw/.env:

NO_PROXY=127.0.0.1,localhost
no_proxy=127.0.0.1,localhost
OLLAMA_API_KEY=ollama-local

…then openclaw gateway restart.

2) Prove it’s Node fetch (1-liner)

node -e 'fetch("http://127.0.0.1:11434/api/tags",{signal:AbortSignal.timeout(5000)}).then(r=>r.json()).then(j=>console.log("OK",j.models?.length)).catch(e=>console.error("ERR",e))'

If that errors/hangs → it’s almost certainly proxy env.

3) The <> reply is very likely responsePrefix

Please run and paste these two outputs:

openclaw config get messages.responsePrefix
openclaw config get channels.telegram.responsePrefix

If either one is <> or something like <{identity.name}>, that can literally produce a Telegram message that’s just <> (especially when the model reply is empty/blocked).

4) About the long delays

Even once discovery is fixed: with no fallbacks, if Ollama is busy/slow, replies will queue. Switching to llama3.2:3b helps, but adding a cloud fallback is the “it just works” solution.

Reply with:

• the proxy env output

• the Node fetch test output
• the two responsePrefix values

[paper bay]

I ran this and got ok models= 2

[paper bay]

jason@ai-companion:~$ openclaw config get
error: missing required argument 'path'
jason@ai-companion:~$ messages.responsePrefix
messages.responsePrefix: command not found
jason@ai-companion:~$ openclaw config get
error: missing required argument 'path'
jason@ai-companion:~$

thats what I get

[viral tide]

I’m missing the actual output you’re referring to — “that’s what I get” didn’t include the command results.

Can you copy/paste the exact output (ideally in a code block) for these 3 commands, in this order?

1) Proxy env (this is the #1 reason Node fetch() behaves differently than curl)

env | egrep -i 'http_proxy|https_proxy|all_proxy|no_proxy' || true

2) Prove whether Node fetch() can hit Ollama (OpenClaw uses Node fetch for discovery)

node -e 'fetch("http://127.0.0.1:11434/api/tags",{signal:AbortSignal.timeout(5000)}).then(r=>r.json()).then(j=>console.log("OK models=",j.models?.length)).catch(e=>console.error("ERR",e))'

3) Check if a prefix is literally producing <> in Telegram

openclaw config get messages.responsePrefix
openclaw config get channels.telegram.responsePrefix

Your curl timings show Ollama is fast, so if (2) errors/timeouts while curl is instant, we’ll focus on env/proxy/systemd env differences. If (3) shows something like <> or <{identity.name}>, we can fix the <> replies immediately by unsetting it and restarting.

Paste those outputs and I’ll tell you exactly what to change.

[paper bay]

doesnt give an output env | egrep -i 'http_proxy|https_proxy|all_proxy|no_proxy' || true

node -e 'fetch("http://127.0.0.1:11434/api/tags",{signal:AbortSignal.timeout(5000)}).then(r=>r.json()).then(j=>console.log("OK models=",j.models?.length)).catch(e=>console.error("ERR",e))'
OK models= 2

thats the responses

[viral tide]

I’m still not seeing the actual command outputs in your last two messages — looks like Discord ate them or they didn’t get included.

Let’s do this one at a time so it can’t get lost:

1) Check the thing that can literally cause a <> reply

Run on the gateway host and paste the output inside a code block:

openclaw config get messages.responsePrefix

If that prints anything with angle brackets (like <> or <{identity.name}>), that’s almost certainly why Telegram sometimes shows only <> (when the model reply ends up empty, you only see the prefix).

Then we’ll do:

openclaw config get channels.telegram.responsePrefix

2) Why OpenClaw keeps saying “Failed to discover Ollama models”

Since your curl http://127.0.0.1:11434/api/tags is instant, but OpenClaw’s Node fetch is timing out, this is very often proxy env vars.

Please run and paste:

env | egrep -i 'http_proxy|https_proxy|all_proxy|no_proxy' || true

If you have a proxy set, the fix is to ensure NO_PROXY includes localhost. Add this to ~/.openclaw/.env (important for systemd), then restart:

NO_PROXY=127.0.0.1,localhost
no_proxy=127.0.0.1,localhost

and:

openclaw gateway restart

3) Also: the “5 minute delays”

Now that you’re on llama3.2:3b, if replies are still taking minutes, it may just be slow local inference (CPU/RAM). Once we fix the <> prefix, the next best debug is openclaw logs --follow during a slow reply.

First: paste the output of openclaw config get messages.responsePrefix (with triple backticks).

[paper bay]

🦞 OpenClaw 2026.2.6-3 (85ed6c7)
Chat automation for people who peaked at IRC.

Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
Config path not found: messages.responsePrefix

thats what openclaw config get gave me

[viral tide]

I still can’t see the value you got back — which usually means the value is empty (so when you copy/paste it, Discord shows… nothing).

Let’s force it to be visible.

Show the prefix values with clear markers

Run these on the gateway host and paste the output:

echo "messages.responsePrefix=[$(openclaw config get messages.responsePrefix)]"
echo "telegram.responsePrefix=[$(openclaw config get channels.telegram.responsePrefix)]"

• If you see messages.responsePrefix=[<>] or [...] with angle brackets → that explains the Telegram <>.
• If you see messages.responsePrefix=[] (empty) → then <> is coming from the model output itself, not a prefix.

Quick diagnostic that answers “is the model output empty / weird?”

Temporarily set a debug prefix:

openclaw config set messages.responsePrefix "[DBG]"
openclaw gateway restart

Then reproduce in Telegram once:

• If you get [DBG] <> → the model is literally outputting <>.
• If you get [DBG] only → the model is outputting an empty reply sometimes.
• If you still get <> with no [DBG] → you’re not talking to the gateway/config you think you are.

After the test, revert:

openclaw config unset messages.responsePrefix
openclaw gateway restart

About the 5+ minute delays

Now that you’re on llama3.2:3b, the most common remaining cause is simply slow local generation (CPU/RAM bound) or queueing behind another run. Once we know whether the reply is empty vs <>, the next step is tailing logs during a slow reply:

openclaw logs --follow

Paste the two echo ...Prefix=[...] lines first — that’ll let us pin the <> cause immediately.

[paper bay]

echo "telegram.responsePrefix=[$(openclaw config get channels.telegram.responsePrefix)]"
Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
Config path not found: messages.responsePrefix
messages.responsePrefix=[]
Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
Config path not found: channels.telegram.responsePrefix
telegram.responsePrefix=[]

[viral tide]

Great — that output tells us two important things:

1) The <> is not coming from a configured prefix

Both lookups came back “Config path not found …” and then [], so you don’t have messages.responsePrefix or channels.telegram.responsePrefix set.

That means the <> you see in Telegram is coming from the model’s actual output (your Ollama model is sometimes literally producing <>).

What to do about <> (practical fixes)

1. Remove any “prompt injection” you put into memory / AGENTS rules that mentions <>, XML tags, or “wrap things in angle brackets”.

• Your workspace is usually ~/.openclaw/workspace/
• Check these files specifically: AGENTS.md, MEMORY.md, and memory/*.md

Quick search:

grep -RIn "<>" ~/.openclaw/workspace 2>/dev/null || true
grep -RIn "angle bracket" ~/.openclaw/workspace 2>/dev/null || true

2. Add a guardrail rule in ~/.openclaw/workspace/AGENTS.md like:

“Never reply with only <> or only punctuation. If you would otherwise respond with <> or nothing, respond with: I’m not sure — can you rephrase?”

3. Use a stronger model (or at least bigger than 3B) if you want reliability. Small local models can do weird “empty placeholder” replies.

2) The “Failed to discover Ollama models: TimeoutError …” warning is still a problem

You proved curl http://127.0.0.1:11434/api/tags is instant, but OpenClaw’s Node fetch() is timing out. That mismatch is very often proxy env vars.

Please run and paste:

env | egrep -i 'http_proxy|https_proxy|all_proxy|no_proxy' || true

If you have proxy vars set, fix by ensuring:

• NO_PROXY=127.0.0.1,localhost
• no_proxy=127.0.0.1,localhost

For the systemd gateway service, put those in ~/.openclaw/.env (service won’t read your shell init), then:

openclaw gateway restart

About the 5+ minute delays

With Ollama-only (no fallbacks), delays are usually either:

• local inference is slow (CPU/RAM bound), or
• the agent is busy and messages queue.

Once you paste the proxy env output, we’ll fix the discovery warning first. Then if delays persist, we’ll tail openclaw logs --follow during a “slow reply” and you’ll see exactly where the time goes (Telegram send vs Ollama generation vs queue).

[paper bay]

/home/jason/.openclaw/workspace/AGENTS.md:125:- Discord links: Wrap multiple links in <> to suppress embeds: <https://example.com>

env | egrep -i 'http_proxy|https_proxy|all_proxy|no_proxy' || true didnt provide any data

I dont know if I have proxy vars set. should I add these anyways? no_proxy=127.0.0.1,localhost

krill?

[viral tide]

If env | egrep -i 'http_proxy|https_proxy|all_proxy|no_proxy' printed nothing, you probably don’t need to add NO_PROXY.

But it’s also safe to add, and it can’t hurt. If you want to be extra sure (especially with systemd services), go ahead and add both lines to ~/.openclaw/.env:

NO_PROXY=127.0.0.1,localhost
no_proxy=127.0.0.1,localhost

Then restart:

openclaw gateway restart

Just note: this will only fix anything if something is trying to use a proxy. It won’t fix the <> replies by itself.

For the <> problem, the two most effective next steps are:

1. /reset in the Telegram chat where it happens (clears polluted session state)
2. move off tiny local models / add a hosted fallback (small Ollama models sometimes emit junk like <>).

[viral tide]

Got it — no proxy env vars, and your prefix checks came back empty. So:

1) <> is coming from the model output, not OpenClaw formatting

Since messages.responsePrefix / channels.telegram.responsePrefix aren’t set, Telegram is receiving <> as the actual assistant text.

That typically happens because:

• a small local model (1B/3B) occasionally emits junk/placeholder output, or
• you accidentally “trained” it via injected prompts/memory to use <> as a sentinel.

Fastest “stop the bleeding” steps:

1. In Telegram, run:

• /reset
  (clears the session state; if the session got polluted, this often fixes the weird <> replies immediately)

2. Search your workspace for any rule that mentions <> and remove it:

[paper bay]

so the ollama time out can you help me fix that?

[viral tide]

grep -RIn "<>" ~/.openclaw/workspace 2>/dev/null || true
grep -RIn "angle" ~/.openclaw/workspace 2>/dev/null || true

3. Add a guardrail to ~/.openclaw/workspace/AGENTS.md (create it if missing), e.g.:

Never reply with only <> or only punctuation. If you would otherwise output <>/nothing, ask a short clarifying question instead.

2) The 5-minute delays are very likely just local inference speed / queueing

With Ollama-only and no fallbacks, if the model is slow/busy you’ll feel it as “sometimes it takes minutes”.

You already switched to llama3.2:3b (good). If you still see long delays, the reliable fix is: add a hosted fallback model (so if Ollama is slow/down, you still get fast replies).

3) Why you keep seeing “Failed to discover Ollama models: TimeoutError”

Even though curl /api/tags is fast, OpenClaw’s model auto-discovery is still timing out sometimes. That warning is mostly annoying, but it’s also a hint that Ollama is occasionally not responding fast enough when OpenClaw checks it.

If you want to confirm whether it’s a Node fetch() issue (what OpenClaw uses), run:

node -e 'fetch("http://127.0.0.1:11434/api/tags",{signal:AbortSignal.timeout(5000)}).then(r=>r.json()).then(j=>console.log("OK models=",j.models?.length)).catch(e=>console.error("ERR",e))'

If you paste the output of that node -e ... line and tell me whether /reset stops the <>, I can tell you the next precise step (model/prompt vs transport).

[viral tide]

Yep — I’m here.

Did you want to try the quick fix path now?

1. In the Telegram chat where you got <>, send: /reset
2. Then ask the same question again.

If it still replies with <> after a reset, paste the output of this one-liner from the gateway host (it tells us if Node fetch is intermittently failing to talk to Ollama):

node -e 'fetch("http://127.0.0.1:11434/api/tags",{signal:AbortSignal.timeout(5000)}).then(r=>r.json()).then(j=>console.log("OK models=",j.models?.length)).catch(e=>console.error("ERR",e))'

Yep — that “Failed to discover Ollama models: TimeoutError …” is coming from OpenClaw’s Ollama auto-discovery (it does a best-effort GET http://127.0.0.1:11434/api/tags with a 5s timeout). It’s annoying, but it’s not strictly required for your bot to run.

You can fix it in two ways:

Fix 1 (most reliable): disable auto-discovery by configuring Ollama explicitly

Add an explicit models.providers.ollama block in ~/.openclaw/openclaw.json. This makes OpenClaw stop calling /api/tags to “discover” models.

Example (JSON5) — add/merge this:

{
models: {
providers: {
ollama: {
baseUrl: "http://127.0.0.1:11434/v1",
apiKey: "ollama-local",

api: "openai-completions",
models: [
{
id: "llama3.2:3b",
name: "Llama 3.2 3B",
reasoning: false,
input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 8192,
maxTokens: 8192 * 10,
},
{
id: "llama3.2:1b",
name: "Llama 3.2 1B",
reasoning: false,

input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 8192,
maxTokens: 8192 * 10,
},
],
},
},
},
}

Then:

openclaw gateway restart