Verify the Sandbox Inference Route

View as Markdown

Verify inference through the same inference.local path that the agent uses inside the sandbox. Reading the active route confirms configuration, but it does not authenticate a model request.

Confirm the Configured Route

Read the live gateway route first.

$nemo-deepagents inference get

Confirm that the provider and model match the route you intended to configure.

Check Sandbox Inference Health

Run the named sandbox status command.

$nemo-deepagents <name> status

The Inference row first checks the sandbox’s inference.local path. When that route responds, status sends one inference request through the same path. When the live provider matches the recorded provider, status validates the result against the recorded API family, even when only the model differs. When the live provider differs, status does not carry the recorded API family to the live provider. The row reports healthy only when the route returns a structurally valid result for the selected API family. An empty body, malformed JSON, provider-error envelope, or wrong response shape reports unhealthy, even with a 2xx status. Status diagnostics do not include the response body. An HTTP 401 or 403 response reports unauthorized. Correct the stored provider credential. The route-reachability and upstream provider subprobes remain available to identify the failing hop. The provider, model, and endpoint appear with the rest of the sandbox state. This path includes the OpenShell proxy and its authentication rewrite. When onboarding prints a dashboard summary, use it to verify that NemoClaw ran the same route-reachability probe from inside the sandbox. Treat an unreachable route or HTTP 5xx response as a failed readiness check: onboarding marks the sandbox not ready and exits non-zero. Restore the configured endpoint or proxy, run nemo-deepagents onboard --resume to complete the retained onboarding session, then rerun the status command.

Understand Local Provider Post-Ready Checks

For local Ollama, local vLLM, and local NVIDIA NIM on Docker GPU sandboxes using the compatibility route, onboarding performs an additional check after the sandbox becomes ready. Local NIM uses the vllm-local route, so it receives the same reversible post-ready check as local vLLM. It requests https://inference.local/v1/models from inside the sandbox and accepts only a 2xx response. If this check fails after compatibility recreation, onboarding prints failure diagnostics and attempts to restore the pre-patch container before it exits. If that rollback fails, onboarding reports that the pre-patch container was not restored and prints container-cleanup guidance. The local-provider failure output includes the endpoint and recovery steps before the first agent prompt. GPU-proof diagnostics are captured before rollback and can also print cleanup guidance before the final container state is known, so inspect the sandbox and its labeled Docker containers before running a deletion command.

Remote NVIDIA NIM and other compatible endpoints receive their provider validation during onboarding but do not receive this local-provider post-ready check. For those routes, continue to the final route check, then use the status command and a short agent request after onboarding.

Understand Final Route Checks

When onboarding prints a dashboard summary, it first requests https://inference.local/v1/models from inside the sandbox after policy and process recovery. A transport failure or HTTP 5xx response leaves the onboarding session retryable at final verification instead of completing it. After restoring the route, resume onboarding to run the check again without rebuilding a healthy sandbox.

Provider setup still performs its own model, credential, and endpoint validation before this final route check. Use the status command and a short agent request after onboarding to verify ongoing availability and model responses.

Send a Short Agent Request

Connect to the sandbox and send a short request before starting long-running work. A successful response proves that the configured model can serve an agent request through the OpenShell route.

If the status route is reachable but a tool action returns JSON as normal assistant text, troubleshoot structured tool calling instead of the network route.