GPT-5.6 Sol, server overloaded errors

[akhansari]

Description

Since few hours I experience repetitive server overloaded errors with the Sol model.
I have no issue with Pi or Codex.

Plugins

No response

OpenCode version

1.18.9

Steps to reproduce

No response

Screenshot and/or share link

Operating System

Fedora 44

Terminal

Ghostty

[github-actions]

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

• OpenAI server_is_overloaded stream errors are not retried #25884: OpenAI server_is_overloaded stream errors are not retried — same symptom (overloaded errors with OpenAI models) and likely the same root cause
• Codex server_is_overloaded stream errors are not retried #25730: Codex server_is_overloaded stream errors are not retried — same underlying issue for a different OpenAI model

If your issue is specifically that the overloaded error is surfaced to you repeatedly without automatic retries, those issues track the fix.

[r0naldoom]

Same here, started a few hours ago. Only Sol — Pi and Codex are fine, and the other 5.6 tiers (Terra, Luna) too. Just repeated AI_APICallError / "Our servers are currently overloaded, please try again later".

I'm on the ChatGPT/Codex OAuth (not an API key) and on a totally different setup (NixOS), so it's not environment-specific. OpenAI's status page is green as well, so it really looks like Sol capacity rather than a general outage. Request id in case it helps: e8453f9a-0fcd-4fd1-9c6e-1f00d5cf00a9

Retrying for hours doesn't get through, so I don't think it's just the retry gap from #25884 — Sol itself seems throttled right now. Switched that agent to Terra as a workaround and it's fine.

[nyxiereal]

interesting, it all works in codex. i have chatgpt pro over oauth

[pedropereira-cd]

I'm having the same issues. For me this has started about 24 hours ago.

The 2x backoff retry multiplier makes this especially frustrating. After a few attempts, the wait jumps to several minutes, so in practice Sol becomes unusable. At least fixing the 2x backoff should be a very simple fix, but a PR for that has been rejected more than once now.

[nyxiereal]

@pedropereira-cd 2x backoff is okay, its there for a reason. a feature not a bug. it doesnt cause issues with sol as you may suggest

[pedropereira-cd]

@nyxiereal after attempt #8 it's already a 256s wait, and it doesn't stop there. I understand a backoff policy but 2x without caps when there are no retry-after headers it's too much. IMO.

[pedropereira-cd]

Temporary workaround that fixed it for me:

OPENCODE_EXPERIMENTAL_WEBSOCKETS=true

After setting it, fully quit and reopen OpenCode (and OS if necessary, i.e. make sure the new ENV is being read).

Windows PowerShell:

[Environment]::SetEnvironmentVariable(
  "OPENCODE_EXPERIMENTAL_WEBSOCKETS",
  "true",
  "User"
)

macOS:

launchctl setenv OPENCODE_EXPERIMENTAL_WEBSOCKETS true

Linux:

export OPENCODE_EXPERIMENTAL_WEBSOCKETS=true

I have only tested this on Windows and OpenCode Desktop, but the environment variable should apply across platforms. Since enabling it, Sol has stopped hitting the repeated overload/retry loop for me.

As an added benefit, replies and reasoning looks much faster as well.

[akhansari]

It seems to be working again now (without changing anything).
Same thing for you?

It was super annoying to switch to codex/pi btw!

[r0naldoom]

Yeah, same here — Sol's back to normal and I didn't change anything to fix it, so it does look like it just cleared up on OpenAI's side after a few hours.

And agreed, having to fall back was annoying (I'd temporarily pointed that agent at Terra to get through it).

[pedropereira-cd]

There's a chance that my "fix" above was pure coincidence then :)
I still find it decently faster though.

[akhansari]

@StarpTech I close the issue. We don't have enough logs, but I think this could happen again maybe because of some weird API responses.

[pedropereira-cd]

Same inital issue is back for me, meaning that the workaround was for sure pure coincidence. It still feels decently faster so I'm keeping it.

I would reopen the issue, so that at least the retry/backoff policy is looked into.