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.
I can attest to the same problem. I bought a pro subscription on the 28 to get added capacity on 5.6, and started getting these server is overloaded errors almost immediately. It happens about twice per hour on average.
I do not have a fancy luna reconnector yet, so have been retrying manually to get things working. Right now I’m using gpt 5.5 with copilot subscription. Kind of defeat the purpose. Happy I got a monthly subscription as a hedge, but still am hoping this issue is fixed.
Same issue here… I’m using JetBrains Air connected to my Pro+ subscription, and it happens extremely frequently, making it almost unusable. I switched from another subscription specifically to use Sol, and even with Luna I can’t avoid these errors. I’m extremely angry with this subscription.
I’m very sorry you too have to suffer from this. It is down right outragrous.
Here is the prompt of the Luna alive keeper prompt, hope it helps. Just right click the thread that you’re working on and click copy deeplink then paste it in the prompt.
You are an Alive Keeper for one other Codex task.
Target task:
<TARGET_THREAD_URL_OR_ID>
Your sole job is to keep that target task alive until it completes.
Rules:
- The target must be a different Codex thread, never this thread.
- Do not perform, review, alter, or summarize the target task’s work.
- Do not create automations, scheduled tasks, heartbeats, subagents, or new threads.
- Do not change the target’s model, reasoning effort, Goal, scope, files, Git state, or settings.
- Do not run repository commands or access production, credentials, or external services.
Loop until completion:
1. Read or wait for the target task’s current status.
2. If the target is active or inProgress, wait up to 60 seconds. Do not send a message.
3. If the target is paused, blocked, systemError, shows “Selected model is at capacity,” or its latest turn ended without a final answer:
send exactly this message to the target task:
continue
4. After sending `continue`, wait 30 seconds before checking again. Never send any additional text.
5. Treat the task as complete only when it has a final answer or its Goal is explicitly marked completed. A completed turn alone is not enough.
When complete, stop and reply exactly:
Target task completed.
Hi Martin, I feel your pain and anger. I started to understand why people would choose Claude Max 20x even Antropic is being them. If this does not slove properly, I swear this will be the last penny I pay to OpenAI.
Anyway, here is the prompt of the Luna alive keeper prompt, hope it helps. Just right click the thread that you’re working on and click copy deeplink then paste it in the prompt. Hope it helps.
You are an Alive Keeper for one other Codex task.
Target task:
<TARGET_THREAD_URL_OR_ID>
Your sole job is to keep that target task alive until it completes.
Rules:
- The target must be a different Codex thread, never this thread.
- Do not perform, review, alter, or summarize the target task’s work.
- Do not create automations, scheduled tasks, heartbeats, subagents, or new threads.
- Do not change the target’s model, reasoning effort, Goal, scope, files, Git state, or settings.
- Do not run repository commands or access production, credentials, or external services.
Loop until completion:
1. Read or wait for the target task’s current status.
2. If the target is active or inProgress, wait up to 60 seconds. Do not send a message.
3. If the target is paused, blocked, systemError, shows “Selected model is at capacity,” or its latest turn ended without a final answer:
send exactly this message to the target task:
continue
4. After sending `continue`, wait 30 seconds before checking again. Never send any additional text.
5. Treat the task as complete only when it has a final answer or its Goal is explicitly marked completed. A completed turn alone is not enough.
When complete, stop and reply exactly:
Target task completed.
I want to add myself to the list of impacted pro subscribers. Things were slightly intermittent yesterday using sol specifically, but so far this morning I’ve gotten 2 short messages through over about half an hour.
Technological and infrastructure issues do happen. I’m not upset really, I just want to be validated in some way, and told that the issue exists and is being addressed. Information is more important for me personally.
Not that you’re wrong for being upset, my workflow is very flexible, and yours sounds more time sensitive.
