dsh-connect-trae 4.0.1 → 4.1.0

package/CHANGELOG.md

@@ -1,5 +1,57 @@
 # Changelog
 
+## 4.1.0 (2026-10-21)
+
+> **受限网络（企业网只放行少数域名）下「刷新模型 500 / 聊天 4001」的完整修复。**
+>
+> 链路是三段式的：`solo.trae.cn` 的 CONNECT 被代理拒绝（403）→ 目录 `fetch failed`（刷新 500）→
+> 模型丢失 `wireFunction` → 聊天按默认 `solo_work_lite` 发请求 → 模型不在该 function 的 config 名单里就
+> 4001 `config_name rejected`。本版对三段各有一处改动：目录 host 回退到聊天网关的同路径（带冷却重试）、
+> 目录分组的 function 兜底 `wireFunction`（只认可聊分组）、bridge 对「只带 function」的目录行保留
+> resolver 的 `config_name` 大小写（issue #38 的坑）。
+>
+> 合并 PR #43 前做了对抗性复现，修掉了四处会伤到真实用户的回归——**最关键的一处**：原实现把功能名
+> 属于 `solo_agent`/`builder_v3` 的目录行整行丢弃，而受限网络下那正是 9 个只在 `solo_agent` 分组里
+> 出现的模型（`gpt-5.5`、`gpt-5.6-*`、`gpt-6-astra`、`glm-5.2`、`kimi-k2.7-code`、`Dola-Seed-2.0-Code`、
+> `deepseek-v4-flash-0731`），它们正是 issue #19 修复要暴露的那批、且实测在默认 chat function 下
+> 都能正常应答。现在只把非可聊 function **降级清空**，行保留。
+
+### 修复
+
+- **受限网络下模型目录走聊天网关备用 host，目录分组 function 兜底 `wireFunction`**（`fix(cn)`）。修复分三层：
+  - **目录 host 回退**：官方 remote host 网络错误 / 超时 / 5xx 时，按序尝试聊天网关的同一路径
+    （CN 为 `trae-api-cn.mchost.guru/api/remote/v1`，实测同路径同响应结构）；401/403/404 等语义性拒绝**不回退**。
+    进程内记住最近一次**给出了非空目录**的 host。官方 host 失败后进入 5 分钟冷却：冷却期内先走记住的备用
+    host、官方 host 排在链尾（备用也挂了时仍有一次机会），冷却到期后官方 host 重新排第一 —— 只把官方 host
+    「排在第二」并不能让它被重试，因为循环在第一个成功处返回，所以必须显式冷却重试，恢复的网络才会在
+    一个冷却窗口内重新接管。空目录（200-but-empty）既不算成功（不记忆）也不终止链路（继续试下一个 base），
+    否则一个还没同步的镜像会永久堵死官方 host。回退只作用于 remote/v1 目录这一个 base；
+    `get_detail_param`、`llm_utils_chat` 照旧走各自原有 host。
+  - **目录分组 function 归因**：`fetchModels` 不再丢弃 `data.list[].function`——解析时把**可聊**分组的 function
+    附到每个模型（同一模型出现于多个分组时按 `TRAE_DIRECTORY_FUNCTIONS` 的实测优先级取，而非请求参数
+    `functions=` 的顺序；后者是历史列表，与 wire roster 自己的收集顺序不同，混用会让同一模型在「roster 有没有
+    返回」两种网络下拿到不同 function，`solo_agent_remote` 在 Remote 付费门后，优先它会多出 1005）。
+    `mergeTraeModelSources` 的 `wireFunction` 优先取 `get_detail_param` 的结论，目录分组兜底（roster 知道
+    账号的付费/可用状态，目录不知道）。同一 function 名重复出现时按名分桶保留全部，不再只留最后一组。
+  - **非可聊 function 只降级、不丢行**：`solo_agent`、`builder_v3` 是 IDE/Remote-agent roster，聊天通道实测
+    4011/4001，所以**不把这两个 function 写进 `wireFunction`**；模型本身**保留**，改由默认 chat function
+    调用。把它们整行丢掉等于在本次修复针对的受限网络里重新藏起 issue #19 的成果（详见上方导语）。
+    仅带 `wireFunction`（无 `wireConfigName`）的目录行，聊天请求会带上该 function，但 `config_name` 仍由
+    resolver 提供（目录 id 只是展示名，网关 `config_name` 大小写敏感，见 issue #38）。默认 function 与
+    fallback 模型常量未动。
+  - 已知取舍：模型被目录放在 `chat_v3` 分组下、但实际不可聊时，插件仅凭目录数据无法区分，仍会展示，
+    聊天失败走现有 4001 提示翻译（诊断入口见 `docs/ISSUE19_DIAGNOSIS.md`）。
+
+### 测试
+
+- 回归用例：host 回退（官方网络错误 → 备用 host 同路径同查询；401 不回退；5xx 回退；**空目录继续尝试下一个
+  base 且不被记住**；记住最近成功 host；**冷却到期后官方 host 重新排第一**；显式 baseUrl 钉住单 host）、
+  分组 function 归因（可聊分组优先；**同一 function 名重复出现时不丢模型**；容量来自后分组时保留先到先得的
+  function）、合并兜底与 `withChatCallableFunctions` 的**降级而非丢弃**、bridge 对 wireFunction-only 目录行
+  保留 resolver 的 `config_name`（大小写）、以及受限网络端到端（wire roster 为空时 9 个 `solo_agent`-only
+  模型仍然在目录里）。
+- 全仓 **921** 例通过，0 skipped；`tsc` 两个工程干净；`build` 通过；CI（ubuntu + windows）全绿。
+
 ## 4.0.1 (2026-10-19)
 
 > CN 区模型卡「最大输出」整列空白（issue #42）修复：上游**是**发布输出上限的——`get_detail_param` 的

package/lib/index.d.ts

@@ -30,9 +30,29 @@ interface TraeDiscoveredModel {
   creditMultiplier?: number;
   reasoningSupported: boolean;
   reasoning?: TraeDiscoveredReasoning;
+  /**
+   * The directory group the model was seen under (`data.list[].function`).
+   *
+   * The Remote `/models` answer is grouped by SOLO function and the group is
+   * the authoritative statement of which function the model belongs to — the
+   * `config_name` the gateway accepts is isolated per function, so a model in
+   * `solo_work_remote` answers 4001 when asked through `solo_work_lite`. The
+   * wire join (see `mergeTraeModelSources`) prefers its own
+   * `get_detail_param` function and uses this as the fallback when the roster
+   * has nothing to say (restricted networks often return an empty
+   * `config_info_list` for the chat functions).
+   */
+  function?: string;
 }
-/** Parse only capabilities explicitly advertised by Trae's remote model API. */
-declare function parseTraeRemoteModel(value: unknown): TraeDiscoveredModel | undefined;
+/**
+ * Parse only capabilities explicitly advertised by Trae's remote model API.
+ *
+ * @param groupFunction The `data.list[].function` of the group this raw row
+ * was read from; attached verbatim so downstream can replay the model's own
+ * function instead of the `llm_utils_chat` default (see
+ * {@link TraeDiscoveredModel.function}).
+ */
+declare function parseTraeRemoteModel(value: unknown, groupFunction?: string): TraeDiscoveredModel | undefined;
 //#endregion
 //#region src/paths.d.ts
 type TraeEdition = 'cn' | 'sg' | 'solo' | 'solo-sg';
@@ -2810,6 +2830,13 @@ interface TraeSoloRemoteCatalogOptions {
   credential(): Promise<TraeCredential>;
   fetchImpl?: typeof fetch;
   baseUrl?: string;
+  /**
+   * Diagnostics sink (wired to `ctx.logger.warn` by the plugin). Called only
+   * on the interesting path — when a NON-official host served the directory
+   * or is reused as the remembered first candidate — never on the happy path
+   * of official-host-first.
+   */
+  log?: (message: string, detail?: unknown) => void;
 }
 /**
  * Read-only model catalog client for the SOLO Web API.
@@ -2821,9 +2848,118 @@ declare class TraeSoloRemoteCatalogClient {
   private readonly options;
   private readonly fetchImpl;
   private readonly baseUrl;
+  /**
+   * The last base that answered the directory with a NON-EMPTY catalog in this
+   * process.
+   *
+   * A proxy-blocked network pays the failing official attempt on EVERY refresh
+   * otherwise, so a backup that has served the catalog is tried first on later
+   * refreshes. Putting the official base "second" is NOT enough to re-probe it:
+   * the loop returns on the first success, so a backup that keeps answering
+   * means the official base is never asked again. The official host is
+   * therefore re-probed on a COOLDOWN instead (see {@link OFFICIAL_RETRY_MS}):
+   * while the cooldown runs the backup is used and the official host is
+   * skipped; when it expires the official host is tried FIRST again, so a
+   * healed network takes over within one cooldown window rather than never.
+   */
+  private lastSuccessfulBase;
+  /**
+   * When the official base may be probed again after a transport/5xx failure,
+   * as epoch milliseconds (0 = probe it on the next refresh).
+   */
+  private officialRetryAtMs;
+  /**
+   * How long a failing official host is skipped before it is re-probed.
+   *
+   * Long enough that a blocked network stops paying the failing attempt on
+   * every refresh (the point of the fallback), short enough that a healed
+   * network takes over without a restart. Each probe costs one connect timeout
+   * (30 s) in the worst case, so 5 minutes bounds that to ~1 attempt per 5 min.
+   */
+  private static readonly OFFICIAL_RETRY_MS;
   constructor(options: TraeSoloRemoteCatalogOptions);
   private headers;
   fetchModels(signal?: AbortSignal): Promise<TraeDiscoveredModel[]>;
+  /**
+   * Bases to try for one refresh, in order.
+   *
+   * While the official host is in its post-failure cooldown the backup hosts go
+   * first and the official base is kept LAST as a final chance (so a still-down
+   * backup does not fail the whole refresh while the official host happens to
+   * be reachable). Once the cooldown expires the official base is first again:
+   * that is what lets a healed network take over — the loop returns on the
+   * first success, so simply placing the official base second never re-probes
+   * it while a backup keeps answering.
+   */
+  private candidateBases;
+  /**
+   * Union every returned group into one deduplicated list, attributing each
+   * model to the CHAT function the directory listed it under.
+   *
+   * Each group is a roster the gateway is willing to serve; a model listed by
+   * any of them is a model the IDE can offer, and the wire join downstream (see
+   * mergeTraeModelSources) is what decides whether it is actually callable.
+   * Restricting this to `solo_agent_remote` dropped the nine models issue #19
+   * was opened about.
+   *
+   * FUNCTION ATTRIBUTION (2026-10-20): a group is the authoritative statement
+   * of which SOLO function a model belongs to — the accepted `config_name` is
+   * isolated per function (glm-5.3 answers `solo_work_remote` and 4001s under
+   * `solo_work_lite`). The wire join prefers its own `get_detail_param`
+   * function and falls back to this one when the roster says nothing, which
+   * restricted networks often do (measured: an empty `config_info_list` for
+   * every chat function but `chat_v3`).
+   *
+   * ONLY CHAT-CAPABLE GROUPS ARE ATTRIBUTED. `solo_agent` and `builder_v3` are
+   * IDE/Remote-agent rosters: asking `llm_utils_chat` with either answers
+   * 4011/4001 (measured 2026-10-01 on a live credential, issue #19). A model
+   * that appears ONLY there is still not uncallable, though — the SAME models
+   * answered normally under `solo_work_remote` / `solo_work_lite` /
+   * `solo_agent_remote` (measured the same day, see `TRAE_DIRECTORY_FUNCTIONS`
+   * in solo.ts), and the default function is what has always reached them:
+   * they are exactly the nine models issue #19's fix exposes (`gpt-5.5`,
+   * `gpt-5.6-*`, `gpt-6-astra`, `glm-5.2`, `kimi-k2.7-code`,
+   * `Dola-Seed-2.0-Code`, `deepseek-v4-flash-0731` — docs/ISSUE19_DIAGNOSIS.md).
+   * Stamping `solo_agent` onto such a row makes every call 4011; DROPPING it
+   * undoes issue #19 for exactly the restricted-network users this fallback
+   * exists for. It therefore keeps NO function, the bridge falls back to the
+   * default chat function exactly as before this change, and a refusal (if the
+   * model really is unreachable) comes back as a readable upstream message
+   * instead of a silent absence.
+   *
+   * CHAT GROUPS ARE WALKED IN `TRAE_DIRECTORY_FUNCTIONS` ORDER, not in the
+   * request's `functions=` order. That list is the measured precedence of which
+   * function serves a shared config, and it is the order the wire roster itself
+   * collects in (`solo.ts`) — walking a different order would attribute the
+   * same model differently depending on whether the roster answered, and the
+   * difference is not cosmetic: `solo_agent_remote` sits after the two
+   * `solo_work_*` functions because it is behind the Remote plan gate, so
+   * preferring it can turn a free-tier model into a `1005 requires a paid
+   * plan` refusal.
+   *
+   * A model appears in SEVERAL groups and the groups disagree about its
+   * capacity, so dedupe keeps the MOST CAPABLE row rather than the first one
+   * (issue #23). "First wins" assumed the group order was stable; measured
+   * 2026-10-05 on a live CN credential it is not — five calls returned five
+   * different orders — so the published window became a coin flip:
+   * `Doubao-Seed-2.1-Pro` came back as `116000`/no-Max (`builder_v3`), or
+   * `256000`/no-Max (`solo_work_*`), or `256000`/`1000000` (`chat_v3`,
+   * `solo_agent*`) depending on which group answered first. The Max tier is
+   * the one users enable in the IDE, and `applyContextBudgets` can only raise
+   * a window to `maxContextWindow` — so losing that field silently capped
+   * every configured 1M model at 256K or less, and DSH compressed far earlier
+   * than the chosen budget implied.
+   *
+   * Ordering rule: a row advertising a Max tier beats one that does not, a
+   * larger Max wins over a smaller one, and with no Max on either side the
+   * wider dev window wins. Every row for one id carries the same
+   * `multimodal` / `reasoning` / credit facts (verified the same day), so
+   * choosing on capacity loses no capability. The result no longer depends on
+   * the gateway's group order — and the FUNCTION does not either: the winning
+   * row's capacity may come from a later group, but the separately-tracked
+   * attribution is re-asserted on it.
+   */
+  private collectModels;
 }
 //#endregion
 //#region src/delegating-upstream.d.ts

package/lib/index.js

@@ -235,6 +235,7 @@ function mergeTraeModelSources(remote, wire) {
 	for (const model of remote) {
 		const wireModel = wireById.get(displayKey(model.id)) ?? wireByName.get(displayKey(model.name));
 		const creditMultiplier = wireModel?.creditMultiplier ?? model.creditMultiplier;
+		const wireFunction = wireModel?.function ?? model.function;
 		result.push({
 			id: model.id,
 			name: model.name,
@@ -250,12 +251,45 @@ function mergeTraeModelSources(remote, wire) {
 				reasoningEfforts: Object.fromEntries(model.reasoning.supported.map((effort) => [effort, effort === "low" ? "light" : effort === "xhigh" ? "extra_high" : "high"]))
 			},
 			...wireModel !== void 0 && wireModel.id !== "" && wireModel.id !== model.id ? { wireConfigName: wireModel.id } : {},
-			...wireModel?.function === void 0 ? {} : { wireFunction: wireModel.function }
+			...wireFunction === void 0 ? {} : { wireFunction }
 		});
 	}
 	return result;
 }
 /**
+* Demote a NON-chat `wireFunction` to "no function", keeping the row.
+*
+* A row pinned to an IDE/Remote-agent roster — `solo_agent`, `builder_v3` — is
+* not callable through `llm_utils_chat` by THAT function: asking answers
+* 4011/4001 (measured 2026-10-01, issue #19). Dropping the row is not the fix,
+* though, and was a regression: a model can carry a non-chat function for a
+* reason that says nothing about its chat availability. The directory lists
+* `gpt-5.5`, `gpt-5.6-*`, `gpt-6-astra`, `glm-5.2`, `kimi-k2.7-code`,
+* `Dola-Seed-2.0-Code` and `deepseek-v4-flash-0731` under `solo_agent` ALONE
+* (docs/ISSUE19_DIAGNOSIS.md), yet the same models answer normally under
+* `solo_work_remote` / `solo_work_lite` / `solo_agent_remote` — they are
+* exactly the models issue #19's fix was opened to expose. Dropping them
+* re-hid the whole set on the restricted networks this fallback targets, where
+* the wire roster is empty and the directory group is the only attribution.
+*
+* Keeping the row with the function CLEARED preserves both facts: the model
+* stays visible (issue #19), and the bridge sends the region's DEFAULT chat
+* function instead of one that is guaranteed to refuse. That is the pre-change
+* behaviour for these rows — a genuinely unreachable model still fails with a
+* readable upstream message rather than a silent absence.
+*
+* `chatFunctions` must be the region's own `TRAE_DIRECTORY_FUNCTIONS` list —
+* the functions `llm_utils_chat` accepts. Callers should log the demoted rows:
+* "which function did it lose, and why" deserves an answer.
+*/
+function withChatCallableFunctions(rows, chatFunctions) {
+	return rows.map((model) => {
+		if (model.wireFunction === void 0 || chatFunctions.includes(model.wireFunction)) return model;
+		const { wireFunction: _demoted, ...withoutFunction } = model;
+		return withoutFunction;
+	});
+}
+/**
 * Apply the saved local budget. Trae advertises two windows per model (dev and
 * Max), so the budget may only switch a model to its own advertised Max value —
 * never to a fabricated number. Everything else keeps the dev window.
@@ -277,6 +311,7 @@ function discoveredCatalog(models) {
 		input: ["text"],
 		...model.creditMultiplier === void 0 ? {} : { creditMultiplier: model.creditMultiplier },
 		...model.multimodal === void 0 ? {} : { multimodal: model.multimodal },
+		...model.function === void 0 ? {} : { wireFunction: model.function },
 		reasoningSupported: model.reasoningSupported,
 		...model.reasoning === void 0 ? {} : {
 			reasoning: model.reasoning,
@@ -4702,8 +4737,9 @@ var TraeSoloBridge = class {
 			if (typeof input["model"] === "string" && input["model"] !== "") model = input["model"];
 			const entryKey = model.trim().toLowerCase();
 			const entry = this.catalog?.current().find((item) => item.id === model || item.id.trim().toLowerCase() === entryKey);
-			const fromCatalog = entry?.wireConfigName === void 0 ? void 0 : {
-				configName: entry.wireConfigName,
+			const catalogConfigName = entry?.wireConfigName;
+			const fromCatalog = entry === void 0 || catalogConfigName === void 0 && entry.wireFunction === void 0 ? void 0 : {
+				configName: catalogConfigName ?? entry.id,
 				...entry.wireFunction === void 0 ? {} : { function: entry.wireFunction }
 			};
 			const fromResolver = this.wireResolver?.(model) ?? this.wireResolver?.(entry?.name ?? "");
@@ -4718,11 +4754,28 @@ var TraeSoloBridge = class {
 			* directory, so borrowing its function is safe exactly when both sources
 			* agree on the wire config_name; a disagreement means the resolver found
 			* a different row and its function would be wrong.
+			*
+			* The MIRROR case is equally load-bearing and is the reason the row's own
+			* id is not accepted as its wire spelling: a row that carries only the
+			* FUNCTION (`wireConfigName` absent) has no config_name of its own, and
+			* its display id is the wrong-cased spelling of the wire name in exactly
+			* the cases issue #38 is about. The resolver's config_name is then the
+			* only correct one, so it must win for the NAME while the row keeps
+			* winning for the FUNCTION.
 			*/
 			const sameWireConfig = fromCatalog !== void 0 && fromResolver !== void 0 && fromCatalog.configName.toLowerCase() === fromResolver.configName.toLowerCase();
+			/**
+			* Whether the catalog row knows its own wire `config_name` (as opposed to
+			* only carrying the display id plus a function). Only such a row may
+			* decide the name on its own.
+			*/
+			const catalogKnowsConfigName = catalogConfigName !== void 0;
 			const target = fromCatalog !== void 0 && fromCatalog.function === void 0 && sameWireConfig && fromResolver !== void 0 ? {
 				configName: fromCatalog.configName,
 				...fromResolver.function === void 0 ? {} : { function: fromResolver.function }
+			} : fromCatalog !== void 0 && !catalogKnowsConfigName && fromResolver !== void 0 ? {
+				configName: fromResolver.configName,
+				...fromCatalog.function === void 0 ? {} : { function: fromCatalog.function }
 			} : fromCatalog ?? fromResolver;
 			/**
 			* Last line of defence: the discovered row's own id.
@@ -4786,8 +4839,15 @@ const EFFORT_MAP = {
 	high: "high",
 	extra_high: "xhigh"
 };
-/** Parse only capabilities explicitly advertised by Trae's remote model API. */
-function parseTraeRemoteModel(value) {
+/**
+* Parse only capabilities explicitly advertised by Trae's remote model API.
+*
+* @param groupFunction The `data.list[].function` of the group this raw row
+* was read from; attached verbatim so downstream can replay the model's own
+* function instead of the `llm_utils_chat` default (see
+* {@link TraeDiscoveredModel.function}).
+*/
+function parseTraeRemoteModel(value, groupFunction) {
 	const raw = record(value);
 	if (raw === void 0 || typeof raw.name !== "string" || raw.name === "") return void 0;
 	const context = record(raw.context_window_tokens);
@@ -4818,7 +4878,8 @@ function parseTraeRemoteModel(value) {
 		...supported.length === 0 ? {} : { reasoning: {
 			supported,
 			...defaultEffort === void 0 ? {} : { defaultEffort }
-		} }
+		} },
+		...groupFunction === void 0 || groupFunction === "" ? {} : { function: groupFunction }
 	};
 }
 //#endregion
@@ -4885,6 +4946,23 @@ const TRAE_REMOTE_DIRECTORY_FUNCTIONS = {
 	]
 };
 /**
+* Backup bases for the model directory, in try order after the official base.
+*
+* In restricted (proxy-sandboxed) networks the official catalog host
+* `solo.trae.cn` is behind a CONNECT rejection while the region's chat gateway
+* stays reachable — and that gateway serves the SAME `/api/remote/v1/models`
+* endpoint with an identical response shape (verified against
+* `https://trae-api-cn.mchost.guru/api/remote/v1` 2026-10-20; `chat` already
+* carries `/api/remote/v1`'s parent in {@link REGION_GATEWAYS}). The backup is
+* therefore derived from the region's chat base, mirrored on the remote path;
+* `ai` shares a single host for chat and remote, so it yields no candidate and
+* keeps its single-host behavior. An explicit `baseUrl` disables the chain.
+*/
+function traeSoloRemoteFallbackBases(region, officialBase) {
+	const backupBase = `${REGION_GATEWAYS[region].chat}/api/remote/v1`;
+	return backupBase === officialBase ? [] : [backupBase];
+}
+/**
 * Of two rows for the SAME model id, the one that advertises the stronger
 * capacity (issue #23).
 *
@@ -4942,10 +5020,39 @@ function remoteDressing(region) {
 * This deliberately has no chat/session method: the Remote session protocol
 * only exposes a final answer and cannot preserve DSH's structured tool loop.
 */
-var TraeSoloRemoteCatalogClient = class {
+var TraeSoloRemoteCatalogClient = class TraeSoloRemoteCatalogClient {
 	options;
 	fetchImpl;
 	baseUrl;
+	/**
+	* The last base that answered the directory with a NON-EMPTY catalog in this
+	* process.
+	*
+	* A proxy-blocked network pays the failing official attempt on EVERY refresh
+	* otherwise, so a backup that has served the catalog is tried first on later
+	* refreshes. Putting the official base "second" is NOT enough to re-probe it:
+	* the loop returns on the first success, so a backup that keeps answering
+	* means the official base is never asked again. The official host is
+	* therefore re-probed on a COOLDOWN instead (see {@link OFFICIAL_RETRY_MS}):
+	* while the cooldown runs the backup is used and the official host is
+	* skipped; when it expires the official host is tried FIRST again, so a
+	* healed network takes over within one cooldown window rather than never.
+	*/
+	lastSuccessfulBase;
+	/**
+	* When the official base may be probed again after a transport/5xx failure,
+	* as epoch milliseconds (0 = probe it on the next refresh).
+	*/
+	officialRetryAtMs = 0;
+	/**
+	* How long a failing official host is skipped before it is re-probed.
+	*
+	* Long enough that a blocked network stops paying the failing attempt on
+	* every refresh (the point of the fallback), short enough that a healed
+	* network takes over without a restart. Each probe costs one connect timeout
+	* (30 s) in the worst case, so 5 minutes bounds that to ~1 attempt per 5 min.
+	*/
+	static OFFICIAL_RETRY_MS = 3e5;
 	constructor(options) {
 		this.options = options;
 		this.fetchImpl = options.fetchImpl ?? fetch;
@@ -4966,24 +5073,183 @@ var TraeSoloRemoteCatalogClient = class {
 	}
 	async fetchModels(signal) {
 		const region = regionOfCredential(await this.options.credential());
-		const base = this.baseUrl ?? REGION_GATEWAYS[region].remote;
+		const officialBase = this.baseUrl ?? REGION_GATEWAYS[region].remote;
 		const headers = await this.headers(region);
 		const functions = TRAE_REMOTE_DIRECTORY_FUNCTIONS[region].join(",");
-		const response = await this.fetchImpl(`${base}/models?functions=${functions}`, {
-			headers,
-			signal: signal ?? AbortSignal.timeout(3e4)
-		});
-		if (!response.ok) throw new Error(`SOLO remote models returned HTTP ${response.status}`);
-		const groups = (await response.json()).data?.list ?? [];
+		let lastError;
+		let emptyError;
+		for (const base of this.candidateBases(region, officialBase)) {
+			let response;
+			try {
+				response = await this.fetchImpl(`${base}/models?functions=${functions}`, {
+					headers,
+					signal: signal ?? AbortSignal.timeout(3e4)
+				});
+			} catch (error) {
+				if (signal?.aborted) throw error;
+				if (base === officialBase) this.officialRetryAtMs = Date.now() + TraeSoloRemoteCatalogClient.OFFICIAL_RETRY_MS;
+				lastError = error;
+				continue;
+			}
+			if (!response.ok) {
+				if (response.status < 500) throw new Error(`SOLO remote models returned HTTP ${response.status}`);
+				if (base === officialBase) this.officialRetryAtMs = Date.now() + TraeSoloRemoteCatalogClient.OFFICIAL_RETRY_MS;
+				lastError = /* @__PURE__ */ new Error(`SOLO remote models returned HTTP ${response.status}`);
+				continue;
+			}
+			const json = await response.json();
+			const models = this.collectModels(region, json.data?.list ?? []);
+			if (models.length === 0) {
+				emptyError = /* @__PURE__ */ new Error("SOLO remote models response contained no models");
+				lastError = emptyError;
+				continue;
+			}
+			if (base !== officialBase) this.options.log?.(this.lastSuccessfulBase === base ? `model directory served by the remembered fallback host ${base}; the official host (${officialBase}) is re-probed every ${TraeSoloRemoteCatalogClient.OFFICIAL_RETRY_MS / 6e4} minutes` : `model directory served by fallback host ${base}; the official host (${officialBase}) failed this refresh`, { officialBase });
+			else this.officialRetryAtMs = 0;
+			this.lastSuccessfulBase = base;
+			return models;
+		}
+		if (emptyError !== void 0) throw emptyError;
+		throw lastError instanceof Error ? lastError : new Error(String(lastError));
+	}
+	/**
+	* Bases to try for one refresh, in order.
+	*
+	* While the official host is in its post-failure cooldown the backup hosts go
+	* first and the official base is kept LAST as a final chance (so a still-down
+	* backup does not fail the whole refresh while the official host happens to
+	* be reachable). Once the cooldown expires the official base is first again:
+	* that is what lets a healed network take over — the loop returns on the
+	* first success, so simply placing the official base second never re-probes
+	* it while a backup keeps answering.
+	*/
+	candidateBases(region, officialBase) {
+		if (this.baseUrl !== void 0) return [officialBase];
+		const fallbacks = traeSoloRemoteFallbackBases(region, officialBase);
+		if (this.officialRetryAtMs <= Date.now()) return [officialBase, ...fallbacks];
+		const remembered = this.lastSuccessfulBase;
+		return [
+			...remembered === void 0 ? [] : [remembered],
+			...fallbacks.filter((base) => base !== remembered),
+			officialBase
+		];
+	}
+	/**
+	* Union every returned group into one deduplicated list, attributing each
+	* model to the CHAT function the directory listed it under.
+	*
+	* Each group is a roster the gateway is willing to serve; a model listed by
+	* any of them is a model the IDE can offer, and the wire join downstream (see
+	* mergeTraeModelSources) is what decides whether it is actually callable.
+	* Restricting this to `solo_agent_remote` dropped the nine models issue #19
+	* was opened about.
+	*
+	* FUNCTION ATTRIBUTION (2026-10-20): a group is the authoritative statement
+	* of which SOLO function a model belongs to — the accepted `config_name` is
+	* isolated per function (glm-5.3 answers `solo_work_remote` and 4001s under
+	* `solo_work_lite`). The wire join prefers its own `get_detail_param`
+	* function and falls back to this one when the roster says nothing, which
+	* restricted networks often do (measured: an empty `config_info_list` for
+	* every chat function but `chat_v3`).
+	*
+	* ONLY CHAT-CAPABLE GROUPS ARE ATTRIBUTED. `solo_agent` and `builder_v3` are
+	* IDE/Remote-agent rosters: asking `llm_utils_chat` with either answers
+	* 4011/4001 (measured 2026-10-01 on a live credential, issue #19). A model
+	* that appears ONLY there is still not uncallable, though — the SAME models
+	* answered normally under `solo_work_remote` / `solo_work_lite` /
+	* `solo_agent_remote` (measured the same day, see `TRAE_DIRECTORY_FUNCTIONS`
+	* in solo.ts), and the default function is what has always reached them:
+	* they are exactly the nine models issue #19's fix exposes (`gpt-5.5`,
+	* `gpt-5.6-*`, `gpt-6-astra`, `glm-5.2`, `kimi-k2.7-code`,
+	* `Dola-Seed-2.0-Code`, `deepseek-v4-flash-0731` — docs/ISSUE19_DIAGNOSIS.md).
+	* Stamping `solo_agent` onto such a row makes every call 4011; DROPPING it
+	* undoes issue #19 for exactly the restricted-network users this fallback
+	* exists for. It therefore keeps NO function, the bridge falls back to the
+	* default chat function exactly as before this change, and a refusal (if the
+	* model really is unreachable) comes back as a readable upstream message
+	* instead of a silent absence.
+	*
+	* CHAT GROUPS ARE WALKED IN `TRAE_DIRECTORY_FUNCTIONS` ORDER, not in the
+	* request's `functions=` order. That list is the measured precedence of which
+	* function serves a shared config, and it is the order the wire roster itself
+	* collects in (`solo.ts`) — walking a different order would attribute the
+	* same model differently depending on whether the roster answered, and the
+	* difference is not cosmetic: `solo_agent_remote` sits after the two
+	* `solo_work_*` functions because it is behind the Remote plan gate, so
+	* preferring it can turn a free-tier model into a `1005 requires a paid
+	* plan` refusal.
+	*
+	* A model appears in SEVERAL groups and the groups disagree about its
+	* capacity, so dedupe keeps the MOST CAPABLE row rather than the first one
+	* (issue #23). "First wins" assumed the group order was stable; measured
+	* 2026-10-05 on a live CN credential it is not — five calls returned five
+	* different orders — so the published window became a coin flip:
+	* `Doubao-Seed-2.1-Pro` came back as `116000`/no-Max (`builder_v3`), or
+	* `256000`/no-Max (`solo_work_*`), or `256000`/`1000000` (`chat_v3`,
+	* `solo_agent*`) depending on which group answered first. The Max tier is
+	* the one users enable in the IDE, and `applyContextBudgets` can only raise
+	* a window to `maxContextWindow` — so losing that field silently capped
+	* every configured 1M model at 256K or less, and DSH compressed far earlier
+	* than the chosen budget implied.
+	*
+	* Ordering rule: a row advertising a Max tier beats one that does not, a
+	* larger Max wins over a smaller one, and with no Max on either side the
+	* wider dev window wins. Every row for one id carries the same
+	* `multimodal` / `reasoning` / credit facts (verified the same day), so
+	* choosing on capacity loses no capability. The result no longer depends on
+	* the gateway's group order — and the FUNCTION does not either: the winning
+	* row's capacity may come from a later group, but the separately-tracked
+	* attribution is re-asserted on it.
+	*/
+	collectModels(region, groups) {
 		const byId = /* @__PURE__ */ new Map();
-		for (const group of groups) for (const raw of group.models ?? []) {
-			const model = parseTraeRemoteModel(raw);
-			if (model === void 0) continue;
-			byId.set(model.id, preferStrongerRow(model, byId.get(model.id)));
+		const attributedFunction = /* @__PURE__ */ new Map();
+		/**
+		* The function a row may be stamped with: only a CHAT function. A non-chat
+		* roster is not "the function this model belongs to" in any sense the chat
+		* route can use (see the method note above), so it is not recorded at all.
+		*/
+		const chatFunctions = new Set(TRAE_DIRECTORY_FUNCTIONS[region]);
+		const attribution = (groupFunction) => groupFunction !== void 0 && chatFunctions.has(groupFunction) ? groupFunction : void 0;
+		const addGroup = (groupFunction, raws) => {
+			const fn = attribution(groupFunction);
+			for (const raw of raws) {
+				const model = parseTraeRemoteModel(raw, fn);
+				if (model === void 0) continue;
+				if (fn !== void 0 && !attributedFunction.has(model.id)) attributedFunction.set(model.id, fn);
+				byId.set(model.id, preferStrongerRow(model, byId.get(model.id)));
+			}
+		};
+		/**
+		* Every group the gateway sent, bucketed BY FUNCTION NAME and kept as a
+		* LIST.
+		*
+		* A name→group `Map` would keep only the LAST group of a name and silently
+		* drop the models of every earlier one: nothing documents that the gateway
+		* sends a function at most once, and the pre-change code unioned every
+		* element of `data.list`, so a repeated name lost real models. Bucketing
+		* keeps that union while the walk below still imposes a deterministic
+		* order.
+		*/
+		const byFunction = /* @__PURE__ */ new Map();
+		for (const group of groups) {
+			const key = group.function ?? "";
+			const bucket = byFunction.get(key);
+			if (bucket === void 0) byFunction.set(key, [group]);
+			else bucket.push(group);
 		}
-		const models = [...byId.values()];
-		if (models.length === 0) throw new Error("SOLO remote models response contained no models");
-		return models;
+		for (const name of TRAE_DIRECTORY_FUNCTIONS[region]) for (const group of byFunction.get(name) ?? []) addGroup(name, group.models ?? []);
+		for (const [name, bucket] of byFunction) {
+			if (chatFunctions.has(name)) continue;
+			for (const group of bucket) addGroup(name, group.models ?? []);
+		}
+		return [...byId.values()].map((model) => {
+			const fn = attributedFunction.get(model.id);
+			return fn === void 0 || fn === model.function ? model : {
+				...model,
+				function: fn
+			};
+		});
 	}
 };
 //#endregion
@@ -8756,7 +9022,10 @@ function apply(ctx, config) {
 			...panel === "enterprise" ? { route: "enterprise" } : {},
 			log: (message, detail) => ctx.logger.warn(message, detail)
 		});
-		const remoteCatalog = new TraeSoloRemoteCatalogClient({ credential: () => store.resolve() });
+		const remoteCatalog = new TraeSoloRemoteCatalogClient({
+			credential: () => store.resolve(),
+			log: (message, detail) => ctx.logger.warn(message, detail)
+		});
 		const wireResolver = (displayId) => wire.byId.get(displayId) ?? wire.byName.get(displayId.trim().toLowerCase());
 		/**
 		* One client + bridge per provider id.
@@ -8909,18 +9178,24 @@ function apply(ctx, config) {
 			},
 			discoverModels: async (signal) => {
 				const merged = mergeTraeModelSources(await withDirectoryRetry(() => remoteCatalog.fetchModels(signal)), await solo.fetchModels(signal));
-				wire.callableKeys.clear();
+				const callable = withChatCallableFunctions(merged, TRAE_DIRECTORY_FUNCTIONS[region]);
+				const chatFunctions = TRAE_DIRECTORY_FUNCTIONS[region];
 				for (const model of merged) {
+					if (model.wireFunction === void 0 || chatFunctions.includes(model.wireFunction)) continue;
+					ctx.logger.warn(`model directory row is pinned to a non-chat function and will be called through the default chat function instead: ${model.id} (pinned to function ${model.wireFunction})`);
+				}
+				wire.callableKeys.clear();
+				for (const model of callable) {
 					wire.callableKeys.add(model.id.trim().toLowerCase());
 					wire.callableKeys.add(model.name.trim().toLowerCase());
 				}
-				wire.resolved = merged.length > 0;
-				const wireTargets = wireTargetsOf(merged);
+				wire.resolved = callable.length > 0;
+				const wireTargets = wireTargetsOf(callable);
 				wire.byId = wireTargets.byId;
 				wire.byName = wireTargets.byName;
 				latestDiscovery.length = 0;
-				latestDiscovery.push(...merged);
-				return merged;
+				latestDiscovery.push(...callable);
+				return callable;
 			},
 			/**
 			* One-click availability test. The ids come from the card, so each one is

package/package.json

@@ -2,7 +2,7 @@
   "name": "dsh-connect-trae",
   "displayName": "DSH Connect Trae",
   "description": "把本机登录的 Trae 模型接入 DeepSeek Harness：国内版与国际版双供应商并行，提供用量/积分概览与每日签到领取。",
-  "version": "4.0.1",
+  "version": "4.1.0",
   "author": "dingminhua",
   "copyright": "Copyright (c) 2026 LaoDing",
   "license": "MIT",