Mix and match two machines | Friends of the Crustacean 🦞🤝 | Page 1

next dock Mar 4, 2026, 4:03 PM

#

I have 2 machines one with a RTX2070 and one witha rtx5080, nice right, well the thing is I want to use the 5080 for heavy tasks/delegate it/turn on when needed(can be via WoL or not) and the rtx2070 machine is where openclaw is installed on, Debain 13 in Proxmox with gpu passthrough btw.
How do I make it switch/ask itself? Was trying qwen3 on 2070 and thats too slow qwen 3.5 on the 5080 is quite okay.

Also I want it to have full access to everything, basically when I tell it to install something itll do that and stuff.

I am quite new to this, ot to IT or Linux itself 🙂

white jewelBOT Mar 4, 2026, 4:03 PM

#

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

zenith basinBOT Mar 4, 2026, 4:06 PM

#

You’re basically trying to solve two separate problems:

Where the model inference runs (Qwen3/3.5 speed → your 5080 box)
Where the tools/commands run (“install stuff”, heavy builds, etc. → maybe also the 5080 box)

OpenClaw can do both, but they’re configured differently.

1) Put the LLM on the 5080 machine (fast Qwen there)

Run a model server on the 5080 box (most people use Ollama or vLLM), then point OpenClaw (running on the 2070 VM) at that server over your LAN.

If you use Ollama (recommended for “it just works”)

Important detail from the docs: for remote Ollama you should use the native Ollama API (http://host:11434), not the OpenAI-compat /v1 URL, or tool-calling gets flaky.

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

#

Then configure a provider entry on the gateway like:

models.providers.ollama.baseUrl: "http://<5080-ip>:11434"
models.providers.ollama.api: "ollama"
and set your primary model to ollama/<your-qwen-model-tag>

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

“Switch/ask itself” part

OpenClaw doesn’t automatically decide “this is heavy, switch to GPU box now” (no built-in smart router like that yet).

What you can do instead:

Manual switching per chat: use /model to switch when you want heavy mode.
Fallbacks: set 5080 model as primary, and a smaller/faster/cheap model as fallback.
- If the 5080 machine is off, the request will fail and it can fall back automatically.
- But it still won’t wake the 5080 box by itself (more on that below).

#

2) Run “heavy commands” on the 5080 box too (delegate builds/installs)

This is where Nodes come in.

You can run a headless node host on the 5080 machine, pair it to your gateway, and then tell OpenClaw to run exec on that node.

Docs: https://docs.openclaw.ai/nodes (see “Remote node host (system.run)”)

High level flow:

On the 5080 machine: run openclaw node run ... to connect it to the gateway
On the gateway: approve the pairing (openclaw devices approve ...)
Then set tools.exec.host=node (and pick that node)

That way:

#

the model can still run wherever you want (local/cloud/5080),
but the commands (compiling, installing packages, running scripts) can execute on the 5080 machine.

3) “Turn on 5080 machine when needed” (WoL)

OpenClaw won’t auto-WoL a machine on model failure out-of-the-box.

Typical setup is:

enable WoL in BIOS/NIC on the 5080 machine
install a WoL command on the gateway host
then you manually say something like “wake the 5080 box” and let the agent run the WoL command (if you allow exec)

If you want this fully automated, that becomes a custom workflow (script/skill + retry logic).

#

4) “Full access to everything / install stuff”

You can do that, but it’s the #1 way people accidentally let an agent nuke their box.

What I recommend instead:

Keep exec enabled, but keep approvals on (at least while you’re new)
Only enable “no-approval” mode when you’re confident

Elevated mode docs (this is the “skip approvals” mechanism): https://docs.openclaw.ai/tools/elevated

If you tell me what channel you’re using OpenClaw from (Discord DM vs server channel) I can suggest a safer policy—because in public channels, “full access” is extra dangerous.

Quick questions so I can point you to the exact config shape

What are you using to run Qwen on the 5080 machine: Ollama, vLLM, LM Studio, something else?
Is your 5080 machine Linux or Windows?

#

Are you talking to OpenClaw via Discord DMs or in a server channel?
What does openclaw --version show on the 2070 VM?

With those, I can give you a minimal “working” config approach (primary/fallback + node exec) without guessing.

next dock Mar 4, 2026, 4:40 PM

#

the channel i use it on is web, i jsut go to localip:18789

What are you using to run Qwen on the 5080 machine: Ollama, vLLM, LM Studio, something else? ollama, but im more then fine to switch to anything else if its ebtter/faster!
Is your 5080 machine Linux or Windows? windows, openclaw debian
Are you talking to OpenClaw via Discord DMs or in a server channel? web channel? i just open the web
What does openclaw --version show on the 2070 VM? 2026.3.2 but keep in mind that the box where the rtx 2070 is on has ollama but it just isnt showing up/doensnt have models/idk how to switch it

zenith basinBOT Mar 4, 2026, 4:44 PM

#

Cool, that narrows it down a lot.

You’ve got:

Gateway/OpenClaw running on Debian VM (RTX 2070 passthrough)
Ollama running on Windows (RTX 5080)
You use the web UI at http://<vm-ip>:18789

There are two separate “why isn’t Ollama showing up?” causes that bite people:

OpenClaw only auto-discovers local Ollama on 127.0.0.1:11434 (inside the Debian VM), and only when Ollama is enabled.
Auto-discovery filters to tool-capable models. If your Ollama models don’t advertise tool support, OpenClaw may show “nothing”, even though ollama list shows models.

So: for a setup like yours (remote Windows Ollama), you almost always want explicit provider config.

#

A) Make Windows Ollama reachable from the Debian VM

By default Ollama on Windows often binds to localhost only, so the VM can’t reach it.

On the Windows 5080 machine:

Ensure Ollama is listening on the LAN (not just 127.0.0.1)
Allow port 11434 through Windows firewall

Ollama supports this via OLLAMA_HOST (common setting is 0.0.0.0:11434).

Then from the Debian VM, verify it’s reachable:

curl http://<windows-ip>:11434/api/tags

If that fails, don’t touch OpenClaw config yet—fix network/bind/firewall first.

#

Docs note (important): for OpenClaw + remote Ollama use the native URL like http://host:11434 (no /v1).
https://docs.openclaw.ai/providers/ollama

B) Add a remote Ollama provider for the 5080 box (explicit config)

In ~/.openclaw/openclaw.json on the Debian VM, add a custom provider (name can be anything; I’ll call it ollama5080):

{
  models: {
    providers: {
      ollama5080: {
        baseUrl: "http://<windows-ip>:11434",
        api: "ollama",
        apiKey: "ollama-local", // any string is fine; Ollama doesn’t really auth by default

#

        models: [
          { id: "qwen3.5:whatever-tag", name: "Qwen 3.5 (5080)" }
        ]
      }
    }
  },

  agents: {
    defaults: {
      model: {
        primary: "ollama5080/qwen3.5:whatever-tag",
        // optional fallback if 5080 is off:
        fallbacks: ["ollama/qwen3:whatever-tag"]
      }
    }

#

}
}

Then restart the gateway.

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

Switching in the web UI

In the web chat, try:

/model list
/model status
/model ollama5080/<your-model-id>

(Yes, /model … works outside Discord too.)

#

C) Why your local 2070 Ollama “isn’t showing up”

On the Debian VM, run:

ollama list
curl http://127.0.0.1:11434/api/tags
openclaw models list
openclaw models status

If ollama list shows models but openclaw models list shows none, the usual reason is: auto-discovery only includes tool-capable models.

Fix options:

Pull a model that Ollama reports as tool-capable (best experience), or

#

Define a local provider explicitly too (so OpenClaw will list it even if it doesn’t advertise tools), but then tool-usage may be limited/flaky depending on the model.

D) “Make it switch / ask itself” + “turn on 5080 when needed”

Out of the box:

OpenClaw can fallback automatically if the 5080 endpoint is down.
OpenClaw will not auto-WoL the Windows machine by itself yet.

Practical workflow is:

You wake the 5080 box (manual button or a WoL command)
/model ollama5080/... (or set it as primary)

If you want, you can later automate WoL with exec, but I’d keep that for after your basics are stable.

#

If you paste these two outputs, I can tell you exactly what’s wrong in your case

From the Debian VM:

curl -sS http://127.0.0.1:11434/api/tags | head -50
curl -sS http://<windows-ip>:11434/api/tags | head -50

Also: what’s the exact model tag you pulled in Ollama for “qwen3.5” on Windows? (ollama list output line is fine.)

next dock Mar 4, 2026, 4:56 PM

#

ai@ai:~$ curl -sS http://127.0.0.1:11434/api/tags | head -50
{"models":[{"name":"qwen3:8b","model":"qwen3:8b","modified_at":"2026-03-04T14:56:45.119162889+01:00","size":5225388164,"digest":"500a1f067a9f782620b40bee6f7b0c89e17ae61f686b92c24933e4ca4b2b8b41","details":{"parent_model":"","format":"gguf","family":"qwen3","families":["qwen3"],"parameter_size":"8.2B","quantization_level":"Q4_K_M"}}curl -sS http://10.10.10.95:11434/api/tags | head -50 | head -50
{"models":[{"name":"qwen3.5:latest","model":"qwen3.5:latest","modified_at":"2026-03-04T13:07:04.9619886+01:00","size":6594474711,"digest":"6488c96fa5faab64bb65cbd30d4289e20e6130ef535a93ef9a49f42eda893ea7","details":{"parent_model":"","format":"gguf","family":"qwen35","families":["qwen35"],"parameter_size":"9.7B","quantization_level":"Q4_K_M"}}]}ai@ai:~$

qwen3.5:latest and qwen3:latest i see in ollama list on teh debian machine the model also when doing openclaw models list i see it, jsut not in the webui

#

cancel that, i can see the qwen3:8b model now, but i just dont see the qwen3.5 model anymore

zenith basinBOT Mar 4, 2026, 4:58 PM

#

Nice — both endpoints are reachable, so the “hard” part (networking) is done.

If openclaw models list shows the models but the web Control UI doesn’t, it’s usually one of these:

You’re looking at a UI dropdown that doesn’t auto-refresh, while the gateway catalog is correct
The session/UI model picker is showing only an allowlisted set (via agents.defaults.models)
You actually can switch, but you need to do it via the chat command (/model …) rather than a dropdown

Here’s the quickest way to confirm + fix.

1) Switch models from the web UI using `/model` (works even if dropdown is weird)

In the web chat input, type:

/model list

#

You should see a numbered list. Then try:

/model ollama/qwen3:8b
/model ollama5080/qwen3.5:latest (or whatever provider name you used for the Windows box)

And check:

/model status

If /model list shows both, you’re good — the dropdown is just being dumb/cached.

Tip: in the Control UI, hit Disconnect → Connect (or hard refresh the page) after changing models/providers.

2) If `/model list` does NOT show them: you probably have a model allowlist set

#

Run on the Debian VM:

openclaw config get agents.defaults.models

If that returns a big object, that’s an allowlist. Anything not in there won’t appear in /model pickers (and can feel “missing” in the UI).
Fix is either:
- add your Ollama models/providers into agents.defaults.models, or
- remove the allowlist entirely (simplest while you’re experimenting)

This behavior is documented here: https://docs.openclaw.ai/concepts/models (“Model is not allowed” section)

3) Make the 5080 model the default (and 2070 as fallback)

Once the provider exists, you can do it via CLI (no manual JSON editing):

#

openclaw models set ollama5080/qwen3.5:latest
openclaw models fallbacks add ollama/qwen3:8b

Then reconnect the web UI and check /model status.

(Models CLI reference: https://docs.openclaw.ai/concepts/models)

4) One important safety note (since you want “full access”)

The web Control UI is an admin surface (chat, config editing, exec approvals, etc.). Treat it like SSH: don’t expose it publicly.

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

#

Quick question

In your config, what did you name the Windows Ollama provider — is it literally ollama (overridden), or something like ollama5080?

If you paste the output of:

openclaw models status

I can tell you exactly what the UI should be seeing and where it’s getting filtered/cached.

#

That makes sense: OpenClaw will auto-discover only the local Ollama (127.0.0.1:11434). It will not auto-discover your remote Windows Ollama unless you add it as an explicit provider.

So what happened is: you’re back to “local Ollama only”, so you see ollama/qwen3:8b, but the 5080 model (qwen3.5:latest on 10.10.10.95) disappears.

Fix: add a remote Ollama provider (keep local discovery intact)

Add this to your ~/.openclaw/openclaw.json (or via Control UI → Config → Raw JSON):

{
  models: {
    providers: {
      ollama5080: {
        baseUrl: "http://10.10.10.95:11434",
        api: "ollama",
        apiKey: "ollama-local",
        models: [

#

          { id: "qwen3.5:latest", name: "Qwen 3.5 (5080)" }
        ]
      }
    }
  }
}

Then restart the gateway and in the web chat do:

/model list
/model ollama5080/qwen3.5:latest

Quick sanity check

Run on the Debian VM:

#

openclaw models status

You should see both:

ollama (local auto-discovery)
ollama5080 with baseUrl: http://10.10.10.95:11434

If you paste your openclaw models status output, I can tell you exactly what it thinks is configured (and whether a model allowlist is filtering it).

next dock Mar 4, 2026, 5:10 PM

#

⚠️ Agent failed before reply: No API key found for provider "ollama". Auth store: /home/ai/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/ai/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.
Logs: openclaw logs --follow

Happens when i did /model ollama5080 all to switch(it also still doesnt show int eh dropdown menu?) heres the raw o fix and give me the full one back, also mayeb its my env thats wrong i did sudo nano ~/.openclaw/openclaw.json and this is it and you can remove unnecesary things or add things needed, ill have to ptu the message in two due to discord limit.. {
"meta": {
"lastTouchedVersion": "2026.3.2",
"lastTouchedAt": "2026-03-04T17:01:27.773Z"
},
"wizard": {
"lastRunAt": "2026-03-04T15:44:39.192Z",
"lastRunVersion": "2026.3.2",
"lastRunCommand": "configure",
"lastRunMode": "local"
},
"models": {
"providers": {
"ollama5080": {
"baseUrl": "http://10.10.10.95:11434",
"apiKey": "ollama-local",
"api": "ollama",
"models": [
{
"id": "qwen3.5:latest",
"name": "Qwen 3.5 (5080)",
"api": "ollama",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 8192
}
]
}
}
},
"agents": {
"defaults": {
"model": {
"primary": "ollama/qwen3:8b"
},

#

"workspace": "/home/ai/.openclaw/workspace",
"compaction": {
"mode": "safeguard"
},
"maxConcurrent": 4,
"subagents": {
"maxConcurrent": 8
}
}
},
"tools": {
"profile": "messaging",
"web": {
"search": {
"enabled": false
},
"fetch": {
"enabled": true
}
}
},
"messages": {
"ackReactionScope": "group-mentions"
},
"commands": {
"native": true,
"nativeSkills": true,
"text": true,
"bash": true,
"config": true,
"debug": true,
"restart": true,
"useAccessGroups": true,
"ownerDisplay": "raw"
},
"session": {
"dmScope": "per-channel-peer"
},
"hooks": {
"internal": {
"enabled": true,
"entries": {
"boot-md": {
"enabled": true
},
"bootstrap-extra-files": {
"enabled": true
},
"command-logger": {
"enabled": true
},
"session-memory": {
"enabled": true
}
}
}
},
"gateway": {
"port": 18789,
"mode": "local",
"bind": "lan",
"controlUi": {
"enabled": true,
"allowedOrigins": [
"http://localhost:18789",
"http://127.0.0.1:18789"
],
"dangerouslyAllowHostHeaderOriginFallback": true,
"allowInsecureAuth": true,
"dangerouslyDisableDeviceAuth": true
},
"auth": {
"mode": "token",
"token": "my-token-i-have-saved",
"password": "none",
"rateLimit": {
"maxAttempts": 10,
"exemptLoopback": false
}
},
"allowRealIpFallback": false,
"tailscale": {
"mode": "off",
"resetOnExit": false
},
"nodes": {
"denyCommands": []
}
},
"memory": {
"backend": "qmd"
},
"skills": {
"allowBundled": [],
"install": {
"nodeManager": "npm"
}
}

zenith basinBOT Mar 4, 2026, 5:13 PM

#

That error + your edit command screams the real problem:

1) You probably edited the wrong config file

You did:

sudo nano ~/.openclaw/openclaw.json

With sudo, ~ usually becomes /root, so you likely edited:

/root/.openclaw/openclaw.json

…but your gateway is clearly running as user ai (see the error path):

/home/ai/.openclaw/...

So your changes may not be what the gateway is actually using.

#

Fix: edit the real file:

sudo -u ai nano /home/ai/.openclaw/openclaw.json

Or easiest: use the Control UI → Config editor, because it edits the live gateway config.

2) Why you got “No API key found for provider ollama”

Your config sets the primary model to:

"primary": "ollama/qwen3:8b"

#

…but you didn’t configure provider ollama with an apiKey/auth, so OpenClaw complains.

Easiest way to avoid this entirely: don’t use the special provider id ollama at all. Define two explicit providers (one per machine) and pick between them.

Drop-in config (minimal, clean) for your exact setup

Replace the relevant parts of /home/ai/.openclaw/openclaw.json with this (you can keep your meta/wizard blocks if you want, they’re harmless):

{
  "models": {
    "providers": {
      "ollama2070": {
        "baseUrl": "http://127.0.0.1:11434",
        "api": "ollama",

#

        "apiKey": "ollama-local",
        "models": [
          { "id": "qwen3:8b", "name": "Qwen3 8B (2070)" }
        ]
      },

      "ollama5080": {
        "baseUrl": "http://10.10.10.95:11434",
        "api": "ollama",
        "apiKey": "ollama-local",
        "models": [
          { "id": "qwen3.5:latest", "name": "Qwen3.5 (5080)" }
        ]
      }
    }

#

  },

  "agents": {
    "defaults": {
      "model": {
        "primary": "ollama5080/qwen3.5:latest",
        "fallbacks": ["ollama2070/qwen3:8b"]
      }
    }
  }
}

Then restart the gateway (as user ai, or from the Control UI apply/restart button):

#

sudo -u ai openclaw gateway restart

Switching in the web UI (even if the dropdown is flaky)

In the chat box:

/model list
/model ollama5080/qwen3.5:latest
/model ollama2070/qwen3:8b

If /model list shows both, you’re good — ignore the dropdown.

#

Quick check: paste this output

Run:

sudo -u ai openclaw models status

If it still complains about provider auth, we’ll know the gateway isn’t reading the file you edited (or there’s another config overriding it).

#

Yep — with the config you pasted, the failure is explained:

Why it blew up: you’re still using `ollama/...` as the primary model

Your first chunk showed:

"primary": "ollama/qwen3:8b"

…but your config only defines models.providers.ollama5080. There is no provider config for ollama, so when you switch/use that model you get:

No API key found for provider "ollama"

So the fix is: stop referencing ollama/… (or explicitly configure ollama too).

#

Minimal fix (recommended): define two providers and use them

Add a local provider (2070) next to your existing Windows one, and then point your defaults at those.

1) In `models.providers`, add this local provider:

"ollama2070": {
  "baseUrl": "http://127.0.0.1:11434",
  "apiKey": "ollama-local",
  "api": "ollama",
  "models": [
    { "id": "qwen3:8b", "name": "Qwen3 (2070)" }
  ]
}

2) Change your default model to use the 5080 provider and fallback to the 2070 provider:

#

"agents": {
  "defaults": {
    "model": {
      "primary": "ollama5080/qwen3.5:latest",
      "fallbacks": ["ollama2070/qwen3:8b"]
    }
  }
}

After that:

/model list should show both ollama5080/... and ollama2070/...
and you won’t hit the “provider ollama missing api key” error anymore.

#

Important: your Control UI security settings are currently “break glass”

You have:

dangerouslyDisableDeviceAuth: true
dangerouslyAllowHostHeaderOriginFallback: true

Those are very unsafe, especially if you later enable exec/install access.

At minimum, I’d set dangerouslyDisableDeviceAuth back to false once you’re connected successfully. (Docs call this out as a severe downgrade.)

Docs: https://docs.openclaw.ai/web/dashboard and https://docs.openclaw.ai/web/control-ui

Why it “doesn’t show in the dropdown”

The dropdown can be flaky/cached. The reliable way is still:

#Mix and match two machines