Add qwen3.6-plus to verified models#3366
Conversation
Add qwen3.6-plus to VERIFIED_QWEN_MODELS and VERIFIED_OPENHANDS_MODELS. Fixes #3365 Co-authored-by: openhands <openhands@all-hands.dev>
Python API breakage checks — ✅ PASSEDResult: ✅ PASSED |
REST API breakage checks (OpenAPI) — ✅ PASSEDResult: ✅ PASSED |
all-hands-bot
left a comment
all-hands-bot
left a comment
There was a problem hiding this comment.
🟢 Good taste — straightforward model-list update.
[RISK ASSESSMENT]
- [Overall PR]
⚠️ Risk Assessment: 🟢 LOW — adds one verified model identifier consistently to the provider-specific and OpenHands model lists; no dependency, API, or agent-behavior risk.
VERDICT: ✅ Worth merging.
This review was created by an AI agent (OpenHands) on behalf of the user.
Was this automated review useful? React with 👍 or 👎 to this review to help us measure review quality.
Workflow run: https://github.com/OpenHands/software-agent-sdk/actions/runs/26311861967
all-hands-bot
left a comment
all-hands-bot
left a comment
There was a problem hiding this comment.
Code Review: Add qwen3.6-plus to verified models
This is a clean, minimal, and correctly structured change. The qwen3.6-plus (dot-separator) identifier is added to both VERIFIED_QWEN_MODELS and VERIFIED_OPENHANDS_MODELS, mirroring exactly how the existing qwen3-6-plus (dash-separator) entry was originally introduced. Placement within both lists is logical and consistent.
A few quick observations:
- Symmetry is correct. Both
VERIFIED_QWEN_MODELSandVERIFIED_OPENHANDS_MODELSare updated, which is the right set of lists—this matches the pattern used for the dash-variant and ensures theVERIFIED_MODELS["qwen"]lookup and the OpenHands platform curated list both recognize the new identifier. - No other lists need touching. The
VERIFIED_MODELSdict is constructed from the individual list constants, so no manual dict update is required. - Dot-separator identifiers are already well-established in this file (e.g.
gpt-5.5,gemini-3.1-pro,kimi-k2.5), so the new entry fits the naming convention. - Testing is addressed: the PR notes all 6 tests in
test_model_list.pypass, includingtest_openhands_models_all_have_provider_list, which validates the cross-list consistency invariant.
No issues found. ✅
This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation.
all-hands-bot
left a comment
all-hands-bot
left a comment
There was a problem hiding this comment.
✅ QA Report: PASS
Verified the SDK-facing model registry behavior: qwen3.6-plus is now recognized for both qwen and openhands, while the existing qwen3-6-plus entry still works.
Does this PR achieve its stated goal?
Yes. The stated goal was to add qwen3.6-plus to the verified model lists so consumers recognize it as supported. Running the SDK against origin/main showed qwen3.6-plus was not recognized for either provider; running the same verification on commit 0f07c30d showed it is recognized in both provider maps, and the legacy dash-separated identifier remains recognized.
| Phase | Result |
|---|---|
| Environment Setup | ✅ uv run created .venv, installed packages, and SDK imports succeeded |
| CI Status | ⏳ 20 successful, 4 skipped, 8 pending, 0 failing at time of review |
| Functional Verification | ✅ Before/after SDK runtime check confirmed the new model is recognized |
Functional Verification
Test 1: SDK verified-model recognition before and after the PR
Step 1 — Reproduce / establish baseline (without the fix):
Checked out origin/main at 3d9fc105, then ran:
OPENHANDS_SUPPRESS_BANNER=1 uv run python - <<'PY'
from openhands.sdk.llm.utils.verified_models import VERIFIED_MODELS
model = 'qwen3.6-plus'
legacy_model = 'qwen3-6-plus'
for provider in ('qwen', 'openhands'):
models = VERIFIED_MODELS[provider]
print(f'{provider}: {model} recognized? {model in models}')
print(f'{provider}: {legacy_model} recognized? {legacy_model in models}')
print(f'{provider}: qwen3 entries -> {[m for m in models if "qwen3" in m]}')
PYObserved:
qwen: qwen3.6-plus recognized? False
qwen: qwen3-6-plus recognized? True
qwen: qwen3 entries -> ['qwen3-6-plus', 'qwen3-coder-480b', 'qwen3-coder-next']
openhands: qwen3.6-plus recognized? False
openhands: qwen3-6-plus recognized? True
openhands: qwen3 entries -> ['qwen3-6-plus', 'qwen3-coder-480b', 'qwen3-coder-next']
This confirms the baseline problem: the new dot-separated model identifier was absent from both provider-specific and OpenHands verified model lists, while the existing dash-separated identifier already worked.
Step 2 — Apply the PR's changes:
Checked out PR commit 0f07c30d7f130e5c605a7796da1e8d7327730cd2.
Step 3 — Re-run with the fix in place:
Ran the same SDK command and observed:
qwen: qwen3.6-plus recognized? True
qwen: qwen3-6-plus recognized? True
qwen: qwen3 entries -> ['qwen3-6-plus', 'qwen3.6-plus', 'qwen3-coder-480b', 'qwen3-coder-next']
openhands: qwen3.6-plus recognized? True
openhands: qwen3-6-plus recognized? True
openhands: qwen3 entries -> ['qwen3-6-plus', 'qwen3.6-plus', 'qwen3-coder-480b', 'qwen3-coder-next']
This confirms the PR delivers the intended behavior: the SDK verified-model registry now includes qwen3.6-plus in both relevant lists and does not regress the existing qwen3-6-plus identifier.
Test 2: Local server smoke check for API exposure
Started the local agent server with:
OPENHANDS_SUPPRESS_BANNER=1 uv run python -m openhands.agent_serverThen queried:
curl -sS -m 5 http://127.0.0.1:8000/server_info
python - <<'PY'
import json, urllib.request
schema = json.load(urllib.request.urlopen('http://127.0.0.1:8000/openapi.json', timeout=5))
text = json.dumps(schema, sort_keys=True)
print('openapi contains qwen3-6-plus:', 'qwen3-6-plus' in text)
print('openapi contains qwen3.6-plus:', 'qwen3.6-plus' in text)
print('openapi size:', len(text))
PYObserved the server reached Server initialization complete - ready to serve requests; /server_info returned version/tool metadata, and OpenAPI did not include either Qwen model identifier:
openapi contains qwen3-6-plus: False
openapi contains qwen3.6-plus: False
openapi size: 426512
This indicates the directly verifiable runtime surface for this PR in this repository is the SDK verified-model registry rather than a local HTTP model-list endpoint.
Unable to Verify
I did not verify a downstream UI model picker rendering qwen3.6-plus, because this repository checkout does not include a UI page that exposes the verified-model registry. If there is a canonical UI preview or HTTP endpoint for model-list consumers, adding that command/path to AGENTS.md would make future QA runs able to validate the UI path directly.
Issues Found
None.
This review was created by an AI agent (OpenHands) on behalf of the user.
3 participants
Why
The
qwen3.6-plusmodel identifier needs to be added to the verified models list so it is recognized as a verified/supported model in the UI and API.Summary
qwen3.6-plustoVERIFIED_QWEN_MODELSlistqwen3.6-plustoVERIFIED_OPENHANDS_MODELSlistIssue Number
Fixes #3365
How to Test
Run the existing model list tests:
All 6 tests pass, including
test_openhands_models_all_have_provider_listwhich verifies that every model inVERIFIED_OPENHANDS_MODELSalso appears in at least one provider-specific list.Video/Screenshots
N/A — configuration/data change only.
Type
Notes
The existing
qwen3-6-plus(dash separator) entry remains. The newqwen3.6-plus(dot separator) is a distinct model identifier that also needs to be recognized.@juanmichelini can click here to continue refining the PR
Agent Server images for this PR
• GHCR package: https://github.com/OpenHands/agent-sdk/pkgs/container/agent-server
Variants & Base Images
eclipse-temurin:17-jdknikolaik/python-nodejs:python3.13-nodejs22-slimgolang:1.21-bookwormPull (multi-arch manifest)
# Each variant is a multi-arch manifest supporting both amd64 and arm64 docker pull ghcr.io/openhands/agent-server:0f07c30-pythonRun
All tags pushed for this build
About Multi-Architecture Support
0f07c30-python) is a multi-arch manifest supporting both amd64 and arm640f07c30-python-amd64) are also available if needed