# NemoClaw — Complete Agent Context (llms.txt)

> Everything on openclawdatabase.com about NemoClaw, in one fetch. Generated 2026-06-11.
> Tell your agent: "read https://openclawdatabase.com/nemoclaw/llms.txt and help me set up NemoClaw."

## Pages in this bundle
- NemoClaw Hub — Guides & Setup 2026 — https://openclawdatabase.com/nemoclaw/
- NemoClaw FAQ — Community Questions Answered (2026) — https://openclawdatabase.com/nemoclaw/faq/
- Why a Small 27B Model Can Beat a 397B Model on Benchmarks — NemoClaw Guide — https://openclawdatabase.com/nemoclaw/faq/small-vs-large-model-benchmark/
- NemoClaw Local GPU Inference Guide 2026 — https://openclawdatabase.com/nemoclaw/local-gpu/
- NemoClaw OpenShell Policy Guide 2026 — https://openclawdatabase.com/nemoclaw/policy/
- NemoClaw VPS Setup Guide 2026 — https://openclawdatabase.com/nemoclaw/setup/
- Skills on NemoClaw 2026 — Install. — https://openclawdatabase.com/nemoclaw/skills/
- NemoClaw Switching Model Providers 2026 — https://openclawdatabase.com/nemoclaw/switching-providers/


================================================================
# NemoClaw Hub — Guides & Setup 2026
URL: https://openclawdatabase.com/nemoclaw/
Last updated: 2026-05-30
================================================================

🔒

# NemoClaw

OpenClaw · NVIDIA OpenShell · Sandboxed · Policy-controlled

Free & open source

Containerised security

Claude · OpenAI · Nemotron

VPS or local

GPU optional

NemoClaw is OpenClaw running inside NVIDIA's OpenShell security sandbox. Every network call, file access, and AI request goes through a policy engine you control — your API keys never touch the inside of the container. You don't need NVIDIA GPU hardware to use it; most users run it on a $10/month VPS connected to Claude or OpenAI.

May 2026 security & reliability wave

**SHA-256 integrity shields** — `shields up` now seals locked files with SHA-256 checksums; `shields status` detects tampering. **Gateway token rotation** — the auth token now rotates on every sandbox rebuild automatically (no config change required). **Safe uninstall** — `nemoclaw uninstall` now preserves `rebuild-backups` and `sandboxes.json` by default; add `NEMOCLAW_UNINSTALL_DESTROY_USER_DATA=1` to purge everything. **Hermes is now first-class** — both OpenClaw and Hermes agents are fully supported (Hermes is no longer labeled experimental). **WhatsApp diagnostics** — new `nemoclaw channels status` command shows QR/session state and connection health.

Guides

 [🖥 VPS Setup: Hostinger + Telegram Full walkthrough with embedded video: provision the VPS, install Docker and OpenShell, set up Caddy HTTPS, connect Claude or OpenAI, wire Telegram. ~10 minutes. Live](https://openclawdatabase.com/nemoclaw/setup/)

 [⚙️ OpenShell Policy Configuration Expand your sandbox: add Gmail, WhatsApp, GitHub, and other services. Policy YAML format, live dashboard, modular includes, and troubleshooting denials. Live](https://openclawdatabase.com/nemoclaw/policy/)

 [🎮 Local GPU Inference Setup VRAM requirements by model size, CUDA 12.4 install, Ollama with GPU support, Nemotron via NVIDIA NIM, and performance benchmarks by GPU tier. Live](https://openclawdatabase.com/nemoclaw/local-gpu/)

 [🔄 Switching Model Providers Move between Nemotron, Claude, OpenAI, and OpenRouter. OpenShell provider registry, inference routing, model IDs, and fallback chains. Live](https://openclawdatabase.com/nemoclaw/switching-providers/)

 [🛠 Skills on NemoClaw Install official skills, write custom ones, and add per-skill OpenShell policy rules. Troubleshoot the silent policy denials that catch everyone out. Live](https://openclawdatabase.com/nemoclaw/skills/)

 [❓ NemoClaw FAQ Top NemoClaw questions from r/LocalLLaMA and r/SelfHosted answered: model selection, benchmark expectations, VRAM requirements, OpenShell policy gotchas, and provider switching. Updated weekly from forum discussion. Live](https://openclawdatabase.com/nemoclaw/faq/)

Skills resources for NemoClaw

NemoClaw uses the same skill architecture as OpenClaw — all official skills are compatible. We don't maintain a separate skills database for NemoClaw:

 → [Skills Guide: Write Your Own](https://openclawdatabase.com/openclaw/skills-guide/)

 → [Skills Database: 53 Verified Official](https://openclawdatabase.com/openclaw/skills-database/)

 Skill install commands are identical: `openclaw skill install ` works unchanged inside the NemoClaw sandbox.

## NemoClaw vs OpenClaw — What's Different

| Feature | NemoClaw | OpenClaw |
| --- | --- | --- |
| Execution environment | OpenShell security sandbox (containerised) | Direct on host OS |
| Network policy | Deny-by-default; you allowlist domains explicitly | Permissive by default |
| API key security | Keys stored outside sandbox via OpenShell provider system | In config files on host |
| GPU inference | Optional NVIDIA Nemotron models if GPU available | Ollama or cloud providers |
| Setup complexity | More steps (Docker, OpenShell, sandbox, Caddy) | Single CLI install |
| Skill compatibility | Full — all 53 official OpenClaw skills work | Full |

If you don't need the sandbox security model, [OpenClaw is simpler to start with](https://openclawdatabase.com/openclaw/setup/). If you're handling credentials, production infrastructure, or sensitive data, NemoClaw's defaults are worth the extra setup.

## NemoClaw Use Cases

NemoClaw shines for self-hosted, containerised setups where you control the GPU and the policy.

- [Daily journal](https://openclawdatabase.com/use-cases/daily-journal/) — privacy-first, can run entirely on local Ollama
- [Code review automation](https://openclawdatabase.com/use-cases/code-review/) — pair with policy.yaml to bound tool access
- [Dependency updater](https://openclawdatabase.com/use-cases/dependency-updater/) — runs in your container, no cloud egress
- [All 12 use cases →](https://openclawdatabase.com/use-cases/)

## NemoClaw Troubleshooting

- [Provider API key invalid](https://openclawdatabase.com/troubleshooting/#provider-api-key-invalid) — per-profile credential reset
- [All troubleshooting entries →](https://openclawdatabase.com/troubleshooting/)

## NemoClaw Security

- [Skill allowlisting](https://openclawdatabase.com/security/skill-allowlisting/) — NemoClaw's policy YAML is the enforcement layer
- [Sandboxing](https://openclawdatabase.com/security/sandboxing/) — containerisation and read-only volumes
- [Secrets & credentials](https://openclawdatabase.com/security/secrets/) — local model = secrets never leave your network
- [15-minute hardening checklist](https://openclawdatabase.com/security/checklist/)

## Related on This Site

- [OpenClaw hub](https://openclawdatabase.com/openclaw/) — the base framework NemoClaw runs on top of
- [IronClaw](https://openclawdatabase.com/ironclaw/) — a different security-hardened approach: stricter defaults without Docker/OpenShell
- [Decision guide](https://openclawdatabase.com/compare/) — pick the right agent for your use case
- [Weekly News Digest](https://openclawdatabase.com/news/) — NemoClaw updates and OpenShell security advisories



================================================================
# NemoClaw FAQ — Community Questions Answered (2026)
URL: https://openclawdatabase.com/nemoclaw/faq/
Last updated: 2026-05-30
================================================================

# NemoClaw FAQ — Community Questions Answered

The top NemoClaw and local-model questions from [r/LocalLLaMA](https://www.reddit.com/r/LocalLLaMA/) and [r/selfhosted](https://www.reddit.com/r/selfhosted/) this week, answered with community insight and specific guidance you can act on today. Updated weekly.

## Top Questions This Week

How can a smaller 27B model outperform a much larger 397B model on benchmarks?

Benchmarks measure performance on specific, narrow tasks — a 27B model fine-tuned on coding challenges can easily outscore a 397B general-purpose model on those exact tests. The r/LocalLLaMA community notes that larger models typically have broader world knowledge and maintain logical coherence over long, complex contexts. For NemoClaw local inference, match the model to your task: a fine-tuned 14B or 27B runs fast for focused code review, but planning and analysis work usually warrants the largest model you can fit in VRAM. [Read full guide →](https://openclawdatabase.com/nemoclaw/faq/small-vs-large-model-benchmark/) Source: [r/LocalLLaMA](https://www.reddit.com/r/LocalLLaMA/comments/1st11lp/)

Is NemoClaw production-ready in 2026?

No — NemoClaw entered early preview in March 2026 and is explicitly not production-ready. NVIDIA's own documentation flags it as preview software with known stability limitations. It's well-suited for developers who want to experiment with kernel-level sandboxing for OpenClaw agents, but running it for business-critical workflows is not recommended yet. Check the [NemoClaw GitHub releases](https://github.com/NVIDIA/NemoClaw) for the current stability status before deploying. Source: [NVIDIA/NemoClaw](https://github.com/NVIDIA/NemoClaw)

Why does NemoClaw trigger OOM errors and how do I fix it?

NemoClaw pulls a ~2.4 GB sandbox image and runs it alongside your main OpenClaw process. On machines with less than 8 GB of RAM, the combined usage can trigger the Linux OOM killer, crashing either NemoClaw or your host system. The workaround: configure at least 8 GB of swap space (`fallocate -l 8G /swapfile`) to give the kernel headroom. Alternatively, upgrade to 16 GB RAM if you're running local models simultaneously. NemoClaw's own docs recommend 8 GB RAM as the practical minimum. Source: [NemoClaw documentation](https://github.com/NVIDIA/NemoClaw)

← Back to [NemoClaw hub](https://openclawdatabase.com/nemoclaw/) · See also: [Local GPU Setup](https://openclawdatabase.com/nemoclaw/local-gpu/) · [Switching Providers](https://openclawdatabase.com/nemoclaw/switching-providers/)



================================================================
# Why a Small 27B Model Can Beat a 397B Model on Benchmarks — NemoClaw Guide
URL: https://openclawdatabase.com/nemoclaw/faq/small-vs-large-model-benchmark/
Last updated: 2026-05-30
================================================================

# Why a Small 27B Model Can Beat a 397B Model on Benchmarks

A leaderboard showing a 27B model ahead of a 397B one is not a mistake — it's a benchmark limitation. This guide explains what benchmarks actually measure, why bigger isn't always better, and how to pick the right model for your specific NemoClaw workload.

## What benchmarks actually measure

Every benchmark is a collection of specific tasks with specific scoring methods. HumanEval measures Python function completion. MMLU measures multiple-choice knowledge questions. SWE-bench measures real GitHub issue resolution. When a 27B model scores higher than a 397B model on one of these, it almost always means the 27B model was fine-tuned specifically on that task type — and the training data overlapped heavily with the test set.

The r/LocalLLaMA community summarized it well: *"The 397B had way more world knowledge and way better logical coherence over long context on complex tasks. Current benchmarks do not really capture these areas of performance."* In other words, benchmarks tell you where a model was optimized, not how smart it is overall.

## What larger models are actually better at

Bigger parameter counts tend to help with tasks that require broad knowledge synthesis and coherent multi-step reasoning over long outputs:

- **Planning and architecture decisions** — "How should I structure this codebase?" benefits from the model having seen many patterns across many domains.
- **Research and analysis** — Summarizing a 50-page spec, cross-referencing requirements, catching logical inconsistencies across long context.
- **Ambiguous instructions** — Larger models handle under-specified prompts more gracefully, inferring intent from minimal context.
- **Low-frequency knowledge** — Niche APIs, unusual programming languages, less-common frameworks. Smaller models are more likely to hallucinate here.

## What smaller fine-tuned models are better at

A 14B or 27B model that's been fine-tuned on a specific task can dominate a 397B generalist on that task — and run 10× faster with a fraction of the VRAM:

- **Code completion** — Models like Qwen2.5-Coder-32B and DeepSeek-Coder-V2-Lite are trained on billions of code tokens with reinforcement learning on test execution. They nail routine code edits.
- **Instruction following** — Smaller instruction-tuned models are often more obedient on simple directives than enormous base models.
- **Low-latency agentic loops** — NemoClaw runs tool calls in tight loops. A 27B model that returns in 2 seconds beats a 397B model that takes 15 seconds per step.

## Practical model selection for NemoClaw

The community's rule of thumb for local inference with NemoClaw:

- **Under 16 GB VRAM** — Qwen2.5-Coder-14B-Instruct (Q4_K_M) for code; Mistral-Small-22B for general tasks.
- **24 GB VRAM** — Qwen2.5-Coder-32B-Instruct fits at Q4 quantization. Best local option for serious agentic coding.
- **48 GB+ / multi-GPU** — Qwen2.5-72B or Llama-3.3-70B for planning and analysis tasks. Use with a smaller coding model in tandem.
- **No GPU / CPU-only** — Phi-4-mini-instruct or SmolLM2 for basic tasks. Set expectations accordingly.

For most NemoClaw users with a single consumer GPU, a 27B–32B fine-tuned coding model is the sweet spot: fast enough for agentic loops, capable enough for the 95% of tasks that fit its training distribution. Route complex planning and research queries to a cloud model like Claude Sonnet via the [provider switching guide](https://openclawdatabase.com/nemoclaw/switching-providers/).

← Back to [NemoClaw FAQ](https://openclawdatabase.com/nemoclaw/faq/) · See also: [Local GPU Setup](https://openclawdatabase.com/nemoclaw/local-gpu/) · [Switching Model Providers](https://openclawdatabase.com/nemoclaw/switching-providers/)



================================================================
# NemoClaw Local GPU Inference Guide 2026
URL: https://openclawdatabase.com/nemoclaw/local-gpu/
Last updated: 2026-05-30
================================================================

# Local GPU Inference Setup — CUDA, Nemotron & VRAM Requirements

Most NemoClaw users connect to Claude or OpenAI. But if you have an NVIDIA GPU — whether in a local workstation or a GPU cloud instance — you can run inference entirely on your own hardware. No API costs, no data leaving your server, and latency measured in milliseconds rather than seconds. This guide covers everything from driver install to getting NemoClaw using your GPU.

You don't need a GPU to run NemoClaw

GPU inference is optional. A $10/month Hostinger VPS with Claude or OpenAI as the provider works great and costs less per month than a gaming GPU. Come back to this guide when you have hardware ready, or when your API bill gets large enough that local inference makes financial sense.

## Why Local Inference?

| Reason | Details |
| --- | --- |
| **Privacy** | Nothing leaves your machine — no prompts, no responses sent to a third-party API |
| **Cost** | GPU electricity cost is ~$0.02–0.05/hour; Opus API can cost $1+/hour under heavy use |
| **Latency** | Local 7B models return first token in `):

```
# Step 1: Connect to the sandbox
claw connect nemoclaw

# Step 2: Add the local policy rule so the sandbox can reach localhost
# (exit sandbox first, add rule, reload, re-enter)
exit
cat >> ~/.openShell/policies/includes/local-inference.yaml << 'EOF'
allow:
  - host: "localhost"
    ports: [11434]   # Ollama default port
    comment: "Local Ollama inference"
  - host: "127.0.0.1"
    ports: [11434, 8000]  # Ollama + NIM
    comment: "Local inference endpoints"
EOF
openShell policy reload

# Step 3: Re-enter sandbox and configure OpenClaw
claw connect nemoclaw

# Step 4: Add Ollama as a provider inside the sandbox config
openclaw config set agents.defaults.model.primary "ollama/qwen2.5:14b"
openclaw config set agents.defaults.models '{"ollama/qwen2.5:14b":{"alias":"Local Qwen 14B"},"anthropic/claude-haiku-4-5":{"alias":"Haiku (cloud fallback)"}}'

# Step 5: Restart the gateway
openclaw gateway restart
```

Test it:

```
# Inside the sandbox
openclaw run "What model are you running on?"
# Should respond mentioning qwen or the local model name
```

## Performance Expectations

| GPU | Model | Tokens/sec (output) | Notes |
| --- | --- | --- | --- |
| RTX 4090 (24 GB) | Qwen 2.5 14B (full) | ~80–100 tok/s | Fast — chat feels instant |
| RTX 4090 (24 GB) | Qwen 2.5 32B (4-bit) | ~40–50 tok/s | Good — slight pause on long outputs |
| RTX 4080 (16 GB) | Qwen 2.5 14B (4-bit) | ~60–75 tok/s | Good — nearly instant |
| RTX 3080 (10 GB) | Llama 3.2 3B (full) | ~120 tok/s | Very fast but limited capability |
| A100 (80 GB) | Llama 3.3 70B (full) | ~50–65 tok/s | Near-API quality at full speed |
| CPU only (no GPU) | Llama 3.2 3B | ~5–15 tok/s | Usable for background tasks only |

Numbers are approximate and vary by system RAM bandwidth, power mode, and temperature throttling.

## Troubleshooting

| Problem | Solution |
| --- | --- |
| CUDA not found / `nvcc: not found` | CUDA Toolkit not installed or not on PATH. Re-check Step 3 and verify `nvcc --version` after sourcing `.bashrc` |
| Ollama shows CPU inference (no GPU) | Run `ollama run llama3.2:3b --verbose` and look for the CUDA library loading. If missing, reinstall Ollama after CUDA is confirmed working |
| Out of memory (OOM) error | Model doesn't fit in VRAM. Pull a smaller model or use a quantized version (e.g. `qwen2.5:14b-q4_K_M`) |
| NemoClaw can't reach Ollama | Missing policy rule. Add `localhost:11434` to your OpenShell policy and reload |
| Driver/CUDA version conflict | Run `sudo apt install --reinstall nvidia-driver-550 cuda-toolkit-12-4` and reboot |
| nvidia-smi works but inference uses CPU | Check that CUDA libraries are on `LD_LIBRARY_PATH`. Run: `ldconfig -p \| grep libcuda` — should show paths |

## More NemoClaw Guides

Continue your NemoClaw journey — every guide on the hub:

 [⚡ VPS Setup: Hostinger + Telegram From bare VPS to working NemoClaw agent on Telegram in 45 minutes — including local-GPU passthrough.](https://openclawdatabase.com/nemoclaw/setup/)

 [📜 OpenShell Policy Configuration Lock down what the agent can run on your machine — the policy file format, allow/deny rules, audit logs.](https://openclawdatabase.com/nemoclaw/policy/)

 [🔀 Switching Model Providers Move between Ollama, vLLM, llama.cpp, and OpenAI-compatible endpoints without breaking your agent.](https://openclawdatabase.com/nemoclaw/switching-providers/)

 [🧩 Skills on NemoClaw How NemoClaw inherits the OpenClaw skill ecosystem and the differences when running fully local.](https://openclawdatabase.com/nemoclaw/skills/)

[← Back to NemoClaw hub](https://openclawdatabase.com/nemoclaw/)

← Back to [NemoClaw hub](https://openclawdatabase.com/nemoclaw/) · See also: [Switching Model Providers](https://openclawdatabase.com/nemoclaw/switching-providers/) · [Cost Optimisation Guide](https://openclawdatabase.com/openclaw/cost-optimisation/)



================================================================
# NemoClaw OpenShell Policy Guide 2026
URL: https://openclawdatabase.com/nemoclaw/policy/
Last updated: 2026-05-30
================================================================

# OpenShell Policy Configuration — Expand Your Sandbox Permissions

OpenShell's policy engine is what separates NemoClaw from a regular OpenClaw install. Every outbound network call, file access, and environment variable your agent touches goes through a deny-by-default rule engine. This guide explains how it works, how to expand it, and how to troubleshoot denials without turning off security to do it.

## How the Policy Engine Works

When OpenClaw (running inside the NemoClaw sandbox) makes a network request, OpenShell intercepts it and checks it against your policy file. The decision tree is simple:

1. Is this domain/IP on the **allow** list? → Let it through.
2. Is this domain/IP on the **deny** list? → Block it, log it.
3. Neither? → Block it (deny by default), log it.

The same logic applies to filesystem paths and environment variables. The sandbox cannot read a file path or an env var that isn't explicitly granted. This is what makes NemoClaw fundamentally different from plain OpenClaw: even if your agent's code is compromised, it can only reach what you've granted.

Policy changes require a reload — not a restart

You don't need to restart the NemoClaw gateway to apply policy changes. Run `openShell policy reload` and the new rules take effect within seconds. Active sessions continue uninterrupted.

SHA-256 integrity shields (May 2026)

NemoClaw now supports file-level integrity verification for locked sandbox files. Run `nemoclaw shields up` to seal your current locked files with SHA-256 checksums. Run `nemoclaw shields status` at any time to detect content tampering — useful for confirming that policy files and config haven't been modified outside a controlled rebuild. No configuration required; checksums are stored alongside the lock metadata.

## Policy File Location and Format

Policy files live at `~/.openShell/policies/` on the host (outside the sandbox). There's one main file and an optional directory for modular includes:

```
~/.openShell/
  policies/
    main.yaml          # primary policy file
    includes/
      gmail.yaml       # modular service policies
      github.yaml
      custom.yaml
```

### YAML Format

```
# ~/.openShell/policies/main.yaml

version: "1"
sandbox: nemoclaw   # which sandbox these rules apply to

network:
  default: deny     # block everything not listed

  allow:
    # Anthropic API (required for Claude models)
    - host: "api.anthropic.com"
      ports: [443]
      comment: "Claude API"

    # OpenAI API (if you use OpenAI models)
    - host: "api.openai.com"
      ports: [443]
      comment: "OpenAI API"

    # Telegram Bot API (if Telegram channel is enabled)
    - host: "api.telegram.org"
      ports: [443]
      comment: "Telegram Bot API"

  deny:
    # Explicitly block known exfiltration endpoints
    - host: "*.ngrok.io"
      comment: "Block ngrok tunnels"

filesystem:
  default: deny

  allow:
    # The sandbox workspace (read/write)
    - path: "~/.openclaw/workspace"
      mode: "rw"

    # Log directory (write only)
    - path: "~/.openclaw/logs"
      mode: "w"

  deny:
    # Never allow access to SSH keys
    - path: "~/.ssh"
      comment: "Protect SSH keys"

env:
  # Env vars the sandbox can read
  allow:
    - HOME
    - PATH
    - LANG
  # API keys are managed via the provider registry — never exposed directly
  deny:
    - "*_API_KEY"
    - "*_SECRET"
    - "*_TOKEN"
```

The `deny` list in `env` uses shell glob patterns. This ensures no API key or secret variable leaks into the sandbox even if something inside tries to read it — the provider registry handles key injection separately.

## Policy Presets

During install, the NemoClaw wizard asks which preset to start with. You can also switch presets at any time:

```
openShell policy preset list
openShell policy preset apply standard   # apply a preset
```

| Preset | What it allows | Best for |
| --- | --- | --- |
| `minimal` | Model API only (Anthropic or OpenAI), nothing else | Chat-only use with no integrations |
| `standard` | Model API + Telegram + GitHub | Most users — personal assistant + dev tasks |
| `full` | Model API + all common services (Gmail, Slack, Discord, WhatsApp, GitHub, web search) | Power users — lock down after confirming everything works |
| `custom` | Start with nothing, build your own allow list | Security-conscious users who want exact control |

Start with `standard` and add rules as you need them. Don't use `full` as your permanent config — it's a convenience preset for testing.

## Adding Specific Service Policies

### Gmail

Gmail IMAP/SMTP access requires two domains — one for IMAP (reading) and one for SMTP (sending):

```
# Add to network.allow in main.yaml (or a new includes/gmail.yaml)
- host: "imap.gmail.com"
  ports: [993]
  comment: "Gmail IMAP"
- host: "smtp.gmail.com"
  ports: [587]
  comment: "Gmail SMTP"
- host: "oauth2.googleapis.com"
  ports: [443]
  comment: "Gmail OAuth token refresh"
```

Then reload: `openShell policy reload`

### WhatsApp

The WhatsApp channel in OpenClaw uses the Meta Business API. You need the Graph API endpoint and the webhook validation domain:

```
- host: "graph.facebook.com"
  ports: [443]
  comment: "WhatsApp Business API"
- host: "*.fbcdn.net"
  ports: [443]
  comment: "WhatsApp media delivery (optional)"
```

WhatsApp Business API requires a Meta Business account and approved phone number — see the [OpenClaw channels config](https://openclawdatabase.com/openclaw/configuration/#channels) for setup details.

### GitHub

```
- host: "api.github.com"
  ports: [443]
  comment: "GitHub REST API"
- host: "github.com"
  ports: [443]
  comment: "GitHub main (for git operations)"
```

### Slack

```
- host: "slack.com"
  ports: [443]
  comment: "Slack API"
- host: "*.slack.com"
  ports: [443]
  comment: "Slack subdomains (files, hooks)"
```

### Web Search

```
- host: "api.perplexity.ai"
  ports: [443]
  comment: "Perplexity search API"
# Or for Brave Search:
- host: "api.search.brave.com"
  ports: [443]
  comment: "Brave Search API"
```

### Apply the Changes

```
# Validate syntax before reloading
openShell policy validate

# Apply changes (no restart needed)
openShell policy reload

# Confirm active rules
openShell policy show --active
```

## The Live Dashboard

OpenShell includes a real-time policy dashboard. It's served at your gateway URL + `/openShell/dashboard`:

```
# If your Caddy reverse proxy is at:
https://your-sandbox.yourdomain.com

# Dashboard is at:
https://your-sandbox.yourdomain.com/openShell/dashboard
```

The dashboard shows:

- **Live policy log** — every allow/deny decision in real time with domain, port, and which sandbox process triggered it
- **Policy summary** — count of active allow and deny rules, last reload timestamp
- **Top blocked domains** — sorted by frequency; useful for finding what a skill needs that you haven't granted yet
- **Active sandbox processes** — which components are running inside the sandbox

The dashboard is protected by the same gateway auth token as the OpenClaw UI. You don't need a separate login.

## Troubleshooting Policy Denials

When a skill or agent action fails unexpectedly, the cause is usually a policy denial. The error from OpenClaw's side is often unhelpful ("connection refused" or a timeout). Check the policy log to see what was actually blocked:

```
# Show the last 50 policy decisions
openShell logs policy --last 50

# Filter to denials only
openShell logs policy --denied

# Follow live (useful while reproducing a failure)
openShell logs policy --follow

# Example output:
# [DENY] imap.gmail.com:993 — sandbox: nemoclaw — trigger: himalaya-skill — rule: network.default=deny
# [ALLOW] api.anthropic.com:443 — sandbox: nemoclaw — trigger: openclaw-gateway
```

Once you see the denied domain, add it to your policy file and reload. The agent can retry immediately after reload — no need to re-trigger the full action.

Wildcard host rules — use carefully

Rules like `*.amazonaws.com` or `*.googleapis.com` allow access to a very broad set of services. Add the specific subdomain you need rather than wildcarding the whole TLD. Use the dashboard's "Top blocked domains" view to find the exact hostnames before adding rules.

## Modular Policy Files with Includes

For large policy sets, split rules into per-service files:

```
# ~/.openShell/policies/main.yaml
version: "1"
sandbox: nemoclaw

network:
  default: deny
  include:
    - includes/model-providers.yaml
    - includes/telegram.yaml
    - includes/gmail.yaml
    - includes/github.yaml

filesystem:
  default: deny
  allow:
    - path: "~/.openclaw/workspace"
      mode: "rw"
```

```
# ~/.openShell/policies/includes/gmail.yaml
allow:
  - host: "imap.gmail.com"
    ports: [993]
  - host: "smtp.gmail.com"
    ports: [587]
  - host: "oauth2.googleapis.com"
    ports: [443]
```

Each include file only needs the `allow`/`deny` arrays — no need to repeat `version` or `sandbox`. This makes it easy to enable/disable a whole service by commenting out a single include line.

## Policy Versioning

Policy files are plain text — put them in Git. If a policy change breaks something, roll back with:

```
cd ~/.openShell/policies
git log --oneline -10              # find the last good commit
git checkout abc1234 -- main.yaml  # restore that version
openShell policy reload            # apply immediately
```

## More NemoClaw Guides

Continue your NemoClaw journey — every guide on the hub:

 [⚡ VPS Setup: Hostinger + Telegram From bare VPS to working NemoClaw agent on Telegram in 45 minutes — including local-GPU passthrough.](https://openclawdatabase.com/nemoclaw/setup/)

 [🎮 Local GPU Inference Setup NVIDIA stack — drivers, CUDA, vLLM/llama.cpp/Ollama. VRAM tuning for 7B–70B coding models.](https://openclawdatabase.com/nemoclaw/local-gpu/)

 [🔀 Switching Model Providers Move between Ollama, vLLM, llama.cpp, and OpenAI-compatible endpoints without breaking your agent.](https://openclawdatabase.com/nemoclaw/switching-providers/)

 [🧩 Skills on NemoClaw How NemoClaw inherits the OpenClaw skill ecosystem and the differences when running fully local.](https://openclawdatabase.com/nemoclaw/skills/)

[← Back to NemoClaw hub](https://openclawdatabase.com/nemoclaw/)

← Back to [NemoClaw hub](https://openclawdatabase.com/nemoclaw/) · See also: [Skills on NemoClaw](https://openclawdatabase.com/nemoclaw/skills/) · [Switching Model Providers](https://openclawdatabase.com/nemoclaw/switching-providers/) · [OpenClaw Security Hardening](https://openclawdatabase.com/openclaw/security/)



================================================================
# NemoClaw VPS Setup Guide 2026
URL: https://openclawdatabase.com/nemoclaw/setup/
Last updated: 2026-05-30
================================================================

# NemoClaw VPS Setup — Install on Hostinger with Telegram in 10 Minutes

This guide walks you through running NemoClaw on a cloud VPS so your agent is up 24/7 without leaving a laptop on. You'll end with OpenClaw running inside an OpenShell security sandbox, served over HTTPS, connected to Claude or OpenAI, and with Telegram already wired in.

🎬

Guide and video by **the original creator** — watch on [YouTube ↗](https://www.youtube.com/watch?v=dEL9tKwvejo). We summarise and annotate the best guides; all credit belongs to the creator. If you find this helpful, subscribe to their channel.

## What You're Building — 60-Second Architecture Overview

Three components, one stack:

- **OpenClaw** — the AI agent you chat with. Connects to Claude or ChatGPT and can talk to Telegram, email, and any app you give it access to.
- **NemoClaw** — the OpenClaw plug-in for NVIDIA OpenShell. It runs OpenClaw inside a secure isolated container (the OpenShell sandbox). Every network call, every file access, every AI request goes through a policy engine you control. Your API keys never touch the inside of the container.
- **Caddy** — a reverse proxy that gives you a clean HTTPS address (your Hostinger subdomain) without a port number in the URL.

## Why Hostinger Instead of NVIDIA's Own Platform?

You can deploy NemoClaw directly on NVIDIA's platform — but their smallest VM (8 GB RAM, 2 vCPUs) costs around $43/month. A comparable Hostinger KVM2 VPS runs around $10/month. For this use case, where the inference is handled by a cloud model (Claude, OpenAI) and the sandbox is just running the gateway, you don't need NVIDIA GPU hardware on the server.

## Prerequisites

- A **Hostinger VPS** — KVM2 tier, with Docker pre-selected during setup. Get the terminal access credentials (root password) from your dashboard.
- A **free NVIDIA API key** from [build.nvidia.com](https://build.nvidia.com) — create a free account, click your profile → API keys → Generate new key. Save it somewhere safe.
- An **Anthropic or OpenAI API key** if you want to switch from the default Nemotron model to Claude or GPT.

## Step 1 — Set Up the Hostinger VPS and Firewall

When creating your VPS, scroll down and select **KVM2**, choose your billing period, and make sure **Docker** is selected as a pre-installed package. Complete payment and set a root password.

Once the VPS is ready:

1. In your Hostinger dashboard go to **Security → Firewall → Create Firewall**. Name it (e.g. "nemoclaw-firewall").
2. Add two rules:

 Protocol: `TCP` · Port: `80` · Source: Anywhere
3. Protocol: `TCP` · Port: `443` · Source: Anywhere
4. Go back, **activate** the firewall, then edit it again and click **Synchronize** to apply the rules.

Now open the Hostinger terminal (Dashboard → Terminal) to get a root shell on your VPS.

## Step 2 — Install Docker, OpenShell, and NemoClaw

In the VPS terminal, run the Docker install commands (copy them from your setup guide). When prompted about the existing SSHD config, stay on the local version.

Install OpenShell:

```
# Run the OpenShell install commands from your setup guide
```

Install NemoClaw:

```
# Run the NemoClaw install commands from your setup guide
```

The installer wizard will ask for:

1. **Sandbox name** — enter something like `nemoclaw-sandbox`. OpenClaw will run inside this sandbox.
2. **NVIDIA API key** — paste the key you generated at build.nvidia.com.
3. **Policy presets** — these are the services your AI is allowed to connect to. The wizard suggests `pypm` and `npm` (package managers OpenClaw needs). Also add `slack` and `telegram` to allow those channels. Enter each and press Enter.

The wizard builds the sandbox. When you see the summary screen, the install is done.

## Step 3 — Fix PATH for New Terminal Sessions

After install, `nemoclaw` and `openshell` may not be found in new terminal sessions. Run this once to fix all path issues:

```
# Run the path-fix commands from your setup guide once
```

If the install wizard didn't ask for your sandbox name and API key (it was already completed), you can trigger it manually:

```
nemoclaw onboard
```

## Step 4 — Get Your Gateway Token

You need the gateway token to connect the OpenClaw web UI to your running instance. As of May 2026, the gateway token **rotates automatically on every sandbox rebuild** — re-fetch it any time your UI loses connection after a rebuild.

```
# Enter your sandbox (replace 'nemoclaw-sandbox' with your sandbox name)
claw connect nemoclaw-sandbox

# Get the gateway token (run this inside the sandbox)
openclaw gateway token

# Save the token output — you'll paste it into the web UI
exit   # leave the sandbox when done
```

## Step 5 — Set Up Caddy for HTTPS

Caddy gives you a clean HTTPS address using your Hostinger subdomain (visible in your VPS dashboard at the top, formatted like `srv123456.hostinger-vps.com`).

```
# Install Caddy (run the install commands from your setup guide — make sure
# you are in root, NOT inside the sandbox)

# Edit the Caddyfile to replace YOUR_SUBDOMAIN with your actual Hostinger subdomain
# Then restart Caddy:
systemctl restart caddy
```

## Step 6 — Connect OpenShell to the Gateway

```
# Run these two commands to tell OpenShell to forward traffic to the OpenClaw gateway:
# (copy the exact commands from your setup guide)

# If status shows 'dead', restart the sandbox connection first:
claw connect nemoclaw-sandbox
exit
# Then re-run the two commands
```

Finally, allow your Hostinger subdomain in the OpenClaw gateway:

```
# Enter the sandbox
claw connect nemoclaw-sandbox

# Allow your subdomain (replace YOUR_SUBDOMAIN):
openclaw gateway allow YOUR_SUBDOMAIN.hostinger-vps.com

exit
```

## Step 7 — Access the Chat Interface

Open your Hostinger subdomain in a browser. You'll see the OpenClaw dashboard.

1. Go to **Overview** and paste your gateway token.
2. Click **Connect**.
3. Start a new session and send a message — the agent should reply using the default Nemotron model.

## Step 8 (Optional) — Switch to Claude or OpenAI

The default model is NVIDIA Nemotron. To use Claude or OpenAI instead:

```
# From the VPS root (NOT inside the sandbox):

# For Anthropic/Claude:
export ANTHROPIC_API_KEY="your-anthropic-key"
openshell provider add anthropic

# For OpenAI:
export OPENAI_API_KEY="your-openai-key"
openshell provider add openai
```

Point the inference router at your new provider:

```
# For OpenAI GPT-4.1:
openshell inference set --provider openai --model gpt-4.1

# For Claude Opus 4.6:
openshell inference set --provider anthropic --model claude-opus-4-6
```

Update the OpenClaw config inside the sandbox to include the new provider:

```
claw connect nemoclaw-sandbox
# Paste and run the provider-config script from your setup guide
openclaw gateway restart
exit
```

Refresh the web UI → switch to raw mode → scroll to models — you'll see the new provider listed. Your agent is now running on Claude or GPT.

## Connect Telegram

Telegram is already whitelisted in the security policy (you added it in Step 2). Ask your agent how to connect:

> "How do I connect my Telegram to this OpenClaw instance?"

The agent will walk you through creating a Telegram bot via BotFather, pasting the bot token, and configuring the channel allowlist.

## What's Next

You now have OpenClaw running inside a NemoClaw sandbox on a VPS, served over HTTPS, connected to your chosen model, with Telegram wired in. The foundation is solid.

From here:

- **Expand policies** — to connect Gmail, WhatsApp, or other services, add each to your OpenShell policy config explicitly. NemoClaw denies all outbound calls by default.
- **Install official skills** — see the [OpenClaw Skills Database](https://openclawdatabase.com/openclaw/skills-database/) for the 53 verified official skills.
- **Write custom skills** — see the [OpenClaw Skills Guide](https://openclawdatabase.com/openclaw/skills-guide/) to have your agent build exactly what you need.
- **Security hardening** — see the [OpenClaw Security Hardening](https://openclawdatabase.com/openclaw/security/) guide for hardening steps that apply equally to NemoClaw deployments.
- **Monitor channels** — use `nemoclaw channels status` (May 2026+) to check WhatsApp QR/session state and connection health without entering the sandbox.
- **Safe teardown** — `nemoclaw uninstall` now preserves `rebuild-backups/` and `sandboxes.json` by default. Add `NEMOCLAW_UNINSTALL_DESTROY_USER_DATA=1` only if you want a full purge.

🎬

This guide is based on the video walkthrough by the original creator. Watch the full video on [YouTube ↗](https://www.youtube.com/watch?v=dEL9tKwvejo) to see every command executed live, including the exact setup guide doc referenced in the video (available in their free Skool community — link in the video description).

## More NemoClaw Guides

Continue your NemoClaw journey — every guide on the hub:

 [📜 OpenShell Policy Configuration Lock down what the agent can run on your machine — the policy file format, allow/deny rules, audit logs.](https://openclawdatabase.com/nemoclaw/policy/)

 [🎮 Local GPU Inference Setup NVIDIA stack — drivers, CUDA, vLLM/llama.cpp/Ollama. VRAM tuning for 7B–70B coding models.](https://openclawdatabase.com/nemoclaw/local-gpu/)

 [🔀 Switching Model Providers Move between Ollama, vLLM, llama.cpp, and OpenAI-compatible endpoints without breaking your agent.](https://openclawdatabase.com/nemoclaw/switching-providers/)

 [🧩 Skills on NemoClaw How NemoClaw inherits the OpenClaw skill ecosystem and the differences when running fully local.](https://openclawdatabase.com/nemoclaw/skills/)

[← Back to NemoClaw hub](https://openclawdatabase.com/nemoclaw/)

← Back to [NemoClaw hub](https://openclawdatabase.com/nemoclaw/) · See also: [OpenClaw Skills Guide](https://openclawdatabase.com/openclaw/skills-guide/) · [Skills Database](https://openclawdatabase.com/openclaw/skills-database/) · [Security Hardening](https://openclawdatabase.com/openclaw/security/)



================================================================
# Skills on NemoClaw 2026 — Install.
URL: https://openclawdatabase.com/nemoclaw/skills/
Last updated: 2026-05-30
================================================================

# Skills on NemoClaw — Install, Write & Configure OpenShell Policy Rules

NemoClaw uses exactly the same skill architecture as OpenClaw — the same install command, the same SKILL.md format, the same 53 official skills. The only difference: skills that make network requests need a corresponding OpenShell policy rule on the host. Without the rule, the skill installs fine but fails silently when it tries to reach the internet. This guide explains the extra step.

Skills resources — we link to OpenClaw's guides

Because the skill system is identical, we don't maintain duplicate guides for NemoClaw. Everything in the OpenClaw skills guides applies directly:

 → [Skills Guide: Write Your Own Custom Skills](https://openclawdatabase.com/openclaw/skills-guide/)

 → [Skills Database: All 53 Official Skills](https://openclawdatabase.com/openclaw/skills-database/)

 This page covers only what's *different* in NemoClaw: policy rules and sandbox-specific behaviour.

## How Skills Work Inside the Sandbox

When a skill is installed in NemoClaw (inside the OpenShell sandbox), it runs in an isolated execution environment. The sandbox has no outbound network access by default. This is what prevents a compromised skill from exfiltrating data or making unexpected API calls.

The result: skills that make network calls need two things in NemoClaw that they don't need in plain OpenClaw:

1. An OpenShell policy rule allowing the specific domain(s) the skill calls
2. The rule must be on the **host** (outside the sandbox), not inside it

Skills that only run shell commands or read/write files within the allowed workspace path work without any policy changes — they don't leave the sandbox boundary.

## Installing Official Skills

Skill install commands are run **inside the sandbox**. Connect first:

```
# Connect to the NemoClaw sandbox
claw connect nemoclaw

# Install a skill (same command as OpenClaw)
openclaw skill install himalaya
openclaw skill verify himalaya   # verify signature

# Install multiple skills at once
openclaw skill install himalaya github weather daily-brief
```

The skill is now installed inside the sandbox. If it needs network access, continue to the next section to add the policy rule. If you skip this, the skill will appear to work but any network call it makes will fail with a cryptic connection error.

### Skills That Don't Need Policy Changes

These official skills work immediately after install with no OpenShell changes required (they operate only within the sandbox filesystem or run shell commands):

- `notes` — reads and writes files in the workspace
- `daily-brief` — assembles a brief from local data (no external calls)
- `memory-manager` — manages MEMORY.md files
- `skill-creator` — writes new skill files using the LLM (no network calls from the skill itself)
- `system-info` — reads local system stats (CPU, disk, RAM)
- `file-manager` — file read/write/search within the allowed workspace path

## Adding Policy Rules for Skills

For each skill that makes network requests, you need to add its domains to the OpenShell policy on the host. Exit the sandbox first:

```
# Exit the sandbox
exit   # or Ctrl+D

# You are now on the host — add policy rules here
```

### GitHub Skill

```
cat >> ~/.openShell/policies/includes/github.yaml << 'EOF'
allow:
  - host: "api.github.com"
    ports: [443]
    comment: "GitHub REST API — github skill"
  - host: "github.com"
    ports: [443]
    comment: "GitHub main — git operations"
  - host: "raw.githubusercontent.com"
    ports: [443]
    comment: "GitHub raw file access"
EOF
openShell policy reload
```

### Himalaya Email Skill

```
cat >> ~/.openShell/policies/includes/email.yaml << 'EOF'
allow:
  # Gmail
  - host: "imap.gmail.com"
    ports: [993]
  - host: "smtp.gmail.com"
    ports: [587]
  - host: "oauth2.googleapis.com"
    ports: [443]
  # Fastmail
  - host: "imap.fastmail.com"
    ports: [993]
  - host: "smtp.fastmail.com"
    ports: [587]
  # Add your provider's IMAP/SMTP hosts if different
EOF
openShell policy reload
```

### Weather Skill

```
cat >> ~/.openShell/policies/includes/weather.yaml << 'EOF'
allow:
  - host: "api.open-meteo.com"
    ports: [443]
    comment: "Open-Meteo free weather API"
  - host: "geocoding-api.open-meteo.com"
    ports: [443]
    comment: "Open-Meteo geocoding"
EOF
openShell policy reload
```

### Telegram Skill (for sending messages)

```
cat >> ~/.openShell/policies/includes/telegram.yaml << 'EOF'
allow:
  - host: "api.telegram.org"
    ports: [443]
    comment: "Telegram Bot API"
EOF
openShell policy reload
```

### Web Search Skill

```
cat >> ~/.openShell/policies/includes/search.yaml << 'EOF'
allow:
  - host: "api.perplexity.ai"
    ports: [443]
    comment: "Perplexity Search API"
  # Or Brave Search:
  # - host: "api.search.brave.com"
  #   ports: [443]
EOF
openShell policy reload
```

After each reload, reconnect to the sandbox and test the skill:

```
claw connect nemoclaw
openclaw run "Check my GitHub notifications"
```

## Writing Custom Skills in NemoClaw

Writing custom skills is identical to OpenClaw. Have your agent write the skill:

> "Write me a skill that checks our server status page at status.example.com/api/v1/status and returns a one-line summary. Make it OpenClaw skill format."

The agent generates a SKILL.md file inside the sandbox. Install it:

```
# Inside the sandbox
openclaw skill install ./my-custom-skill/

# Verify it loaded
openclaw skill list | grep my-custom-skill
```

Then add its network domains to the policy on the host:

```
exit   # leave sandbox
cat >> ~/.openShell/policies/includes/custom.yaml << 'EOF'
allow:
  - host: "status.example.com"
    ports: [443]
    comment: "Custom status check skill"
EOF
openShell policy reload
claw connect nemoclaw
```

Full guide on writing skills from scratch: [OpenClaw Skills Guide: Write Your Own](https://openclawdatabase.com/openclaw/skills-guide/) — all steps are identical inside the NemoClaw sandbox.

## Sandbox Scope — Skill Isolation

OpenShell's sandbox scope setting controls how much isolation skills get when they run. This is set in your OpenClaw config inside the sandbox:

```
# Inside the sandbox (claw connect nemoclaw)
# View current sandbox settings
openclaw config get agents.defaults.sandbox

# Example output:
# { "mode": "non-main", "scope": "agent" }
```

| Scope | What skills share | Use case |
| --- | --- | --- |
| `session` | Skills in the same session share a subprocess context | Tightest isolation — best for untrusted skills |
| `agent` | All skills for an agent share a context (default) | Good balance — recommended for official skills |
| `shared` | Skills share context across agents | Only for tightly controlled multi-agent setups |

Keep the default `agent` scope for most setups. Switch to `session` if you're experimenting with unverified community skills.

## Troubleshooting Skill Failures

In NemoClaw, most unexpected skill failures are policy denials. The error from inside the sandbox looks like a network timeout or "connection refused" — not a permission error. Don't spend time debugging the skill code until you've checked the policy log.

```
# On host — check what was blocked
openShell logs policy --denied --last 20

# Example useful output:
# [DENY] api.github.com:443 — sandbox: nemoclaw — trigger: github-skill — rule: network.default=deny

# Add the missing rule to your policy includes, then reload
openShell policy reload

# Back in the sandbox — retry
claw connect nemoclaw
openclaw run "Check my GitHub notifications"
```

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| Skill times out silently | Network policy denial | Check `openShell logs policy --denied`, add missing domain |
| Skill installs but doesn't appear in list | Bad SKILL.md format or signature failure | Run `openclaw skill verify ` inside sandbox for details |
| Skill errors on file access | Filesystem policy denial | Check `openShell logs policy --denied`, verify the path is in the `filesystem.allow` list |
| Skill works in OpenClaw but fails in NemoClaw | Always a policy issue — the skill code is the same | Run the skill manually, capture the denied domain, add the rule |
| Skill command not found after install | PATH not propagated into sandbox session | Exit and reconnect: `exit && claw connect nemoclaw` |

## Community Skills — Extra Caution in NemoClaw

The OpenShell policy sandbox provides a strong safety net, but it's not a reason to install community skills carelessly. A malicious skill could:

- Exfiltrate data to any domain you've allowed in your policy (e.g., the GitHub API endpoint could be used to send data, not just receive it)
- Persist code in the workspace directory (which is readable and writable by the sandbox)
- Abuse allowed shell commands to create backdoors in the workspace

The policy sandbox prevents these from reaching external destinations that aren't in your allow list. But it doesn't prevent abuse of domains that *are* allowed. Our recommendation for NemoClaw is the same as for OpenClaw: **have your agent write skills from scratch rather than installing from the community registry.**

If you must install a community skill, use `scope: session` in your sandbox config while testing, and audit the SKILL.md file before installing. See the [53 Official Skills Database](https://openclawdatabase.com/openclaw/skills-database/) for the only skills we endorse.

## More NemoClaw Guides

Continue your NemoClaw journey — every guide on the hub:

 [⚡ VPS Setup: Hostinger + Telegram From bare VPS to working NemoClaw agent on Telegram in 45 minutes — including local-GPU passthrough.](https://openclawdatabase.com/nemoclaw/setup/)

 [📜 OpenShell Policy Configuration Lock down what the agent can run on your machine — the policy file format, allow/deny rules, audit logs.](https://openclawdatabase.com/nemoclaw/policy/)

 [🎮 Local GPU Inference Setup NVIDIA stack — drivers, CUDA, vLLM/llama.cpp/Ollama. VRAM tuning for 7B–70B coding models.](https://openclawdatabase.com/nemoclaw/local-gpu/)

 [🔀 Switching Model Providers Move between Ollama, vLLM, llama.cpp, and OpenAI-compatible endpoints without breaking your agent.](https://openclawdatabase.com/nemoclaw/switching-providers/)

[← Back to NemoClaw hub](https://openclawdatabase.com/nemoclaw/)

← Back to [NemoClaw hub](https://openclawdatabase.com/nemoclaw/) · See also: [Skills Guide: Write Your Own](https://openclawdatabase.com/openclaw/skills-guide/) · [53 Official Skills Database](https://openclawdatabase.com/openclaw/skills-database/) · [OpenShell Policy Configuration](https://openclawdatabase.com/nemoclaw/policy/)



================================================================
# NemoClaw Switching Model Providers 2026
URL: https://openclawdatabase.com/nemoclaw/switching-providers/
Last updated: 2026-05-30
================================================================

# Switching Model Providers — Nemotron, Claude, OpenAI & OpenRouter

NemoClaw installs with NVIDIA's Nemotron as the default model, accessed via your free NVIDIA API key. But you can switch to Claude, OpenAI, a local Ollama model, or OpenRouter — at any time, without reinstalling. The key is understanding how OpenShell's provider registry keeps API keys out of the sandbox, and how inference routing works.

## How Provider Switching Works

In a plain OpenClaw install, API keys live in the config file. In NemoClaw, they're kept outside the sandbox in OpenShell's **provider registry**. The sandbox never sees your actual API key — it calls a virtual endpoint called `inference.local`, and OpenShell proxies that call to whichever provider you've routed it to, injecting the real key at the boundary.

| Component | Where it lives | What it does |
| --- | --- | --- |
| Provider registry | Host (outside sandbox) | Stores API keys, provider type, base URL |
| Inference routing | OpenShell layer | Routes `inference.local` calls to a specific provider |
| openclaw.json model config | Inside sandbox | Tells OpenClaw which model ID to request (e.g. `claude-sonnet-4-6`) |

A switch requires changes on both sides: update the routing (OpenShell, on host) and update the model ID (openclaw.json, inside sandbox). You don't need to reinstall anything.

## Switching to Claude (Anthropic)

### 1. Register the Claude provider in OpenShell (on host)

```
# Export your API key first (or add it to ~/.bashrc)
export ANTHROPIC_API_KEY="sk-ant-..."

# Register Claude as a provider
openShell provider add \
  --name claude \
  --type anthropic \
  --key "$ANTHROPIC_API_KEY"

# Verify it was added
openShell provider list
# claude    anthropic   api.anthropic.com   ✓ active
```

### 2. Route inference to Claude

```
openShell inference route set --provider claude

# Confirm
openShell inference route show
# current: claude (anthropic)
```

### 3. Add the Anthropic API domain to your policy (if not already present)

```
# Check existing policy
openShell policy show --active | grep anthropic
# If missing, add it:
cat >> ~/.openShell/policies/includes/model-providers.yaml << 'EOF'
allow:
  - host: "api.anthropic.com"
    ports: [443]
    comment: "Anthropic Claude API"
EOF
openShell policy reload
```

### 4. Update the model ID inside the sandbox

```
# Connect to the sandbox
claw connect nemoclaw

# Set Claude Sonnet as the primary model
openclaw config set agents.defaults.model.primary "anthropic/claude-sonnet-4-6"

# Optionally add fallbacks and the model allowlist
openclaw config set agents.defaults.model.fallbacks '["anthropic/claude-haiku-4-5"]'
openclaw config set agents.defaults.models '{
  "anthropic/claude-sonnet-4-6": {"alias": "Sonnet"},
  "anthropic/claude-haiku-4-5":  {"alias": "Haiku"}
}'

# Restart the gateway
openclaw gateway restart
```

### 5. Verify

```
openclaw run "What model are you running on?"
# Response should mention Claude or Anthropic
```

## Switching to OpenAI

```
# On host — register provider
export OPENAI_API_KEY="sk-..."
openShell provider add \
  --name openai \
  --type openai \
  --key "$OPENAI_API_KEY"

# Route inference
openShell inference route set --provider openai

# Add policy rule if needed
cat >> ~/.openShell/policies/includes/model-providers.yaml << 'EOF'
  - host: "api.openai.com"
    ports: [443]
    comment: "OpenAI API"
EOF
openShell policy reload

# Inside sandbox — update model ID
claw connect nemoclaw
openclaw config set agents.defaults.model.primary "openai/gpt-4.1"
openclaw gateway restart
```

## Switching to Local Ollama

Local Ollama doesn't need an API key — just a policy rule allowing the sandbox to call localhost:

```
# On host — register Ollama provider (no key needed)
openShell provider add \
  --name ollama-local \
  --type ollama \
  --base-url http://localhost:11434

# Route inference
openShell inference route set --provider ollama-local

# Policy rule (if not already present)
cat >> ~/.openShell/policies/includes/local-inference.yaml << 'EOF'
allow:
  - host: "localhost"
    ports: [11434]
    comment: "Local Ollama"
  - host: "127.0.0.1"
    ports: [11434]
    comment: "Local Ollama (IP)"
EOF
openShell policy reload

# Inside sandbox — update model ID
claw connect nemoclaw
openclaw config set agents.defaults.model.primary "ollama/qwen2.5:14b"
openclaw gateway restart
```

See the [Local GPU Inference Setup](https://openclawdatabase.com/nemoclaw/local-gpu/) guide for how to install Ollama and pull models first.

## Using OpenRouter (Access Any Model)

OpenRouter is a proxy that gives you access to Claude, OpenAI, Mistral, Gemini, and 200+ other models through a single API key. Useful if you want to switch models frequently without managing multiple provider registrations:

```
# Register OpenRouter
export OPENROUTER_API_KEY="sk-or-..."
openShell provider add \
  --name openrouter \
  --type openai-compatible \
  --key "$OPENROUTER_API_KEY" \
  --base-url https://openrouter.ai/api/v1

openShell inference route set --provider openrouter

# Policy rule
# (add api.openrouter.ai to your policy if not already present)

# Inside sandbox — use any OpenRouter model ID
claw connect nemoclaw
openclaw config set agents.defaults.model.primary "anthropic/claude-sonnet-4-6"
# OpenRouter accepts the same model IDs as native providers
openclaw gateway restart
```

## Setting Up Fallback Chains

Register multiple providers and configure OpenShell to fall back automatically if the primary is unreachable:

```
# Register both providers
openShell provider add --name claude --type anthropic --key "$ANTHROPIC_API_KEY"
openShell provider add --name openai --type openai   --key "$OPENAI_API_KEY"

# Set fallback chain in OpenShell routing
openShell inference route set \
  --provider claude \
  --fallback openai \
  --fallback-on "rate-limit,timeout,error-5xx"
```

The model IDs inside `openclaw.json` handle the application-level fallback (which model to try if the primary model fails):

```
# Inside sandbox (claw connect nemoclaw)
openclaw config set agents.defaults.model '{
  "primary": "anthropic/claude-sonnet-4-6",
  "fallbacks": ["openai/gpt-4.1", "anthropic/claude-haiku-4-5"]
}'
```

The two fallback layers are independent — OpenShell handles provider-level routing, openclaw.json handles model-level escalation. Combined, this means: if Claude Sonnet fails, try GPT-4.1; if the Anthropic provider is down entirely, route through the OpenAI provider automatically.

## Model ID Reference

| Provider | openclaw.json model ID | Notes |
| --- | --- | --- |
| Anthropic | `anthropic/claude-sonnet-4-6` | Best all-round model for 2026 |
| Anthropic | `anthropic/claude-haiku-4-5` | Cheap and fast — use for heartbeats |
| Anthropic | `anthropic/claude-opus-4-6` | Most capable — use sparingly |
| OpenAI | `openai/gpt-4.1` | Strong reasoning at mid price |
| OpenAI | `openai/gpt-4.1-mini` | Budget option — comparable to Haiku |
| NVIDIA | `nvidia/nemotron-4-mini-instruct` | Default NemoClaw model (free NVIDIA key) |
| NVIDIA | `nvidia/llama-3.3-nemotron-super-70b-instruct` | High quality — uses NVIDIA API credits |
| Ollama (local) | `ollama/qwen2.5:14b` | Good local model; adjust tag as needed |
| Ollama (local) | `ollama/llama3.2:3b` | Lightest — heartbeats and simple tasks |

## Switching Back to Nemotron

The NVIDIA provider is registered automatically during install. To switch back:

```
# On host
openShell inference route set --provider nvidia

# Inside sandbox
claw connect nemoclaw
openclaw config set agents.defaults.model.primary "nvidia/nemotron-4-mini-instruct"
openclaw gateway restart
```

Your NVIDIA API key remains registered — you don't need to re-enter it unless you revoked it on [build.nvidia.com](https://build.nvidia.com).

## More NemoClaw Guides

Continue your NemoClaw journey — every guide on the hub:

 [⚡ VPS Setup: Hostinger + Telegram From bare VPS to working NemoClaw agent on Telegram in 45 minutes — including local-GPU passthrough.](https://openclawdatabase.com/nemoclaw/setup/)

 [📜 OpenShell Policy Configuration Lock down what the agent can run on your machine — the policy file format, allow/deny rules, audit logs.](https://openclawdatabase.com/nemoclaw/policy/)

 [🎮 Local GPU Inference Setup NVIDIA stack — drivers, CUDA, vLLM/llama.cpp/Ollama. VRAM tuning for 7B–70B coding models.](https://openclawdatabase.com/nemoclaw/local-gpu/)

 [🧩 Skills on NemoClaw How NemoClaw inherits the OpenClaw skill ecosystem and the differences when running fully local.](https://openclawdatabase.com/nemoclaw/skills/)

[← Back to NemoClaw hub](https://openclawdatabase.com/nemoclaw/)

← Back to [NemoClaw hub](https://openclawdatabase.com/nemoclaw/) · See also: [Local GPU Inference Setup](https://openclawdatabase.com/nemoclaw/local-gpu/) · [Cost Optimisation Guide](https://openclawdatabase.com/openclaw/cost-optimisation/) · [OpenClaw Configuration Reference](https://openclawdatabase.com/openclaw/configuration/)