dsh-llm-bailian-kimi

DSH ships two built-in adapters, but neither survives contact with Alibaba Cloud Bailian: dsh-llm-deepseek rejects images outright with UNSUPPORTED_CONTENT, while dsh-llm-pi-ai sends the system prompt as role developer and gets a 400 back. dsh-llm-bailian-kimi fills exactly that gap. Once installed, an Alibaba Bailian group appears in the DSH model picker with kimi/kimi-k3 ready to go. Core capabilities include multimodal image input (including base64, verified with 7 MB images), streaming output with reasoning chains, function calling, and token plus cache-hit accounting. The entire plugin is pure ESM JavaScript with zero build steps.\n\nUnder the hood the plugin handles three Bailian-specific quirks that are easy to miss. The system prompt must use role system instead of developer; tool-call continuation chunks carry JSON null for id and name rather than empty strings, so type guards must check typeof rather than undefined; and kimi-k3 forbids disabling thinking entirely, so the plugin exposes only high and max reasoning effort tiers and deliberately omits off, because sending disabled triggers a misleading 400 about temperature. The config block in settings.yaml is hot-reloaded on the next request, and for live instances that cannot be restarted, cordis.patch.yml provides a transactional hot-mount path.\n\nThe route is intentionally scoped to bailian-kimi because the thinking-parameter dispatch is Kimi-specific; other Bailian models such as deepseek-v3.2 will 400 on the same call. If you need Bailian Qwen, GLM, or anything else, a sibling plugin with its own route name is the right approach. Two plugins sharing a route will trigger a DUPLICATE_ADAPTER and fail registration outright. This plugin is for developers who need multimodal Kimi capabilities inside a DSH workflow, or for anyone who wants a clean, tested adapter against Bailian's OpenAI-compatible endpoint.