dsh-connect-trae 4.0.1 → 4.2.0

package/lib/index.d.ts

@@ -3,6 +3,46 @@ import { Context, ProviderStreams } from "@earendil-works/pi-ai";
 import { PiAiAdapter } from "@deepseek-ai/dsh-llm-pi-ai";
 import { Context as Context$1 } from "@deepseek-ai/cordis";
 import { AttachmentStore } from "@deepseek-ai/dsh-attachment";
+//#region src/promo.d.ts
+/** One price pair, as upstream published it. Rates are credits per Mtoken. */
+interface TraePromoPrice {
+  /** Undiscounted rate. */
+  beforeRate?: number;
+  /** Discounted rate, when upstream stated one for this branch. */
+  rate?: number;
+  /**
+   * Pay ratio in percent, straight from `discount`: 100 = full price, 50 = 五折,
+   * 25 = 二五折. NOT a 0–1 multiplier — read literally, the way it is written.
+   */
+  discountPercent?: number;
+}
+/** One `off_peak` window: ISO weekdays 1(Monday)–7(Sunday), minutes 0–1440. */
+interface TraePromoWindow {
+  weekdays: number[];
+  /** Inclusive. */
+  startMinute: number;
+  /** Exclusive; 1440 is upstream's way of writing "end of day". */
+  endMinute: number;
+}
+/** The whole `activity_discount` document, kept unflattened on purpose. */
+interface TraeActivityDiscount {
+  /** Upstream's machine name for the campaign, e.g. `subsidy_member_discount`. */
+  subKey?: string;
+  /** Upstream's own "right now" verdict. */
+  current?: TraePromoPrice & {
+    discountType?: string;
+  };
+  /** Subscription price — hover material only, see the module note. */
+  member?: TraePromoPrice;
+  /** Recurring cheap hours, judged locally against each model's own zone. */
+  offPeak?: TraePromoPrice & {
+    timeZone?: string;
+    windows: TraePromoWindow[];
+  };
+  /** Subsidy branch, when upstream names it separately from `current`. */
+  subsidy?: TraePromoPrice;
+}
+//#endregion
 //#region src/reasoning.d.ts
 declare const TRAE_REASONING_EFFORTS: readonly ["minimal", "low", "medium", "high", "xhigh"];
 type TraeReasoningEffort = typeof TRAE_REASONING_EFFORTS[number];
@@ -30,9 +70,34 @@ 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;
+  /**
+   * Trae's discount rule for this row (`features.activity_discount`), kept whole
+   * so the card can judge it against the clock at paint time (src/promo.ts).
+   */
+  activityDiscount?: TraeActivityDiscount;
 }
-/** 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';
@@ -161,6 +226,16 @@ interface TraeModelInfo {
    * image to a model that cannot read one burns credits for a silent failure.
    */
   multimodal?: boolean;
+  /**
+   * Trae's discount RULE for this model, exactly as published (see src/promo.ts).
+   *
+   * Kept unflattened and unjudged: whether a badge is painted depends on the
+   * clock, so the card judges it at paint time rather than trusting a verdict
+   * frozen into a saved catalog. Absent means the model carries no promotion
+   * document — including every `ai` (international) row, whose subscription
+   * models publish no `consumption_rate` at all.
+   */
+  activityDiscount?: TraeActivityDiscount;
 }
 /**
  * Bootstrap catalog: identity only where current Trae metadata has not been
@@ -247,6 +322,15 @@ interface TraeWireModel {
    * therefore has to replay the directory's own function.
    */
   function?: string;
+  /**
+   * The row's own `activity_discount`, read from `display_contact_config`.
+   *
+   * The wire roster is the richer of the two directories (8 rows carrying a
+   * discount vs the Remote directory's 4), and the same model can name a
+   * different campaign on each side, so this value wins over the Remote one
+   * during the merge — the precedence `creditMultiplier` already follows.
+   */
+  activityDiscount?: TraeActivityDiscount;
 }
 /**
  * Merge the two Trae model sources into one authoritative catalog.
@@ -728,6 +812,13 @@ interface TraeWebModel {
   probe?: TraeModelProbeVerdict;
   /** Upstream's own words for the verdict, when it gave any. */
   probeDetail?: string;
+  /**
+   * Trae's discount rule for this row, straight from the directory that
+   * advertised it (see src/promo.ts). The CARD decides whether it is live right
+   * now: the rule carries weekday/time windows in an upstream-declared zone, so
+   * a verdict baked in here would be stale by the next morning.
+   */
+  activityDiscount?: TraeActivityDiscount;
 }
 /**
  * One model's availability verdict from the one-click test.
@@ -2697,6 +2788,11 @@ interface TraeSoloModel {
   reasoning?: TraeReasoningCapability;
   /** Effective (post-discount) credit multiplier, as the Trae IDE shows it. */
   creditMultiplier?: number;
+  /**
+   * The row's `activity_discount` rule, read from `display_contact_config`.
+   * Display data only: src/promo.ts decides at paint time whether a badge shows.
+   */
+  activityDiscount?: TraeActivityDiscount;
   /** The directory function that listed this config (replayed when calling it). */
   function?: string;
 }
@@ -2810,6 +2906,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 +2924,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