Skip to content

[Feedback] qwen3.7-max/plus service instability on OpenCode Go (Zen API) - frequent timeouts and intermittent failures #33721

Closed as not planned
Closed as not planned
[Feedback] qwen3.7-max/plus service instability on OpenCode Go (Zen API) - frequent timeouts and intermittent failures#33721
Assignees
fwang

Description

@Joelincn
Joelincn
opened on Jun 24, 2026

投诉/反馈：OpenCode Zen 的 qwen3.7 系列模型服务不稳定

问题描述

我是 OpenCode Go 的付费订阅用户。在使用 qwen3.7-max 和 qwen3.7-plus 这两个模型时，遇到了严重的服务不稳定问题，具体表现为：

  1. 频繁超时/中断 — 同样的请求有时几秒返回，有时直接超时无响应。成功率大约只有 60-70%
  2. 间歇性失败 — 连续两次相同请求，一次成功一次超时，说明不是客户端配置问题
  3. thinking mode 响应时间波动极大 — 简单请求（budget_tokens=1000）反而疯狂超时，复杂请求（budget_tokens=5000）反而正常返回

测试数据

使用 OpenClaw（第三方客户端）通过标准 anthropic-messages 接口调用 https://opencode.ai/zen/go/v1/messages，实测结果：

测试 模型 条件 结果 耗时
T1 qwen3.7-max 无 thinking ✅ 成功 <1s
T2 qwen3.7-max thinking enabled (budget=1000) ❌ 超时（连续2次） 60s+
T3 qwen3.7-plus 无 thinking ❌ 超时（连续2次） 60s+
T4 qwen3.7-max thinking budget=5000 ✅ 成功 ~8s
T5 qwen3.7-plus thinking enabled (budget=1000) ❌ 超时 → ✅ 重试成功 第一次超时，第二次~40s

分析

排除了客户端配置问题后（其他模型如 deepseek-v4-pro/flash 正常，nvidia 等外部 provider 也正常），可以确定问题出在 OpenCode Zen/Go 后端对 qwen3.7 系列的负载处理上。怀疑是：

  • 后端限流策略过于激进
  • qwen3.7 系列的实例资源分配不足，高负载下响应退化严重
  • thinking 模式下的超时阈值设置过短

期望

作为付费用户，希望官方能够：

  1. 排查 qwen3.7 后端资源分配和限流策略
  2. 提高 thinking 模式下的超时容忍度
  3. 提供更稳定的服务体验。付费不是为了"碰运气能用"
  4. 如果这是已知资源瓶颈，请告知是否有扩容计划或替代方案

环境

  • 服务： OpenCode Go (Zen API) — 付费订阅
  • 端点： https://opencode.ai/zen/go/v1/messages
  • 模型： qwen3.7-max, qwen3.7-plus
  • 客户端： OpenClaw（第三方集成）
  • 地区： 中国大陆（通过代理访问）

感谢阅读。作为付费用户，我希望能得到一个官方回应，哪怕只是一个"已知问题，正在处理"的确认。谢谢。

Activity

  1. github-actions
    assigned
    fwang
    on Jun 24, 2026

  2. github-actions commented on Jun 24, 2026

    @github-actions
    github-actionsBot
    on Jun 24, 2026 – with GitHub Actions
    Contributor

    This issue doesn't fully meet our contributing guidelines.

    What needs to be fixed:

    • This issue does not use one of the three required issue templates (Bug Report, Feature Request, or Question). Please resubmit using the appropriate template — this appears to be a Bug Report, so please use that template and fill in all required fields (Description, steps to reproduce, environment info, etc.).

    Please edit this issue to address the above within 2 hours, or it will be automatically closed.

    This issue might be a duplicate of existing issues. Please check:

    If you believe this was flagged incorrectly, please let a maintainer know.

  3. github-actions
    added
    needs:complianceThis means the issue will auto-close after 2 hours.
    on Jun 24, 2026

  4. Joelincn commented on Jun 24, 2026

    @Joelincn
    Joelincn
    on Jun 24, 2026
    Author

    English Version (中文版见上方)

    Issue: qwen3.7-max/plus Service Instability on OpenCode Go (Zen API)

    I am a paid subscriber of OpenCode Go. I am experiencing severe instability when using qwen3.7-max and qwen3.7-plus via the standard anthropic-messages endpoint (https://opencode.ai/zen/go/v1/messages).

    Symptom

    • Same request sometimes returns in <1s, sometimes times out at 60s+
    • Success rate is approximately 60-70%
    • This is not a client-side issue (deepseek-v4-pro/flash and other models work fine)

    Test Results (all via curl with anthropic-messages format)

    Test Model Config Result Latency
    T1 qwen3.7-max no thinking ✅ Success <1s
    T2 qwen3.7-max thinking enabled (budget=1000) ❌ Timeout (x2) 60s+
    T3 qwen3.7-plus no thinking ❌ Timeout (x2) 60s+
    T4 qwen3.7-max thinking budget=5000 ✅ Success ~8s
    T5 qwen3.7-plus thinking enabled (budget=1000) ❌ Timeout first try, ✅ Success on retry First: 60s, Second: ~40s

    Analysis

    The non-deterministic behavior suggests backend resource contention or aggressive rate limiting specific to the qwen3.7 series:

    1. No thinking on qwen3.7-max works perfectly (T1)
    2. Simple thinking (budget=1000) on qwen3.7-max consistently times out (T2 x2)
    3. Complex thinking (budget=5000) on qwen3.7-max works fine (T4)
    4. qwen3.7-plus shows similar intermittent behavior (T3, T5)

    This pattern points to a backend issue rather than client configuration. The fact that T4 (larger budget) works while T2 (smaller budget) does not is particularly puzzling.

    As a paying customer, I expect:

    1. Investigation into qwen3.7 resource allocation and rate limiting on the backend
    2. Better timeout tolerance for thinking mode requests
    3. A stable experience — paying to "maybe work" is not acceptable
    4. If this is a known resource bottleneck, please communicate plans for resolution

    Environment

    • Service: OpenCode Go (Zen API) — paid subscription
    • Endpoint: https://opencode.ai/zen/go/v1/messages
    • Models: qwen3.7-max, qwen3.7-plus
    • Client: OpenClaw (third-party integration)
    • Region: Mainland China (via proxy)

    Any acknowledgment or update would be greatly appreciated. Thanks.

  5. Joelincn commented on Jun 24, 2026

    @Joelincn
    Joelincn
    on Jun 24, 2026
    Author

    The bot asked to use the Bug Report template. Let me try to resubmit, but first I want to highlight an important finding from the related issue #32418:

    Key insight from @BernhardGruen in #32418: The root cause of the intermittent timeouts is that Cloudflare in front of opencode.ai has a 120s proxy read timeout, while qwen3.7 generation (especially with thinking) can take longer than 120s. Cloudflare then returns a 524 timeout error as HTML, which the client SDK cant parse as JSON, resulting in cryptic errors and retries.

    This perfectly explains our test results:

    • No thinking → fast (<1s) → no timeout → works ✅
    • Thinking with small budget → response time varies greatly → sometimes hits 120s CF limit → timeout ❌
    • Thinking with large budget → sometimes shorter than expected → passes CF limit → works ✅

    The fix needs to happen on the server side — either:

    1. Cloudflare needs a longer timeout for qwen3.7 endpoints
    2. Or the backend needs to translate 524 errors into proper JSON error responses

    cc @anomalyco/devs

    I will also re-submit with the proper Bug Report template as requested.

  6. github-actions commented on Jun 24, 2026

    @github-actions
    github-actionsBot
    on Jun 24, 2026 – with GitHub Actions
    Contributor

    This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.

    Feel free to open a new issue that follows our issue templates.

  7. github-actions
    removed
    needs:complianceThis means the issue will auto-close after 2 hours.
    on Jun 24, 2026
  8. github-actions
    closed this as not plannedon Jun 24, 2026

  9. Arsalankhan315 commented on Jun 24, 2026

    @Arsalankhan315
    Arsalankhan315
    on Jun 24, 2026 via email
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions