Walkthrough

This PR updates the Ollama bootstrap model registry from qwen2.5:7b to qwen3.5:9b, including the model's memory requirements and download size. The production registry change propagates through derived constants and requires test adjustments across inference, onboarding, and E2E suites to reflect the new model identifier.

Changes

Model Registry and Integration Tests

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• NVIDIA/NemoClaw#3683: The test updates in test/generate-openclaw-config.test.ts adjust the model identifiers used in existing supportsUsageInStreaming assertions for ollama/ollama-local, which relates to PR #3683's ollama-local supportsUsageInStreaming compat behavior.

Suggested labels

Local Models, feature, area: inference, area: local-models, area: providers, v0.0.58

Suggested reviewers

• cv
• ericksoa

Poem

🐰 A nimble model trade, so neat and clean,
From seven-point-five to nine-point-three we've seen,
Qwen's newer sibling takes the smallest role,
Tests across the realm now reach their goal,
One registry change ripples through them all! ✨

❌ Failed checks (1 warning)

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• gpu-e2e (high; requires linux-amd64 GPU runner and pulls an Ollama model): Required because the source change affects local Ollama onboarding and inference. This is the existing live GPU/Ollama E2E that installs Ollama, runs NemoClaw onboarding with NEMOCLAW_PROVIDER=ollama, pulls a model, creates a sandbox, and verifies Ollama-backed inference through OpenShell/OpenClaw.

Optional E2E

• gpu-double-onboard-e2e (high; requires linux-amd64 GPU runner and repeated Ollama onboarding): Useful adjacent confidence for Ollama re-onboarding and auth-proxy token consistency after changing the bootstrap model registry, but less directly tied to the model metadata change than the single onboarding GPU proof.
• ollama-proxy-e2e (medium; installs Ollama and pulls a small CPU model): Optional host-side validation for real Ollama plus auth proxy reachability/auth/inference. It does not exercise the changed bootstrap registry directly, but it covers adjacent local Ollama proxy behavior touched by nearby tests.
• strict-tool-call-probe-e2e (low to medium; hermetic mock, no GPU/Ollama infrastructure): Optional hermetic regression for local Ollama model validation/tool-call probe behavior. The PR changes Ollama capability/model-selection tests, but the live registry tag change is better covered by gpu-e2e.

New E2E recommendations

• local-ollama-bootstrap-model (high): Existing GPU E2Es typically run on high-VRAM GPUs and may select a larger registry model, so they might not prove that the new smallest fallback qwen3.5:9b is actually pulled, routed, and usable end-to-end.
  • Suggested test: Add a targeted Ollama GPU E2E variant or scenario that pins NEMOCLAW_MODEL=qwen3.5:9b (or constrains detected available memory) and verifies install/onboard, model pull, Dockerfile/OpenClaw config, and sandbox inference.
• e2e-gpu-model-defaults (medium): The Brev/GPU E2E harness default changes to qwen3.5:9b, but workflow-level env defaults can still pin older model names. Coverage should catch stale E2E model pins when the registry smallest tag changes.
  • Suggested test: Add a lightweight CI assertion that E2E workflow defaults for NEMOCLAW_GPU_E2E_MODEL match SMALLEST_OLLAMA_MODEL_TAG or intentionally override it with an explicit comment.

Dispatch hint

• Workflow: .github/workflows/nightly-e2e.yaml
• jobs input: gpu-e2e

E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required scenario E2E

• gpu-repo-local-ollama-openclaw: The PR changes the Ollama bootstrap model registry, including the smallest/default local Ollama model metadata. The only dispatchable scenario that exercises local Ollama onboarding and inference is gpu-repo-local-ollama-openclaw.
  • Dispatch: gh workflow run e2e-scenarios.yaml --ref <pr-head-ref> --field scenarios=gpu-repo-local-ollama-openclaw

Optional scenario E2E

• None.

Relevant changed files

• src/lib/inference/ollama-model-registry.ts

🛠️ Needs attention

• None.

🔎 Worth checking

• Source-of-truth review needed: Ollama starter model registry metadata: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: `src/lib/inference/ollama-model-registry.ts` sets `qwen3.5:9b` with `requiredMemoryMB: 12_000` and `downloadSizeBytes: 6_600_000_000`; tests mostly assert table mirroring or mocked capabilities.
• Source-of-truth review needed: Ollama starter model defaults across runtime and workflow validation: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: `.github/workflows/e2e-branch-validation.yaml:266` still uses `'qwen2.5:7b'`, while `test/e2e/brev-e2e.test.ts` now falls back to `'qwen3.5:9b'` only when `NEMOCLAW_GPU_E2E_MODEL` is unset.
• Branch GPU E2E still defaults to the old Ollama starter (.github/workflows/e2e-branch-validation.yaml:266): The PR changes `test/e2e/brev-e2e.test.ts` so its local fallback is `qwen3.5:9b`, but the branch-validation workflow exports `NEMOCLAW_GPU_E2E_MODEL` with a fallback of `qwen2.5:7b`. Because the test only uses its internal fallback when that environment variable is absent, this workflow path will continue exercising the old model by default. That leaves the main runtime/sandbox validation path out of sync with the PR's stated replacement of the starter model.
  • Recommendation: Update the workflow fallback to `qwen3.5:9b`, or remove the workflow override so the test's fallback is used. If the old value is intentionally retained for capacity reasons, document that exception and add separate validation for the new default.
  • Evidence: `test/e2e/brev-e2e.test.ts` now uses `process.env.NEMOCLAW_GPU_E2E_MODEL || "qwen3.5:9b"`, while `.github/workflows/e2e-branch-validation.yaml:266` still sets `NEMOCLAW_GPU_E2E_MODEL: ${{ vars.NEMOCLAW_GPU_E2E_MODEL || 'qwen2.5:7b' }}`.
• New default model metadata is manually trusted (src/lib/inference/ollama-model-registry.ts:37): The new starter model's tag, 12 GB fit threshold, 6.6 GB fallback download size, and tool-capable behavior are now central to onboarding decisions, but the changed tests mostly assert that code paths mirror the registry table or use mocked capability responses. An incorrect tag or size would still pass these unit fixtures and surface only during runtime pull/probe or user onboarding.
  • Recommendation: Add or identify an independent validation for the new registry entry: verify that `qwen3.5:9b` exists at the expected Ollama manifest URL, that the fallback size is close enough to the actual download size, that it supports tools, and that the 12 GB boundary is intentional. A targeted boundary unit test for 11,999 MB versus 12,000 MB would also make the changed fit threshold explicit.
  • Evidence: `OLLAMA_MODEL_REGISTRY` now contains `{ tag: "qwen3.5:9b", requiredMemoryMB: 12_000, downloadSizeBytes: 6_600_000_000 }`. The registry tests assert derived behavior, and `test/ollama-tools-capability.test.ts` mocks `/api/show` as returning `capabilities: ["completion", "tools"]` rather than proving the real model capability.

🌱 Nice ideas

• None.