Feature Request: Service Load and Capacity Transparency

What variant of Codex are you using?

App and Chat

What feature would you like to see?

Summary

I would like to suggest adding a user-facing service load / capacity indicator to ChatGPT, Codex, and potentially other OpenAI products.

When OpenAI services are experiencing high demand or capacity constraints, users currently have very limited visibility into whether a problem is caused by their own network, client, account, model availability, or temporary service congestion.

A simple, privacy-preserving service status indicator could significantly improve the user experience.

The Problem

When a model becomes slow, requests fail, reconnections fail, or a model temporarily becomes unavailable, users often cannot determine what is actually happening.

For example, a user may experience:

• Requests taking unusually long to complete
• "Failed to reconnect" errors
• Requests being rejected or failing intermittently
• A model being temporarily unavailable
• Significant differences in response latency
• Codex requests failing or being queued for a long time

From the user's perspective, these symptoms can look very similar to a local network problem, client problem, authentication problem, account problem, or model-specific issue.

This creates unnecessary troubleshooting and uncertainty.

Proposed Solution

Add a simple user-facing service load indicator.

For example:

🟢 Normal
Service operating normally.

🟡 Elevated Load
Demand is currently elevated. Some requests may experience increased latency.

🟠 High Load
Service capacity is under significant pressure. Requests may experience delays or intermittent failures.

🔴 Service Degradation
Some services or models are currently experiencing degraded availability.

⚫ Service Unavailable
The service is currently unavailable.

The exact terminology and thresholds would of course be determined by OpenAI.

Model / Product-Level Status

Ideally, the status could also be displayed at the product or model level.

For example:

ChatGPT

• GPT-5.6 Luna — 🟢 Normal
• GPT-5.6 Sol — 🟠 High Load
• Web Search — 🟢 Normal

Codex

• Codex — 🟠 High Load

This would be particularly useful when only a specific model or product is experiencing capacity issues.

Important: No Sensitive Infrastructure Information Is Required

I am not suggesting that OpenAI expose internal infrastructure metrics such as:

• GPU utilization
• Number of servers
• Internal request queue sizes
• Internal capacity figures
• Infrastructure topology

A simple aggregated status level would be sufficient.

The goal is not to expose internal infrastructure. The goal is to provide users with enough information to distinguish between:

"Something is wrong on my side"

and

"OpenAI is currently experiencing elevated demand or reduced capacity."

Why This Would Be Valuable

This could improve the user experience in several ways:

1. Reduce unnecessary troubleshooting

Users would not need to repeatedly restart the application, change networks, reinstall clients, or modify configuration when the underlying issue is service-side congestion.

2. Improve transparency

Users would have a clearer understanding of why service behavior may temporarily change.

3. Improve confidence in the product

Temporary degradation is understandable for a large-scale AI service. The frustrating part is often not the degradation itself, but not knowing whether it is happening.

4. Help users make better decisions

For example, if a model is experiencing high load, users could temporarily switch to another model instead of repeatedly retrying the same request.

5. Improve the Codex experience

This would be particularly useful for Codex because development workflows can involve many requests, and repeated connection failures can make it difficult to determine whether the problem is local or service-side.

Possible UI

A small indicator could be placed near the model selector or connection status.

For example:

GPT-5.6 Sol · 🟠 High Load

Clicking the indicator could show:

"OpenAI is currently experiencing elevated demand for this model. You may experience increased latency or intermittent request failures."

It could also provide a link to the detailed OpenAI Status page.

Optional Historical Information

An additional improvement would be a short-term status history, such as:

Last 24 hours:

• 09:00 — Normal
• 11:30 — Elevated Load
• 12:15 — High Load
• 13:05 — Normal

This would help users understand whether an issue is temporary or persistent.

Overall Goal

The goal is not to guarantee perfect availability.

The goal is to provide users with a clear signal about the current service condition so that they can distinguish between local problems and OpenAI-side capacity or availability issues.

Even a simple three-level indicator such as:

🟢 Normal
🟡 Elevated Load
🔴 Degraded

would already be a significant improvement.

I believe this would be a relatively simple product feature with a meaningful impact on transparency, troubleshooting, and user trust.

Additional information

I believe this would be especially useful during periods of high demand, when users experience model unavailability, failed requests, slow responses, or repeated reconnection attempts.

A simple real-time load indicator would help users quickly understand whether the issue is likely on their side or related to OpenAI service capacity.

I am not suggesting exposing sensitive infrastructure metrics. A simple aggregated status such as "Normal", "Elevated Load", or "High Load" would already be very helpful.

This could potentially be integrated with the existing OpenAI Status system and displayed directly in ChatGPT and Codex.

I would really appreciate it if the OpenAI team could consider this request. I hope this suggestion can help improve the user experience, and I’d be happy to provide any additional feedback if needed.

My email address: tengjieling@gmail.com

I look forward to hearing from you.

The issue names no Codex files, tests, or entry point; start by checking how the existing OpenAI Status system could be surfaced in Codex. Define the supported products and models, status source, privacy boundaries, UI location, and acceptance criteria before implementation.