#I ran out of OpenAI API tokens, how to switch to my OAUTH ChatGPT subscription??

75 messages · Page 1 of 1 (latest)

sly acorn
#

I ran out of OpenAI API tokens, how to switch to my OAUTH ChatGPT subscription??

rigid shoreBOT
#

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

nova voidBOT
wicked mantleBOT
#

Yep, but the key gotcha is this:

ChatGPT/OAuth != openai/*
Your ChatGPT subscription only works through the openai-codex/* route in OpenClaw, not the direct OpenAI API route.

Quickest fix:

openclaw models auth login --provider openai-codex --set-default

Or run:

openclaw configure
#

and choose OpenAI Code (Codex) subscription (OAuth).

Then check:

openclaw models status

If you're already in a chat/session, switch that session to an openai-codex/* model via /model.

If you're headless/remote, the OAuth flow can also let you paste the redirect URL/code manually.

Docs:

#

If you get stuck, paste:

openclaw --version
openclaw models status

and I can help you from there.

sly acorn
#

I really like the current model I am using OpenAI via API key (GPT 5.4) there is any free model that I can run without care about the tokens that is very similar to that model?? that it would feel mostly the same?

wicked mantleBOT
#

Honestly, not really.

If by free you mean “feels basically like the same top OpenAI API experience”, I wouldn’t promise that. The tradeoff is usually pretty noticeable.

My blunt take:

  • Closest without extra API spend: use your ChatGPT/Codex OAuth path in OpenClaw (openai-codex/*)
  • Free hosted models: usually feel worse or less reliable
  • Local models: can be okay, but “mostly the same” usually means serious hardware, not a normal laptop

So if you already pay for ChatGPT, that’s probably the best next move instead of chasing a “free equivalent”.

For current real-world alternatives, ask in #models because that changes fast and I don’t want to give you stale model recommendations.

Docs:

sly acorn
#

I have 64GB RAM and good computer

wicked mantleBOT
#

64GB RAM is nice, but for local models the bigger question is GPU/VRAM, not just system RAM.

So:

  • 64GB RAM + no strong GPU: probably no, it won’t feel close
  • 64GB RAM + a beefy GPU: usable for some local setups, but still not really “same as GPT-5.4”
  • For agentic/tool-heavy OpenClaw use, cloud still tends to feel a lot better

So I’d still recommend:

  1. Use your ChatGPT/Codex OAuth if you want the closest feel without burning API credits
  2. Only go local if you specifically want privacy/offline/hobby tinkering

If you want, send your GPU model and I can tell you pretty quickly whether local is realistic or not.

sly acorn
#

I have an AMD Ryzen 7 5800X and a NVIDIA GeForce RTX 3060

wicked mantleBOT
#

With a 5800X + RTX 3060, I’d say:

  • Good enough to try local stuff
  • Not enough to get “basically GPT-5.4”
  • For OpenClaw-style agent/tool workflows, it’ll usually feel slower and less reliable than the cloud options

Small nuance:

  • If your 3060 is the common 12GB desktop version, that’s decent for local experimentation
  • If it’s a 6GB laptop/mobile variant, it’s a lot tighter

So my honest recommendation is:

  • Use ChatGPT/Codex OAuth for the closest experience right now
  • Treat local models as a separate “cheap/private/good-enough” path, not a same-feeling replacement

If you want the best current local suggestions for that exact GPU, ask in #models since those recommendations move fast and I don’t want to feed you stale picks.

sly acorn
#

I know it won't be exactly the same, but I already used all my OpenAI tokens, and now I am using almost all my codex tokens, so I will need a free alternative

wicked mantleBOT
#

Yeah, in that case the honest answer is:

If you need truly free and don’t want to care about tokens, go local.

On your hardware, that means something like Ollama is the realistic path. It won’t feel the same, but it can be good enough for a lot of day-to-day stuff.

What I’d expect on your setup:

  • Fine for local experimentation and lighter coding/chat
  • Noticeably worse than top cloud models for hard reasoning
  • More brittle with tool calling / long agent loops sometimes

So I’d do one of these:

  1. Best zero-ongoing-cost path: switch OpenClaw to Ollama
    • openclaw onboard and choose Ollama
    • or openclaw configure and switch the model/provider there
sly acorn
#

my openclaw is running in WSL should I install ollama in the same WSL and just switch model?

wicked mantleBOT
#

Yeah, that’s the simplest path.

If OpenClaw is running in WSL, I’d generally recommend:

  • Install Ollama in the same WSL distro
  • then switch OpenClaw to Ollama
  • let OpenClaw talk to the default local Ollama URL: http://127.0.0.1:11434

Why: fewer Windows/WSL networking weirdnesses.

Two important notes:

  • Use the native Ollama URL, not /v1
  • If you keep Ollama on Windows instead of WSL, OpenClaw in WSL needs a custom base URL that is reachable from WSL, not just Windows localhost

Easiest setup flow:

# 
openclaw onboard

Choose Ollama, then Local.

Quick checks after:

ollama list
openclaw models list --provider ollama

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

If you want, I can give you the exact WSL-first setup steps next.

sly acorn
#

[14/04/2026 18:05] Adrian H.: your subagent called "marketing" ?????
[14/04/2026 18:06] Director: I don’t have a built-in subagent literally named marketing.

In this environment, spawned delegates need an explicit configured agentId, and the spawn failed because that id wasn’t provided.

So right now:

• I can delegate
• but I need the exact allowed agentId
• and I don’t have a tool here that lists those ids

If you already know the agent id for your marketing delegate, send it and I’ll use it.
Otherwise, I can just do the marketing work directly here without waiting.

{
"agents": {
"defaults": {
"workspace": "/home/bc/.openclaw/workspace",
"models": {
"openai-codex/gpt-5.4": {}
},
"model": {
"primary": "openai-codex/gpt-5.4"
},
"subagents": {
"requireAgentId": true,
"allowAgents": [
"reverser",
"lowcode",
"marketing"
],
"maxSpawnDepth": 1,
"maxConcurrent": 3,
"runTimeoutSeconds": 900,
"archiveAfterMinutes": 60
}
},
"list": [
{
"id": "main",
"subagents": {
"allowAgents": [
"reverser",
"lowcode",
"marketing"
]
}
},
{
"id": "reverser",
"name": "reverser",
"workspace": "/home/bc/.openclaw/workspace-reverser",
"agentDir": "/home/bc/.openclaw/agents/reverser/agent"
},
{
"id": "lowcode",
"name": "lowcode",
"workspace": "/home/bc/.openclaw/workspace-lowcode",
"agentDir": "/home/bc/.openclaw/agents/lowcode/agent"
},
{
"id": "marketing",
"name": "marketing",
"workspace": "/home/bc/.openclaw/workspace-marketing",
"agentDir": "/home/bc/.openclaw/agents/marketing/agent"
}
]
}

wicked mantleBOT
#

Yep, the config you pasted already shows the answer.

Because you have:

  • requireAgentId: true
  • allowAgents: ["reverser", "lowcode", "marketing"]

the spawn must include an explicit agentId, and marketing is valid.

So the issue was probably just:

  • spawn called without agentId
  • not that marketing doesn’t exist

Correct patterns are:

  • slash command: /subagents spawn marketing <task>
  • tool/API: sessions_spawn with agentId: "marketing"
#

Also, OpenClaw does have discovery for this, docs say to use agents_list for allowed ids.

Docs: https://docs.openclaw.ai/tools/subagents

So short version: yes, marketing is the right id. The previous assistant just missed that.

sly acorn
#

so I can't just ask my director to ask his subagent to make a meeting and talk about something??? I have to /subagents spawn marketing taskname first??

wicked mantleBOT
#

You can ask naturally, but there’s an important difference:

  • Natural ask: “Director, have marketing handle this”
    • may work if the agent decides to delegate and passes agentId: "marketing" correctly
  • Explicit command: /subagents spawn marketing <task>
    • this is the reliable way, because it forces the target agent id

Since your setup has requireAgentId: true, the agent cannot do a vague spawn. It has to name the subagent explicitly.

So the practical answer is:

  • Yes, you can ask in plain English
  • but if you want to be sure it happens, use /subagents spawn marketing ...

If you want, I can show you the cleanest phrasing for:

  1. a normal delegation ask, and
  2. the explicit /subagents spawn version.
sly acorn
#

something is weird, I told him:

please meet up with lowcode and reverser, talk about a project plan we need to build a solid bot, we already got an important part which is the injection and the protocol, but we need to start building features to use but first we need to finish the core

after the meeting, just start working, notify to me any progress but don't keep asking for confirmation if it's not required, I want to start getting results

I got this reply:

I hit an OpenClaw limitation on named subagents here, so I’m doing the “internal meeting” myself by reviewing the code and notes from both angles, then I’ll move straight into implementation.

not sure if it's a problem with codex, or what happens

wicked mantleBOT
#

I don’t think this is “Codex being broken”.

What’s more likely is one of these:

  1. Plain-English delegation is non-deterministic
    The agent understood your request, but instead of actually spawning lowcode + reverser, it chose the fallback path and did the work itself.

  2. There isn’t a literal built-in “subagents meet in a room” primitive
    The normal pattern is:

    • spawn lowcode
    • spawn reverser
    • main/orchestrator agent combines the results

  3. If “Director” is itself already a subagent, then maxSpawnDepth: 1 matters
    With maxSpawnDepth: 1, a subagent cannot spawn more children. That would be a real limitation.

So the safest interpretation is: this was a delegation/orchestration issue, not specifically a Codex issue.

#

If you want it to happen reliably, be explicit, for example:

  • /subagents spawn lowcode draft the implementation plan for X
  • /subagents spawn reverser review the protocol/injection/core risks for X

Then ask the main agent to merge the outputs and continue.

So yes, “please have them meet” is nice human phrasing, but today the more reliable OpenClaw pattern is explicit spawn + synthesize, not a magical free-form subagent meeting.

sly acorn
#

i've installed ollama but how do I run a model inside Ollama so OpenClaw can connect?

wicked mantleBOT
#

Yep, the key thing is:

OpenClaw connects to the Ollama server, not to an ollama run terminal window.

So the usual flow is:

ollama serve
ollama pull <model-name>
ollama list

Optional quick test:

ollama run <model-name>
#

But you do not need to keep ollama run open for OpenClaw.
As long as:

  • ollama serve is running
  • at least one model is pulled
  • OpenClaw is pointed at Ollama

then OpenClaw can use it.

After that, verify from OpenClaw:

openclaw models list --provider ollama

If you haven’t switched yet, easiest is:

# 
openclaw onboard

then choose Ollama → Local.

Also, use the native Ollama URL, not /v1.

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

If you want, I can give you the exact WSL commands step-by-step next.

sly acorn
#

bc@pc:~/.openclaw/workspace/tibia/parser$ ollama list
NAME ID SIZE MODIFIED
qwen3.5:latest 6488c96fa5fa 6.6 GB 37 minutes ago
bc@pc:~/.openclaw/workspace/tibia/parser$ openclaw models list --provider ollama

🦞 OpenClaw 2026.4.12 (1c0672b) — The lobster in your shell. 🦞

No models found.
bc@pc:~/.openclaw/workspace/tibia/parser$

wicked mantleBOT
#

Nice, that means Ollama itself is fine, and the problem is on the OpenClaw side.

The most likely issue is that OpenClaw does not see Ollama as enabled yet.

Try this in the same shell:

export OLLAMA_API_KEY="ollama-local"
curl http://localhost:11434/api/tags
openclaw models list

Two important gotchas from the docs:

  1. OLLAMA_API_KEY must be set (or an auth profile must exist) for auto-discovery
  2. If you explicitly defined models.providers.ollama in config, auto-discovery is skipped unless you manually define models there
#

So also check:

openclaw config get models.providers.ollama

If that returns a custom ollama provider block, that may be why discovery is not happening.

So the quick path is:

  • set OLLAMA_API_KEY="ollama-local"
  • make sure curl http://localhost:11434/api/tags works
  • avoid a custom models.providers.ollama block unless you want to define models manually

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

If you paste the output of:

# 
echo $OLLAMA_API_KEY
curl http://localhost:11434/api/tags
openclaw config get models.providers.ollama

I can tell you exactly which piece is blocking it.

sly acorn
#

bc@pc:~/.openclaw/workspace/tibia/parser$ export OLLAMA_API_KEY="ollama-local"
bc@pc:~/.openclaw/workspace/tibia/parser$ curl http://localhost:11434/api/tags
{"models":[{"name":"qwen3.5:latest","model":"qwen3.5:latest","modified_at":"2026-04-14T19:52:31.01227394+02:00","size":6594474711,"digest":"6488c96fa5faab64bb65cbd30d4289e20e6130ef535a93ef9a49f42eda893ea7","details":{"parent_model":"","format":"gguf","family":"qwen35","families":["qwen35"],"parameter_size":"9.7B","quantization_level":"Q4_K_M"}}]}bc@pc:~/.openclaw/workspace/tibia/parser$ openclaw models list

🦞 OpenClaw 2026.4.12 (1c0672b) — I can't fix your code taste, but I can fix your build and your backlog.

Model Input Ctx Local Auth Tags
openai-codex/gpt-5.4 text+image 1025k no yes default,configured
bc@pc:~/.openclaw/workspace/tibia/parser$ openclaw config get models.providers.ollama

🦞 OpenClaw 2026.4.12 (1c0672b) — I can't fix your code taste, but I can fix your build and your backlog.

Config path not found: models.providers.ollama
bc@pc:~/.openclaw/workspace/tibia/parser$

wicked mantleBOT
#

Thanks, this is actually really helpful.

From that output:

  • Ollama is running
  • OpenClaw can reach Ollama (curl works)
  • OLLAMA_API_KEY is set
  • there is no explicit models.providers.ollama block

So in theory, discovery should work. Since it doesn’t, this smells like either:

  1. a 2026.4.12 discovery quirk/bug, or
  2. you’re relying on shell env for something that really needs to be written through OpenClaw’s setup flow

Best next move

I’d stop fighting implicit discovery and do the supported setup path:

# 
openclaw configure

Go to the Model section and pick Ollama, or rerun:

openclaw onboard

and choose Ollama → Local.

That usually wires it up properly instead of depending on ad-hoc env detection.

One more important WSL/service gotcha

If your Gateway is running as a daemon/service, a shell export does not automatically reach it.
So even if the current shell sees OLLAMA_API_KEY, the actual running Gateway may not.

#

If you want one more diagnostic first

Run:

openclaw models status --plain

If you paste that, I can tell whether OpenClaw is seeing ollama auth but no catalog, or not seeing ollama at all.

Docs:

If this ends up being fixed by configure/onboard, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

sly acorn
#

I go through this selection:
│ Model
│
â—‡ Model/auth provider
│ Ollama
│
â—‡ Ollama base URL
│ http://127.0.0.1:11434
│
â—‡ Ollama mode
│ Local

then it shows me a big list of models and tells me to select a model, but I can't find the model that I already have installed (qwen3.5:latest)

#

it's because of WSL?? I think it's running as a daemon

sly acorn
#

i've restarted the machine but still same problem

I go through this selection:
│ Model
│
â—‡ Model/auth provider
│ Ollama
│
â—‡ Ollama base URL
│ http://127.0.0.1:11434/
│
â—‡ Ollama mode
│ Local

then it shows me a big list of models and tells me to select a model, but I can't find the model that I already have installed (qwen3.5:latest)
it's because of WSL?? I think it's running as a daemon

wicked mantleBOT
#

I don’t think WSL by itself is the problem.

I think the more likely issue is the daemon/service context.

Why I’m suspicious:

  • in your shell, ollama list and curl http://localhost:11434/api/tags work
  • but OpenClaw setup is not showing your actual installed tag
  • that usually means the setup flow is not seeing the same local Ollama context, so it falls back to a generic catalog/list

With WSL, 127.0.0.1 only means “this exact environment”. If OpenClaw is running as a daemon/service, that can behave differently from your interactive shell.

I’d test it like this

openclaw gateway status
openclaw gateway stop
#

Then, in the same WSL shell where ollama list works, run:

openclaw configure

Choose Ollama → Local again.

If qwen3.5:latest suddenly appears, then yeah, it was the daemon context, not Ollama itself.

If it still does not appear even with the daemon stopped

Then I’d call it a 2026.4.12 bug/quirk, because your local Ollama catalog is clearly there.

At that point I’d also check:

sly acorn
#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-14.log
Command: /usr/bin/node /home/bc/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 93188, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

when running openclaw configure, it asks for ollama base url and points by default at 127.0.0.1:11434 maybe ollama daemon doesn't listen there??

i'm inside "models" in the configure, not inside "daemon" i didn't even check what is daemon

wicked mantleBOT
#

Yep, in your case “daemon” just means the OpenClaw Gateway is running as a background systemd service. It’s not a separate thing inside the Model menu.

And based on your earlier curl, http://127.0.0.1:11434 is probably the correct Ollama URL. So I would not change that yet.

What I think is happening:

  • OpenClaw gateway is daemonized
  • Ollama/model discovery in the picker is being weird
  • the picker may be showing a fallback/generic catalog instead of your exact installed local tag

A couple of practical things:

  1. In the picker, try searching for:

    • qwen3.5
    • not just qwen3.5:latest

  2. Check whether Ollama is actually listening in WSL right now:

# 
ss -ltnp | grep 11434
ps aux | grep ollama

If that listener is there, then the base URL is fine and this is more likely a picker/discovery quirk than a network problem.

So short version:

  • No, I would not blame WSL first
  • No, I would not change the base URL yet
  • Yes, the “daemon” here is just your background OpenClaw service
  • Most likely this is the Ollama model picker not surfacing your local tag correctly

If you paste the output of:

# 
ss -ltnp | grep 11434
ps aux | grep ollama

I can tell you pretty quickly whether this is a listener issue or just the picker being dumb.

sly acorn
#

bc@pc:/mnt/c/Users/BC$ ss -ltnp | grep 11434
LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:*
bc@pc:/mnt/c/Users/BC$ ps aux | grep ollama
ollama 64509 1.0 0.2 2894696 86916 ? Ssl 18:10 2:05 /usr/local/bin/ollama serve
bc 111425 0.0 0.0 4092 1936 pts/2 S+ 21:29 0:00 grep --color=auto ollama

wicked mantleBOT
#

Perfect, that narrows it down a lot.

That output means:

  • Ollama is running
  • it is listening on 127.0.0.1:11434
  • so this is not really a WSL networking problem

At this point I’d treat it as a model-picker/catalog quirk.

Best workaround

The docs say onboarding/configure can also let you enter the model manually.

So instead of hunting in the big list, use the manual model entry path and set:

# 
ollama/qwen3.5:latest

or if it wants just the raw model id:

qwen3.5:latest

Why I’m confident now

Your listener check proves the base URL is right, so the weird part is just the picker not surfacing your installed tag properly.

If the wizard still fights you, the next thing I’d try is:

sly acorn
#

okai I think it's connected now, how I change the model in the same chat I ran out of tokens?

wicked mantleBOT
#

Yep, for this same chat/session, use:

/model

On Discord that should open the model picker.
Or set it directly with:

/model ollama/qwen3.5:latest

A couple of useful notes:

  • /model is session-scoped, so it changes this chat, not every chat
  • if the agent is idle, it switches right away
#
  • if a reply/run is already in progress, the switch may apply on the next turn

If you want to confirm what this chat is using after the switch:

/model status

Docs: https://docs.openclaw.ai/tools/slash-commands#model-selection-model

If that works, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

sly acorn
#

Current model: gpt-5.4 via openai-codex

Model set to ollama/qwen3.5:latest.

Failed to set model: RpcError: model not allowed: ollama/status

wicked mantleBOT
#

Ah, that looks like a model allowlist problem, not an Ollama connection problem.

The important clue is this part from the docs:

  • agents.defaults.models controls what shows up in /model and what is allowed

So your config probably still only allows the Codex model, and the Ollama one is not in the allowlist yet.

Fix

Run:

openclaw configure --section model

Then in the Model section, make sure your Ollama model is included in the allowlist too, not just the Codex one.

#

If you want to check first:

openclaw config get agents.defaults.models

If that only shows the Codex entry, that’s the problem.

Then try again in the same chat

/model ollama/qwen3.5:latest

The weird ollama/status bit is probably just /model status getting parsed while the model allowlist is still locked down, but the root issue is the allowlist.

Docs:

sly acorn
#

i am not sure if its working the agent stays thinking, but I don't get any results or reply

wicked mantleBOT
#

Yeah, that can happen with local/Ollama models, especially in a long existing thread with lots of prior context and tools.

I’d test it in this order:

  1. Check the current session model
/model status
  1. Start a fresh session on the Ollama model
/new ollama/qwen3.5:latest
  1. In that fresh chat, send something tiny like:
# 
reply with exactly: hello

Why

A smaller local model might be fine on a tiny prompt, but choke on:

  • a long old thread
  • tool-heavy agent prompts
  • session context carried over from the OpenAI/Codex run

So if the fresh session works, the issue is probably old session context, not connectivity.

If it still hangs even in a fresh session

Then check logs:

# 
openclaw logs --follow

and paste the first relevant error lines.

Bluntly, local/Ollama models are often way less reliable at tool-calling than the cloud ones, so “thinking forever” is a pretty common failure mode.

Docs:

If you try /new ollama/qwen3.5:latest and a tiny prompt, tell me whether that works. That’s the fastest way to separate model works from agent loop is choking.

sly acorn
#

19:49:08+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=128513 error="FailoverError: LLM request timed out."
19:49:08+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:session-1776196010585 durationMs=128515 error="FailoverError: LLM request timed out."

19:49:23+00:00 error Embedded agent failed before reply: All models failed (2): ollama/qwen3.5:latest: LLM request timed out. (timeout) | openai-codex/gpt-5.4: ⚠️ You have hit your ChatGPT usage limit (plus plan). Try again in ~45 min. (rate_limit) | ⚠️ You have hit your ChatGPT usage limit (plus plan). Try again in ~45 min.

wicked mantleBOT
#

Nice, the logs make it clear now.

This is the real issue:

  • Ollama did get selected
  • but ollama/qwen3.5:latest timed out
  • then OpenClaw fell back to Codex
  • Codex is rate-limited
  • so the whole run dies with no reply

So this is not a connection problem anymore. It’s a slow local-model timeout problem.

Why

OpenClaw’s LLM idle timeout is 120s by default.
Your local model didn’t produce enough output before that, so OpenClaw killed it.

Docs: https://docs.openclaw.ai/concepts/agent-loop#timeouts

#

Best fixes

Option 1, easiest: raise the idle timeout

openclaw config set agents.defaults.llm.idleTimeoutSeconds 300
openclaw gateway restart

If you want to be more aggressive:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 0
openclaw gateway restart

0 disables the idle timeout, but I’d try 300 first so it doesn’t hang forever.

#

Option 2: use a fresh short chat for the local model
Long old threads are brutal for smaller local models.

Option 3: pick a smaller/faster Ollama model for agent use
Your current one may just be too slow for full OpenClaw agent prompts on your machine.

So I’d do this next:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 300
openclaw gateway restart

then test in a new session with a tiny prompt.

If that works, you found it.
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

sly acorn
#

it did reply "hello" but it took ages

wicked mantleBOT
#

Yep, that means it’s working, but honestly, too slowly to feel good.

That’s the important distinction:

  • timeout fixed = it can answer
  • speed is still bad = this model is probably too heavy for comfortable OpenClaw agent use on your setup

And OpenClaw is harder than plain chat because it adds:

  • a bigger system prompt
  • tools
  • session history
  • agent loop overhead

So if “hello” took ages, real tasks will feel rough.

My honest recommendation

#

Use this local model only for:

  • short fresh chats
  • simple prompts
  • emergency fallback when cloud quota is dead

If you want local to feel less painful, do one of these:

  1. Use a smaller/faster Ollama model
  2. Keep local sessions fresh and short
  3. Avoid long old threads for local models
  4. Treat local as backup, not your main agent brain

So yeah, I’m glad we got it working, but I wouldn’t pretend this is a great day-to-day setup on that model/hardware combo.

If you want, the next step is either:

  • pick a faster local model, or
  • keep using Codex/OpenAI when quota resets and keep Ollama as fallback.
sly acorn
#

I think I should switch to deepseek-coder:6.7b

how can I do it now that we know that it works but slow??

wicked mantleBOT
#

Yep, that’s the right kind of move, go smaller/faster.

Do it like this:

  1. Pull it into Ollama:
ollama pull deepseek-coder:6.7b
ollama list
  1. If your model allowlist is strict, add it in:
openclaw configure --section model

and include the new Ollama model in the allowlist.

  1. Switch the current chat:
# 
/model ollama/deepseek-coder:6.7b

My real recommendation

Even better, test it in a fresh session instead of this long thread:

/new ollama/deepseek-coder:6.7b

Then send a tiny prompt first.

Why: even a faster local model can still feel worse inside a long old agent thread.

So short version: