LingmaProxyIntl.exe (Qoder intl desktop, port 9095)

Built at 4a8e14d (main). Windows x64 Wails production build.
SHA256 EA04BFEE995284FC57EAAB796E812F4AF5922ABECB6ED300F475C5D40A139917
Needs a lingma-proxy.json beside the exe: port 9095, backend qodercli, qodercli_sites ["global"], instance_id lingma-proxy-desktop-intl, instance_name "Lingma Proxy - Intl".
Requires the international Qoder desktop app installed and signed in. Double-click to start, no env vars.
Tag does not match v*, so release.yml is not triggered.

LingmaProxy 桌面版：一个二进制的三种站点变体 (cn:8095 / intl:9095 / both:10095)

一个二进制的三种站点变体

当前构建：LingmaProxy.exe sha256 前缀 9bf15d49，15,120,384 字节，代码 8e2473b + 两处慢机修复（10-02，尚未 commit，见 924.md §2.17）。
本代含 tool-call XML 方言解析、SSE 生命周期配对、CLI 终止帧返回、失败探测负缓存，以及：请求路径回落磁盘 CLI 目录缓存、超长行后的有界 drain。
手工出包必须带 Wails 的 -tags production：缺它编进去的是 dev 外壳，进程活着、日志一条不写、端口一个不绑。
差别只有 exe 旁边 lingma-proxy.json 里的 qodercli_sites / port / instance_id。
解压到固定目录后直接双击 LingmaProxy.exe，三份可同时运行。

	cn	intl	both
下载	LingmaProxy-cn-win-x64.zip	LingmaProxy-intl-win-x64.zip	LingmaProxy-both-win-x64.zip
端口	8095	9095	10095
网页控制台	8096	9096	10096
站点	["cn"]	["global"]	["cn","global"]
instance_id	lingma-proxy-cn	lingma-proxy-intl	lingma-proxy-both
/v1/models	14	17	31
模型 id 形态	裸名 Qwen3.8-Flash	裸名 Ultimate	CN 裸名 + 国际版 intl/Ultimate
需要的登录态	com.qodercn.app.stable	com.qoder.app.stable	两份都要

both 版调国际版模型必须带 intl/ 前缀（两站有同名模型，靠前缀防撞名）；单站点的 cn / intl 版不带前缀。

三个 zip 的 sha256（拿到文件后请回读核对）：

• cn ed3de0f8dc189b47305ef407a83a3521b32860d0e33ff6292d2bb7b4a758beca（6239478 字节）
• intl 8918f1725010c3fd9d5f1a3afef72878d2bcd06bef6177b9230d3257e2794a5c（6239487 字节）
• both fd72b1c7ed7846d594ecf8d49c4442f922127f6aac58fdf93b8c127ee03dd0fa（6239494 字节）

这一版换的五件事，全来自一台慢机器的实测（192.168.50.239）：

1. 每站点的 CLI 模型名单落盘（<UserConfigDir>\lingma-proxy\cli-catalog-<site>.json，TTL 1 h）。之前重启一次内存缓存就清零，第一发 /v1/models 必须现场赢下一次 CLI 冷启动（那台机器 36-218 s），实测重启后第一发 120.7 s 回 500；现在重启后第一发直接吃到盘上那份旧名单。
2. CLI 进程已经退出、cmd.Wait() 却还在等 stdout 的 EOF —— 这个不再无限等（cmd.WaitDelay 3 s）。那台机器上 CN 侧 CLI 记了 process.exiting exit_code=0 uptime_ms=36337（36 s 正常退出），而同一时刻发起的 /v1/models 到 400 s 还没返回：退出状态早到了，晚到的只是那个继承到写端句柄的后代进程放开的 EOF。
3. headless 版不再把日志写在控制台（改落 %APPDATA%\lingma-proxy\headless.log）。启动那几行日志在 net.Listen 之前，控制台一旦停止服务写就把进程钉死在绑端口之前 —— 那台机器上"进程活着、CPU 零点几秒、端口不监听、事后一条日志都没有"的现场就是这个。A/B：同一个 exe，stderr 重定向到文件 10 s 内绑端口，走交互式计划任务则一直不动。
4. 预热改成后台跑，并且允许跑到赢为止（cliPrimeProbeTimeout 15 min/站点）。之前预热走的是客户端那套 8 s / 120 s 预算，而那台机器一次探测就要 36-218 s，于是预热每一次都在客户端预算上被砍死、盘上名单永远是空；headless.log 里是一串 cancelled before it finished: context deadline exceeded。客户端预算不变：有缓存就秒回，没缓存最多等 120 s。
5. 上一代留下的两条仍然生效：冷探测预算 cliColdProbeTimeout 25 s -> 120 s、cliCatalogTTL 5 min -> 1 h。

热路径本机实测（装机实例 00745C47，.scratch/local_fe09d5f.txt）：删掉两份盘上名单、重启实例、不发任何请求 → 9 s 后 cli-catalog-cn.json 自己落盘；随后 /v1/models 31 条（其中 17 条 intl/*）5.59 s；再重启一次，第一发 /v1/models 31 条 0.02 s；CN/intl 各跑 stream 与非 stream 四种组合都回 1 2 3 4 5 6 7 8（非 stream 15.34 s / 14.08 s，stream 首字 7.47 s / 7.76 s），Anthropic /v1/messages 首字 7.28 s；这一代还多修了一条：对话一拿到 CLI 的终止帧就返回，不再等那个进程自己退出（进程在后台回收）。

自检：curl http://127.0.0.1:<端口>/health -> 200（只做存活检查，对话中也是毫秒级）；
curl http://127.0.0.1:<端口>/v1/models 出列表；curl -i http://127.0.0.1:<端口+1>/api/admin/status
应 401。网页控制台入口地址与令牌在桌面「设置」页，令牌另存于 app-state 的 admin_token。
起 cn（8095）前先停掉原来占着 8095 的那份。