Help: wow-agent OpenCode Zen 502 Error

[uuzjw]

🏷️ Discussion Type

Question

Body

Hello OpenCode Community,

大家好，我正在开发一个开源终端 AI Agent —— wow-agent，在集成 OpenCode Zen 的 ox-alpha-free API 时遇到了一个稳定性问题，希望得到一些建议。

Environment / 环境

• OS / 操作系统: Ubuntu 24.04.4 LTS
• Agent: wow-agent (custom terminal AI agent)
• API: OpenCode Zen compatible API
• Model: ox-alpha-free
• Client: OpenAI-compatible API client

Problem / 问题

When using ox-alpha-free through OpenCode Zen, the API sometimes fails during streaming responses.

在通过 OpenCode Zen 调用 ox-alpha-free 时，流式响应过程中偶尔会失败。

The error message:

APIError: Streaming response failed: [502]
Upstream error from Nvidia:
Service temporarily overloaded

How to reproduce / 复现方式

1. Start wow-agent.
2. Configure OpenCode Zen API.
3. Select ox-alpha-free model.
4. Send a request that requires an agent response.
5. Sometimes the streaming response fails with HTTP 502.

Expected Behavior / 期望结果

The model should return responses normally, or the client should receive a proper retryable error.

希望模型能够正常返回结果，或者客户端能够收到明确的可重试错误。

Actual Behavior / 实际情况

The request occasionally fails with a 502 upstream overload error.

该请求偶尔会因为上游服务过载返回 502 错误。

Questions / 想请教的问题

1. Is ox-alpha-free currently experiencing rate limits or temporary overload?
2. Is there a recommended retry/backoff strategy for streaming API requests?
3. Are there recommended timeout or streaming configurations for OpenCode Zen?

是否有推荐的：

• 重试机制？
• timeout 配置？
• streaming 参数设置？

Thank you for your help!

感谢大家的帮助和建议！

Guidelines

• I have read and understood this category's guidelines before making this post.

[iawaisahmd]

the 502 upstream error from nvidia: service temporarily overloaded points more to the upstream provider than wow-agent itself. for the client side, i'd treat 502/503/504 as retryable and use exponential backoff with jitter, for example 1s, 2s, 4s, then 8s, with a small retry limit.

for streaming, also make sure a failed stream starts a fresh request rather than trying to continue the broken connection. logging the request id and retry count would help confirm whether failures cluster during provider load.

[uuzjw]

Thank you for the detailed explanation!

I agree that this looks more like an upstream provider overload issue rather than a wow-agent issue.

I will implement the following changes:

• Add retry with exponential backoff and jitter (e.g., 1s, 2s, 4s, 8s) for 502/503/504 errors, with a small retry limit.
• Make sure failed streams create fresh requests instead of continuing broken connections.
• Add request ID and retry count logging for debugging.

Thanks for your help!

[v-coder247]

Hi @uuzjw, thanks for participating!

Unfortunately, we don’t currently have moderators for languages other than English. Until that changes, we need to ask that everyone use English here in the GitHub Community when posting to ensure discussions are adhering to our Code of Conduct.

We’ll be locking this post for now, but please feel encouraged to create a new discussion in English if you still need support.