When starting KoboldCPP with --routermode --admin --admindir <dir> --config <model.kcpps> you would expect the first request to the server - specifying the same model name - to run directly since it is already loaded. Instead it causes an unnecessary model swap/reload:
Admin: Received request to reload config to Qwen3.6-35B-A3B-UD-IQ4_NL.gguf + jinja.kcpps
Reloading new model/config: ...
Terminating old process...
Restarting KoboldCpp...
Note that the model being reloaded is the exact same one already running. After the reload, subsequent requests are handled fine. This whole song and dance takes comparatively little time since its all presumably already cached into vram, but it still feels odd that it's happening twice for no reason.
I threw my clanker at it and he identified the following as the cause:
The model loads correctly — the reload is triggered by the router proxy's internal comparison logic, which uses a separate variable (current_model) that wasn't updated when the model was loaded via --config.
The router proxy (koboldcpp.py line ~4823) compares the request's model field against current_model. If they differ, it triggers a reload. However, current_model is initialized to "initial_model" at startup and only gets updated to the actual model name when the admin manager loop processes a restart_target — which doesn't happen for the startup --config model.
So the flow is:
- KoboldCPP starts with
--config "Qwen3.6-..." → model loads correctly
current_model remains "initial_model" (never updated)
- API request arrives with
"model": "Qwen3.6-..."
- Router proxy compares:
"Qwen3.6-..." != "initial_model" → triggers reload
- Reload sends the same model — no-op in practice, but still a full restart cycle
The API endpoint GET /api/v1/model reports the correct model, confirming the model loading itself works fine. The bug is isolated to the router proxy's internal state not being initialized for the startup model.
Relevant code points:
current_model initialized to "initial_model" at koboldcpp.py:84 and :10870 (admin mode MP init)
- Only updated at
:10990 when admin manager processes a restart_target — never for startup --config model
- Router proxy comparison at
:4823: if model_name and model_name != global_memory["current_model"]:
- Reload triggered at
:4842: conn.request("POST", "/api/admin/reload_config", body=reqbody, headers=reqheaders)
When starting KoboldCPP with
--routermode --admin --admindir <dir> --config <model.kcpps>you would expect the first request to the server - specifying the same model name - to run directly since it is already loaded. Instead it causes an unnecessary model swap/reload:Note that the model being reloaded is the exact same one already running. After the reload, subsequent requests are handled fine. This whole song and dance takes comparatively little time since its all presumably already cached into vram, but it still feels odd that it's happening twice for no reason.
I threw my clanker at it and he identified the following as the cause:
The model loads correctly — the reload is triggered by the router proxy's internal comparison logic, which uses a separate variable (
current_model) that wasn't updated when the model was loaded via--config.The router proxy (
koboldcpp.pyline ~4823) compares the request'smodelfield againstcurrent_model. If they differ, it triggers a reload. However,current_modelis initialized to"initial_model"at startup and only gets updated to the actual model name when the admin manager loop processes arestart_target— which doesn't happen for the startup--configmodel.So the flow is:
--config "Qwen3.6-..."→ model loads correctlycurrent_modelremains"initial_model"(never updated)"model": "Qwen3.6-...""Qwen3.6-..." != "initial_model"→ triggers reloadThe API endpoint
GET /api/v1/modelreports the correct model, confirming the model loading itself works fine. The bug is isolated to the router proxy's internal state not being initialized for the startup model.Relevant code points:
current_modelinitialized to"initial_model"atkoboldcpp.py:84and:10870(admin mode MP init):10990when admin manager processes arestart_target— never for startup--configmodel:4823:if model_name and model_name != global_memory["current_model"]::4842:conn.request("POST", "/api/admin/reload_config", body=reqbody, headers=reqheaders)