Switching between local models / Serving issues

[Novacane01]

My Setup & Environment

• OS: Windows 10/11 (running natively via launch-windows.ps1, no Docker).

• Hardware: Intel Arc A770 (16GB VRAM).

• My Binary: A custom-compiled native Windows llama-server.exe with optimized SYCL/Vulkan support, sitting in ~\vulkan\bin.

• Models: Local GGUF files (Gemma 4 4B and a 26B IQ4_NL non-linear quant).

Problem

I want to serve my local models using the Cookbook UI so I can hotswap between different sizes (like flipping between 4B and 26B) on the fly with a single click, without having to manually go back to my terminal to kill and restart llama-server every time.
The Problem

When I try to click "Serve" in the Cookbook UI, the server crashes immediately with a 127 error or spits out a WinError 10061 (Connection Refused) error.

The Virtual Environment (venv) hides the system PATH

Even though ~\vulkan\bin is set up in my global Windows environment variables, the Python venv running Odysseus scrubs or isolates the path context. Because of this, shutil.which("llama-server") evaluates to None inside the app. Odysseus then assumes I don't have the binary at all and tries to force a local source-compilation fallback loop, which fails because my machine doesn't have a full C++ compiler toolchain setup (error: failed-wheel-build-for-install).

What I've Tried So Far

1. Manual API Loopback: Running my custom llama-server.exe string directly in a standalone PowerShell window works perfectly and utilizes my Intel Arc beautifully. But this completely locks the port to a single model file. Changing models requires a manual terminal restart, defeating the purpose of the UI hotswap.
2. Ollama Backend: Ollama handles the VRAM flushing and automated hotswapping over its API perfectly, but it's way too slow. It defaults to a generic runner that abstracts away low-level controls, losing the massive speed advantages of my custom SYCL/Vulkan binary.
3. Modifying PowerShell Environment Scripts: I tried manually appending the path in the launch-windows.ps1 script which solved the issue of llama.cpp not being found by odysseus but that still didn't fix the serve error.
4. Isolated Script vs. App Layer: I wrote a quick test script inside the venv context that hardcodes the path to bash.exe and forces os.environ["PATH"]. Running that script from my open terminal spins up the model and translates the Bash syntax flawlessly. However, the second the exact same logic is triggered through the Odysseus UI backend via the "Launch" button, the runtime manager strips the path context again, causing the process to fail.

[CoolJohn-lab]

is it something dumb like you don't have /v1/ in your custom endpoint URL so it won't connect to it?