Kimi assistant: make it open and chat on a deployed tester (2 fixes on development_mik, 1 follow-up) #4

Closed
opened 2026-06-04 04:18:34 +00:00 by mik-tf · 2 comments
Owner

The Kimi assistant could not be opened or chat on a deployed tester VM. Three causes were found and the first two are fixed on the branch development_mik (2 commits):

  1. The web binary bound its socket as hero_kimi_web/web_chat.sock and advertised name kimi / socket web_kimi, which does not match the router convention /<service>/web/ to <service>/web.sock, so /hero_kimi/web/ never resolved. Fixed: it now binds hero_kimi/web.sock and advertises name hero_kimi / socket web.

  2. The agent only builds its single built-in kimi chat provider (which already speaks the OpenAI-compatible chat/completions API, so it drives OpenRouter via base_url); any other provider type falls through to no LLM, so the deployer config that used openai_legacy produced LLM is not set on every turn. The deployer now writes provider type kimi, and the provider now also reads OPENROUTER_API_KEY / OPENAI_API_KEY from the environment so the key can stay out of the on-disk config.

Remaining follow-up (not yet fixed): the agent loads its built-in agent spec, skills, and plugins from the build-machine source tree (the path baked in at compile time), which does not exist on a deployed machine, so the worker exits with Agent spec file not found unless those directories are copied to that exact path. It would be better to embed them in the binary or resolve them relative to the executable or an environment-configurable directory. With those files staged manually, the branch binaries were proven end to end on the live tester: open, new conversation, send, and a real streamed model reply.

Signed-by: mik-tf mik-tf@noreply.invalid

The Kimi assistant could not be opened or chat on a deployed tester VM. Three causes were found and the first two are fixed on the branch `development_mik` (2 commits): 1. The web binary bound its socket as `hero_kimi_web/web_chat.sock` and advertised name `kimi` / socket `web_kimi`, which does not match the router convention `/<service>/web/` to `<service>/web.sock`, so `/hero_kimi/web/` never resolved. Fixed: it now binds `hero_kimi/web.sock` and advertises name `hero_kimi` / socket `web`. 2. The agent only builds its single built-in `kimi` chat provider (which already speaks the OpenAI-compatible chat/completions API, so it drives OpenRouter via base_url); any other provider type falls through to no LLM, so the deployer config that used `openai_legacy` produced `LLM is not set` on every turn. The deployer now writes provider type `kimi`, and the provider now also reads `OPENROUTER_API_KEY` / `OPENAI_API_KEY` from the environment so the key can stay out of the on-disk config. Remaining follow-up (not yet fixed): the agent loads its built-in agent spec, skills, and plugins from the build-machine source tree (the path baked in at compile time), which does not exist on a deployed machine, so the worker exits with `Agent spec file not found` unless those directories are copied to that exact path. It would be better to embed them in the binary or resolve them relative to the executable or an environment-configurable directory. With those files staged manually, the branch binaries were proven end to end on the live tester: open, new conversation, send, and a real streamed model reply. Signed-by: mik-tf <mik-tf@noreply.invalid>
Author
Owner

Added a third browser-facing fix to development_mik (the branch is now 3 commits). Opening the chat at /hero_kimi/web without a trailing slash rendered unstyled, because index.html referenced its CSS and JS with relative paths that resolved one level too high, so every asset returned 404. Commit e635e3e rewrites the shell's static asset references to be absolute under the forwarding prefix, so the UI styles correctly with or without the slash (and still works on direct access with an empty prefix). Deployed and verified on a live tester: the served HTML now emits /hero_kimi/web/static/... and the page renders styled. Separately, chat was also hanging on Reconnecting on deployed testers because of a WebSocket-tunnel gap in the gateway's Host-based routing, fixed in hero_proxy#59; with both fixes the assistant now opens, styles, and streams replies on a deployed tester.

Added a third browser-facing fix to `development_mik` (the branch is now 3 commits). Opening the chat at `/hero_kimi/web` without a trailing slash rendered unstyled, because index.html referenced its CSS and JS with relative paths that resolved one level too high, so every asset returned 404. Commit [e635e3e](https://forge.ourworld.tf/lhumina_code/hero_kimi_rust/commit/e635e3e) rewrites the shell's static asset references to be absolute under the forwarding prefix, so the UI styles correctly with or without the slash (and still works on direct access with an empty prefix). Deployed and verified on a live tester: the served HTML now emits `/hero_kimi/web/static/...` and the page renders styled. Separately, chat was also hanging on `Reconnecting` on deployed testers because of a WebSocket-tunnel gap in the gateway's Host-based routing, fixed in [hero_proxy#59](https://forge.ourworld.tf/lhumina_code/hero_proxy/issues/59); with both fixes the assistant now opens, styles, and streams replies on a deployed tester.
Author
Owner

The third deploy blocker is fixed properly and everything is merged to main. The agent read its builtin agent specs, skills, and plugins from the build machine's source path (baked in at compile time), so a deployed worker died with Agent spec file not found unless those directories were copied onto the VM by hand. They are now embedded in the binary with include_dir! and materialized to ~/.kimi/builtin on first use, so the binary is self-contained. Verified on a live tester: with the hand-staged directories and ~/.kimi/builtin both deleted, the worker respawned cleanly (no spec file not found), recreated ~/.kimi/builtin from itself, loaded its spec/skills/plugins from there, connected the planner and whiteboard MCP servers, and chatted. main is now at 1e6acd4 with all four fixes (web socket name, provider env-key, prefix-absolute asset paths, embedded spec), so CI republishes a latest that works on a fresh tester with no staging. Note development is now behind main and should pull these four commits (or merge main) when convenient. Closing as done; reopen if you want the materialization approach changed.

The third deploy blocker is fixed properly and everything is merged to `main`. The agent read its builtin agent specs, skills, and plugins from the build machine's source path (baked in at compile time), so a deployed worker died with `Agent spec file not found` unless those directories were copied onto the VM by hand. They are now embedded in the binary with `include_dir!` and materialized to `~/.kimi/builtin` on first use, so the binary is self-contained. Verified on a live tester: with the hand-staged directories and `~/.kimi/builtin` both deleted, the worker respawned cleanly (no `spec file not found`), recreated `~/.kimi/builtin` from itself, loaded its spec/skills/plugins from there, connected the planner and whiteboard MCP servers, and chatted. `main` is now at [1e6acd4](https://forge.ourworld.tf/lhumina_code/hero_kimi_rust/commit/1e6acd4) with all four fixes (web socket name, provider env-key, prefix-absolute asset paths, embedded spec), so CI republishes a `latest` that works on a fresh tester with no staging. Note `development` is now behind `main` and should pull these four commits (or merge `main`) when convenient. Closing as done; reopen if you want the materialization approach changed.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_kimi_rust#4
No description provided.