Connect the NemoClaw Stack

The diagram separates three interfaces:

• REST (Representational State Transfer). One request carries all the info necessary to produces one response.
• Model Context Protocol (MCP). A common request format lets a runtime discover and call tools.
• OpenClaw gateway. A WebSocket at /cli/gateway carries JSON-RPC events for the agent session.

The two endpoints you work with from here

The model route is stateless and uses an nvapi- key. The NemoClaw route keeps a running OpenClaw session inside OpenShell. Compare each route's URL, credential, and state below.

Local deployments use the same gateway contract; follow the NemoClaw setup playbook.

Start the launchable

1. Open the NemoClaw launchable and sign in.
2. Open <launchable>/dashboard.
3. Find the running my-assistant card and select Chat with Agent.
4. Return here and enter the launchable URL. If this course is not served by the launchable, paste the launchable's browser access session too.

Your launchable answers on one of two account-specific hostnames. Both are supported, and the probe selects the matching access provider from the hostname:

• https://nemoclaw-<id>.apps.run.brev.nvidia.com uses Pomerium. When the course shares the launchable origin, the browser supplies its signed-in session. Otherwise, paste the complete _pomerium value from the signed-in launchable.
• https://nemoclaw-<id>.brevlab.com uses Cloudflare Access. Its matching CF_Authorization session authenticates the separately hosted course through the approved relay.

Step 1 · Verify the connections

The model probe checks the configured model route. The NemoClaw check then verifies agent metadata, both WebSocket paths, and launchable health in the order later exercises need them.

Model route settings

The model probe is a read-only mirror of the persistent chat route configured on the course home page or in Module 1a. Change it here once; the benchmark and later lessons reuse that route. The NemoClaw launchable settings below remain separate.

Latency and time to first token across models

Before committing to a model, measure it. The cells below pull matching models from the catalog, stream a short prompt through each one, and record each model's time to first token (TTFT) and time to finish. The catalog-fetching cell starts open so the filter list is visible before you run the benchmark.

Inspect one HTTP request

The connection check and exposed code share the normalized launchable connection and provider decision. The helper prints the status, headers, and body after redaction. Change PATH between /api/agent and /healthz to inspect either bootstrap response.

A Pomerium launchable keeps bootstrap and WebSocket traffic direct: HTTP checks run through its terminal loopback. Cloudflare sends HTTP checks through the approved relay; its WebSockets try the launchable first and can recover through the relay. The probe shows the route without displaying the session value.

Step 2 · The gateway

The model endpoint speaks the Chat Completions API, where a single POST carries everything the call needs.

• The request line is a single POST to the completions route.
• The JSON body carries model and messages.
• An Authorization header names the caller.

OpenClaw implements that same route internally too. A separately hosted course reads its metadata through the launchable access layer, then opens authenticated WebSockets directly from the signed-in browser.

The channel that is open to you runs a different protocol, a WebSocket at /cli/gateway speaking JSON-RPC.

That token carries operator.admin scope, the same authority the Control UI holds. With it you can:

• models.list enumerates every model the runtime serves.
• cron.add schedules work that runs without you.
• chat.send with a sessionKey drops a message straight into the running agent's loop.

Check before changing runtime settings

Supported NemoClaw launchables normally report tools.toolSearch=false. A custom configuration can still enable it, so the health check reads the live value before Recover changes anything:

• Symptom: you ask for a command, nothing comes back, the run stalls, and then it times out.
• Cause: toolSearch lets the model reach its tools by writing code for a bridge (tool_search_code · “run bridge code”), and the model loops on that bridge instead of calling exec.
• Recovery: run the health check. If toolSearch is on and the exec probe fails, Recover can turn it off with config.patch. Session clearing and restart remain opt-in.

With the runtime shaped, you can drop a message into the agent's loop. The three cells below run in order so that the first ones connect and list models and crons before a later cell sends a chat turn and the last one streams the trace back. Read that trace row by row:

• Each ⚙️ row is a tool call with its input arguments.
• Each ✓/✗ row is that tool's result.
• The model's reasoning is not forwarded by the gateway, so this input/output trace is the deepest per-step view. When a run stalls with no result, the 📜 logs cell above tails the runtime instead.

Every chat run self-checks: if one logs ⚠ DEGRADED, come back up here, run Recover, then retry.

Step 3 · Memory lives in the session key

Every chat.send takes a sessionKey, and that key decides what the turn remembers:

• Same key, twice: the gateway rehydrates the first turn's history before the second runs, so the agent answers from a conversation your client never re-sent.
• Different key: a clean start, nothing carried over.

The first cell below plants a fact and then asks for it back under the same key. The agent answers from a turn your client never re-sent, because the gateway rehydrated that history server-side. The other two cells let you manage the stored state.

• Clear wipes one session in a single call, so the next turn starts from nothing. Every chat cell also carries a commented sessions.reset line to start fresh in place.
• Clean up sweeps the throwaway sessions that pile up in the Control UI as you experiment (including Step 2's per-run keys), keeping only the Main Session.

What's next

Module 3b opens the files that shape each OpenClaw turn. Module 3c adds skills and scheduled triggers, then Module 4 tests how OpenShell limits the actions those persistent instructions can start.

Try it · talk to your launchable

Once the probe above is green, this artifact opens the same /cli/gateway WebSocket and lets you chat with your live OpenClaw agent. It streams the reply and shows a chip whenever the agent reaches for a tool. Every reply you see here came back over that live gateway connection.