#.

1 messages · Page 1 of 1 (latest)

cyan quarryBOT
crisp tulipBOT
#

Short version: use macOS or Linux if you can. Use Windows via WSL2 if Windows is your main machine. I would avoid native Windows unless you specifically want to test that path.

My practical recommendation:

  • macOS: best if you want the desktop companion app, local browser/UI automation, iMessage/BlueBubbles, or a personal always-on Mac setup.
  • Linux / VPS: best for an always-on gateway/server setup. Cheap, stable, easy to run headless.
  • Windows: supported, but WSL2 is the recommended route for the full experience; native Windows is more likely to have edge-case friction.

Docs:
https://docs.openclaw.ai/start/getting-started
https://docs.openclaw.ai/install
https://docs.openclaw.ai/platforms/windows

#

A few, but they’re mostly “my world is already Windows” scenarios, not “OpenClaw is better on Windows” scenarios.

Windows can make sense if:

  • your main always-on machine is already a Windows desktop
  • you need to automate or inspect Windows-only apps/files/tools
  • you want to keep everything on one Windows workstation and are comfortable using WSL2
  • you’re testing Windows support itself

For OpenClaw specifically, I’d still pick macOS over Windows if you have both available, especially for the companion app, permissions-managed local automation, screen/camera/system tools, and the smoother desktop path. If you use Windows, I’d use WSL2, not native Windows, unless your needs are very CLI-only.

Docs:
https://docs.openclaw.ai/platforms/windows
https://docs.openclaw.ai/platforms/macos

#

CLI means Command Line Interface: using typed commands in a terminal instead of clicking around in a graphical app.

For OpenClaw, examples are commands like openclaw --version, openclaw doctor, or openclaw onboard. On macOS/Linux you’d run those in Terminal; on Windows you’d run them in WSL2/Ubuntu Terminal or PowerShell depending on install path.

So when I say “CLI-only,” I mean: using OpenClaw mostly through terminal commands and the gateway, without relying on a native desktop companion app.

#

Yes, that’s one of the main browser-control use cases.

The important bit: don’t give the agent your password or payment details. Best flow is:

  1. Have OpenClaw open its dedicated browser profile.
  2. You manually log in when needed.
  3. Let the agent navigate, search, fill carts/forms, compare options, etc.
  4. For purchases/payment/checkout, stay in the loop and do the final confirmation yourself.

OpenClaw’s default browser profile is separate from your personal browser, which is good for safety. If the site needs an existing signed-in session, there’s also a “user” browser mode, but you should only use that when you’re present to approve/monitor it.

This is also where macOS tends to be nicer than Windows: the macOS companion app + local browser automation path is smoother. On Windows with WSL2, browser control can work, but crossing from WSL2 into Windows Chrome adds extra setup/friction.

Docs:
https://docs.openclaw.ai/tools/browser
https://docs.openclaw.ai/tools/browser-login
https://docs.openclaw.ai/tools/browser-wsl2-windows-remote-cdp-troubleshooting

#

Right — if the target is desktop PowerPoint or desktop Excel, the OS matters because the app has to exist on the machine being controlled.

Practical breakdown:

  • Excel/PowerPoint web apps: any OS can work through browser automation, including Linux.
  • Microsoft Office desktop on Mac: macOS can work if you’re using the Mac versions of Excel/PowerPoint.
  • Microsoft Office desktop on Windows: Windows is the right place if you specifically need Windows Office, Windows-only add-ins, macros, COM automation, or files/workflows that only behave correctly in Windows Office.
  • Linux: good for the gateway/server, but not for native Microsoft Office desktop automation. You’d use browser-based Office, LibreOffice, or connect a Windows/Mac machine as a node.

A common setup is: run the OpenClaw Gateway on the most stable host, then connect the machine with the actual app as a node. So you could have a Linux/VPS gateway, but a Windows PC node for Excel/PowerPoint work, or a Mac node for Mac desktop apps.

Docs:
https://docs.openclaw.ai/nodes
https://docs.openclaw.ai/platforms/windows
https://docs.openclaw.ai/platforms/macos

#

I meant Windows PC node — typo/wording issue on my side.

A node is another device connected to your OpenClaw Gateway so the agent can use that device’s local capabilities. So a Windows PC node would mean: your OpenClaw setup connects to a Windows computer, and tasks that need Windows apps like desktop Excel/PowerPoint run on that Windows machine.

Think: Gateway = brain/control center. Node = a connected device the agent can use.

#

Yep, exactly: node. In OpenClaw terms, that means a connected device the gateway can use for local actions, like running commands or controlling apps on that machine.

#

Not necessarily. A node is any connected device/host that exposes capabilities to OpenClaw.

It could be:

  • your MacBook
  • a Windows desktop
  • a Linux server
  • a phone node
  • a VM, if you choose to run one

So a VM can be a node, but “node” just means “machine/device OpenClaw can use.” The key point is that actions happen wherever the node is running. If you need desktop Excel, the node needs to be on a machine/VM that actually has desktop Excel installed.

#

Not if the Mac mini can do the jobs you care about.

If your Mac mini is the machine running OpenClaw, it can be both:

  • the Gateway: the control center
  • the node: the local machine where apps/browser/actions happen

You’d only need another device if you need capabilities the Mac mini doesn’t have. Example: if you specifically need Windows desktop Excel/PowerPoint, then you’d need a Windows PC or Windows VM with Office installed. But for browser work, files, Mac apps, and Microsoft Office for Mac, the Mac mini can be the main setup.

#

Yes. The Mac mini can be the node too.

Simple setup:
Mac mini = Gateway + node + browser/app machine

That’s probably the cleanest starting point if you already have a Mac mini. Add another node later only if you need something the Mac mini can’t provide, like Windows-only Office behavior or a different physical device.

#

Yes, that’s fine as a starting point. If your active PC is Windows, I’d install it using WSL2 rather than native Windows unless you have a reason not to.

A few practical notes:

  • It’s okay to run OpenClaw on your daily PC while you’re learning/testing.
  • Keep in mind the Gateway is most useful when the machine is awake and online.
  • Browser/app automation can use your PC, but stay present for logins, purchases, payments, and anything sensitive.
  • If you later buy a Mac mini or move to a VPS, you can make that the always-on host and keep the PC as a node for Windows-specific work.

For setup, start here:
https://docs.openclaw.ai/start/getting-started
https://docs.openclaw.ai/platforms/windows

If you hit weird behavior during setup, grab openclaw --version early — version mismatch is a very common source of confusing support threads.

#

Here’s the WSL2 path in plain English:

  1. Open PowerShell as Administrator on Windows and install Ubuntu:
wsl --install -d Ubuntu-24.04

Reboot if Windows asks.

  1. Open the new Ubuntu app from Start Menu and create your Linux username/password.

  2. In Ubuntu, enable systemd:

sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF
#
  1. Back in PowerShell, restart WSL:
wsl --shutdown
  1. Re-open Ubuntu, then install OpenClaw from inside Ubuntu:
curl -fsSL https://openclaw.ai/install.sh | bash
  1. Run onboarding:
openclaw onboard --install-daemon
  1. Check it:
#

It’s installing Ubuntu on your PC through WSL2, then installing OpenClaw inside that Ubuntu environment.

So physically, yes, it lives on your PC’s disk. But technically, OpenClaw runs in the Linux/Ubuntu side, not directly in normal Windows.

Think of WSL2 as a lightweight Linux environment built into Windows. You still use the same computer, but OpenClaw gets the Linux-style tools/runtime it works best with.

#

Yes. You control it from the same computer.

You open the Ubuntu app from the Windows Start Menu, and that gives you a terminal into the Ubuntu environment. From there you run commands like openclaw onboard, openclaw dashboard, etc.

You can also access files both ways:

  • From Ubuntu, your Windows C: drive is usually at /mnt/c/
  • From Windows File Explorer, Ubuntu files show under \\wsl$

So it’s not a separate physical computer. It’s a Linux environment running inside your Windows PC.

#

Mostly, yes: WSL2 gives you a Linux terminal environment, not a full Ubuntu desktop by default.

But that’s enough for OpenClaw’s Gateway/CLI. You’d run OpenClaw inside Ubuntu, then use normal Windows apps for the visual parts:

  • run commands in the Ubuntu terminal
  • open the OpenClaw dashboard in your Windows browser
  • use Windows Chrome/Edge for browsing if configured
  • use Windows apps directly when needed

So WSL2 is great for the “server/control” side. If you mean “can the agent click around inside a full Ubuntu desktop like a remote computer,” that’s not the default setup. For your use case, the more likely path is: OpenClaw runs in WSL2, and browser/app actions happen in Windows via browser/node configuration when needed.

#

Yes, for a lot of browser automation you can run a separate/headless browser so it doesn’t take over your normal browser window.

Tradeoff:

  • Headless/separate browser: good for background research, checking pages, scraping info, filling non-sensitive forms, repetitive web tasks.
  • Visible browser: better when you need to watch what it’s doing, handle logins, solve MFA/captchas, or confirm purchases/payments.
  • Some sites detect headless/sandboxed browsers more aggressively, especially banks, shopping sites, social networks, and anything with login risk.

OpenClaw’s managed openclaw browser profile is already separate from your personal browser. You can also configure it to run headless with browser.headless: true, but I’d start visible while learning so you can see what’s happening, then move boring repeatable tasks to headless later.

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

#

Yep, that tracks. If OpenClaw was installed natively on Windows, browser control may attach to or launch the normal Windows Chrome path depending on config/profile.

What you want is to make sure it uses the managed openclaw browser profile, not your daily user profile. In OpenClaw terms:

  • openclaw = separate agent browser profile
  • user = your real signed-in Chrome session

After you reinstall/set up through WSL2, I’d check these first:

openclaw --version
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start

If it still opens your normal Chrome session, share your openclaw --version and browser config/profile settings. The relevant docs are here: https://docs.openclaw.ai/tools/browser

#

Main difference: native Windows runs OpenClaw directly in Windows, while WSL2 runs OpenClaw inside Ubuntu/Linux on your Windows PC.

Native Windows

  • Easier mentally: install/run from PowerShell.
  • Better if you only want simple CLI/Gateway experiments directly in Windows.
  • More likely to hit Windows-specific edge cases around paths, services, shells, browser behavior, and tooling.
  • No native Windows companion app yet.

WSL2

  • Recommended path for Windows users.
  • OpenClaw runs in a Linux environment, so the CLI/Gateway/tooling match the better-tested Linux path.
  • Uses Linux service management (systemd) instead of Windows Scheduled Tasks.
  • Slightly more setup up front because you install Ubuntu first.
  • Browser automation that needs Windows Chrome can require extra configuration because OpenClaw is inside WSL2 and Chrome is on the Windows side.

My recommendation: use WSL2 for the main OpenClaw install. Use native Windows only if you specifically need to test native Windows or you’re doing very simple local CLI stuff.

#

Yes, basically. I meant testing OpenClaw’s Windows support itself — like if you were contributing bug reports, helping the project verify native Windows behavior, or intentionally checking whether the Windows installer/service/browser paths work.

For normal use, you probably don’t need native Windows. If you’re just trying to run OpenClaw reliably on your PC, WSL2 is the better choice.

Also tiny wording thing: it’s OpenClaw, not “open class” — easy speech-to-text mixup.

#

I don’t know for sure — I inferred it because “OpenClaw” turning into “open class” is the kind of mistake speech-to-text often makes. Could also just be autocorrect or typing. I shouldn’t have stated it like I knew.

#

I’m Krill 🩐 — the OpenClaw Foundation’s Discord support assistant. I’m here to help people understand/setup OpenClaw, point to the right docs, and keep support threads searchable.

I’m not a separate product you install; I’m running as an OpenClaw-connected assistant in this Discord.

#

For budget: I’d start with the docs’ recommended setup, then ask in #models for current low-cost picks. Model pricing/performance changes fast enough that I don’t want to give you stale names here.

General strategy:

  • use a cheaper model for routine chat/simple tasks
  • use a stronger model only for hard browser automation, coding, or multi-step tasks
  • avoid local/Ollama unless you already have very serious hardware; it can work, but agentic performance usually disappoints on normal PCs
  • set spending limits/usage alerts at the provider side if available

Docs: https://docs.openclaw.ai/concepts/models
Community notes: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

Ask in #models with your rough budget and use case: “Windows PC + WSL2, browser automation, Office tasks, low monthly spend.” That’ll get fresher answers than I can safely hard-code.

#

I wouldn’t assume it’s “best” just because it’s cheap. For OpenClaw, the important question is not only price — it’s whether the model reliably follows tool calls for browser/app automation.

I also don’t want to pretend I have fresh pricing/benchmark data in this thread. Model names, pricing, and provider quality shift fast. Best move: ask in #models with that exact model name and your use case, plus check the docs/community notes:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

For your situation, I’d phrase it like: “Is DeepSeek 4.6 Flash reliable for OpenClaw tool use/browser automation, or just cheap for chat?” That distinction matters a lot.

#

If your provider’s pricing page is showing Llama 4 Scout cheaper than DeepSeek v4 Flash, then for that provider/account, yes, that’s likely the current pricing there.

But two cautions:

  • Prices can differ by provider/router, input vs output tokens, cached tokens, context size, and promos.
  • Cheapest is not always cheapest in practice if the model fails tool calls and you have to rerun tasks.

For OpenClaw, I’d care about: tool reliability first, then price. A cheap model is great for chat/summaries, but browser automation and multi-step agent work need a model that follows tools consistently.

Best place to sanity-check current model picks is still #models: “Is Llama 4 Scout reliable enough for OpenClaw browser/tool use, or only cheap?”

#

Fair. I can help with the decision logic, just not pretend I have perfect live pricing/benchmarks.

If the provider UI shows one model is cheaper, believe the UI for price. Then decide by use case:

  • For cheap chat / summaries / simple Q&A: try the cheaper one first.
  • For browser automation / tool use / multi-step tasks: cheap models often look good until they miss tool calls, get stuck, or need reruns. That can become more expensive than using a stronger model.
  • For your first OpenClaw setup: pick the cheapest option that works, run a few real tasks, then upgrade only if it fails.

A practical test: ask it to do one small browser task, one file/task planning thing, and one “use tools in order” task. If it follows instructions cleanly without wandering, it’s probably fine for learning. If it ignores tools or makes stuff up, don’t fight it too long — switch to a more reliable model for agent work.

So: cheapest is okay for starting. “Best” is the cheapest one that actually completes your tasks without babysitting.

#

Assuming you mean Llama 4 Scout vs DeepSeek v4 Flash: I’d compare them less by “which is smarter on a leaderboard” and more by how they behave inside OpenClaw.

What I’d expect to test:

  • Tool following: does it reliably call the right tool, wait for results, and continue?
  • Browser tasks: can it navigate pages without getting lost or clicking random stuff?
  • Instruction discipline: does it obey constraints like “don’t purchase, stop before checkout”?
  • Cost per completed task: cheap tokens don’t help if it takes 4 reruns.

My practical take: start with whichever is cheaper in your provider UI for simple chat and learning. For browser automation, run a small real test before trusting either one. If one misses tool calls or invents steps, drop it for agent work even if it’s cheaper.

A good starter test prompt would be: “Open a browser, go to example.com, summarize the page title, then stop.” Then try a slightly harder shopping/search task where it must stop before checkout.

#

Switching models won’t permanently “mess up” an agent. The agent’s files/config/memory don’t get corrupted just because you change models.

What can happen:

  • Different models behave differently, so the same agent may feel less consistent.
  • A weaker model may misunderstand the agent’s instructions or use tools poorly.
  • If you switch during an active run, OpenClaw queues/applies the switch at a clean point, so the current task may not instantly change models.
  • Long conversations can get a little weird if you bounce between models with very different reasoning/tool ability.

Practical advice: it’s fine to experiment, especially early. But once you find a model that handles your browser/tool tasks reliably, keep that as your default. Use cheaper models for low-risk/simple stuff, and switch up only when the task is hard or the cheap model starts failing.

Docs: https://docs.openclaw.ai/concepts/models

#

If you mean GPT-4o vs DeepSeek v4 Flash, my practical opinion for OpenClaw is:

GPT-4o is more likely to be better for agent/tool/browser work. It should generally be more reliable at following instructions, using tools, and recovering when a task gets messy.

DeepSeek v4 Flash is the budget experiment. I’d use it for cheap chat, summaries, simple planning, and low-risk tasks. I would not assume it’s the better choice for browser automation until it proves it can follow tools consistently.

So the short version: if you care about “does the task correctly,” I’d start with GPT-4o. If you care about “spend as little as possible while learning,” start with DeepSeek Flash and upgrade when it annoys you.

#

That’s a reasonable worry. Agent work can get expensive if you let it wander, especially browser automation where it may look/read/click through a lot of steps.

Ways to keep it under control:

  • Start with a cheap model for learning and simple tasks.
  • Use a stronger model only when the cheap one fails or the task is important.
  • Set hard spending limits/alerts in the model provider account if they offer them.
  • Give small, bounded tasks: “find X and summarize,” not “go research everything.”
  • For browser tasks, tell it where to stop: “do not purchase,” “stop before checkout,” “ask me before submitting.”
  • Watch the first few runs so you learn what burns tokens.

My honest recommendation: don’t start by trying to automate big purchases or complex workflows. Install it, connect one model, run tiny tests, and see what the provider dashboard says it cost. That will give you a real feel for your own usage before you scale up.

#

Tencent Hy3 is likely Tencent Hunyuan 3 / Hy3 Preview — Tencent’s open-source large language model line.

From current public pages, it’s described as a big Mixture-of-Experts model: lots of total parameters, fewer active per request, long context, and aimed at reasoning/coding/agent tasks.

For your OpenClaw decision, treat it like the others: promising on paper, but the real question is whether your provider’s hosted version has reliable tool calling. It might be cheap/interesting, but I’d test it on small OpenClaw tasks before trusting it for browser automation or anything with money/accounts involved.

Tencent page: https://www.tencent.com/en-us/articles/2202320.html
GitHub: https://github.com/Tencent-Hunyuan/Hy3-preview

#

My honest take: I would not assume Tencent Hy3 is comparable to an Opus-class model for OpenClaw agent work.

Hy3 may be a decent budget/experimental option, especially if your provider prices it well. But for hard tasks — browser automation, multi-step tool use, coding, messy websites, careful “stop before checkout” instructions — Opus-class models are usually the kind of thing people reach for when reliability matters more than token price.

So I’d bucket them like this:

  • Hy3: worth testing, maybe good value, don’t trust blindly yet.
  • Opus-class: expensive, but more likely to complete hard agent tasks cleanly.

If budget is the concern, I’d use Hy3/cheap models for everyday/simple runs and reserve the expensive model for tasks where failure wastes time or could cause real-world trouble.

#

“Preview” usually means the model is being released early for people to try before the provider treats it as a fully stable/final production model.

In practice that can mean:

  • behavior may change over time
  • pricing or availability may change
  • docs/tool support may still be evolving
  • providers may update or replace it without as much backward-compatibility expectation

It doesn’t mean “bad.” It means “don’t build your whole setup assuming this exact model/version will behave the same forever.” For OpenClaw, I’d treat preview models as experiments until they prove reliable on your actual tasks.

#

You’re not locked in. OpenClaw can switch models after setup.

A clean way to think about it:

  • Your OpenClaw install/config/channels are the system.
  • The model is one replaceable backend choice.
  • If a model turns out bad/expensive/unstable, you can change the default model or switch per session.

Common commands/paths:

openclaw models status
openclaw models list
openclaw models set provider/model

In chat sessions, /model can switch the current session model if the model is configured/allowed.

So yes, if Hy3 is your only configured model and it disappears, your agent won’t have another model to use. But the fix is to configure a fallback/second option. A practical setup is:

#

Your whole system should not be thrown off. The model is replaceable.

What carries over:

  • your OpenClaw install
  • channels/accounts
  • workspace files/instructions
  • memory/config
  • agents and sessions, mostly

What changes:

  • the new model may behave differently
  • it may be better/worse at tools
  • you might need to tweak prompts/instructions if the old model had quirks
  • any currently active run/session may need a restart or a fresh message after switching

So if Hy3 vanished, you’d set a new model and keep going. OpenClaw won’t magically make the new model behave identically, but it will still have the same instructions/context to work from.

#

No — having a backup/fallback model does not mean both models are always learning.

A fallback model is more like a spare engine. OpenClaw uses your primary model first. If that fails or you manually switch, it can use the backup. The backup is not sitting there watching and training in the background.

Also, most API models don’t “learn” into themselves from your individual chat in the way people imagine. What persists is usually OpenClaw-side stuff like:

  • workspace instructions
  • memory files, if configured/used
  • session history/context
  • your config

Provider data/training policies vary, so check your model provider’s privacy settings if that matters to you. But inside OpenClaw, the durable memory is separate from the model choice.

#

Close. Tiny correction: OpenClaw, not OpenClause.

The model still matters a lot — it’s the reasoning engine deciding what to say, which tools to use, and how well to follow instructions.

But the agent setup is what gives it shape:

  • instructions/personality
  • memory/workspace files
  • configured tools
  • connected channels/devices
  • permissions and safety settings
  • session history/context

So the agent is the “person + environment,” and the model is the “brain engine” you plug into it. Swap the model and it’s still the same OpenClaw agent setup, but it may behave smarter, cheaper, sloppier, or more reliable depending on the model.

#

I would not fresh-install Windows just for this. That’s a huge hammer.

Much safer path:

  1. Leave Windows alone.
  2. Install a fresh WSL2 Ubuntu environment.
  3. Install OpenClaw inside that clean Ubuntu environment.
  4. Treat any old native-Windows OpenClaw install as separate/legacy until you know the WSL2 setup works.

If the old install is broken, don’t try to untangle everything first unless it conflicts. WSL2 gives you a clean Linux-side setup without wiping your PC.

Before doing anything destructive, grab this from wherever you previously installed it:

openclaw --version

And if you already have WSL/Ubuntu installed, also check inside Ubuntu:

# 
openclaw --version

If native Windows says openclaw exists but you’re moving to WSL2, that’s okay — just make sure you’re running the WSL2 commands inside the Ubuntu terminal, not PowerShell.

#

If you already want to reset it for other reasons, then sure — just treat that as a Windows maintenance decision, not an OpenClaw requirement.

Before resetting, make sure you’ve backed up anything you care about:

  • Documents/Desktop/Downloads
  • browser passwords/bookmarks if not synced
  • SSH keys/API keys/config files
  • any old OpenClaw files you might want later, usually under %USERPROFILE%\.openclaw on native Windows

After the reset, I’d install in this order:

  1. Windows updates + GPU/browser updates
  2. WSL2 + Ubuntu
  3. OpenClaw inside Ubuntu
  4. model provider/API key setup
  5. browser automation config only after the basic dashboard works

That gives you the cleanest path without mixing old native-Windows OpenClaw state into the new WSL2 setup.

#

Yes, it’s designed to be movable. Small correction: OpenClaw, not OpenClock.

The key thing to migrate later is the OpenClaw state directory plus your workspace. By default the state directory is ~/.openclaw inside WSL2 Ubuntu. That contains config, auth profiles, sessions, channel state, etc.

High-level move later:

  1. Stop the gateway on WSL2.
  2. Archive/copy ~/.openclaw and your workspace.
  3. Install OpenClaw on the Mac mini.
  4. Extract/copy the files there.
  5. Run openclaw doctor, restart, and verify.

The main gotcha is secrets: that state folder can contain API keys/auth/channel credentials, so transfer/store it carefully.

Docs: https://docs.openclaw.ai/install/migrating

#

Glad it helped. For your path, I’d keep it simple: reset only if you already want to, install WSL2 + Ubuntu, install OpenClaw inside Ubuntu, start cheap with models, and only add complexity once the dashboard/basic chat works.

If this thread answered the question, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.

#

You can usually delete your own Discord messages if the server/channel permissions allow it: right-click/long-press the message → Delete Message.

Whether the whole thread can be deleted/hidden depends on server permissions. I can’t promise that from here, and I shouldn’t delete support content on your behalf.

One note: this thread is fairly general setup/model-choice discussion, so it probably is useful to future people. But if you’re uncomfortable with anything personal in it, deleting your own messages is the right first step.