Codex review: needs maintainer review before merge. Reviewed July 19, 2026, 6:14 AM ET / 10:14 UTC.

Summary
The branch changes two configured-model reasoning inference checks so explicitly configured bailian models with Qwen thinking formats are handled like vllm models.

PR surface: Source +1. Total +1 across 2 files.

Reproducibility: no. reviewer-established current-main run is available, but the source-level gate and the contributor’s redacted after-fix gateway/session transcript give a concrete, medium-confidence reproduction path for explicitly configured bailian Qwen-format models.

Review metrics: none identified.

Root-cause cluster
Relationship: partial_overlap
Canonical: #26037
Summary: This PR targets the custom configured-provider inference subset of the broader Bailian reasoning request; it does not implement the official catalog and onboarding scope still tracked there.

Members:

• canonical: [Feature]: Ali bailian coding plan support ( thinking/reasoning enabled ) #26037 - The open issue is the broader canonical request for official Bailian Coding Plan support, including scope beyond this two-file custom-provider fix.
• partial_overlap: feat(config): support Qwen thinkingFormat values #79777 - The merged PR established the configured Qwen thinking-format contract that this branch relies on, but it did not add Bailian provider inference.
• adjacent_distinct: feat(qwen): add Token Plan (Team Edition) provider #94419 - The merged Token Plan provider uses a Qwen-plugin-owned stream path and is explicitly described in discussion as complementary rather than the same runtime path.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Confirm the intended narrow bailian compatibility contract and retain the broader official-provider issue as non-closing context.

Risk before merge

• [P1] Merging changes behavior for existing custom bailian rows that explicitly opt into a Qwen thinking format; that is likely desired, but maintainers should confirm this is a supported narrow custom-provider contract rather than implicitly closing the broader official-provider/onboarding request.

Maintainer options:

1. Confirm narrow support and preserve issue scope (recommended)
   Approve the bailian exception for explicit Qwen compatibility rows, but change the broader issue reference to non-closing context before merge.
2. Adopt a provider-neutral rule instead
   If explicit provider-name allowlists are not the intended contract, pause this PR and design a generic compatibility inference path with tests for the supported backends.

Next step before merge

• [P2] A maintainer must select the permanent custom-provider support boundary and ensure the broader linked issue is not closed by this narrower fix.

Maintainer decision needed

• Question: Should core explicitly treat custom provider ID bailian as Qwen-thinking-compatible when its model row opts into compat.thinkingFormat, while leaving official Bailian catalog and onboarding work outside this PR?
• Rationale: The implementation is narrow and has real-run evidence, but the linked issue requests broader first-class provider support, so only maintainers can define whether this core allowlist is the intended long-term support boundary.
• Likely owner: indulgeback — They introduced the prior merged configured-Qwen compatibility surface most directly related to this boundary.
• Options:
  • Approve the narrow custom-provider contract (recommended): Keep the two inference changes, update the issue reference to non-closing context, and leave official catalog/onboarding scope in the linked issue.
  • Keep inference provider-neutral: Replace the explicit provider allowlist with a generic configured-model compatibility rule only if maintainers want every explicitly opted-in OpenAI-compatible Qwen backend to receive this behavior.

Security
Cleared: The two-line provider compatibility change adds no dependency, secret, network, permission, or code-execution mechanism.

Useful fix. One data point that might help scope it: the bundled qwen-token-plan provider being added in #94419 does not go through resolveThinkingProfile for its thinking at all. It rides the qwen plugin's own wrapQwenProviderStream (gated by isQwenProviderId), so its Alibaba-hosted Qwen/GLM/Kimi models get reasoning handling without touching the provider === "vllm" checks this PR widens.

So this looks complementary rather than overlapping: your change fixes the generic user-configured bailian provider path, and the bundled provider covers the Token Plan path through a different route. Flagging it so the two do not get treated as competing.

@andreacasini thanks for the PR. ClawSweeper is still waiting on real behavior proof before this can move forward.

Useful proof can be a screenshot, short video, terminal output, copied live output, linked artifact, or redacted logs that show the changed behavior after the fix. Please redact private tokens, phone numbers, private endpoints, customer data, and anything else sensitive.

Once proof is added to the PR body or a comment, ClawSweeper or a maintainer can re-check it.

Proof: Bailian provider generates thinking blocks without reasoning: true

As requested by ClawSweeper, here is the proof that the bailian provider (Alibaba Cloud Coding Plan) generates thinking blocks purely through the code changes in this PR — without relying on reasoning: true in the model config.

Test Setup

1. Removed reasoning: true from the bailian qwen3.6-plus model config in openclaw.json
2. Restarted the gateway to pick up the config change
3. Spawned a subagent with model=bailian/qwen3.6-plus and thinking=low

Evidence 1: Gateway Log (redacted)

2026-07-09T20:53:31.830+00:00 [provider-transport-fetch] |
[model-fetch] start provider=bailian api=openai-completions model=qwen3.6-plus
method=POST url=https://coding-intl.dashscope.aliyuncs.com/v1/chat/completions
timeoutMs=500000 proxy=none policy=custom

Key: policy=custom — without this PR's changes, resolveThinkingProfile returns null for non-vllm providers, so no custom thinking policy would be applied. The fact that policy=custom appears proves the code path in model-selection-shared.ts and embedded-agent-runner/model.ts correctly recognizes bailian as a reasoning-capable provider.

Evidence 2: Subagent Session Transcript

{
  "role": "assistant",
  "content": [
    {
      "type": "thinking",
      "thinking": "This is a simple test task. I just need to reply with a greeting message."
    },
    {
      "type": "text",
      "text": "Hello, test message for bailian reasoning proof."
    }
  ],
  "api": "openai-completions",
  "provider": "bailian",
  "model": "qwen3.6-plus",
  "stopReason": "stop"
}

The "type": "thinking" block was generated by the model — proving that the bailian provider supports reasoning output when the thinking profile is correctly resolved.

Evidence 3: Model Config Used for Test (no reasoning: true)

{
  "id": "qwen3.6-plus",
  "name": "qwen3.6-plus",
  "input": ["text", "image"],
  "cost": {"input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0},
  "contextWindow": 1000000,
  "maxTokens": 65536,
  "compat": {
    "thinkingFormat": "qwen",
    "supportsUsageInStreaming": true
  },
  "api": "openai-completions"
}

Note: NO reasoning: true field — the model was recognized as reasoning-capable purely through the PR's code changes in isVllmQwenThinkingCompat().

PR Changes (after ClawSweeper feedback)

• ✅ thinking-policy.ts change reverted — that code path is dead in production (bailian doesn't go through the vllm extension)
• ✅ bailian-thinking-provider.test.ts removed — tests were targeting the wrong code path
• ✅ Only 2 files changed: model-selection-shared.ts and embedded-agent-runner/model.ts — both replace === "vllm" with (=== "vllm" || === "bailian")

@clawsweeper re-review

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

@clawsweeper re-review