From 857af82d9bc1a78fe5e3230a0b256601a9732b7d Mon Sep 17 00:00:00 2001
From: gitgarmin <38784172+gitgarmin@users.noreply.github.com>
Date: Fri, 11 Sep 2026 13:16:20 +0800
Subject: [PATCH] fix(command-code): add v4.1-flash and Qwen3.8-Flash effort
 ladders

Both routes are live-discovered but had no row in the official effort table, so
supportedCommandCodeEffort resolved to undefined and the adapter omitted
reasoning_effort entirely: a client's `max` reached /alpha/generate as no reasoning
parameter at all, and neither preset advertised an effort control for them.

The ladders are inferred from the same-family rows (deepseek v4: high..max; the
Qwen 3.8 family: low..max). The profile pages render client-side with an empty
reasoning payload, so the self-refresh path stays dead for these rows exactly as
the #2647 block above documents. Measured live 2026-09-11 on 2.50.0:
/alpha/generate accepts reasoning_effort "max" on both routes (HTTP 200), while the
unpatched adapter stripped the field before the wire.

Tests: bun test tests/providers/command-code-provider.test.ts (47 pass),
bun test tests/providers/commandcode-provider.test.ts (8 pass), bun x tsc --noEmit
(clean), bun run privacy:scan (clean).
---
 src/providers/command-code-efforts.ts         | 23 +++++++++++++
 tests/providers/command-code-provider.test.ts | 33 +++++++++++++++++++
 2 files changed, 56 insertions(+)

diff --git a/src/providers/command-code-efforts.ts b/src/providers/command-code-efforts.ts
index 621eb330bc..8ffc900a66 100644
--- a/src/providers/command-code-efforts.ts
+++ b/src/providers/command-code-efforts.ts
@@ -130,6 +130,29 @@ const COMMAND_CODE_MODEL_EFFORTS = {
     efforts: ["low", "medium", "high", "xhigh", "max"],
     profileUrl: "https://commandcode.ai/models/meta-muse-spark-1.1",
   },
+  /*
+   * Two live routes that never gained a row here, so the adapter dropped every
+   * requested effort (a client's `max` left the wire as no reasoning parameter
+   * at all) and the preset advertised no effort control for them.
+   *
+   * PROVENANCE, stated plainly: both ladders are inferred from the same-family
+   * rows above — deepseek v4: high..max; the Qwen 3.8 family: low..max — NOT
+   * read from the profile pages. commandcode.ai renders those client-side and
+   * ships an empty reasoning payload, so the self-refresh below is as dead for
+   * these rows as the #2647 block above already documents. Measured live
+   * 2026-09-11: /alpha/generate accepts `reasoning_effort: "max"` on both
+   * routes (HTTP 200). `ultra` is deliberately not offered: the adapter would
+   * strip it, and no profile evidence backs an ultra→max alias the way it does
+   * for v4-pro/v4-flash above.
+   */
+  "deepseek/deepseek-v4.1-flash": {
+    efforts: ["high", "max"],
+    profileUrl: "https://commandcode.ai/models/deepseek-v4-1-flash",
+  },
+  "Qwen/Qwen3.8-Flash": {
+    efforts: ["low", "medium", "high", "max"],
+    profileUrl: "https://commandcode.ai/models/qwen3-8-flash",
+  },
 } as const;
 
 /**
diff --git a/tests/providers/command-code-provider.test.ts b/tests/providers/command-code-provider.test.ts
index a3b81e408d..638f2e6dc9 100644
--- a/tests/providers/command-code-provider.test.ts
+++ b/tests/providers/command-code-provider.test.ts
@@ -112,6 +112,39 @@ describe("Command Code provider", () => {
     expect(commandCodeReasoningEfforts("z-ai/glm-5.3-flash-vision")).toBeUndefined();
   });
 
+  /*
+   * deepseek/deepseek-v4.1-flash and Qwen/Qwen3.8-Flash are live routes that had
+   * no row in the official table, so `supportedCommandCodeEffort` dropped the
+   * field — a client's `max` reached /alpha/generate as no reasoning parameter
+   * at all. The two presets are constructed separately and must each carry the
+   * rows; the request assertions pin that the effort survives construction.
+   */
+  test("the live v4.1-flash and Qwen3.8-Flash routes forward their own ladder", async () => {
+    const oauth = PROVIDER_REGISTRY.find(row => row.id === "command-code");
+    const apiKey = PROVIDER_REGISTRY.find(row => row.id === "commandcode");
+    for (const [label, entry] of [["oauth", oauth], ["api-key", apiKey]] as const) {
+      expect(entry?.modelReasoningEfforts?.["deepseek/deepseek-v4.1-flash"], `${label} preset ladder`)
+        .toEqual(["high", "max"]);
+      expect(entry?.modelReasoningEfforts?.["Qwen/Qwen3.8-Flash"], `${label} preset ladder`)
+        .toEqual(["low", "medium", "high", "max"]);
+    }
+    expect(commandCodeReasoningEfforts("deepseek/deepseek-v4.1-flash")).toEqual(["high", "max"]);
+    expect(commandCodeReasoningEfforts("Qwen/Qwen3.8-Flash")).toEqual(["low", "medium", "high", "max"]);
+    // The live-discovered id may arrive in any case; the lookup folds it.
+    expect(commandCodeReasoningEfforts("qwen/qwen3.8-flash")).toEqual(["low", "medium", "high", "max"]);
+
+    const deepseekMax = await builtRequest({
+      ...parsed("deepseek/deepseek-v4.1-flash"),
+      options: { reasoning: "max", maxOutputTokens: 100 },
+    });
+    expect(JSON.parse(deepseekMax.body).params.reasoning_effort).toBe("max");
+    const qwenMax = await builtRequest({
+      ...parsed("Qwen/Qwen3.8-Flash"),
+      options: { reasoning: "max", maxOutputTokens: 100 },
+    });
+    expect(JSON.parse(qwenMax.body).params.reasoning_effort).toBe("max");
+  });
+
   test("OAuth and API-key presets share only verified image capabilities", () => {
     const oauth = PROVIDER_REGISTRY.find(row => row.id === "command-code");
     const apiKey = PROVIDER_REGISTRY.find(row => row.id === "commandcode");