I am repeatedly seeing the following in Codex Desktop when selecting GPT-5.6 Sol:
Selected model is at capacity. Please try a different model.
I also receive server_overloaded errors. This persists after reproducing on a mobile hotspot with VPN and Secure DNS disabled, so it does not appear limited to my usual proxy or network.
I submitted in-app /feedback immediately after reproducing and have an open OpenAI Support case.
Selected model is at capacity. Please try a different model.
does not necessarily indicate that the earlier incident has returned. Capacity errors can occur again whenever demand for a particular model temporarily exceeds the available capacity, even after a previous incident has been resolved.
When ChatGPT first became available, similar capacity messages could appear several times a day, and the forum received many reports about them.
As the message suggests, try selecting a different model. Alternatively, wait about 15 minutes and try again.
Thanks. I understand that a one-off capacity message can be transient. However, that is not the case being reported here.
For over 48 hours, GPT-5.6 Sol has been almost continuously unavailable for me across repeated tasks. I have retried well beyond 15 minutes many times, including over a mobile hotspot with VPN and Secure DNS disabled. The errors persist.
An OpenAI Support case is already open. Based on the evidence supplied, Support stated that this appears to be a service-side capacity or routing issue rather than an exhausted usage limit or an issue specific to my usual network.
I subscribe to Pro specifically to use Sol / Sol Max. Falling back to another model is not an equivalent workaround for the capability I pay for, and it does not resolve a sustained failure of Sol availability.
Please treat this as an unresolved prolonged availability issue. Can an OpenAI team member confirm whether it has been escalated to the Codex model-serving team and whether there is a known account-, region-, or routing-specific incident?
Let's see if others are affected as well. In the meantime, could you share the support case number you mentioned? I'll take a look and see what's going on.
Hey everyone, if you're seeing the same issue, could you share:
Your device
Your plan (Free, Plus, Pro, Team, etc.)
Your region or country
That information will help narrow down whether this is affecting a specific set of users.
Support case number: 12301157
Device: Codex Desktop on macOS
Plan: Pro 20X
I prefer not to disclose my region or country in a public forum. I am happy to provide it privately through the existing support case if it is necessary for diagnosis.
I need to emphasize the severity and business impact. I purchased Pro 20X specifically for Sol Max and Ultra—the availability of those capabilities was the sole reason I chose this plan. For more than 48 hours, across several days, Sol has been almost continuously unavailable to me. The recurring capacity and server_overloaded failures have severely disrupted my work and caused significant distress.
Fallback models are not an acceptable remedy: they do not provide the paid Sol Max and Ultra capability I bought the plan for. I have already completed the requested network-isolation tests and submitted the feedback required in Case #12301157.
Please correlate this forum report with Case #12301157, have the Codex model-serving team investigate it as a prolonged availability failure, and provide a concrete escalation status and remedy. At this point, a generic “try another model” workaround is not sufficient. Please also advise what remedy is available given the prolonged loss of this paid capability.
@OpenAI_Support One further critical impact needs to be recorded.
Because my work is time-sensitive and I cannot afford a Sol task to stop, I have had to set up a dedicated Luna thread to monitor the work. Whenever the Sol task stops, Luna automatically sends “continue” repeatedly until the task completes. This is the only way I can make Sol minimally usable at the moment.
This is not a viable workaround. It consumes additional Luna quota, wastes time on repeated recovery attempts, and forces Sol to reprocess context after each interruption, increasing Sol usage. More importantly, I cannot verify that the critical reasoning and results after these repeated continuations actually meet the Sol Max / Ultra capability I paid for.
I cannot absorb the cost, delay, and quality risk created by this forced recovery loop while working under time pressure. Please treat it as urgent: have the model-serving team resolve the root cause promptly, and provide a clear explanation of what is happening, the escalation status, and the remedy for the prolonged loss of the paid Sol capability.
This is not a transient capacity message. Sol has remained effectively unusable across multiple projects, despite repeated recovery attempts. In two affected task sessions alone, there are 38 and 32 recorded “Continue” inputs respectively (70 total), yet reliable availability was not restored.
This forced recovery loop is not a viable workaround for time-sensitive work: it consumes additional Luna quota, repeatedly reprocesses context, wastes time, and gives me no reliable assurance that the resulting work retains the Sol Max / Ultra quality I am paying for. I purchased Pro 20X specifically for Sol Max and Ultra; fallback models are not an equivalent remedy.
Could you please:
Correlate this topic, Case #12301157, and the /feedback already submitted with the Codex model-serving review;
Confirm whether the investigation shows a capacity, account-routing, or other service-side issue;
Provide a concrete escalation status, next update point, and the remedy available for this prolonged loss of the paid Sol capability.
Also, please do not treat the generic “wait 15 minutes / use another model” guidance as a solution for this topic while the case remains unresolved.
If other users are seeing the same sustained pattern, it would help to reply with plan, Codex Desktop/CLI, approximate UTC time, and whether it affects multiple projects. There is no need for anyone to publicly disclose location or network configuration.
