Thanks for the PR, @barry166!

Template looks good ✓ — all required sections present.

Problem: Real, observed bug — issue #6666 documents Qwen3 returning <think> tags in the content field instead of reasoning_content. Users see raw thinking tags in visible output. Maintainer @wenshao has since confirmed the fix is load-bearing locally (removing the PR's source causes test failures and reproduces the visible <think> leak).

Direction: Aligned. The converter already has TaggedThinkingParser and taggedThinkingTags infrastructure (used by MiniMax). This PR simply opts Qwen3 into that existing parsing path on the default provider. No new abstractions, no scope creep — just connecting the wires. The explicit scoping to Qwen3 avoids reopening the broader default-provider behavior that was reverted for DashScope GLM in #6248.

Size: 3 files, +34 / -1. Production logic: 11 lines (9 in default.ts, 2 in minimax.ts). Tests: 24 lines. Well under any threshold.

Approach: Scope is exactly right — minimal, focused, one thing. Reuses the existing shouldMirrorReasoningContentForQwen3 helper for the response-side gate, keeping request/response alignment consistent. The override addition on MiniMax is a correct TypeScript fix now that the base class implements the method. Nothing to cut.

— Qwen Code · qwen3.7-max

Code Review

I read the diff against the existing provider/converter/pipeline infrastructure. The implementation is clean and correct.

Independent proposal (before reading diff): I would have added a getResponseParsingOptions() method to DefaultOpenAICompatibleProvider that returns { taggedThinkingTags: true } for Qwen3 models, reusing the existing shouldMirrorReasoningContentForQwen3 helper and the already-wired TaggedThinkingParser in the converter pipeline. I would have also fixed MiniMax's override keyword.

Comparison: The PR does exactly this — no more, no less. The approach matches my independent proposal 1:1.

Findings: No critical blockers. No AGENTS.md violations. Specifically:

• The shouldMirrorReasoningContentForQwen3 helper is correctly reused for the response-side gate, keeping request/response Qwen3 detection aligned (already used in buildRequest at line 111).
• getResponseParsingOptions was already part of the OpenAICompatibleProvider interface as optional — adding it to the base class doesn't break any consumer. The pipeline at pipeline.ts:990 already uses ?.() optional chaining.
• MiniMax's override keyword is a correct TS fix — it was implementing the interface method directly before; now that the base class has the method, override is the right declaration. MiniMax always returns true regardless of model, preserving existing behavior.
• Tests cover both positive (Qwen3 → true) and negative (gpt-4o → false) paths, following existing test patterns.

Test Results

PR unit tests (CI green):

✓ default.test.ts — 30 tests passed (including 2 new from this PR)
✓ minimax.test.ts — 9 tests passed (existing behavior preserved)
✓ converter.test.ts — 14 tagged-thinking tests passed
✓ typecheck — clean (tsc --noEmit, no errors)

Maintainer local verification (@wenshao — 212/212 related tests):

✓ typecheck — 0 errors
✓ eslint — clean on all 3 changed files
✓ provider/default.test.ts — 30/30 (incl. 2 new)
✓ provider/minimax.test.ts — 9/9
✓ converter.test.ts — 143/143
✓ taggedThinkingParser.test.ts — 27/27
✓ pr6751-e2e.verify.test.ts — 3/3 (maintainer's independent integration test)

Load-bearing confirmed: maintainer overlaid main's pre-fix default.ts and the PR's tests failed with provider.getResponseParsingOptions is not a function, plus a regression-guard test reproduced the visible <think> leak. Restoring the PR's source → all 212 pass.

Real-Scenario Testing

Attempted tmux before/after with both installed qwen and the PR bundle:

## Before (installed build)

$ qwen -p "What is 2+2?" --model "qwen3-235b-a22b" 2>&1 | head -30
Warning: QWEN_HOME points to ... but no settings.json was found there. ...
[API Error: <400> InternalError.Algo.InvalidParameter: Range of max_tokens should be [1, 16384]]

## After (this PR bundle)

$ node dist/cli.js -p "What is 2+2?" --model "qwen3-235b-a22b" 2>&1 | head -30
Warning: QWEN_HOME points to ... but no settings.json was found there. ...
[API Error: <400> InternalError.Algo.InvalidParameter: Range of max_tokens should be [1, 16384]]

The DashScope endpoint rejects both builds with an unrelated max_tokens range error before any response is returned — so the <think> tag parsing path can't be exercised in this CI environment. Both builds behave identically — the PR introduces no regressions. The maintainer's integration test (pr6751-e2e.verify.test.ts) provides the end-to-end wiring evidence that the CI tmux test cannot.

— Qwen Code · qwen3.7-max

This is a clean, minimal fix that does exactly what it needs to — opts Qwen3 into the existing TaggedThinkingParser response parsing path that MiniMax already uses. 11 production lines, no new abstractions, no scope creep. The author clearly understood the codebase: they reused the existing shouldMirrorReasoningContentForQwen3 helper, scoped the change to Qwen3 only (avoiding the DashScope GLM regression from #6248), and added both positive and negative test cases.

The maintainer @wenshao has since done thorough local verification — 212/212 related tests, confirmed the fix is load-bearing (removing the PR's source reproduces the <think> leak), and added an independent integration test that wires provider → pipeline → converter end-to-end. This closes the evidence gap from the CI tmux test (which couldn't reach the parsing path due to an unrelated DashScope max_tokens error).

No reservations. The problem is real, the fix is minimal and correct, and the verification is comprehensive.

— Qwen Code · qwen3.7-max

✅ Local verification (maintainer) — merge reference

I built and ran the real test suite locally for this PR. Summary: all green, the fix is load-bearing, and behavior is correctly scoped to Qwen3.

Environment: macOS · Node v22.23.1 · npm 10.9.8 · vitest 3.2.4 · @qwen-code/[email protected] · PR head b8cf479 over main.

What I ran

Before / after — the change is load-bearing

To confirm the fix actually matters, I overlaid main's pre-fix default.ts (which has no getResponseParsingOptions) and re-ran the PR's tests. The 2 new provider tests and 2 of my e2e tests fail with provider.getResponseParsingOptions is not a function, and a regression-guard test reproduces the visible <think> leak. Restoring the PR's source → all 212 pass.

Independent end-to-end check

The PR's unit tests verify the two halves separately (the provider gate in default.test.ts; the converter parsing in converter.test.ts). Nothing tests them joined, so I added a small integration test that wires them exactly as pipeline.ts does — provider → responseParsingOptions → converter — and asserts the user-facing outcome for the real #6666 shape (<think>…</think> arriving inside content, not reasoning_content):

• Qwen3 model → <think>let me reason…</think>The answer is 42. becomes a hidden thought part + visible The answer is 42. (no raw tags).
• non-Qwen3 model → passed through verbatim (no accidental parsing).
• pre-fix (gate off) → raw <think> leaks into visible text — i.e. the qwen 3.7 max 模型在 content 字段中返回 <think> 标签而非 reasoning_content #6666 bug, asserted explicitly.

(Happy to contribute this test to the PR if useful — it is not part of the current diff.)

Correctness notes for merge

• Scoped by model name, not provider. The gate is model.toLowerCase().includes('qwen3'), shared with the existing request-side reasoning_content mirroring. So the DashScope GLM behavior reverted in [codex] Revert GLM tagged thinking parsing for DashScope #6248 stays disabled (GLM ∌ qwen3); only Qwen3 opts in. ✔
• DashScope / DeepSeek / ZAI / ModelScope / MiMo / Mistral inherit the default gate — all correctly off for non-Qwen3, on for Qwen3. MiniMax keeps its unconditional true (the PR only adds the override keyword — no behavior change). ✔
• Case-insensitive matching verified (Qwen/Qwen3.7-Max, qwen3-coder-plus both match). Matches the author's flagged risk: a hypothetical future Qwen alias without qwen3 in its name would be missed — acceptable and trivially extensible later. ✔

Verdict: ✅ LGTM from local verification. Tests pass, typecheck/lint clean, the fix is minimal, correctly scoped, and demonstrably resolves #6666. CI on this PR is also already green (Test (ubuntu-latest, Node 22.x)).

@qwen-code /triage

Thanks for the contribution here.

After checking the real failing traces more closely, I think this fix is at the wrong layer. The issue is not that Qwen3 model names should opt into tagged-thinking parsing by default. In the observed failure, the response had already produced structured reasoning / thought content, but raw <think> / </think> fragments still leaked into visible content. That means the streamed response itself is malformed, rather than a normal <think>...</think> content fallback that should be parsed based on the model name.

I am going to revert this PR and handle the issue with response-shape based retry logic instead: when structured reasoning is already present but visible content contains raw thinking tags, we should drop that malformed attempt and retry, not enable parsing or cleanup based on a Qwen3 model-name match.