[patil2001]

Summary

On a Windows host-native install (NATIVE_LLM_BASE_URL set), the in-stack llama-server is put behind the local-inference profile and never starts (docker-compose.host-native-llm.yml). The installer therefore writes LLM_API_URL=http://litellm:4000 and points Hermes at http://litellm:4000/v1 with LITELLM_KEY (installers/phases/06-directories.sh, _default_llm_api_url / _default_hermes_base_url).

ods mode local (and scripts/mode-switch.sh local) ignored that and always wrote LLM_API_URL=http://llama-server:8080 and HERMES_LLM_BASE_URL=http://llama-server:8080/v1. After the restart it asks for, dashboard chat and Hermes point at a container that is not running.

Fix

In both ods-cli cmd_mode and scripts/mode-switch.sh, local mode reads NATIVE_LLM_BASE_URL from .env:

.env	LLM_API_URL	HERMES_LLM_BASE_URL / key
no native LLM (unchanged)	http://llama-server:8080	llama-server:8080/v1 / sk-ods-hermes-local
native LLM	http://litellm:4000	litellm:4000/v1 / LITELLM_KEY
switchboard enabled (unchanged)	as above	model-router:9099/v1 / no-key

These match what the installer writes for the same .env.

Validation

• bash tests/test-mode-switch-status.sh: 25 passed. The 3 new native-LLM checks fail on main and pass with the fix.
• bash -n ods-cli scripts/mode-switch.sh
• git diff --check upstream/main...HEAD

AI Assistance

AI-assisted (Claude Code). The author reviewed the change and the tests.

Release Lane

Patch: CLI behaviour fix, no new config.

Changed Surface

ods/ods-cli, ods/scripts/mode-switch.sh, ods/tests/test-mode-switch-status.sh.

🤖 Generated with Claude Code

Maintainer integration validation

Updated to main 4906514c09bbe25351ad15e67a7c8659f4ad0b27 and resolved the overlap with #7843, retaining both native LiteLLM routing and portable case folding. Exact updated head: 20b5fa52f0512d86d92a0e9b1f83e5a24e69e782.

The combined script passes all 34 cases on the physical Mac Mini's /bin/bash 3.2.57 and WSL Bash 5. An independent fixture using the real CLI cmd_mode, environment loader, and writer covers default, native, switchboard, native-plus-switchboard, and cloud routing: four native-route assertions fail on current main, while all 15 pass on this candidate. External lifecycle operations are stubbed in that fixture; installed configuration is not modified.

A read-only probe from the real Mac dashboard-api container confirms that the old llama-server:8080 route is unreachable there, while authenticated LiteLLM /v1/models returns HTTP 200 and the active local model aliases. This is native-backend transport evidence, not full Windows host-native qualification; the Mac does not use the Windows NATIVE_LLM_BASE_URL profile.

The previous head's failed managed-project CI job passed on retry. All checks on the updated head remain required before merge. Scoped evidence here does not establish fleet green.

Tower2 assisted with review and the conflict resolution. Codex rejected unsupported review findings, verified the source contract, and independently ran the focused checks.

Live generated-route validation

On the physical Mac Mini's Bash 3.2, ran current-main and candidate mode-switch.sh against isolated host-native profiles, then used each generated Hermes URL and key for an actual completion from the installed dashboard-api container. Baseline generated llama-server:8080 and failed to connect. Candidate generated LiteLLM, preserved the gateway key, and returned HTTP 200 with the correct answer 4 in 1.28 seconds. Installed configuration hashes remained unchanged. This validates the changed routing behavior against a real native backend; it does not claim full Windows host-native qualification.

[Lightheartdevs]

Thanks for keeping host-native local mode aligned with the installer's LiteLLM routing and preserving the switchboard override.

Advisory status: not ready yet

Quickest path to merge:

• Resolve the failed managed-project check in Portal project build. The log shows test_project_controller.py::ProjectControllerRuntimeTests::test_complete_pipeline_and_replay_after_reopen failing with engine-info-unavailable after a five-second Docker info timeout, plus both real diagnostic cases in test_project_diagnostics.py (under ods/extensions/services/pixel-agent/tests/). Rerun the job; if it persists, compare with the base revision and attach that evidence for a maintainer decision. The log alone does not establish a routing regression.

What I checked:

• Exact-head diff against installer defaults and the host-native Compose overlay; 69 checks pass and one fails.
• All 25 bash tests/test-mode-switch-status.sh cases pass locally. A separate fixture using the real cmd_mode, load_env, and _env_set confirms the CLI loads LITELLM_KEY from .env and writes the native URL/key correctly. git diff --check is clean.

The routing change looks sound on this evidence; clearing or explaining that CI failure is the remaining step.

[roshangupta00750]

Checked this one: with only the updated tests/test-mode-switch-status.sh on main's ods-cli/mode-switch.sh, the three native-local cases fail (LLM_API_URL stays on llama-server, Hermes too, no LiteLLM key). On this head, 25/25 pass. The new lines in mode-switch.sh use nothing Bash-4-only.

One overlap: #7843 also edits scripts/mode-switch.sh (the ${configured_backend,,} → portable lowercase fix for macOS /bin/bash 3.2), and the two conflict in that file. Whichever lands second needs a rebase. Until #7843 lands, mode-switch.sh local still exits on 3.2 at line 79 before reaching this new branch, the same as on main.