Codex Desktop no longer shows visible context/token usage indicator
What version of the Codex App are you using (From “About Codex” dialog)?
26.519.2081.0
What subscription do you have?
ChatGPT Business
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
After updating Codex Desktop, the app no longer shows a visible context/token usage indicator in the chat UI.
Previously, Codex exposed context usage information such as context-window pressure near the input area / usage indicator. After the recent update, I can no longer find this context usage display or tooltip.
This makes long coding sessions harder to manage because I cannot tell when a thread is getting close to compaction, context pressure, or possible context loss. For professional coding workflows, this information is important because it helps users decide when to compact, start a new thread, reduce pasted context, or split work.
Related existing issues:
What steps can reproduce the bug?
- Open Codex Desktop on Windows.
- Start or open any Codex chat/thread.
- Look near the input area or usage/context indicator where context usage was previously visible.
- Hover over available usage/status UI elements.
- Observe that there is no visible context/token usage information or context pressure indicator.
What is the expected behavior?
Codex Desktop should show visible context/token usage information again, or provide an advanced context/status panel.
Ideally it should show:
- current context
- remaining context or approximate context pressure
- whether compaction has happened or is approaching
- a clear distinction between current context usage and cumulative usage/quota
Additional information
This appears to be a UI/UX regression. If a raw percentage is considered misleading, an approximate context health indicator would still be much better than hiding the information entirely.
Suggested UI:
- Low / Medium / High context pressure
- Last compaction status
- Loaded files or active context sources
- “Consider starting a new thread” recommendation when appropriate
172 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I can confirm the context window indicator has gone.
again, a stupid bug that can reproduce if you just open app
Additional local evidence for the context/token usage indicator regression:
Environment:
C:\Program Files\WindowsApps\OpenAI.Codex_26.519.2081.0_x64__2p2nqsd0c76g0\app\Codex.exe26.519.21041.26.513.4821.0; after reboot only26.519.2081.0is installed/running.Config/backend evidence:
models_cache.jsondid not regress:gpt-5.5.effective_context_window_percent=95,context_window=272000;gpt-5.4.context_window=1050000,effective_context_window_percent=95via a local model catalog.token_countevents withmodel_context_window=258400forgpt-5.5.context compactedseparator after compaction.Frontend evidence from the extracted 26.519 webview bundle:
git-branch-picker-dropdown-content-DbCczbcx.jscomputes context usage fromtokenUsage.modelContextWindowandtokenUsage.last.totalTokens.composer-CWBCSPDQ.js, that computed usage is only referenced by:/compactslash-command description:Compact this thread's context ({usage}% full)/statuspanel row:Context: {remaining}% left ({used} used / {total})This suggests the current issue is not a model metadata or auto-compaction failure. The backend has the required token/context data, but the Desktop UI no longer exposes it as a visible persistent context indicator in 26.519.
Adding another data point from #23838, which was closed as a duplicate of this issue.
This is specifically about the Codex desktop app, not the CLI/TUI
/statuslinefeature./statusis useful as an explicit command, but it is not a replacement for passive context awareness during long-running desktop threads.The use case is not just curiosity about token counts. A persistent, clearly labeled
Context N% usedorContext N% remainingindicator helps users decide when to compact, fork, or start a fresh thread before output quality starts degrading or auto-compaction surprises them. The previous passive indicator materially affected workflow planning in long sessions.If the old UI caused confusion with quota/rate limits, an opt-in advanced setting would solve that without removing the signal entirely:
I also submitted this through the Codex feedback form:
019e48ff-3e50-7750-87c8-4d29a4fd0ab8.Yes, they are very stupid. Every update has very stupid bugs, and the bugs in the Codex app are outrageously numerous.
Same issue. Please fix quickly.
I can confirm the context window indicator has gone.
I'm on a MacOS 15.7.7 (24G720). It's missing in Version 26.519.22136 (3003) here too. It was visible in the previous release.
<img width="369" height="51" alt="Image" src="https://github.com/user-attachments/assets/122aee37-a6fb-4d43-8757-2ec08f2d95fd" />
<img width="214" height="30" alt="Image" src="https://github.com/user-attachments/assets/b02d29b2-3e88-48b5-9341-f2264a737f1a" />
Daily reminder that we miss our context window indicator.
Any idea how to get this back? It's breaking my workflow. Is this truly the intention of the Codex team? I can't believe that.
hello all! yes, this was not an accidental change. the intention is that Codex has infinite context, and the indicator often gets in the way of leveraging automatic compaction (which we believe is the best experience). we have also shipped a
/compactcommand if you'd like to manage it manually.there are still two ways you can view the current context window:
<img width="1528" height="326" alt="Image" src="https://github.com/user-attachments/assets/75fbd171-67cf-4f2b-8f4c-6a0aff1704a1" />
<img width="1528" height="326" alt="Image" src="https://github.com/user-attachments/assets/a4d0bbb6-0925-4b21-9e6c-eb80059f766b" />
please do share how this broke your workflows!
Compaction is neither free nor instantaneous. If it were, it would be closer to supporting the intention of infinite context. Because it's not, I will make an (ideally educated) tradeoff between starting a new thread or compacting the current one. You've made that significantly harder by hiding the visibility behind a status command.
Please fix, the visual context indicator was a really nice quality of life enhancement over Claude Code
@alexi-openai - appreciate the transparency on this being intentional and your fast engagement. That means a lot. That said, here is my feedback:
"Codex has infinite context" (or appearing to from a user perspective) is a good aspiration, but it is obviously not the current reality. Until automatic compaction is reliable enough that users genuinely don't ever need to think about context health, removing the passive indicator hurts the user experience, not helps it.
The /status and /compact commands are useful, and I use them, but they are not true replacements for an always-visible indicator. Passive context awareness is different from a command I have to remember to run. I care about context management and try to track when to compact or start a new thread, but when I’m deep in flow state, I won’t always think to check /status. (Or have that huge window open all the time with info I don’t need, like session ID.) The indicator caught issues I would have missed; by the time I’m suspicious enough or remember to run a command, the context fill-up has likely already cost me time, tokens, or both.
Bottom line.... That indicator was the single most accessible tool we had for managing both session quality and token spend per response. And you removed it before delivering the improvement that would justify its removal. What happened here is basically analogous to removing the speedometer/dashboard from the self-driving car because you're optimistic it'll eventually be updated to never exceed the speed limit on its own.
I'd strongly suggest restoring the indicator as an opt-in setting, at minimum. Default users who trust automatic compaction can have it hidden by default. Power users who find careful control of context management important can keep it as a mini dashboard. That gives you the default UX you want without stripping power users of a signal they actively depend on. Enough people have been upset by this and are seeking out solutions and answers to justify this rollback or opt-in change.
One last side note: I know how minor this complaint must seem in the big picture, in terms of the "real problems," but it's little details like this that make the user experience something special versus the competition.
empathize with that! do you mind sharing why automatic compaction doesn't always work for you? any specificity would be helpful for the team.
HEY, RETUTN IT
I strongly urge the Product Managers to listen to their users; this represents a blatant regression in the product. There is absolutely no regard for the user experience of the Codex client community. While I am fully aware that OpenAI possesses exceptional context compression capabilities, the very least you could do is offer users a choice—specifically, a toggle button that allows them to enable or disable this feature themselves. I am convinced that, for the vast majority of Codex users, access to the context window is an absolute necessity.
Originally, before sending a request, I could easily glance at the context window to see whether it was close to the automatic compression limit. This allowed me to manually compress the context with /compact before the work started. But without this UI, I often miss this step.
Automatic compression has some serious bugs. First, when automatic compression happens, the work that was still in progress before compression may be treated as completed after compression, causing the process to skip ahead directly. Second, automatic compression may compress the instructions from the current conversation as well. This can damage the completeness of the instructions I gave and cause the agent’s work to drift away from my needs. Sometimes, large parts of my requirements are even lost during the compression process.
Most importantly, the Codex context window is not truly infinite, and compression itself also takes time. When automatic compression happens in the middle of a workflow, the experience is much worse than noticing the context limit in advance through the UI and then manually compressing the context or switching to a new thread.
Displaying the context window is extremely important to me. As a researcher, the loss of critical information can disrupt my entire workflow; therefore, I typically choose to open a new window once my context usage approaches approximately 200k.
@alexi-openai You are being way too arrogant.
Before killing a feature, you should at least keep a toggle for the developers who need it. Every compaction loses information. Isn’t that obvious? When you compress a 200k context down to 20k, how could there possibly be no loss?
You can hide it by default if you want, but please give us an option to turn it back on.
I was able to roll back successfully. The context indicator is back for me on 26.513.31313.
Shortest macOS Apple Silicon workaround:
Right-click Codex in the Dock -> Quit, or quit it from the menu bar.
On macOS, press
Cmd + Space, typeTerminal, and press Enter.Then start Codex CLI:
``
bash
``codex
```text
Please roll back my Codex Desktop App to version 26.513.31313.
I am on macOS Apple Silicon / arm64. Use the official package:
https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.513.31313.zip
Requirements:
defaults write com.openai.codex SUEnableAutomaticChecks -bool false
defaults write com.openai.codex SUAutomaticallyUpdate -bool false
```
Note: this is a manual rollback, not an official rollback button. I would only use the official OpenAI
persistent.oaistatic.compackage, not third-party download sites.@cooltzy's response shows the disconnect:
We are not asking for better compaction, no one in this thread is. We want easy to see information that lets us avoid compaction entirely if we choose to.
The question @alexi-openai asked presupposes that we want compaction to happen and just want it optimized. That we want it to feel like "infinite context" and a limitless, never ending chat thread. But actually, a lot of us treat the context window as sacred space. A compaction event replaces specific information we might need presented as is with a summary, and that summary is lossy no matter how well it's done. @apple-ouyang has it right: when you compress 200k context down to 20k, how could there possibly be no loss? Especially for scientific and specific coding workflows.
We used the indicator to see compaction coming so we could avoid it, or to know that our cost per message is creeping up to an unacceptable level. Start a new thread, spawn a subagent, or manually compact when timing is right after finishing a task on our own terms, etc. Compaction triggering by surprise because we couldn't passively monitor context usage is the problem. Ask yourselves why the indicator was built in the first place...... That's probably why.
@alexi-openai, I appreciate you engaging with us here, but the framing of the question itself is a huge red flag to me. It points to two possibilities:
Either one is problematic. And no offense is meant, I know you have the best intentions, and at least you are in the conversation, but it's important to be candid here and not beat around the bush.
I'm leaning toward number two, because nobody at OpenAI shipping this product is confused about how attention works in transformer architecture. The engineering team knows that ceiling exists. Infinite context and perfect attention aren't a thing and won't be anytime soon. So compaction is the only option for now. But "We'll make compaction so good you won't notice" is at odds with the reality that many of us don't want it compacted at all. We want specific information preserved exactly as is, not gambled on whether a summary retains it.
The framing of the question I think tells the story. If avoidance were on the table, the question would have sounded more like: "Do you mind sharing why preserving and monitoring context window usage is important to you and why you want to avoid compaction?" Instead it was framed as "why doesn't auto-compaction work for you?" Those are very different questions pointing in very different directions.
The ask from everyone in this thread is clear and simple: restore the indicator, even as opt in. Users who trust auto compaction keep the intended new UI. The rest of us who manage our own context keep the passive indicator, as power users should. That's who Codex is for, as opposed to the "antigravity 2.0, it's all magic, don't worry about it" approach that I would hate for Codex to turn into.
Man it's kinda sad I found this issue, but good to know other smart people found the same problem.
Everything people have said is true. Please bring back the context indicator.
It's funny... just before I updated I was like "Maybe this update won't be evil"
C'mon guys.. very disappointing.
Adding another macOS data point with concrete workflow impact.
Environment:
New evidence:
In a current long-running Codex session, the app automatically entered “Automatically compacting context” while there was no visible persistent context usage indicator near the composer.
This is exactly the workflow problem caused by removing the visible context indicator. Without the old percentage/context-pressure indicator, I had no passive way to know that the thread was getting close to automatic compaction.
Why this matters:
/statusor/compactis not an adequate replacement because it requires active checking. The previous passive indicator gave continuous situational awareness without interrupting the workflow.Expected behavior:
Please restore a visible context usage / context pressure indicator, or add an advanced setting to enable it.
A good compromise would be:
This feature was important for making long Codex sessions predictable and trustworthy. The current behavior makes context compaction feel sudden and harder to manage.
<img width="2047" height="398" alt="Image" src="https://github.com/user-attachments/assets/9c1fa3eb-8418-4390-9ea9-86b7994a85ba" />
@alexi-openai wtf is this update, bring back the context window indicator.
Thanks for the feedback, all. As you know, we at OpenAI are the largest users of Codex and we are all fiercely protective of the product experience.
We believe the future is definitely auto-compaction, where you don't need to worry about this at all. Candidly, we didn't see much pushback internally on this one– there is very wide adoption of "vibe contexting" at OpenAI. Even with extremely long threads!
_However_.
Sometimes it becomes clear we're trying to live a little _too_ in the future and this may have been one of those times.
I do want to be quite clear that the Codex team is incredibly empathetic and that we make product decisions with care. It can be easy to be skeptical of this and ask questions like "well, why would they take this away when there was no issue with having it– we know what we want!" and this is very fair! I think that one of the unique product challenges around LLMs in general is that the model capabilities can change dramatically in very short amounts of time without the product surface changing much. This makes short-term habits stick really hard even when they outlive their usefulness– things like "think hard" or "make no mistakes" or "make a plan first" come to mind. In this case, we thought that the context donut was an anacronism no longer deserving of top-level real estate.
Discussions like this keep us honest and is why we choose to build in the open. I always hope we can do so extending each other grace and not getting too personal.
We will quickly revisit this decision. While we will not always make product decisions through democracy, the feedback here is meaningful and we thank you for it.
Because the codex team can use GPT-5.5's full 1M context window, while we're stuck with the so called 400k but in fact only a 258k context window.
Without context indicator, working with codex becomes so unreliable.
We are professional developers, we know what a context window is and how to manage it.
Please do not hide it from us.
@ambrosino-oai
Cue the Fallout response
Everybody liked that.
👏👏👏
This is a great response and exactly what we like to see. Thanks for being so candid.
Perhaps the issue was exactly like you said , nobody pushed back internally because everyone on your team tends to use Codex the same way. But in the wild, Codex use cases are all over the map.
And it's clear this was a "cart before the horse" situation. If this were one of those solved habits you mentioned, like "think hard" nobody would have noticed or complained. But context management or your compaction isn't solved or perfected yet. Not even close. So it's good you're reconsidering.
Just remember we're asking for the option here, not to totally reverse your decision on what the default should be. I think that's reasonable for everyone.
Good comment. Appreciated.
I appreciate the response and the willingness to revisit the decision. That said, I think I speak for many users when I say that phrases like "while we will not always make product decisions through democracy" ring hollow when zero external feedback was gathered from the people who use and pay for the product.
Two statements in your post deserve closer scrutiny:
Auto-compaction may well be the future, but for me and uniformly among my team, it is not a replacement for visibility. We want to know how much context remains so we can manage our workflows, decide when to start a new session, decide when to summarize, and avoid losing useful thread history mid-task. It's not about "worrying." It's about choice. I don't need OpenAI deciding on my behalf whether something like context visibility is worth "worrying" about. And OpenAI shouldn't be assuming technical preferences on behalf of its users.
Which brings me to the bigger issue:
Candidly, every single developer I spoke with today, and every reaction I saw on Reddit and elsewhere, was uniformly negative about this removal. That gap exposes a real problem. OpenAI's internal testing clearly does not reflect how real-world users think about the tools. And notice the framing: the pushback wasn't absent in external testing, it was absent internally. Why not tell users ahead of time? Why not solicit input before removing a visibility feature people actively rely on? A beta test, a toggle, an opt-in... there are so many transparent ways this could have been handled.
Codex is marketed as a developer tool. Developers are literally paid to care about things like context management and compaction behavior. If the product is also now meant to serve general consumers and address their "worry", great, but make features available for both audiences.
One thing that has become very clear (not just from this issue- but for awhile now) is that we really need to fix our beta program/app and run a proper early access program that leaves room to test changes like this externally
This is probably redundant if your team has already explored this, but just in case it's useful feedback on improving the auto compaction process itself:
The best approach, in my opinion, is to make compaction intelligent rather than uniform. Not just a single blanket summarization pass, but a dedicated compaction sub-agent (similar to how you already have a dedicated permissions review agent) that triages context by type and importance. Actual user/assistant role discussion turn by turn might be kept verbatim, while redundant shared inputs, log files, console outputs, etc can be aggressively trimmed or compressed. (Maybe even stuff like caveman style compression for the turns) Weighted decisions, NOT a blanket process like today typical compaction methods.
Empower this special compaction agent by giving it tools designed for context management . Like a DaisyDisk/WinDirStat-style view of what's in the context window, ranked by token usage. Let it work down from the biggest offenders, compressing or simply truncating altogether what it can for maximum space recovery while leaving as much high-value content untouched as it can. Leaving mini notes, comments, and markers as it goes so it doesn't confuse future turns.That alone changes compaction from a dreaded event into a sensible one.
And maybe give users the ability to set config files or guidance for the compaction agent, the way we already can with the auto-review agent. Let us specify preferences for how different types of content should be treated during compaction.
I think the future is in context management, not prompt engineering, which mattered more in the GPT-4 era. This is where the real workflow gains are now.
this is not just about context window. openai team may not check the token usage since it is abundant for them, but there are developers who need to strictly check their token usage! i am so mad that i updated the app.
I don't mind auto compaction, but the problem is that you guys never fixed the bug of auto compaction failure, where we have to avoid it to manual compact before context reaching 80%, and there's where the live context view is useful.
Adding a Windows data point after the May 22, 2026 desktop updates.
Environment:
OpenAI.Codex_26.519.2736.0_x64__2p2nqsd0c76g0toOpenAI.Codex_26.519.3891.0_x64__2p2nqsd0c76g0; after a later same-day update, the bottom composer context ring is still gone. I could not retrieve the current About-dialog version from the command line becauseGet-AppxPackageis denied on this machine.Observed behavior:
0.133.0release notes and did not see the removal of the persistent context usage indicator called out, so it was not clear from the release notes whether this was intentional.Workflow impact:
/statusand/compactare useful, but they are not equivalent to an always-visible indicator because they require actively remembering to check.Expected behavior:
Good to see the real voice of OpenAI and the Codex team, without faking that they actually care. 👏 An intentional decision without clarification, just letting users find it out themselves, check with each other, and then telling them to get used to it. _Classic._
Since we are embracing _vibe contexting_, can we expect _vibe billing_ to roll out soon? I’d love to stop worrying about my token usage and just pay whatever amount feels right to me.
Please don't feign ignorance, it's really not a good look. We're well past the whimsical early days of AI where this stuff can fly. Real businesses depend on Codex now as an integral part of their workflows.
You know this full well, and I shouldn't need to waste my time stating it here. Automatic compaction is by definition lossy. I need to be able to look at Codex at any moment to quickly establish whether it did recently, or will compact soon because Codex' performance on a task is _vastly_ different when real data is in the context vs. a lossy summary of it.
Worse, when you're dealing with projects over 1 million lines in length, Codex can and _will_ get into compaction loops if you're not careful. It's important to know whether I'm asking too much of the model at any given moment, in which case, I need to spend more time on refining my instructions to the LLM. Typically this involves preparing my own carefully constructed design documents that steer the LLM to the correct parts of the codebase and give it an architectural understanding of _relevant parts_ of neighbouring systems without Codex trying to fit those entire neighbouring systems in its context — since it's incapable of doing so.
I also deliberately compact at appropriate points to avoid issues such as "lost in the middle" or general context drift/pollution. (Which is why Ralph loops are supposed to start fresh on each iteration, btw.)
Am I wrong in assuming that this is still a real problem?
That said, I also miss the old UI indicator.
@alexi-openai @ambrosino-oai one more input, as I did not see this important aspect mentioned, yet: You are not paying for things when using Codex. We (users) have been changed to token-based usage windows not too long ago. Not sure if this is correct, but if token-based billing / usage windows are based roughly on API-pricing, then long context is using up quota / money much quicker. So we absolutely care 🤦. And context compaction also counts towards quota, no? So you are hiding away our meter of consumption very well. This is super annoying.
If my assumptions were wrong, please correct me. But honestly speaking, it smells if you introduce usage-based quota and then remove the metering of that quota.
If you plan to make usage infinite, like the context, sure, maybe less people would object to removing metering (again, without an announcement or clear communication)... This pattern is repeating and frustrating.
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact) just always happen to me
You made it harder to see when to start a new session before codex gets lobotomized by auto compact. Saying the intention is that Codex has infinite context is like saying the intention is that there is world peace... Intentions does not make things magically real.
This is the key point here for me. Think about it carefully. A lot of us assumed the indicator was removed because of a labeling issue, or because users were confusing context usage with rate limits.
But by the OpenAI employees' own words here, the ACTUAL reason was that the indicator conflicted with their product vision of giving the appearance of "infinite context" and never needing to manage your context window. They removed the thing that helped users deal with the current reality because it didn't match the future they wanted to project....but before actually building that future!!
Then @ambrosino-oai candidly admits they didn't catch the problem because they only validated against internal feedback, where nobody complained. But as everyone here noted their internal team all uses Codex basically the same way doesn't have to worry about token spend, and presumably has access to the full 1M context window for 5.5.
In retrospect this is one of those product manager "vision" decisions that's obviously a massive blunder once you see the disconnect between who tested it and who uses it.
Credit to the team for owning it fast once the thread lit up. But this one should probably end up in somebody's internal postmortem deck.
Put the context indicator back please.
Adding our strong request as well: please restore the always-visible current-session context/token indicator in the Codex Desktop composer/status area, or at minimum add an opt-in advanced setting to bring it back.
For our workflow,
/statusand/compactare useful but not equivalent. The old indicator was valuable because it was passive and visible while working, so we could decide before starting a large task whether to compact, fork, or open a fresh thread. Having to remember to run a command breaks that flow, especially in long-running sessions.This is not just about curiosity. It affects context management, compaction timing, session quality, and token/usage awareness. Please bring the indicator back for users who rely on it.
One more important workflow detail: the indicator was not only a convenience feature. Tracking context status directly in the composer helped us get higher-quality results, especially for coding and planning tasks.
When the indicator was visible, we could see context pressure before starting a complex implementation or planning step, then decide whether to compact, split the work, fork the thread, or start fresh. That often produced better answers and fewer degraded/forgotten-context outcomes. Without the visible signal, it is much easier to accidentally begin a large coding or planning task when the session is already too full, which directly hurts result quality.
So for power users, this is part of the quality-control loop, not just a UI preference.
Bring it back please, this is a regression for myself and MANY others. Even if it has to be enabled under the settings menu, for many workflows and types of work it is a very important feature.
vibecoders of codex should be punished . critical bug provided and update today didn't fix it.
People report this decision as a bug. Not a single comment agree with OpenAIs take that we already have infinit condex but instead people say that it's critical to keep track of contex usage for their workflow. The only thing every AI influence is talking about is context managment. Why is this not a clear, bring the feature back quickly, and then lets us reevaluate the decision and gather more information. Dont delay the fix by asking people in the comments to explain how it impact them here in the comments.
if the goal is to reduce UI clutter, please consider making it optional instead of removing it entirely, a simple setting like “Show context usage” would let users who rely on it keep it visible, while others can hide it
This also affects the VS Code Codex extension, not only Codex Desktop.
In the VS Code extension, the context usage indicator disappeared after updating to build 32039. Before this update, I could see the context size/usage during a chat. Now this information is missing.
Please restore the context usage display in the VS Code extension as well.
Seeing your context window is an important part of working with LLM's. Not only does it show you how close you're getting to compression or compaction (which ultimately results in data loss), but it also tells you how your input and its output is affecting context. Were my instructions too broad? Was the task more complex than I anticipated? Did something change with how the model uses tokens? All of this requires knowing how tokens are being used and filling the context window, and has nothing to do with compaction.
It's nice that at least I can still see it with /status, but I check the context window after every response and it has become an integral part of how I manage my sessions.
Also on a related note: I've tried running longer sessions using automatic compaction and found that compaction fills >50% of the context window after a few compactions, meaning they become more frequent and I have less control over what is actually in context. It does pretty good at keeping important things in context, but I definitely see drift and that it has to re process or load past info from the session. So automatic compaction is not "infinite context" like you would like to claim it is.
Please bring the context indicator back.
It was a simple, effective tool that made a huge difference. Its removal is a step backward for developer experience.
I understand the push for a cleaner interface, but context is still a finite resource. It frequently requires manual oversight.
Codex's auto-compaction is probably the best on the market, but compaction isn't flawless. When triggered unexpectedly, it can disrupt workflows, lose track of initial goals, or revert relevant edits, forcing me to spend time and effort re-explaining the initial goals to get the model back on track.
The usage indicator prevented these issues by allowing me to be proactive.
AGENTS.mdto always run project scripts silently, saving tokens and improving the experience.If UI clutter is the primary concern, please consider placing this feature behind a toggle.
Leave it enabled for the "Coding" profile (and hidden for "Everyday Work") 💡
The rapid pace of UI changes and the constant shifting of basic elements (like the pin icon!) creates unnecessary friction. UX should be about ease of use, stability, and predictability, not continuous overhaul.
This push toward "the everything app" might seem like a good idea for management, but it's an illusion: it will alienate us, the fans who love you and the app.
Don't try to be everything for everyone, it won't work. Keep Codex focused on what makes it great for developers _(at least when the "For Coding" profile is selected)_.
We've seen a similar pattern before, with Claude... and many of us rely on Codex precisely because it hasn't gone down the Anthropic path (yet).
Please don't make the same mistakes. Please don't become Anthropic! 🙏
Additional affected-user report / feedback UUID:
019e4e3f-0465-7cb1-9262-2f0c1d96adb4I am seeing the same regression after the latest update: the context window meter/indicator is no longer visible, so I cannot tell how full the context window is during a thread.
In the current UI, the visible status area only shows the model/reasoning selector, e.g.
5.5 Extra High, with a dropdown. There is no context-window fullness meter or equivalent context pressure indicator visible.<img width="759" height="126" alt="Image" src="https://github.com/user-attachments/assets/e9fa98b5-0192-44b3-bced-db4b5ef3d6e5" />
Expected behavior: restore the context-window fullness indicator, or provide an equivalent context pressure/remaining-context signal so users can tell when a thread is approaching compaction or context loss.
@alexi-openai and @ambrosino-oai we _empathize_ with you guys 😃
⚠️ Testing with unlimited budgets and 1M+ context windows on fast mode is not the same.
⚠️ Wow, what a masterclass in communicating with your users! 👏
You guys _really_ care about us, ain't it? It's all about those corpo benjis, am I right? We're just the test base & free advertising sheeple, just like Theo said...
_Candidly_, this feels like "Let them eat cake!" 🍰
PUT 👏 THE 👏 CONTEXT 👏 WINDOW 👏 INDICATOR 👏 BACK 👏 IN 👏 THE 👏 CODEX 👏 APP 👏 PLEASE 👏 OPENAI
Always do things they think are right, without considering the actual user scenarios.
I mean, on this change in particular, I think the answer that would have made the most sense even given the goals/viewpoints of the team at OAI was:
I'm impressed at the rapid speed of development of Codex Desktop, but I think that one of the biggest opportunities that AI-assisted development gives us is that rolling out features/changes "the right way" is a lot easier now too. In the past, it was a much bigger decision to prioritize feature velocity over change testing, but now we should really be able to do both.
Good take. They removed a critical feature that is really the only one way we have to passively make and judge on the thing that lets us directly control model performance and cost per turn... absolutely insane to me they did this only because it harmed their intended perception of users that codex should have "infinite context".
This should be taught in classes as a lesson in how NOT to do prod software changes and engaging with users.
The fact we have to explain the basic reality of context window management to literally OpenAI themselves here is such a blunder. They know full well how important context management is and that the current reality in no way matches their intended perception of having "infinite context". They knee capped a critical workflow feature for zero good reason other than "vibes" as admitted by them directly.
Simply outrageous.
One additional technical point: the underlying data still appears to exist. The app/session still emits
token_countevents,/statusand/compactcan still surface context information, and local config still supports status-line items such ascontext-remaining,five-hour-limit, andweekly-limit.So this does not seem like a missing backend capability. It looks like the Desktop UI deliberately stopped exposing an already-available signal in the composer/status area.
That makes the removal especially frustrating: users are not asking for a brand-new complex metering system. We are asking for an existing, already-computed context signal to remain visible, preferably behind an opt-in setting if the default UI should stay cleaner.
Hiding the signal while continuing to rely on it internally is poor UX for developer workflows, because it removes user agency over context management, compaction timing, and per-turn quality/cost control.
hello again! here's what we'll be shipping soon:
<img width="1340" height="336" alt="Image" src="https://github.com/user-attachments/assets/316cbeb3-116c-44f3-80bf-3f7142309847" />
<img width="650" height="546" alt="Image" src="https://github.com/user-attachments/assets/da92e841-0677-409b-8329-b99f897cacf1" />
we've updated the
/statuscommand to add the context meter to the thread detail panel. we also might add some other fun things in there... stay tuned!just to reiterate: we do genuinely appreciate the feedback, and want Codex to be the best product for everyone. it was not our intention to remove it completely, which is why we still expose it in the app. clearly though we need to have a way to show it a bit more prominently.
it's great to see how passionate you all are about Codex!
There is also an odd competitive angle here. One of the reasons many of us preferred Codex was that it had strong developer-oriented UX details like the visible context indicator. Competitors have been moving toward similar context-awareness features because they are genuinely useful for agentic coding workflows.
So it feels backwards for Codex to remove one of its own advantages just as other tools are adopting similar ideas. The context indicator was not legacy clutter for power users; it was part of what made Codex feel more transparent and controllable than alternatives.
@alexi-openai
You've read through all the comments here, correct?
Why do users now need to type /status?
I don't want more "fun" things. I want the basic functionality back, optional is fine. Why not include a toggle in the settings, or an opt in...that restores the functionality THE SAME AS IT WAS BEFORE?
Why is OpenAI so opposed to this? Is it really still the original basis you provided above, even after reading all of external users' comments?
If so, the disconnect is amazing here.
I want to be very clear about the UX impact here: requiring users to type
/status,/compact, or even just open the slash-command menu to check context is already a significant degradation of the development workflow.Yes, the context value can currently be seen indirectly through
/statusor even by typing/compactand looking at the command description. But that is precisely the problem: developers now have to interrupt their coding or planning flow, invoke a command UI, inspect the value, and then return to what they were doing.The old indicator worked because it required zero action and zero context switch. It was ambient information available at the exact moment when it mattered: before sending the next prompt, starting a complex implementation, or deciding whether to compact.
Moving this behind slash commands is like removing the speedometer from a car dashboard and saying the driver can still open a diagnostic menu whenever they want to check their speed. Technically the information is still available, but the interface is clearly worse for the task.
Putting this behind slash commands turns a passive status signal into an active task. That is not just less convenient; it is a clear UX regression for serious development work.
to be clear
/statusis a persisted setting, it will always show in the panel for all threads until you run/statusagain!@alexi-openai @ambrosino-oai
anthropic has had a same mindset recently and thats leading them to lose a lot of users. are you shipping codex for real customers or just your own internal use.
are you people at openai living in some dreamworld? , if context is infinite why does it even have to auto compact? context is clearly limited and users need to have an idea of what context is left because in some cases its better to start a new session rather than let a session get auto compact.
Thanks for clarifying that
/statuswill be persisted and shown for all threads until toggled again.Could you clarify the persistence scope?
This matters because if users need to rediscover and re-enable it after restarts, workspace switches, or client changes, it still does not replace the old always-visible composer indicator.
This also affects the VS Code Codex extension. The context usage indicator disappeared for me after updating to build 32039.
For me this is not just a UI preference. I need to see when the context is getting full, because before compacting I can stop and ask Codex to review the code changes it made before I commit them.
After compact, part of the working context is already gone, so the same review is not as reliable anymore.
Even when I do not make a summary before the end of a session, I still need to know when compact is getting close. Once it happens, some context will be lost, and Codex may continue making changes without important information from the earlier work. This can make its later actions incorrect.
Without the context indicator I cannot know when I should stop, check the work, make a summary, or start a new session.
Please understand that this greatly reduces usability, especially when working with smaller context windows.
I would not be surprised if some users start looking at other AI providers if basic usability features like this keep being removed from Codex.
For VS Code users, rollback from
v26.519.32039tov26.513.21555to get the visible context/token usage indicator back as a short-term workaround to stay productive for now.Extensions -> Codex -> Uninstall (drop-down arrow) -> Install Specific Version -> 26.513.21555 (1 wk ago)
But this is only a temporary help until the backend changes so much that it can no longer be used.
Wow.
This COMPLETELY misses the point of what this entire thread was asking for.
The problem was never that the information didn't exist somewhere in the app. /status already gave us that data. The problem is that it required a separate action to go look at it. And your solution is... a different separate action to open a different panel? How is that meaningfully different from what we already had?
We need a PASSIVE, always-visible indicator. One that sits in our field of view while we work. Not something we have to stop, open a side panel, check, close, and return to what we were doing. That's what we had before. That's what was removed. That's what this ENTIRE thread has been asking you to restore. It was perfect as is.
All you had to do was give us a checkbox in preferences to bring back what we lost. That's it. Everyone here would have been happy. Instead the same information got moved to yet another place we have to actively navigate to.
I'm honestly baffled at how the team read this thread and landed here as the solution. The word "passive" appears over and over in these comments for a reason. Please actually read what people have been saying.
@ambrosino-oai do you honestly think this is what we want? This "fix" completely misses the point.
This is akin to moving the fuel gauge from the dashboard where we wanted it to the glove compartment and calling it a fix.
Wow. Just... wow.
This is the solution after considering all of the “meaningful input” from users in this thread?
If the new option under /status is anything like the current implementation, then calling it a “persisted setting” is misleading at best. It is just a large box that blocks part of the current conversation until dismissed. That is NOT the prior functionality, and it does not solve the problem users have been raising here.
At the start of this thread, I thought this was OpenAI being out of touch with its user base, which was bad enough. With this new “fix,” it looks less like a misunderstanding and more like an intentional reduction in user choice and transparency.
I agree with every word here.
What this indicent did was expose that the idea that openAI is building codex for us developers and in the sunshine with an open team that values users is a total fabrication.
There is no way smart people working at OpenAI could not get that this doesn't actually fix what we want, so the only explanation is that they value their perception of "infinite context" (despite it not being real currently) over users actual needs and workflow.
Extreme disappointment. This team and product is is not who we thought they were. But at least now they have been exposed.
Where you get info about infinity context?
<img width="1440" height="884" alt="Image" src="https://github.com/user-attachments/assets/3fe18367-622e-4359-b5d5-4b48f679c77f" />
Compact context take to mach tokens and time, so I want have this feature.
Even Clode cloned this feature for itself from you. Don't be stupid.
I appreciate the passion here, but please dial back the rhetoric. It is difficult to have an open and productive discussion when people are making accusations of bad faith, ill intent, or stupidity. Disagreement is welcome, and candid feedback is valuable. Please keep the conversation focused on the substance of the issue and assume good intent from others participating in the discussion.
@NN1985, can you say more about why you think that displaying the information in the right panel doesn't meet your needs? The panel in question is a passive, always-visible display, not something you need to manually open. This panel remains visible unless you make the window really narrow. You asked for a way to toggle this setting. The proposal is to make
/statusthat toggle mechanism — and to make the setting persistent across app restarts. Re-reading your requirements, it sounds like that checks all your boxes. You mentioned "in your field of view". Is your concern that the information is displayed above and to the right of the composer box, as opposed to beneath it?I wouldn't say you have to make the window "really narrow" in order to lose that side panel... Commonly I like to split my 16" macbook screen into codex on the left and a browser window on the right, and this is too narrow for that extra panel to be displayed, even with the conversations drawer collapsed. And when the window is made wide enough to display the panel, there is a lot of dead space below it.
Another huge advantage to the old positioning of the context fill indicator was that is was always in the same place (and very close to where the user types in their response). With this new positioning in the extra panel, it's not in a fixed position any longer, and is harder to casually glace at before sending a new reply.
This is a big downgrade for technical users. I have been a Codex loyalist for a while now, but this change is strongly encouraging me to shift my usage to other harnesses.
@etraut-openai
I already explained clearly why a permanently visible context indicator is necessary.
At this point, you should admit that removing it was a mistake and you should be ashamed of how you are handling this.
WE are paying for a service. What we should get is the service we paid for, not features being taken away from it.
Taking away an important part of a paid service like this is basically theft. It is criminal.
@etraut-openai
With due respect, I think the frustration you're seeing stems from the fact that, after 80+ comments (already third most out of 12K+ issues) with unanimous agreement, OpenAI still doesn't seem to be "getting it."
If, by chance, you were specifically referring to my comment:
I stand by that and think it's more than fair at this point in the conversation. I genuinely welcome your input on why it isn't as simple as restoring the same functionality (which is still present in substantial form), even if only as a toggle. After reading everything in this thread, I haven't seen a compelling answer to that question.
My team currently has a dozen Pro 20x plans and we also use the API extensively. This issue may seem trivial to OpenAI representatives, but you're about to lose those 12 subscriptions. Our business alone may not matter to OpenAI, but there are a lot of users and customers just like us out there.
I genuinely do not understand this level of resistance. 🤦♂️
The core issue is simple: we cannot constantly run
/statusor open side panels in every single chat just to see where we stand. In a single turn, the model might read dozens of files, generate massive outputs, and consume huge chunks of context. Forcing us to manually check our context health after every action is agonizing.Are you not learning from the standard set by your competitors, or even from the positive feedback of your own past features? We previously gave feedback that the old indicator wasn't detailed enough—and your solution was to delete it entirely.
Without a passive indicator, we are constantly blindsided by sudden auto-compactions and have zero visibility into our available space. A real-time, always-visible indicator is essential because it allows us to intelligently control our inputs and manage our workspace before things break.
Removing this feature was a workflow disaster. This stubborn refusal to simply restore a passive UI element is completely baffling, and I cannot comprehend what goal could possibly justify ignoring this much clear user feedback.
With all due respect, it honestly feels like most of these decisions are being driven by internal personal preferences rather than the actual, proven needs of the developer community. At least, that's the vibe I'm getting.
Agreed, 100%.
As far as the disrespectful comments, I think etraut was referring to the user who called them "stupid," but it's pretty clear that person has English as a second language and may not have expressed themselves the way they intended.
I also agree that this probably seems like a minor QOL issue in the eyes of OpenAI. But etraut's latest response, which amounts to "why doesn't the new location work for you," only reinforces what @phatstackzdevops is saying. They simply don't get it. And at this point it's hard to believe it's not intentional. The only conclusion we can draw narrative they want to push is more important to them than what users are actually asking for.
I also have a team here with subscriptions on the line, and this issue is a clear signal of the direction of Codex and the attitude the team actually has toward how users (not their internal team) use and want to use the application. So it's more than just this one "trivial issue," like you said. It's what it represents.
I'm not sure engaging further has much value at this point. It can't be stated any more clearly than it already has been, and they've now signaled they don't intend to restore the feature in a way that actually addresses the ask, only in a way that preserves their "infinite context" narrative.
We did approach it in good faith with a discussion, and when they signaled they intended to reverse course, I cheered them and applauded how they handled it, but after seeing the "fix"... I can't say they are operating in good faith in terms of addressing actual user needs/asks. If I were my company, I would have restored the feature as it was, with an opt-in within 24 hours.
But, if they must know, our team uses second monitors in vertical orientation, and so we don't have sidebars open, just the narrow chat view. We bought monitors specifically to have Codex open 24/7. So this does actually break our workflow; we don't want side panels open!
They don't care about us, brother @mikk73
They're after the corpo dollars 🤑🤑💰
We're just advertising peons: our sole purpose is to spread the gospel, not to question it!
🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑 🐑
You can see it clearly from their attitude in this thread so far.
It's THEIR own product.
They develop it as they please, test it internally (with no limits) and couldn't give a rat's ass about your opinions or preferences.
Not a democracy (🗨️ @ambrosino-oai)
User feedback is optional (🗨️ @alexi-openai)
In their divine grace towards us, they LEND the Codex App to us.
For their benevolence, we should be eternally grateful, kiss their feet and sing them hymns. Haalleeelujah!
Don't disagree with anything they say: it's not "_constructive_" or "_empathetic_". Am I right, @etraut-openai 🤣
Have a different opinion? Blasphemy! We're mistaken or we're holding it wrong!
These people are truly living in a bubble. The arrogance & disconnect is off the charts.
"Codex has infinite context" - unbelievable.
I was hoping for indicator improvement more Cursor style not removing it.
Next reply:
I'm confused by the negative reactions after this comment. Here's my interpretation:
/statustoggles the context usage indicator in _every_ chat.As soon as I get this upgrade, I plan to type
/statusonce and never think about it again. So for me, the only thing that changed is the part of the screen I look at to see this information. It was at the bottom, now it's at the upper right.What am I missing?
Just an image ;)
<img width="750" height="283" alt="Image" src="https://github.com/user-attachments/assets/a674e1b7-85e3-4d9f-ac33-d4ba448b87e2" />
Instead of a small informative icon...
This thread has really regressed... Please, give us the little circle back.
I want to spend time with my family...
@DanKaplanSES
As I noted much earlier and as the image posted by @Omegapy confirms, this is what your missing:
In addition, as @NN1985 noted, many users, myself included, use second and/or third monitors in vertical orientation.
The bottom line is that your question, “What am I missing?” highlights the broader issue. The fact that this does not affect your personal workflow does not mean it is not affecting the many other users in this thread, and that's why it's important to listen to user feedback.
I think we need to accept the fact it's not coming back the way we need or want it to.
Anyone here up for using codex to build some kind of passively visible widget that brings the gauge back in some form? 😅
We can probably build some CLI tool that leverages the pet... or maybe we make a "context window pet". Would solve the problem
One more image ;)
Using
/status<img width="774" height="390" alt="Image" src="https://github.com/user-attachments/assets/a1e5f498-32ff-48f7-bc60-f11ec6fd58a1" />
a better image:
<img width="1464" height="431" alt="Image" src="https://github.com/user-attachments/assets/abae7ed4-20ed-4bcf-b39a-b086871c7003" />
I hope we get the old indicator back
We just want it back—or at the very least, give us an optional toggle switch. Is that really so difficult? I honestly just can't understand it. Please, stop ignoring the voices of your users.
Got the update here as well. As I suspected, it did nothing to solve my problem, and my teams, since we use vertical/portrait mode second monitors specifically for Codex (bought them for it), and it does not show up... hence. So this does nothing to solve the issue of needing a passive indicator for context window usage because it's not visible for our use case. Even if it was visible, I don't want a busy side window open when it was just sitting right where it needed to be.
They moved the speedometer from the dashboard to the glovebox and call it a fix...
Codex is starting to get worse recently. The other thing that has been bothering me is the removal of terminal button (now it takes more clicks to get there). I am fine you add features that we don't need, but please don't take away features just because you feel like it. It's very disruptive to people's workflow. This is not an app in alpha test. When features you have relied on just randomly disappear, I start to feel horror clicking that update button. I am seriously considering moving off of codex because of this, you can't rely on an app that just randomly changes how it works every day.
the new context window shown as a popup is soo much worse! it just blocks half of my chats when i open codex in split screen view. the older indicator was much better and compact.
I have downgraded the codex app mac version to Codex.app 26.513.31313 and now the context window can be displayed
Additional data point from Codex Desktop 26.519.41501 on macOS:
The proposed
/statusreplacement does not appear to work for me./statusis not available/discoverable in the slash-command menu./statusinto the composer and submitting it did not change the UI or enable any persistent status/context panel.So in this build, the replacement for the removed context indicator is either unavailable, not discoverable, or not functioning in this surface.
This makes the regression worse: the original passive indicator was removed, and the proposed replacement cannot actually be used from the UI.
I am using Windows 11, OS build 22621.2428. First, uninstall Codex, then download the MSIX file of an older version of Codex and perform a direct overwrite installation. Remember to back up important data.The installation package from the Microsoft Store is available on CSDN. Those who need it can search for it there.
<img width="397" height="167" alt="Image" src="https://github.com/user-attachments/assets/9b66542c-01ff-40d6-8bb1-0b04cc9ea233" /> The issue we are discussing is not this, but rather the context window of the chat interface.
Switching to the old version, it's still not there. I don't know what's going on
I want to know if this is a bug or intentional
I can see the context window when using this downloaded Codex desktop version 26.513.4821.0_x64.
Yes, I am currently using this feature. Thank you
But this way of working makes me laugh in exasperation
People tend to laugh when they are speechless 😁
Same here!! 💯
I was looking forward to their updates at first, but now I hate it
The "📌 pin chat" icon changed 3+ times so far: right -> left -> now right again...
They settled by placing it close to the "archive" icon, because _Pinning_ and _Deleting_ are very related actions! 🤣 🤣
Schizo approach to app development + paternalistic arrogant attitude => users will churn soon
Big labs cannot be trusted: our incentives and theirs are
never aligned🍆This is why we need good open source harnesses and Local AI models
At this point, I think the product team needs a very simple rule for Codex Desktop:
Think, test, then ship.
For a coding tool, removing a passive context indicator is not a cosmetic tweak. It changes how developers plan work, manage risk, decide when to compact, and avoid losing quality in longer sessions.
This is almost ironic, because Codex itself is built around the idea of verifying before changing code. The app should follow the same principle for its own UX:
Verify before changing workflows that developers depend on.
The context indicator was not decoration. It was part of the development workflow. Removing it without an equivalent, always-visible replacement was a breaking UX change, and it should be treated as such.
Please restore the passive context indicator in the composer/status area, or provide a real persistent option that behaves the same way.
I'm not entirely sure if you've ever had the experience of juggling multiple windows and tasks at once — not just AI-related work, but other things going on simultaneously.
The icon you mentioned, as I recall, only appears when you hover your mouse over it. In the middle of heavy, demanding work, that small movement somehow still manages to pull my attention away. It's a bit like the way an AI's attention fragments — a deeply unpleasant experience, one that keeps whispering in my ear:
"You need infinite tokens. You need to figure out how to get 1M of lossless context, so you no longer have to painstakingly optimize the context for every single output."
But the thing is — who's going to give me infinite tokens? Where exactly does one find lossless context?
By the way guys, remember when Anthropic used to push a dozen new updates to Claude every day?
And all we were asking of them was to fix the broken limits and stop nerfing their models?
But Anthropic kept telling us: _You're holding it wrong! Look at how many new shiny features we're pushing! Stop asking for what you need, just shut up and take it!_
People were actively reverting to old Claude versions just to avoid all the broken & useless shit they were shoving down our throats
Then we migrated en masse to Codex: a nice, clean, simple, focused app which delivered
---
---
Now people are actively reverting to old Codex versions just to avoid all the bloated, broken & useless shit they are pushing down our throats
We're asking OpenAI for features WE want, love or need... and they are telling us the exact same freaking thing: _You're holding it wrong! Don't ask for what you need, we're not a democracy!_
Can you believe this shit?!?
History is repeating itself. To the letter. And they can't see it 🤣
!codex-eat-it
The version I am currently using is 26.513.21555
The discovery has been restored, and you can view the usage context
Can we have this feature back, or at least setting to turn it on, please.
While I agree Codex/GPT have very good context management, it is still useful to power users. Or at very least gives illusion of knowing what is happening and feeling of being in control :).
You would think this would be standard practice for a professional development team. Especially when their CEO is actively pitching enterprise companies to move their development workflows over to Codex.
How can professional teams build processes and standards around an application when the UI and features are shifting on a near daily basis with no warning? They are treating the production app like a testing ground.
Verify first. Then ship.
Stability is the reason we are on Codex. It's supposed to be the professional choice. If we wanted the "thrill" of constantly shifting features we'd be on the Big G applications.
And they know it wasn't decorative. They admitted their motivation right in this thread. It conflicted with the narrative they wanted to project that Codex has infinite context. But it doesn't by definition and won't anytime soon.
The polite option would have been to drop everything and publish an emergency release that brought this back. An obvious reason for not doing so is not wanting to. Not wanting to gives off a certain nefarious vibe in wanting to obfuscate this.
So /status seems to have gotten worse to me: Before this was persistent, a big block, where did this even go? The small odd bubble now is not better than the left menu. I think it would be much better to add a status bar that shows the context window info, the used tokens, the price in tokens, the time of the next refresh, the 5h window remainder, the weekly quota remainder. If using non-subscriptions to look at costs, this would be even more useful and important.
There is a lot of other stuff shown instead that is granted screen estate. For example the remote button next to settings. We also seem to get popups to upgrade when usage gets low. That is a bit telling that this is granted persistent space after the fact.
Other harnesses have things like I described, recently I thought codex seems to be catching up and seemed nice. BTW, was there an official reason for not publishing the codex desktop client? That would have given developers ways to change things like this easily.
A direct answer from open-ai staff would be nice giving insight into these aspects which suggest political motivations with some decisions. Given that "open" is in the name, this would very nice.
Yes, and the nerve that @alexi-openai had to suggest they have lots of "fun" updates coming for us soon, not to worry.
We don't want fun. We don't want a million UI optimizations nobody asked for. We need the critical stuff that supports our actual workflow to work where and how we expect it. It's that easy
When your users are dreading the update button instead of looking forward to it, when they are sharing instructions to roll back to previous versions just to get an indicator back to where they want it, that is a massive red flag that something has gone very very wrong with your product priorities.
to wich shall i downgrade on mac?
It feels to me like some product design manager is putting pressure on the team, because none of them will outright say why they won't just give us the simple option to put it back where it was.
Given this change in attitude, I think we should organize and petition upper management at OpenAI. Even Sam Altman. Bring their attention to this thread and the fact that the Codex team, their new flagship product, has stopped listening to users and is making the same mistakes the Anthropic team made that caused their churn. Which ironically is why most of us are here now.
And we aren't making some nebulous claim about model performance getting dumber. We can point to a real, documented process issue with their team and this sudden attitude of "we know what you want and need better than you do."
It's wild to me that they want to sacrifice useability serve a narrative about compaction being so good you have infinite context when it's simply not true yet.
Let's let management at OpenAI know that some product managers on Codex have lost the plot.
The lack of clear indication on context remaining really sucks. Using /status regularly is just annoying.
With the recent "fix",
/statusrestores a persisted indicator of context usage (yes, you only need to run it once, and it persists across restarts and different conversation). This is a an improvement over the feature regression, but still relegates it to a side panel despite massive user outcry over the importance of the context usage indicator as a first-class product feature.I hope it is an anomaly and not a harbinger of a tidal change in Codex taste and developer experience.
I want to highlight the importance of context management as one of THE most important, fundamental skills in agentic engineering. Even while things are moving in a direction of higher-level orchestration with programmatic integrations such as via app-server, where the main UX will be managing work, the purpose of an agent harness _desktop application_ is to provide a control plane for development (and other work) where the execution is NOT yet fulling automated, and _requires_ user steering mid-course. While
/goalis an interesting middle ground in autonomous long-horizon work, "auto-pilot" shouldn't be the _only_ experience in an application that is supposed to empower users to have visibility and control beyond only a simple chat interface. There are controls and indicators for many things from model to reasoning effort to speed, views of artifacts and reasoning summaries, all of which help power users to have more insight and ability to make informed decisions on how to continue steering the harness beyond a "one-shot vibe-coding" prompt approach.The context % usage indicator is a critical component, one of THE most critical components of that. The whole concept of progressive disclosure with agent skills is related to that: efficient management of context, empowering the harness with the capability it needs without overloading it with unnecessary bloat that overruns the available context window or simply makes it less efficient in terms of performance and accuracy. The dream of "infinite context" is far removed from the current reality, at least for serious and advanced engineers, who want to carefully manage context, branching, manual compaction, and the timing of handoff artifacts and certain operations so that they happen in an expected manner either before or after a compaction event, instead of unpredictably.
Brushing all of that under the rug while trying to pull the wool over our eyes saying "you have infinite context; just let us worry about compaction for you" is a huge differentiator between creating a streamlined magical product for the masses vs. also allowing it to be a power tool for advanced users.
Exactly
But the "fun" stuff is what gets them their dopamine hit
"Boring" features and stable workflows are appreciated by professionals but don't boost engagement on Twitter 🙄
Add a new _fun_ Tamagotchi RGB Pet and whoosh all "AI Influencers" pile up on that crap instantly. The Codex team gets their praise, inflate their egos, the dopamine flows & the vicious circle is created. Do that a few times and Codex becomes a never-ending flow of "fun-fun" & "shiny-shiny" releases of crapware 💩
We're being pushed aside, but will soon find new toys (Pi looks great btw)
Mess with fans & power users, ignore feedback and see how far that'll get you: FAFO!
Same thing happened with Anthropic's blunders this spring. People never learn.
@kumanday
I will not quote everything. You gave a long and reasonable answer, but several of us have already done that.
I realized earlier that common sense does not seem to mean anything to OpenAI here. That is why I used much harsher wording before. If they do not understand reasonable arguments, then maybe we have to make the point in another way and tell them clearly that what they are doing is basically deceiving and robbing paying subscribers.
The main point is that they make and sell a product without even understanding its basic use in real work.
So I think we should expect similar problems in the future. And even the current problem has still not been resolved properly.
Clearly the guys from OpenAI don't use their own products. The /status is useless when you're working with side panels like the live browser. I need to constantly click the info icon.
Keep the subscription. GPT-5.5 is the MVP. Usage limits are (still) generous.
Just drop Codex: the solution is another harness.
Let Codex become an internal tool, just like they perceive it to be 😉
Where can I easily see the 5h/weekly usage now that /status only shows a pop-up with context usage and token speed?🤣
Why can a GUI app have a worse experience than cli?
The change around /status is not serious either.
@alexi-openai
@ambrosino-oai
@etraut-openai
We cancelled all 12 of our team's Pro20X subscriptions this morning. We will not be back.
This should have been addressed by OpenAI within 24 hours. Restoring basic functionality for an important feature should not have required this level of pushback. As I noted before, the current "fix" is a degradation, and the continued resistance and disconnect from actual users tells me OpenAI simply does not care about customers like us. If I treated my clients like this, I wouldn't have a business.
I have no interest in waiting around for the new “fun” additions OpenAI has promised in this thread while the features we actually rely on, and are paying for, are silently stripped away.
I am sure OpenAI will not miss our business. But each member of my team has a strong individual network. Until recently, we were strong OpenAI supporters. The manner in which OpenAI has handled this seemingly simple issue has turned us into vocal critics, and we will make sure our colleagues, friends, family, and professional networks understand exactly what kind of company OpenAI has chosen to be.
EDIT: This may look like a rash decision over a small issue, but it was actually a unanimous team decision based on the culmination of several problems.
Although it is not the focus of this thread, we also analyzed our daily
ccusageand other data across multiple metrics and confirmed another issue our developers had already been reporting anecdotally: usage limits appear to have been reduced by roughly 25% to 50%, depending on the underlying usage pattern.We have already been testing alternative harnesses with similar success to Codex. This was simply the last straw.
Wow. :( This is so sad.
I'm not giving up on Codex just yet because the pain of leaving and going back to anthropic is still greater for us at the moment. But this is definitely a "three strikes" situation, and we're on strike one or two.
Still, I don't blame you one bit. You can almost guarantee they're over there shaking their heads thinking we're just whining over a tiny change and we'll get used to it. Basically not getting it. They don't understand what this signals to us in terms of how their team treats user feedback, how internal vision is overriding app usability, and more importantly, how we can't trust Codex to be a stable and serious work interface for daily team processes if the UI is subject to unannounced constant changes like this.
I'm sending this thread around to the AI influencer circles on X and YouTube. I hope it goes further viral than it already has and forces a real change in direction. We were all hoping Codex wasn't going to become this, but it's at serious risk right now.
That said, I still think they have a window to reverse course and get ahead of this. Make a clear statement that they will actually listen, restore what was taken, and start running changes like this through a beta group with real external users instead of using production as a proving ground. Their internal gauge of what works for their own teams is clearly not enough. They admitted that themselves.
@phatstackzdevops
I also noticed that the limit was running out much faster somehow.
At this point, this is no longer just a small UX issue about where a context indicator is displayed.
By removing a workflow-critical indicator, resisting a straightforward restoration, and offering a degraded replacement despite repeated feedback from paying users, OpenAI has pushed this into a public trust and reputation issue.
More importantly, this behavior comes across as disrespectful to developers and to user feedback. Users are explaining, repeatedly and clearly, that this was not decoration. It was part of how they planned work, managed context, timed compaction, and maintained quality in long coding sessions. Treating that feedback as something users should simply adapt around sends the wrong message.
The concern is now broader than this single indicator. Users are watching how the Codex team responds when a production change breaks an established developer workflow. Do they listen, restore what worked, and improve the process? Or do they insist that users should adapt to a product direction they clearly did not ask for?
That distinction matters. Codex is being positioned as a serious tool for professional and enterprise development workflows. But professional teams cannot build stable processes around an interface that can remove critical visibility overnight and then treat the fallout as a matter of messaging.
Please treat this as the reputational issue it has become: restore the passive context indicator, acknowledge that this should have gone through real external beta testing, and commit to not removing workflow-critical UI without an equivalent replacement again.
There is another concern that now makes the removal of the context/status indicator look even worse.
Several users are reporting that weekly/rolling usage limits appear to be consumed noticeably faster than before. I am seeing the same thing on my side: weekly usage seems to be growing significantly faster than it used to.
If usage accounting, effective limits, model routing, token costs, or quota behavior changed recently, users need a clear and honest explanation. Removing visibility into context/status at the same time makes this look extremely bad.
Even if these two things are unrelated internally, from the user side the pattern is hard to ignore:
For a developer tool, this is not acceptable. Developers need transparency, especially when usage limits and context management directly affect planning, coding quality, and cost control.
Please clarify whether there were any recent changes to usage accounting, quotas, token costs, model routing, or limit behavior. And please restore the passive status/context indicator so users can actually see what is happening instead of being asked to trust an opaque system.
We received your feedback about the current solution not working well for vertical/portrait monitor setups. That's a good point that we didn't fully appreciate when we made the recent change.
It's a three-day weekend in the U.S., and most of the Codex team is taking the weekend off to spend time with their friends and families, but we'll pick this up again early next week. Your feedback isn't going unheard!
Thank you for acknowledging the vertical/portrait monitor issue and for saying that the team will revisit this next week. That is appreciated.
I think the key point is that the fix should not only improve the current side-panel approach. The old behavior worked because it was passive, compact, always visible, and located directly in the composer/status area where developers naturally look while working.
For many of us, that placement was the feature. It allowed us to monitor context without opening panels, typing commands, moving focus, or changing our workspace layout. That is why
/statusin a panel, even if persistent, is still not equivalent to the previous experience.So the ask is simple: please restore an always-visible passive context indicator in the composer/status area, or provide a setting that recreates that behavior as closely as possible.
The broader concern is trust and workflow stability. Codex is becoming part of serious daily development processes, and changes to workflow-critical UI need to preserve existing professional use cases, not replace them with a less suitable interaction model.
@etraut-openai's response just shows that they are still unwilling to acknowledge the root of the problem. This is not about vertical display. I don't use vertical display in any shape or form and I still found this change extremely annoying in many ways. Why is it so hard to just put the original indicator back.
Probably because it is hard to convince anyone that "Codex has infinite context" if you see 80% of the infinity filled up.
They should just bring the 1M context window to codex instead of trying to hide the fact that you run out of the context so fast.
This is the part that makes the situation feel even worse.
When a product team removes visibility into a real limitation and then frames that removal as a better product experience, it comes dangerously close to misleading users.
Users are not asking for decoration. They are asking for visibility into a real constraint that affects planning, compaction, coding quality, and usage management. Hiding or downplaying that constraint does not make Codex feel more capable. It makes the product feel less transparent.
If the goal is truly to improve the experience, then the right answer is to make context and usage more understandable, not less visible. If the goal is to preserve a narrative about “infinite context” while the actual product still has practical limits, then that is a serious trust problem.
This is exactly the kind of thing that damages OpenAI’s reputation with developers. Developers can tolerate limits. They cannot tolerate important limits being obscured behind product framing.
Please be transparent: restore the passive context indicator, clarify any recent changes to usage/limits, and stop treating visibility into real constraints as something that needs to be hidden from users.
The irony is that some of the clearest arguments in this thread were written with help from Codex itself.
So even Codex seems capable of understanding why hiding a workflow-critical context indicator is bad for developers.
Maybe the product should listen to its own tool.
For what it's worth, the above statement by @SergeNS-mne is exactly what I was referring to when I said it was "the last straw" and it is the primary reason we cancelled our subscriptions. I purposely didn't explicitly connect the two in my comment because the usage limits are a separate issue, and I also didn't want to be accused of "assuming ill intent" by @etraut-openai.
Specifically, when we considered (1) the confirmed and undocumented decrease in usage limits, (2) OpenAI's concurrent undocumented removal of the context display, and (3) its unexplainable, almost illogical resistance to restoring it despite unanimous feedback across multiple platforms, we came to the conclusion that this must be a purposeful move to further reduce user choice and transparency.
And I stand by this conclusion, as the most recent comment by @etraut-openai seems to once again confirm this. It is a noticeably constrained and limited response addressing one ancillary issue caused by OpenAI's own fix, with yet again no acknowledgment of the broader, underlying concerns. This strongly reinforces the perception (if not the reality) that our team's conclusions are correct regarding OpenAI's intentions moving forward.
We don't want to work with a company that operates like that, or deal with the uncertainty it introduces into our workflow.
This is my first month on Codex. Now that Anthropic has quota back to normal, if there isn't a way to see the context window transparently, I will likely switch.
I would like full context window transparency. Including an obvious way to see what is loaded by default at the beginning of the thread. And whatever else would help me to understand what's in it. Like what's there after it compacts. Is there a way to view this or can there be a way to see this? Add the indicator back and more.
As I said above, we'll pick this discussion up next week. I'm going to lock this thread in the interim.
Based on your feedback, we've decided to restore the context usage indicator (the "donut") to its previous location beneath the composer box. Its visibility will be controlled by a persisted setting that can be toggled using the
/statusslash command. If you prefer to keep the indicator visible, you can run/statusonce, and your preference will be preserved across app restarts.This change will be included in the next release of both the Codex app and the IDE Extension.
In evaluating this issue, we needed to account for different user needs and workflows, as well as upcoming features and model capabilities. When feedback points in different directions, the most useful input is often a clear explanation of the underlying problem or constraint. For example, this comment from @NN1985 highlighted the need for a solution that works well on vertically oriented monitors. Several other commenters explained in detail how they use the information provided by this indicator in their coding workflows. Specific constraints and use cases like these help us evaluate design options and choose solutions that work for as many users as possible.
Thanks again for taking the time to share your feedback. We do appreciate it, and we do listen!
!Screenshot_20260527_204323_Google.jpg
Fantastic news.
I didn't get a chance to comment prior to this decision, but I can say the missing 'donut' has been immensely disruptive to my workflows.
The unbending fact here is that post-compaction context threads take different actions from pre-compaction context threads.
The generated outputs of a model with 150k context tokens are simply not the same as the outputs of the same model with 25k context tokens. That's sort of the point of the technology; that it does different things depending on what you tell it.
If I'm not indifferent over that variance, then I cannot be indifferent to its timing.
What happened here, as far as I can tell, is that many more of us than you had understood are materially sensitive to that variance.
Thank you! @etraut-openai . You guys have gained a great deal of respect for such a small update.
Truly it makes me feel good having upgraded to the Pro Plan today. Best of luck to you and the team!
@etraut-openai I can elaborate on why it's not about vertically oriented monitors. Just because people are using horizontal monitors doesn't mean they are using codex full screen, and I believe that might be a more common use case. And that means "pinned summary" doesn't actually "pin". Even if you have codex full screen, if you have any side panel open it's hidden as well. This summary panel has been useless to me because I can't see it most of the time if I don't maximize Codex Window. It's going to be annoying if you move anything persistent into that area.
Thank you for revisiting this and for deciding to restore the context usage indicator to its previous location beneath the composer.
This is exactly the kind of response that helps rebuild trust: users explained a real workflow problem, the team listened, and the product direction adjusted.
I am confident that users will value and continue to support Codex when they see that feedback is taken seriously, especially on workflow-critical details like this.
Thank you to the Codex team for listening.
Agreed 100%. Personally, my trust has been restored.
This is the kind of response that signals my team and I can move forward with Codex with confidence.
Thank you to the Codex team for getting this right.
I find a way to see it. Hope this helps.
<img width="520" height="297" alt="Image" src="https://github.com/user-attachments/assets/eeae385c-63da-4d01-8144-1b56bc8e79de" />
I just updated to Codex Desktop 26.527.30818 on macOS, and I honestly cannot believe this is what shipped after this entire discussion.
Users were very clear. We did not ask for a new status dashboard. We did not ask for a large panel. We did not ask for another redesigned workaround.
We asked for the old compact context indicator back.
OpenAI acknowledged the feedback and said the “donut” would be restored to its previous location beneath the composer. That gave users confidence that the team had finally understood the issue.
But this is not what was promised.
What shipped is a huge Status panel above the composer, showing Session, Context, 5h limit, and 7d limit. It takes a large amount of vertical space, blocks the working area, and makes the input area feel crowded and unpleasant. This is not the old indicator. This is not a restoration. This is yet another UX regression.
The previous
/statusside-panel implementation, which users already criticized heavily, now looks almost ideal compared to this. At least it did not physically block the composer area or consume this much vertical space in the main coding flow.And that is the most frustrating part: each version seems to make a normal working tool worse, then users spend days explaining the problem, then we are told it will be fixed, and then the “fix” ships in a form that creates a new problem.
This is exactly the same mistake again.
We already said this in this thread: think, test, verify, then ship. Please do not change workflow-critical UI without actually checking whether it solves the user problem. This implementation would have failed that check immediately.
The old indicator worked because it was small, passive, glanceable, and did not disturb the layout. The new panel does the opposite: it interrupts the workspace, consumes vertical space, and turns a tiny workflow signal into a bulky status dashboard.
For daily coding work, this is not just disappointing. It is a regression in the product’s usefulness as a professional development tool.
Please restore the actual compact context indicator exactly as it was, or provide a compact mode that behaves the same way. Keep the full Status panel as an optional detailed view if needed, but do not present this large panel as the restored donut. It is not equivalent, and it is not what users asked for.
I originally thought the same but the old indicator was indeed restored. It has to be enabled in settings, not
/status.I just learned that this was implemented as a toggle in the Settings rather than the
/statusslash command as we had earlier discussed. Sorry for the confusion.<img width="716" height="124" alt="Image" src="https://github.com/user-attachments/assets/f0093388-6be5-47be-80e5-0d0361d495ad" />
It's in General Settings, at the bottom.
_"Composer Footer"_
Ty @v3i1y cc: @SergeNS-mne
<img width="726" height="134" alt="Image" src="https://github.com/user-attachments/assets/2973afcb-bee6-4ec2-b371-6687ad542a5c" />
@etraut-openai This is better, the
/statuscommand in it's current state, "big box" is useful sometimesWell, now I honestly do not know whether to laugh or cry.
Yes, I found the setting and enabled the old compact indicator. Thank you for pointing out that it is under General Settings → Composer Footer.
But the funny part is that I would never have discovered this without first posting a frustrated complaint in this thread. So apparently this was a blessing in disguise: the bad UX forced me to complain, and the complaint finally led me to the hidden setting that fixes the bad UX.
That said, this also shows the remaining problem very clearly. If a workflow-critical indicator is restored, users should not have to discover it through GitHub comments after getting angry enough to complain. It should be obvious in the app, mentioned in the release notes, or surfaced directly when
/statusis used.The feature is back, and that is genuinely good. But the path to finding it was unnecessarily painful.
lol i found it,
At first I was skeptical and frustrated with the resistance to make the "context indicator" an optional configuration. But eventually you guys and gals came around and listened to the community. Thanks for building such a great tool @etraut-openai & others!
Thank you so much for listening to the community feedback! It is absolutely amazing to see this feature come back better and more optimized than ever. We truly appreciate your dedication and hard work!
When I open Settings> General, the last thing I see is "Code Review" and I don't see this option anywhere
Exactly what i was going to say.
We also lost the 1M Context Window: https://github.com/openai/codex/issues/24031
And even "copy to markdown" button has disappeared: https://github.com/openai/codex/issues/25201
Idk what the fuck is happening at OpenAI or the Codex team but i'm thinking more and more about going all in on Claude at this rate.
For the latest Codex VS Code extension (v26.601.21317), I don't see any way to toggle "Show context window usage" like in the Codex app. The only way for me to get the token usage donut is to downgrade to v26.513.21555.
@etraut-openai was this setting only added to the Codex app, and not the VS Code extension?
Available settings:
<img width="990" height="752" alt="Image" src="https://github.com/user-attachments/assets/8fe6efa0-517d-4c8e-a13a-dcfc114c299f" />
Composer Footer on v26.601.21317 (latest version, no token usage donut):
<img width="266" height="126" alt="Image" src="https://github.com/user-attachments/assets/167dd573-4d3d-43e2-9d28-747638d08c72" />
Composer footer on v26.513.21555 (last version with token usage donut):
<img width="266" height="126" alt="Image" src="https://github.com/user-attachments/assets/b26189f1-dc29-4a59-8a75-909097eef1c1" />
@tomvothecoder, that setting is included in the latest version of the IDE Extension. Click on the gear icon in the Codex side panel, and choose "Codex settings".
<img width="679" height="99" alt="Image" src="https://github.com/user-attachments/assets/b0d2b51b-768d-4776-a960-df2cc03422c3" />
@etraut-openai Great, thanks for the quick reply. I appreciate you and the team for restoring this feature.
@etraut-openai what about the dial that was located in the top-right corner of the screen, the one showing the actual number of tokens consumed by the session? It used to be where the arrow in the screenshot is pointing
<img width="322" height="318" alt="Image" src="https://github.com/user-attachments/assets/1af86a5a-fbbf-4aca-8bc3-74e3c45c2ec9" />
That is gone too. Are you planning to bring it back? Should I open another issue?
@AndreaPi, we temporarily moved the dial (aka donut) to that location, but we moved it back to the composer based on community feedback. You can still see the details by hovering over the donut indicator.
Yes google searcher, this is solved
To save you time (and reading drama): toggle this on in the Codex settings like so.
Codex app version: 26.602.30954
https://github.com/user-attachments/assets/ee9ec757-0c6e-47ae-a33e-533a7cfc7d42
A bit of help, here? I read just above that issue is solved in 26.602.30954, but I can't manage to find de settings to put back in display the left quota. This info is really important for me... Codex just threw at me the "no more quota" without any warning, I hate that, we were in the middle of something..
<img width="869" height="908" alt="Image" src="https://github.com/user-attachments/assets/d7009dd4-5ea4-4416-b8f2-74fd147ae522" />
It was not showing for me too
I saw this new setting which when enabled, shows the context status ring back
<img width="752" height="237" alt="Image" src="https://github.com/user-attachments/assets/8b2c139e-06b2-4820-b0f6-8af7964bd1be" />
And still suffering at 250k - 50k sys prompt - 50k overhead context window which is 150k effective, vs what we had with 5.4 was 1050k-50k-50k=950k effective. which is over 5x worse. id rather the 1m context EVEN at 4x pricing.
For those experiencing the lack of logged in info issue:
Make sure you update to the latest version of Codex. After doing so, you should have a 'Log Out' option. Log out. Log in using your ChatGPT account creds. This fixed the issue for me.
Trillion dollar company that makes state of the art AI models but can't write the code to keep a fucking partially filled circle sitting in a docked bar. If you don't read this as a "fuck you" to you from OpenAI, you're reading it wrong.
Same problem. I can't believe the way that every time you update this application you introduce bugs that would have been found if you were actually using your own application.