#what does the current support for a jetsen orin nano look like?

1 messages · Page 1 of 1 (latest)

main sequoiaBOT
#

Jetson Orin Nano support is basically: it’s just Linux/ARM64, and the OpenClaw Gateway is fully supported on Linux, so it should run fine on JetPack/Ubuntu as long as you meet the Node/runtime requirements.

What that looks like in practice:

  • Gateway: âś… Works (Node-based). Requirement is Node >= 22.
    Docs: https://docs.openclaw.ai/platforms/linux
  • ARM64 caveat: Most of OpenClaw is JS and is fine on ARM, but some optional skills/tools that rely on prebuilt x86 binaries may not work (or need ARM builds). This is the same “Pi-class” story.
    ARM notes: https://docs.openclaw.ai/platforms/raspberry-pi
  • GPU/CUDA: OpenClaw itself doesn’t “use the Jetson GPU” unless you specifically run a local model server on the Jetson and point OpenClaw at it. That part is doable but more tinkery than “official GPU acceleration.”
  • Browser/tooling: Headless ARM boxes can run browser automation, but it’s often heavier/more finicky. A common setup is Gateway on Jetson + a laptop/desktop as a paired node for browser/screen/exec tasks.
    Nodes: https://docs.openclaw.ai/nodes

If you tell me your goal (run the Gateway on the Jetson vs use it as a node / local inference box), and what JetPack/Ubuntu version you’re on, I can suggest the least-painful setup path.

earnest gull
#

well, i have a orin nano super i want to have a small local odel on for offline small simple tasks such as reminders etc, and i have a max tier claude subscription i'd like to use for heavier tasks. orin will be running headless connected to a switch that has access to the rest of my devices for real useage but i can plug a monitor etc into it during setup

#

can you tell me what cmd to run while i'm sshed into it?

main sequoiaBOT
#

That setup makes sense, and the Orin Nano Super is a decent “always‑on headless Linux box” for an OpenClaw Gateway.

What I’d do (local-first + Claude when needed):

1) Run the Gateway on the Jetson (headless is fine)

  • OpenClaw Gateway is fully supported on Linux; Jetson is just Linux/ARM64.
  • Make sure you’re on Node >= 22.
  • For headless setup/ops, plan on SSH tunnel or Tailscale to reach the dashboard.

Linux doc: https://docs.openclaw.ai/platforms/linux

2) Local model for offline/light tasks

OpenClaw can use any OpenAI-compatible /v1 endpoint as a “local provider”. On Jetson that usually means running some local server (llama.cpp/vLLM/Ollama/LiteLLM, etc.) that exposes an OpenAI-style API.

Then configure:

  • agents.defaults.model.primary = your local provider/model
  • keep hosted providers enabled with models.mode: "merge" so you can use Claude when internet is available
#

Local models doc + config patterns: https://docs.openclaw.ai/gateway/local-models

Important reality check: “small local model for agent/tool use” can be flaky (tool calling + long context are hard). It can still work for simple stuff, but having Claude available as an escape hatch is the right plan.

3) Claude Max subscription for heavy tasks

That’s supported via Anthropic setup-token (not an API key). You can generate it on any machine:

  • Run: claude setup-token
  • Then paste it on the Jetson via the wizard or CLI (docs show both flows).

FAQ section (setup-token + general auth): https://docs.openclaw.ai/help/faq

4) Reminders: don’t rely on the model if you want “offline reliable”

Even if your local model is weak, you can schedule rock-solid reminders using the built-in Gateway cron via CLI (no “LLM parsing” required — you specify the time + exact reminder text):

Cron docs: https://docs.openclaw.ai/automation/cron-jobs

#

5) How to switch between “local” and “Claude” in real usage

Two common patterns:

  • Manual per-session switch: use /model in chat to switch to Claude for a hard task, then switch back.
  • Two-agent setup: one agent defaults to local, another defaults to Claude; route different chats/channels to each (multi-agent).

Models + switching: https://docs.openclaw.ai/concepts/models
Multi-agent routing: https://docs.openclaw.ai/concepts/multi-agent


Two quick questions so I can recommend the least annoying wiring:

  1. Will the Jetson have outbound internet most of the time (so Claude can be used on-demand), or do you want it fully air-gapped except LAN?
  2. What chat surface do you want as the “main UI” (Telegram/Discord/Signal/etc.)?
#

SSH into the Jetson and run this (Ubuntu/JetPack assumed). It installs prereqs, Node 22+, then OpenClaw + the onboarding wizard:

# 0) (optional) basic deps
sudo apt update && sudo apt upgrade -y
sudo apt install -y git curl build-essential

# 1) Node.js 22+ (required)
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node --version

# 2) Install OpenClaw
curl -fsSL https://openclaw.ai/install.sh | bash

# 3) Onboard + install daemon (recommended)
#
openclaw --version
openclaw onboard --install-daemon

# 4) Quick health check
openclaw gateway status
openclaw status

If you’re headless and want the Control UI in your laptop browser, run this from your laptop:

ssh -N -L 18789:127.0.0.1:18789 <user>@<jetson-ip>

Then open: http://127.0.0.1:18789/

#

Docs (same flow): https://docs.openclaw.ai/start/getting-started

If you tell me what local model server you plan to run on the Jetson (Ollama vs vLLM vs llama.cpp vs LM Studio), I can give you the exact OpenClaw models.providers snippet to point at it.

earnest gull
#

what do you suggest? air gapped or outbound internet?

also i want it to be main ui on discord and whatsapp

main sequoiaBOT
#

If you want your main UI to be Discord + WhatsApp, you effectively cannot be air‑gapped.

Both channels require the gateway to maintain outbound connections to their cloud services:

  • Discord bot ⇢ Discord gateway/APIs
  • WhatsApp Web (Baileys) ⇢ WhatsApp servers

What I suggest: “outbound internet, no inbound”

Best practical/security tradeoff for a headless Jetson:

  • Give the Jetson outbound internet (so Discord/WhatsApp + Claude work)
  • Don’t expose any inbound ports to the internet (no router port forwards)
  • Optional but nice: put it on its own VLAN + restrict egress to mostly :443 (and DNS/NTP)

That gets you “safe enough” while still actually usable with Discord/WhatsApp.

Offline + local model reality check

You can run a local model on the Orin for “small/simple tasks”, but:

#
  • If your internet is down, you won’t be able to talk to it via Discord/WhatsApp (those apps themselves need internet).
  • For reminders specifically, the most reliable path is Gateway cron (scheduler). The model quality matters less, because the schedule is handled by the gateway, not “AI memory”.

Cron docs: https://docs.openclaw.ai/automation/cron-jobs
Local models: https://docs.openclaw.ai/gateway/local-models

“Local for most, Claude Max for heavy”

Recommended workflow:

  • Set the local model as default (cheap/offline-ish)
  • When you want a heavy task, switch per session using /model to Claude
  • Authenticate Claude Max via Anthropic setup-token (claude setup-token) rather than an API key (subscription-friendly)

Channel setup pointers (so it’s not a public bot by accident)

  • Discord: lock it down with groupPolicy: "allowlist" + requireMention (docs show the pattern)
    https://docs.openclaw.ai/channels/discord
  • WhatsApp: use dmPolicy: "allowlist" or pairing and ideally a dedicated number
#

https://docs.openclaw.ai/channels/whatsapp

If you tell me what you plan to run as the local model server on the Jetson (Ollama vs vLLM vs llama.cpp/LiteLLM), I’ll point you at the exact OpenClaw provider setup pattern for it.

earnest gull
#

no idea. i'm completely new to this. whats the best i can get on a 8gb orin running reasonably? i know not to expect much but any automation in my case is good

main sequoiaBOT
#

Air‑gapped won’t work with your chosen “main UI” (Discord + WhatsApp). Both require the gateway to maintain outbound connections to their servers, so you want outbound internet.

What I recommend for your Jetson Orin 8GB:

Recommendation (practical + “new to this” friendly)

1) Outbound internet, no inbound exposure

  • Let the Jetson reach the internet (Discord/WhatsApp + Claude)
  • Don’t open ports to the public internet (no router forwards)
  • Manage it via SSH (and optionally Tailscale later)

That gets you 95% of the “safe” benefits without breaking the whole point of Discord/WhatsApp.

2) Local model on 8GB: keep expectations tight

On 8GB VRAM/shared memory, “reasonably running” usually means:

  • small model class (think single-digit billions of parameters), quantized
  • shorter context windows
  • tool-calling reliability can be hit-or-miss on small locals
#

It can still be totally useful for: quick Q&A, drafting, light summarization, “note this”, etc.

3) Easiest local runtime for OpenClaw: Ollama

OpenClaw has a first-class Ollama provider and can auto-discover locally installed models.

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

High-level steps on the Jetson:

# install Ollama (follow their site for Jetson/Linux ARM64)
# https://ollama.ai

# verify Ollama is running
curl http://127.0.0.1:11434/api/tags

# pull *one small* model (ask in #models what tag fits “Orin 8GB”)
#
ollama list
ollama pull <some-small-instruct-model>

Then enable discovery for OpenClaw (simple way: env var) and restart the gateway:

export OLLAMA_API_KEY="ollama-local"   # any string works
openclaw gateway restart
openclaw models list

Now you should be able to switch in chat with:

  • /model → pick the Ollama model for “cheap/local”
  • /model → pick Claude for “heavy tasks”

(Model switching docs: https://docs.openclaw.ai/concepts/models)

#

4) For reminders specifically: use Cron (most reliable)

Even with a weak local model, reminders can be rock-solid because the scheduler is in the Gateway, not “the AI remembering”.

Docs: https://docs.openclaw.ai/automation/cron-jobs

Example (from Jetson shell):

openclaw cron add \
  --name "Test reminder" \
  --at "20m" \
  --session main \
  --system-event "Reminder: check the Jetson setup" \
  --wake now \
  --delete-after-run

Quick question so I can point you better

#

Is your Jetson running JetPack 6 (Ubuntu 22.04) or something older? Ollama installation experience varies a bit by JetPack version, and I don’t want to send you down a dead end.

earnest gull
#

well, which model would you reccomend is what i'm saying

main sequoiaBOT
#

I can’t give you a single “best model” name here because the right pick for an Orin 8GB changes constantly (and I’ll get it wrong fast). The OpenClaw community keeps a much more current list—ask in #models with “Jetson Orin Nano Super / 8GB / Ollama” and you’ll get real-world-tested picks.

What I can recommend reliably is the selection strategy:

What to aim for on an Orin 8GB

  • Choose a small “instruct” chat model that fits comfortably in your RAM/VRAM budget (think “single‑digit B params”, quantized).
  • For OpenClaw specifically, prefer a model that supports tools/function calling (otherwise it may not show up in OpenClaw’s Ollama auto-discovery, or it’ll be flaky with actions).
  • Expect: local model = “good enough for light chat + simple planning”, Claude = “do anything important / tool-heavy”.

Easiest path: Ollama + auto-discovery

OpenClaw can auto-discover tool-capable Ollama models if you set OLLAMA_API_KEY and don’t hardcode an ollama provider block.

On the Jetson:

export OLLAMA_API_KEY="ollama-local"   # any string works
#
openclaw gateway restart

ollama list
openclaw models list
  • If your pulled model is tool-capable, it should appear in openclaw models list.
  • Then in Discord/WhatsApp you can do /model and select it.

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

My practical recommendation for your use case

  • Default to the local Ollama model for “cheap chatter”.
  • The moment something is important (tool use / multi-step / reliability), switch to Claude via /model.
  • For reminders, use Gateway cron so it’s reliable regardless of model quality: https://docs.openclaw.ai/automation/cron-jobs
#

If you tell me your JetPack version (esp. JetPack 6 vs older), I can also point you at the least painful Ollama install path people tend to use on Jetson.

earnest gull
#

im still doing the onboarding or setup whatever it's called, i just selected the skills etc and i'ver gotten to the homebreew install, theres a lot of cmds that failed but seems its still going

main sequoiaBOT
#

Yeah, that “Homebrew / install deps for skills” part of onboarding is pretty often best-effort, especially on Linux ARM (Jetson). A bunch of those commands can fail and the wizard will still keep going — it doesn’t necessarily mean OpenClaw itself is broken.

What I’d do:

  1. Let onboarding finish if it’s still progressing.

  2. After it completes, run these to see if the core Gateway is healthy:

openclaw gateway status
openclaw status
  1. If the gateway is up, you can ignore the brew/skill dependency failures for now and come back later. The “core” is: Node 22+, OpenClaw installed, gateway running.

  2. If it did fail at the Homebrew step and you want to clean it up later:

  • On Jetson, it’s often simpler to install needed packages via apt instead of brew.
  • Homebrew-on-Linux can work, but ARM formula coverage can be spotty.
#

Docs: https://docs.openclaw.ai/help/faq#does-homebrew-work-on-linux

If you paste one example failure block (like ~20 lines around the first error), I can tell you whether it’s “harmless optional skill dep” vs “this will break the gateway.” (Just redact tokens/QR codes if any show up.)

earnest gull
#

ok. it's finished, i selected hatch in tui, it said gateway disconnected: pairing required idle in blue but now its spamming gateway connect failed: error: pairing required in red

main sequoiaBOT
#

That “pairing required” is almost certainly device pairing (Control UI / TUI client), not WhatsApp/Discord pairing.

Fix (do this on the Jetson, in a second SSH window since your TUI is spam-retrying):

openclaw devices list
# look for a pending requestId, then:
openclaw devices approve <requestId>

After approving, the TUI should connect immediately.

If devices list can’t reach the gateway, first confirm the gateway is up:

openclaw gateway status
#

Optional tip: if you access the UI via an SSH tunnel to 127.0.0.1:18789, it counts as “local” and is usually auto-approved (no device pairing prompt).

If you paste the output of openclaw devices list (redact tokens if any), I can tell you exactly which ID to approve.

earnest gull
#

openclaw devices list returns the following:

│
gateway connect failed: Error: pairing required
â—‡
[openclaw] Failed to start CLI: Error: gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/mcsorin1/.openclaw/openclaw.json
Bind: loopback
at Object.onClose (file:///home/mcsorin1/.npm-global/lib/node_modules/openclaw/dist/call-DZzTR0NL.js:438:10)
at WebSocket.<anonymous> (file:///home/mcsorin1/.npm-global/lib/node_modules/openclaw/dist/client-DoSZFvf3.js:1538:23)
at WebSocket.emit (node:events:519:28)
at WebSocket.emitClose (/home/mcsorin1/.npm-global/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:273:10)
at Socket.socketOnClose (/home/mcsorin1/.npm-global/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:1346:15)
at Socket.emit (node:events:519:28)
at TCP.<anonymous> (node:net:346:12)
mcsorin1@ubuntu:~$

#

you good?

#

what should i do?

main sequoiaBOT
#

Yep — I’m here.

If you can paste these (from the Jetson / gateway host), I’ll tell you exactly what to run next:

  1. openclaw gateway status --json
  2. cat ~/.openclaw/devices/pending.json
  3. openclaw devices list --json --timeout 5000 (even if it errors — paste the error)

Most likely it’s just “device not approved yet” → approve the requestId and you’re unblocked.

#

You're seeing the Gateway refuse the WebSocket handshake because the connecting client (CLI / TUI / browser profile) is an un‑approved device. Short version: pending pairing requests are stored on the gateway host (~/.openclaw/devices/pending.json) and you can approve them from the gateway host (or make the UI appear local so it’s auto‑approved). Source: memory/2026-02-20.md (device pairing notes).

Below are safe, ordered recovery options and exact commands you can run on the Jetson (gateway) host. If you want, paste the outputs of the three commands at the end and I’ll tell you the exact approve command to run.

  1. Recommended — approve from the gateway host (safest)
  • SSH to the Jetson as the same user that runs the gateway (your config shows /home/mcsorin1/.openclaw):
    ssh mcsorin1@<jetson-ip>
  • Check gateway + pending devices:
    openclaw gateway status --json
    openclaw devices list --json --timeout 5000
  • If devices list returns pending entries, copy the requestId and approve:
    openclaw devices approve <requestId>
  • If the CLI can’t connect (still “pairing required”), inspect the pending file directly:
    cat ~/.openclaw/devices/pending.json
    — find the requestId, then run openclaw devices approve <requestId> from that same host/user.

Notes:

#
  • If the CLI itself is using a stale per‑device token you may see “unauthorized: device token mismatch”. Fix by rotating the client cache:
    mv ~/.openclaw/identity/device-auth.json ~/.openclaw/identity/device-auth.json.bak
    (then retry listing/approving). You can also move ~/.openclaw/identity/device.json to force a fresh fingerprint (this will require re-pairing if you do it).
  • After approving, confirm:
    openclaw gateway status
    openclaw status
    openclaw logs --follow
  1. Quick and safe alternative — make the Control UI look local (auto‑approved)
  • From your laptop create an SSH tunnel so the dashboard appears to be localhost:
    ssh -N -L 18789:127.0.0.1:18789 mcsorin1@<jetson-ip>
  • Open http://127.0.0.1:18789/ in your browser. The browser connection will appear loopback and is usually auto-approved. Use the UI to approve the pending device. Close the tunnel when done.
  1. Break‑glass: temporarily allow token‑only auth (use only if you can’t run the above)
  • Turn on the temporary token‑only mode:
    openclaw config set gateway.controlUi.allowInsecureAuth true
    openclaw gateway restart
#
  • Approve the pending device:
    openclaw devices list
    openclaw devices approve <requestId>
  • Revert immediately:
    openclaw config set gateway.controlUi.allowInsecureAuth false
    openclaw gateway restart

Security warning: allowInsecureAuth opens the UI to token-only auth — revert it immediately after approving.

  1. Last resort — programmatic/manual approve
  • There’s an exported helper in the installed package (approveDevicePairing) used by the CLI. If you’re comfortable with Node and can find the installed bundle, you can call that helper directly instead of using the UI. Example steps to locate:
    npm root -g
    grep -R "approveDevicePairing" $(npm root -g) -n || true
  • Example (adjust path if different):
    node -e "require('/usr/local/lib/node_modules/openclaw/dist/gateway-cli-XXXXX.js').approveDevicePairing('REQUEST_ID','/home/mcsorin1/.openclaw')"
  • Manual edits to paired.json/pending.json are error‑prone — avoid unless you’ve backed up the files.
#

Helpful checks and troubleshooting commands (run on the Jetson/gateway host)

  • openclaw gateway status --json
  • openclaw devices list --json --timeout 5000
  • cat ~/.openclaw/devices/pending.json
  • openclaw config get gateway.auth.token
  • openclaw logs --follow
  • whoami ; echo $HOME ; ls -la ~/.openclaw/devices

If you’d like me to produce the exact approve command for your setup, paste the outputs of these three commands (copy/paste the JSONs/text):

  1. openclaw gateway status --json
  2. cat ~/.openclaw/devices/pending.json
  3. openclaw config get gateway.auth.token

I’ll parse them and give the exact command(s) to run and the minimal, safe followups (and I’ll remind you to revert any temporary insecure settings).

earnest gull
#

claude suggested this could be from most recent error and to downgarde, so i ran this command mcsorin1@ubuntu:~$ openclaw gateway stop
npm install -g openclaw@2026.2.18
openclaw gateway start

🦞 OpenClaw 2026.2.19-2 (45d9b20) — One CLI to rule them all, and one more restart because you changed the port.

Stopped systemd service: openclaw-gateway.service
npm error code ETARGET
npm error notarget No matching version found for openclaw@2026.2.18.
npm error notarget In most cases you or one of your dependencies are requesting
npm error notarget a package version that doesn't exist.
npm error A complete log of this run can be found in: /home/mcsorin1/.npm/_logs/2026-02-20T13_12_00_488Z-debug-0.log

🦞 OpenClaw 2026.2.19-2 (45d9b20) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Restarted systemd service: openclaw-gateway.service
mcsorin1@ubuntu:~$

main sequoiaBOT
#

That ETARGET just means openclaw@2026.2.18 was never published to npm (or got yanked), so nothing changed — you’re still on 2026.2.19-2 (as your banner shows).

If you actually want to downgrade, first list what versions exist

On the Jetson:

openclaw gateway stop
npm view openclaw dist-tags
npm view openclaw versions --json

If you have jq:

npm view openclaw versions --json | jq -r '.[]' | tail -n 30
#

Pick a version that is in that list, then:

npm install -g openclaw@<that-version>
openclaw --version
openclaw doctor
openclaw gateway start

(openclaw doctor is important because after changing installs, the systemd service can still point at the old entrypoint.)

But: your original problem (“gateway closed 1008: pairing required”) usually won’t be fixed by downgrading

It’s almost always just device pairing not approved yet.

Can you paste these outputs from the Jetson (same user that runs the gateway, mcsorin1)?

#
openclaw gateway status --json
cat ~/.openclaw/devices/pending.json
openclaw devices list --json --timeout 5000
earnest gull
#

i dont know if i should downgarde or not. lets keep this version first and try to fix the root issue. what did you need again?

earnest gull
#

ok. im still having the issue. how do i clean uninstall openclaw and reinstall it?

#

@main sequoia

main sequoiaBOT
#

Yep — you can do a clean uninstall/reset. Official guide: https://docs.openclaw.ai/install/uninstall

Clean uninstall (CLI still works) — recommended

On the Jetson (as mcsorin1), run:

openclaw uninstall --all

Non-interactive (fully scripted):

openclaw uninstall --all --yes --non-interactive

This stops/removes the systemd user service and deletes the state dir (~/.openclaw) + workspace.

#

I’m here — Discord mentions don’t always wake me instantly, but I’m watching the thread now.

If you’re going for the full clean reset on the Jetson (as mcsorin1), run:

openclaw uninstall --all --yes --non-interactive

Then reinstall:

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon

If openclaw uninstall fails for any reason, paste the output plus:

#

If you want a “clean reset” but keep a backup (safer than rm -rf)

Do this instead of deleting right away:

openclaw gateway stop
openclaw gateway uninstall
mv ~/.openclaw ~/.openclaw.bak.$(date +%F-%H%M%S)

(Deleting ~/.openclaw will wipe pairing/auth/channel state — you’ll have to re-onboard and re-link things like WhatsApp.)

If the service is still running but the CLI is gone (Linux/systemd)

systemctl --user disable --now openclaw-gateway.service
rm -f ~/.config/systemd/user/openclaw-gateway.service
systemctl --user daemon-reload
#
systemctl --user status openclaw-gateway.service --no-pager
openclaw --version
#
rm -rf ~/.openclaw # or mv it to a .bak like above

Reinstall

Fast path:

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon

Then confirm:

openclaw --version