I can't get ollama qwen2.5:14b to work local on my computer. | Friends of the Crustacean 🦞🤝 | Page 1

tulip birch Feb 11, 2026, 3:01 PM

#

@jolly stirrup

#

can you look into this @jolly stirrup

swift void Feb 11, 2026, 3:02 PM

#

@jolly stirrup

#

krills dead

jolly stirrupBOT Feb 11, 2026, 3:04 PM

#

swift void <@1457407575476801641>

A couple common gotchas with Ollama + OpenClaw (especially with qwen2.5:14b):

1) First: what “doesn’t work” exactly?

Can you paste:

openclaw --version
the exact error you see (or a screenshot)
output of openclaw models list (just the ollama/... lines are enough)

That’ll narrow it down fast.

2) Make sure OpenClaw is actually “seeing” Ollama

OpenClaw only enables/discovers Ollama if you set an API key (any string is fine; Ollama doesn’t require a real key):

export OLLAMA_API_KEY="ollama-local"

#

(or set it in config:)

openclaw config set models.providers.ollama.apiKey "ollama-local"

Then restart the gateway and check:

openclaw models list

Docs: https://docs.openclaw.ai/providers/ollama

3) The big one: auto-discovery filters out models without tool support

OpenClaw’s implicit discovery only includes Ollama models that report tool capability. If qwen2.5:14b doesn’t advertise tools, it simply won’t show up in openclaw models list.

#

Fix options:

Use a model that reports tools (often coder/instruct variants do).
Or add it manually via explicit config (this disables auto-discovery, so you must list models yourself):

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434/v1",
        apiKey: "ollama-local",
        api: "openai-completions",
        models: [
          {
            id: "qwen2.5:14b",
            name: "Qwen 2.5 14B",

#

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

4) Sanity-check Ollama is reachable from where the Gateway runs

If the gateway is on the same machine, this should work:

#

curl http://127.0.0.1:11434/api/tags

If you’re running the gateway in Docker/WSL/another host, 127.0.0.1 might point at the wrong machine, and you’ll need a reachable host IP in baseUrl.

Reply with the error + openclaw --version + what openclaw models list shows, and I’ll tell you which branch you’re in.

swift void Feb 11, 2026, 4:09 PM

#

krill how do i set upp ollama in openclaw for this model nemotron-3-nano:30b-cloud using commands also dont mind it says cloud it runs local

#

@jolly stirrup krill how do i set upp ollama in openclaw for this model nemotron-3-nano:30b-cloud using commands also dont mind it says cloud it runs local

jolly stirrupBOT Feb 11, 2026, 4:10 PM

#

swift void <@1457407575476801641> krill how do i set upp ollama in openclaw for this model ...

To set up Ollama in OpenClaw for a specific local model (even if the tag says “cloud”), you’ve got two paths:

Docs: https://docs.openclaw.ai/providers/ollama

A) Easiest (auto-discovery) — only works if the model reports tool support

# 1) Make sure Ollama is running + model is pulled
ollama serve
ollama pull nemotron-3-nano:30b-cloud
ollama list

# 2) Opt-in Ollama for OpenClaw (any string works)
openclaw config set models.providers.ollama.apiKey "ollama-local"

#

# 3) Restart gateway so it re-detects providers/models
openclaw gateway restart

# 4) See what OpenClaw discovered
openclaw models list

# 5) Set it as default (use the exact id you see in models list)
openclaw config set agents.defaults.model.primary "ollama/nemotron-3-nano:30b-cloud"
openclaw gateway restart

If openclaw models list doesn’t show your model: it’s usually because OpenClaw filters out Ollama models that don’t advertise tools.

B) Force it (manual model entry) — works even if the model doesn’t report tools

#

This disables auto-discovery and explicitly tells OpenClaw what model exists:

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config set models.providers.ollama.api "openai-completions"

openclaw config set models.providers.ollama.models --json '[
  {
    id: "nemotron-3-nano:30b-cloud",
    name: "Nemotron 3 Nano 30B (local)",
    input: ["text"],
    reasoning: false,
    cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
    contextWindow: 8192,
    maxTokens: 8192 * 10

#

  }
]'

openclaw config set agents.defaults.model.primary "ollama/nemotron-3-nano:30b-cloud"
openclaw gateway restart

If it still won’t connect

Run this from the same machine where the Gateway runs:

curl http://127.0.0.1:11434/api/tags

If your Gateway is in Docker/WSL/another host, 127.0.0.1 might be the wrong box — tell me your setup and I’ll give the correct baseUrl.

#

If you paste:

openclaw --version
openclaw models list output (just the ollama lines)
…I can tell you which of A/B you need and what model id OpenClaw expects exactly.

swift void Feb 11, 2026, 4:15 PM

#

Error: Config validation failed: models.providers.ollama.models: Invalid input: expected array, received undefined @jolly stirrup

jolly stirrupBOT Feb 11, 2026, 4:18 PM

#

That error means you have an explicit models.providers.ollama entry, but no models.providers.ollama.models array set yet.

Pick one:

Option A (simplest): remove the explicit provider block (go back to auto-detect)

openclaw config unset models.providers.ollama
openclaw gateway restart

(Then rely on OLLAMA_API_KEY via env/~/.openclaw/.env.)

Option B: define the missing array (this fixes the validation immediately)

openclaw config set models.providers.ollama.models --json '[]'
openclaw gateway restart

swift void Feb 11, 2026, 4:18 PM

#

Error: Config validation failed: models.providers.ollama.models: Invalid input: expected array, received undefined

jolly stirrupBOT Feb 11, 2026, 4:18 PM

#

Then replace [] with your real model definition (array with your model object), like I posted above.

If you run this and paste the output, I can tell you exactly what state you’re in:

openclaw config get models.providers.ollama

#

That error happens when you’ve created an explicit models.providers.ollama block (e.g. by running openclaw config set models.providers.ollama.apiKey ...) but you didn’t define models.providers.ollama.models.

In “explicit provider” mode, OpenClaw expects models.providers.ollama.models to be an array — so validation fails.

You’ve got two clean fixes:

Fix 1 (recommended): go back to auto-detection

Auto-detection works when you set OLLAMA_API_KEY (env) and do NOT define models.providers.ollama in config.

# remove explicit provider config
openclaw config unset models.providers.ollama

# make the daemon pick up Ollama (any string works)
printf "\nOLLAMA_API_KEY=ollama-local\n" >> ~/.openclaw/.env

#

openclaw gateway restart
openclaw models list

Then set your default model (if it appears in openclaw models list):

openclaw config set agents.defaults.model.primary "ollama/nemotron-3-nano:30b-cloud"
openclaw gateway restart

Note: auto-discovery only lists models that report tool support — if it doesn’t show up, use Fix 2.

Fix 2: keep explicit provider + define the model array

Run this (pay attention to --json + the quotes):

swift void Feb 11, 2026, 4:19 PM

#

where is openclaw folder

jolly stirrupBOT Feb 11, 2026, 4:21 PM

#

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config set models.providers.ollama.api "openai-completions"

openclaw config set models.providers.ollama.models --json '[
  {
    id: "nemotron-3-nano:30b-cloud",
    name: "Nemotron 3 Nano 30B (local)",
    input: ["text"],
    reasoning: false,
    cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
    contextWindow: 8192,
    maxTokens: 81920
  }
]'

#


openclaw config set agents.defaults.model.primary "ollama/nemotron-3-nano:30b-cloud"
openclaw gateway restart

If you paste what you currently have for:

openclaw config get models.providers.ollama

…I can tell you which fix is quickest for your current state.

swift void Feb 11, 2026, 4:23 PM

#

hey krill what is tis Error: Config validation failed: models.providers.ollama.models: Invalid input: expected array, received undefined

#

@jolly stirrup Error: Config validation failed: models.providers.ollama.models: Invalid input: expected array, received undefined

#

krill

#

krill i am trying to set ollama to openclaw but when i try to set i get tis Error: Config validation failed: models.providers.ollama.models: Invalid input: expected array, received undefined

#

@jolly stirrup

jolly stirrupBOT Feb 11, 2026, 4:33 PM

#

swift void <@1457407575476801641> Error: Config validation failed: models.providers.ollama....

That validation error means: you have models.providers.ollama set, but models.providers.ollama.models is missing. In explicit-provider mode, OpenClaw requires models to be an array.

Fastest fix (add an empty array so config becomes valid)

macOS/Linux (bash/zsh):

openclaw config set models.providers.ollama.models --json '[]'
openclaw gateway restart

Windows PowerShell:

openclaw config set models.providers.ollama.models --json "[]"
openclaw gateway restart

Then confirm it stuck:

#

openclaw config get models.providers.ollama.models

Better: set the whole ollama provider in one shot (avoids partial/invalid config)

PowerShell-friendly:

openclaw config set models.providers.ollama --json '{ baseUrl: "http://127.0.0.1:11434/v1", apiKey: "ollama-local", api: "openai-completions", models: [] }'
openclaw gateway restart

After that, you can replace the models: [] with your actual model entry.

#

If you tell me what shell you’re on (PowerShell vs CMD vs bash) and paste:

openclaw config get models.providers.ollama

…I’ll give you the exact command with the right quoting for your environment.

jolly stirrupBOT Feb 11, 2026, 4:38 PM

#

swift void <@1457407575476801641>

That error means your config currently has a models.providers.ollama block, but it’s missing models.providers.ollama.models (and in your version/schema that field is required once you go “explicit provider”).

Two questions so I can give you the exact one-liner:

Are you doing this in a terminal (openclaw config ...) or in Discord with /config ...?
What’s your openclaw --version?

Meanwhile, here are the fixes:

If you’re in a terminal

Windows CMD (most common quoting issue):

openclaw config set models.providers.ollama.models --json "[]"
openclaw gateway restart

#

PowerShell:

openclaw config set models.providers.ollama.models --json "[]"
openclaw gateway restart

macOS/Linux:

openclaw config set models.providers.ollama.models --json '[]'
openclaw gateway restart

If you’re using Discord `/config`

Set it without any special flags:

#

/config set models.providers.ollama.models=[]

If you don’t actually want “explicit provider mode”

Then just remove the explicit block entirely (go back to env-based auto-detect):

Terminal:

openclaw config unset models.providers.ollama
openclaw gateway restart

Discord:

/config unset models.providers.ollama

#

Paste:

the exact command you ran
your OS + shell (CMD/PowerShell/bash)
openclaw --version

…and I’ll tell you the exact next command for your setup.

swift void Feb 11, 2026, 4:41 PM

#

it dosnet answer rn so what do i need to set for the config using term

#

it dosnet answer rn so what do i need to set for the config using terminal in debian wsl @jolly stirrup

jolly stirrupBOT Feb 11, 2026, 4:43 PM

#

swift void it dosnet answer rn so what do i need to set for the config using terminal in de...

In Debian WSL the two usual problems are:

your config is in a half-explicit state (you set models.providers.ollama but not models.providers.ollama.models, so validation keeps failing), and/or
WSL can’t reach Ollama (if Ollama is running on Windows, 127.0.0.1:11434 might not be reachable from WSL on your machine).

Here’s the clean “reset + set it correctly” path.

0) Confirm WSL can reach Ollama

Run in WSL:

curl -sS http://127.0.0.1:11434/api/tags | head

If that fails, try Windows-host IP (common on WSL2):

#

WIN_IP=$(grep nameserver /etc/resolv.conf | awk '{print $2}' | head -1)
curl -sS "http://$WIN_IP:11434/api/tags" | head

Keep the working host/port in mind (either 127.0.0.1 or $WIN_IP).

1) Fix the config validation loop (make ollama provider valid)

First, wipe the broken partial ollama provider entry:

openclaw config unset models.providers.ollama

Now set the provider in one command (so it can’t end up missing models:).
Pick the baseUrl that worked in step 0:

#

If `127.0.0.1` worked:

openclaw config set models.providers.ollama --json '{ baseUrl:"http://127.0.0.1:11434/v1", apiKey:"ollama-local", api:"openai-completions", models:[{ id:"nemotron-3-nano:30b-cloud", name:"Nemotron 3 Nano 30B (local)" }] }'

If only `$WIN_IP` worked:

WIN_IP=$(grep nameserver /etc/resolv.conf | awk '{print $2}' | head -1)
openclaw config set models.providers.ollama --json "{ baseUrl:\"http://$WIN_IP:11434/v1\", apiKey:\"ollama-local\", api:\"openai-completions\", models:[{ id:\"nemotron-3-nano:30b-cloud\", name:\"Nemotron 3 Nano 30B (local)\" }] }"

Then set the default model:

openclaw config set agents.defaults.model.primary "ollama/nemotron-3-nano:30b-cloud"

#

Restart the gateway:

openclaw gateway restart

2) Verify OpenClaw sees it

openclaw models list | rg ollama
openclaw config get agents.defaults.model.primary

If it still “doesn’t answer”

Paste these outputs (they’ll show exactly where it’s stuck):

#

openclaw --version
openclaw status --deep
openclaw logs --follow --json | tail -n 50

swift void Feb 11, 2026, 4:44 PM

#

ccnar@DESKTOP-BCT1NJ9:~$ curl -sS http://127.0.0.1:11434/api/tags | head
curl: (7) Failed to connect to 127.0.0.1 port 11434 after 0 ms: Could not connect to server
ccnar@DESKTOP-BCT1NJ9:~$ WIN_IP=$(grep nameserver /etc/resolv.conf | awk '{print $2}' | head -1)
curl -sS "http://$WIN_IP:11434/api/tags" | head
curl: (7) Failed to connect to 10.255.255.254 port 11434 after 0 ms: Could not connect to server @jolly stirrup

#

ima just install ollama in the wsl

#

@jolly stirrup ima just re install openclaw

swift void Feb 11, 2026, 5:08 PM

#

i have set up ollama with ollama launch openclaw --model (model name here) but when i try to message it from telegram or the web ui i get tis HTTP 401: unauthorized

#

@jolly stirrup

#

@jolly stirrup help me i am getting http 401 unautharized

jolly stirrupBOT Feb 11, 2026, 5:14 PM

#

swift void <@1457407575476801641> help me i am getting http 401 unautharized

HTTP 401 Unauthorized is almost always Gateway auth (the dashboard / Control UI or the CLI talking to the Gateway) — not Ollama.

1) If the 401 is in your browser (Dashboard / Control UI)

Open the UI with a tokenized link:

openclaw dashboard

That prints something like http://127.0.0.1:18789/?token=... — open that URL once. The UI stores the token after first load.

If you don’t have a token yet (or lost it):

openclaw doctor --generate-gateway-token
openclaw gateway restart

#

openclaw dashboard

Docs: https://docs.openclaw.ai/web/dashboard

2) If the 401 is in the terminal (CLI commands like `openclaw status`, `openclaw models list`, etc.)

Then your CLI is hitting an auth’d gateway but isn’t sending the right token. Paste the output of:

openclaw status
openclaw gateway status
openclaw config get gateway.auth
env | rg OPENCLAW_GATEWAY

Also tell me where you see the 401 (browser URL you opened, or which exact openclaw ... command).

swift void Feb 11, 2026, 9:10 PM

#

telegrama after i autharized it when i say smth to it it always gives that back

#

@jolly stirrup

#

@jolly stirrup telegrama after i autharized it when i say smth to it it always gives that back

jolly stirrupBOT Feb 11, 2026, 9:12 PM

#

swift void <@1457407575476801641>

What’s the current blocker — still the 401 unauthorized, or is it back to Ollama model not answering?

Paste the output of these (redact any tokens/keys):

openclaw --version
openclaw gateway status
openclaw status --deep
openclaw config get gateway.auth
openclaw models list | rg -i ollama

Also tell me:

Is Ollama running in Windows or inside WSL?
Is the OpenClaw gateway running in WSL or Windows?
Where do you see the 401 (browser dashboard URL, or which openclaw ... command)?

#

If the 401 is in the browser dashboard, the usual fix is just:

openclaw dashboard

(open the URL it prints — it includes the right token once and then gets stored).

swift void Feb 11, 2026, 9:12 PM

#

@jolly stirrup telegrama after i autharized it when i say smth to it it always gives that back

jolly stirrupBOT Feb 11, 2026, 9:14 PM

#

swift void <@1457407575476801641> telegrama after i autharized it when i say smth to it it...

If Telegram is replying with “HTTP 401 Unauthorized” every time, that’s almost never “Telegram auth/pairing” — it usually means OpenClaw is trying to call some HTTP API (model provider) and that provider is rejecting the key (401).

Two quick checks:

1) In the Telegram chat, run:

/model status

That will show what model/provider the bot is actually using. If it’s showing something like OpenAI/Anthropic/OpenRouter, you’ll get 401s until you either add that provider’s API key or switch the bot to Ollama.

(If it already shows ollama/..., then the 401 is coming from somewhere else — logs will tell us.)

2) Tail logs and reproduce once (this will reveal who returns 401)

On the machine running the Gateway (your Debian WSL terminal):

#

openclaw logs --follow | rg -i "401|unauthor"

Then send a test message to the Telegram bot and paste the 5–20 log lines around the 401.

Quick fix if it’s using the wrong model

Force default model to Ollama:

openclaw config set agents.defaults.model.primary "ollama/nemotron-3-nano:30b-cloud"
openclaw gateway restart

Reply with:

the exact 401 text Telegram sends back (copy/paste),
the output of /model status,

#

and the 401 log snippet

…and I’ll tell you exactly what credential/config is missing.

swift void Feb 11, 2026, 9:22 PM

#

21:21:59 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
21:21:59 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb totalActive=1
21:21:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=12e112ac-94c8-41d8-aa73-804c78ed91dd sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb
21:21:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=12e112ac-94c8-41d8-aa73-804c78ed91dd
21:21:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=12e112ac-94c8-41d8-aa73-804c78ed91dd
21:21:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=12e112ac-94c8-41d8-aa73-804c78ed91dd sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb durationMs=186
21:21:59 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
21:21:59 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb totalActive=0
21:21:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=12e112ac-94c8-41d8-aa73-804c78ed91dd sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb durationMs=340 aborted=false
21:21:59 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=342 active=0 queued=0
21:21:59 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=358 active=0 queued=0

#

21:21:59 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
21:21:59 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb totalActive=1
21:21:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=12e112ac-94c8-41d8-aa73-804c78ed91dd sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb
21:21:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=12e112ac-94c8-41d8-aa73-804c78ed91dd
21:21:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=12e112ac-94c8-41d8-aa73-804c78ed91dd
21:21:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=12e112ac-94c8-41d8-aa73-804c78ed91dd sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb durationMs=186
21:21:59 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
21:21:59 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb totalActive=0
21:21:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=12e112ac-94c8-41d8-aa73-804c78ed91dd sessionId=ab2d1e88-5bff-48a9-8eb4-881674059dfb durationMs=340 aborted=false
21:21:59 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=342 active=0 queued=0
21:21:59 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=358 active=0 queued=0 @jolly stirrup

jolly stirrupBOT Feb 11, 2026, 9:26 PM

#

swift void 21:21:59 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=ab...

That log snippet doesn’t include the 401 yet — it’s only showing “run started/completed”, but not why it failed.

When Telegram “always replies 401 unauthorized”, it’s usually because your bot is still using a cloud model provider with a bad/missing key (OpenAI/Anthropic/OpenRouter/etc), not Ollama.

1) In Telegram, run this and paste the result

/model status

This will tell us which provider/model it’s trying to use.

If it’s not ollama/..., that explains the 401.

2) Force Telegram to use your local Ollama model (from Debian WSL terminal)

openclaw config set agents.defaults.model.primary "ollama/nemotron-3-nano:30b-cloud"
openclaw gateway restart

#

Then in Telegram try again.

3) Get the actual 401 line from logs

Run this in WSL, then send 1 message to the Telegram bot, then paste the first error lines that appear:

openclaw logs --follow | rg -i "401|unauthor|error|openai|anthropic|openrouter|ollama|telegram"

Also paste what Telegram literally sends back (the exact text). That + /model status will make this obvious in 30 seconds.

swift void Feb 11, 2026, 9:27 PM

#

Current: ollama/nemotron-3-nano:30b-cloud
Default: ollama/nemotron-3-nano:30b-cloud
Agent: main
Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json

[ollama] endpoint: http://127.0.0.1:11434/v1 api: openai-completions auth: ollama-local (models.json: ~/.openclaw/agents/main/agent/models.json)
• ollama/nemotron-3-nano:30b-cloud

#

Current: ollama/nemotron-3-nano:30b-cloud
Default: ollama/nemotron-3-nano:30b-cloud
Agent: main
Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json

[ollama] endpoint: http://127.0.0.1:11434/v1 api: openai-completions auth: ollama-local (models.json: ~/.openclaw/agents/main/agent/models.json)
• ollama/nemotron-3-nano:30b-cloud @jolly stirrup

#

@jolly stirrup Current: ollama/nemotron-3-nano:30b-cloud
Default: ollama/nemotron-3-nano:30b-cloud
Agent: main
Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json

[ollama] endpoint: http://127.0.0.1:11434/v1 api: openai-completions auth: ollama-local (models.json: ~/.openclaw/agents/main/agent/models.json)
• ollama/nemotron-3-nano:30b-cloud

jolly stirrupBOT Feb 11, 2026, 9:30 PM

#

swift void Current: ollama/nemotron-3-nano:30b-cloud Default: ollama/nemotron-3-nano:30b-cl...

Good — that /model status proves OpenClaw is trying to use Ollama.

So if Telegram is still replying with “401 unauthorized”, the next most likely thing is:

Whatever is listening at http://127.0.0.1:11434 (from inside WSL) is NOT Ollama (or you’re hitting it through something that requires auth).

1) From Debian WSL, check what you get from the Ollama endpoints

Run these and paste the outputs (especially the HTTP status line):

curl -i http://127.0.0.1:11434/api/tags | head -20
curl -i http://127.0.0.1:11434/v1/models | head -20

Expected: HTTP/1.1 200 OK and some JSON.
If you see 401 here too → that’s the root cause (not Telegram).

#

2) See what process is actually bound to port 11434 (inside WSL)

ss -lntp | rg ":11434"

3) If Ollama is running on Windows (not inside WSL)

Often WSL can’t use 127.0.0.1 for Windows services on your setup. Use the Windows host IP:

WIN_IP=$(grep nameserver /etc/resolv.conf | awk '{print $2}' | head -1)
curl -i "http://$WIN_IP:11434/api/tags" | head -20

If that works, update OpenClaw to use it:

#

openclaw config set models.providers.ollama.baseUrl "http://$WIN_IP:11434/v1"
openclaw gateway restart

4) Quick sanity test (bypasses Telegram completely)

openclaw agent --agent main --message "Say hello in one sentence"

If that errors with 401 too, we know it’s 100% the Ollama endpoint/baseUrl.

Paste results from steps 1 + 4 and I’ll tell you exactly which baseUrl you need.

swift void Feb 11, 2026, 9:31 PM

#

ccnar@DESKTOP-BCT1NJ9:~$ curl -i http://127.0.0.1:11434/api/tags | head -20
curl -i http://127.0.0.1:11434/v1/models | head -20
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 456 100 456 0 0 21364 0 --:--:-- --:--:-- --:--:-- 21714
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Wed, 11 Feb 2026 21:31:10 GMT
Content-Length: 456

{"models":[{"name":"nemotron-3-nano:30b-cloud","model":"nemotron-3-nano:30b-cloud","remote_model":"nemotron-3-nano:30b","remote_host":"https://ollama.com:443","modified_at":"2026-02-11T19:50:07.165679992+03:00","size":418,"digest":"01d0d069a14966cea460e079f8aee18b0ff2766dc2283946075b671fb2a2321d","details":{"parent_model":"","format":"","family":"nemotron_h_moe","families":["nemotron_h_moe"],"parameter_size":"32000000000","quantization_level":"fp8"}}]} % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 121 100 121 0 0 49814 0 --:--:-- --:--:-- --:--:-- 60500
HTTP/1.1 200 OK
Content-Type: application/json
Date: Wed, 11 Feb 2026 21:31:10 GMT
Content-Length: 121

{"object":"list","data":[{"id":"nemotron-3-nano:30b-cloud","object":"model","created":1770828607,"owned_by":"library"}]}
ccnar@DESKTOP-BCT1NJ9:~$

#

@jolly stirrup ccnar@DESKTOP-BCT1NJ9:~$ curl -i http://127.0.0.1:11434/api/tags | head -20
curl -i http://127.0.0.1:11434/v1/models | head -20
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 456 100 456 0 0 21364 0 --:--:-- --:--:-- --:--:-- 21714
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Wed, 11 Feb 2026 21:31:10 GMT
Content-Length: 456

{"models":[{"name":"nemotron-3-nano:30b-cloud","model":"nemotron-3-nano:30b-cloud","remote_model":"nemotron-3-nano:30b","remote_host":"https://ollama.com:443","modified_at":"2026-02-11T19:50:07.165679992+03:00","size":418,"digest":"01d0d069a14966cea460e079f8aee18b0ff2766dc2283946075b671fb2a2321d","details":{"parent_model":"","format":"","family":"nemotron_h_moe","families":["nemotron_h_moe"],"parameter_size":"32000000000","quantization_level":"fp8"}}]} % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 121 100 121 0 0 49814 0 --:--:-- --:--:-- --:--:-- 60500
HTTP/1.1 200 OK
Content-Type: application/json
Date: Wed, 11 Feb 2026 21:31:10 GMT
Content-Length: 121

{"object":"list","data":[{"id":"nemotron-3-nano:30b-cloud","object":"model","created":1770828607,"owned_by":"library"}]}
ccnar@DESKTOP-BCT1NJ9:~$

jolly stirrupBOT Feb 11, 2026, 9:35 PM

#

swift void <@1457407575476801641> ccnar@DESKTOP-BCT1NJ9:~$ curl -i http://127.0.0.1:11434/...

Yep, that output explains it.

Your Ollama response shows:

remote_host":"https://ollama.com:443"
remote_model":"nemotron-3-nano:30b"
size":418

A real local 30B model would be many GB, not 418 bytes. So nemotron-3-nano:30b-cloud is a Cloud-backed stub, and when OpenClaw tries to actually generate text, Ollama Cloud is likely returning the 401 Unauthorized you see in Telegram.

Fix (actually run local)

Pull the local variant (no -cloud) on the machine where Ollama runs:

ollama pull nemotron-3-nano:30b
# (or: ollama pull llama3.3  # smaller/easier to run)

#

Switch OpenClaw to the local model id:

openclaw config set agents.defaults.model.primary "ollama/nemotron-3-nano:30b"
openclaw gateway restart

Sanity check in WSL:

curl -s http://127.0.0.1:11434/api/tags | head

You should now see a model with a huge size (GBs), not 418.

If you want to use the `-cloud` model anyway

Then you need to authenticate for Ollama Cloud (i.e., use a real Ollama API key / login), because "ollama-local" won’t cut it for cloud-backed runs.

Before changing anything, run this to confirm the 401 is coming from generation:

#

curl -i http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ollama-local" \
  -d '{"model":"nemotron-3-nano:30b-cloud","messages":[{"role":"user","content":"hi"}],"stream":false}' | head -40

Paste what that returns (especially the HTTP status + JSON error), and I’ll tell you exactly which path you’re on (local too-big vs cloud-auth missing).

swift void Feb 11, 2026, 9:36 PM

#

@jolly stirrup i remembered i havent authed this ollama instance

#

@jolly stirrup ok its wokring now

jolly stirrupBOT Feb 11, 2026, 9:37 PM

#

swift void <@1457407575476801641> i remembered i havent authed this ollama instance

Yep — for *-cloud models, Ollama needs to be signed in.

Per Ollama’s auth docs, local Ollama (http://localhost:11434) normally needs no auth, except when it has to call ollama.com to run a cloud model. Then you must sign in once.

Fix

On the machine where the Ollama daemon is running (Windows Ollama app or Linux Ollama in WSL), run:

ollama signin

Follow the browser prompt/login, then test:

ollama run nemotron-3-nano:30b-cloud "hi"

#

(or if you don’t have the CLI in that environment, just re-try your Telegram bot after signing in)

After that

You shouldn’t need to change your OpenClaw config — it will keep calling http://127.0.0.1:11434/v1, and Ollama will now be able to authenticate its cloud calls internally.

If you tell me whether Ollama is running in Windows vs WSL, I’ll tell you exactly where to run ollama signin.

swift void Feb 11, 2026, 9:39 PM

#

@jolly stirrup so its working now but when i say use sag to say merhaba and send it as mp3 it trys to make a {
"status": "forbidden",
"error": "agentId is not allowed for sessions_spawn (allowed: none)"
} this

#

@jolly stirrup every time i try to do something with the config in openclaw when i try to save it gaves error invalid config every time

#

@jolly stirrup help me every time i try to do something with the config in openclaw when i try to save it gaves error invalid config every time

#

@jolly stirrup add discord to my channels },
"plugins": {
"entries": {
"telegram": {
"enabled": true
},
"discord": {
"enabled": true
}

#I can't get ollama qwen2.5:14b to work local on my computer.

1) First: what “doesn’t work” exactly?

2) Make sure OpenClaw is actually “seeing” Ollama

3) The big one: auto-discovery filters out models without tool support

4) Sanity-check Ollama is reachable from where the Gateway runs

A) Easiest (auto-discovery) — only works if the model reports tool support

B) Force it (manual model entry) — works even if the model doesn’t report tools

If it still won’t connect

Option A (simplest): remove the explicit provider block (go back to auto-detect)

Option B: define the missing array (this fixes the validation immediately)

Fix 1 (recommended): go back to auto-detection

Fix 2: keep explicit provider + define the model array

Fastest fix (add an empty array so config becomes valid)

Better: set the whole ollama provider in one shot (avoids partial/invalid config)

If you’re in a terminal

If you’re using Discord /config

If you don’t actually want “explicit provider mode”

0) Confirm WSL can reach Ollama

1) Fix the config validation loop (make ollama provider valid)

If 127.0.0.1 worked:

If only $WIN_IP worked:

2) Verify OpenClaw sees it

If it still “doesn’t answer”

1) If the 401 is in your browser (Dashboard / Control UI)

2) If the 401 is in the terminal (CLI commands like openclaw status, openclaw models list, etc.)

1) In the Telegram chat, run:

2) Tail logs and reproduce once (this will reveal who returns 401)

Quick fix if it’s using the wrong model

1) In Telegram, run this and paste the result

2) Force Telegram to use your local Ollama model (from Debian WSL terminal)

3) Get the actual 401 line from logs

1) From Debian WSL, check what you get from the Ollama endpoints

2) See what process is actually bound to port 11434 (inside WSL)

3) If Ollama is running on Windows (not inside WSL)

4) Quick sanity test (bypasses Telegram completely)

Fix (actually run local)

If you want to use the -cloud model anyway

Fix

After that

If you’re using Discord `/config`

If `127.0.0.1` worked:

If only `$WIN_IP` worked:

2) If the 401 is in the terminal (CLI commands like `openclaw status`, `openclaw models list`, etc.)

If you want to use the `-cloud` model anyway