# Codex Users Were Asked What Feature Should Be Removed — Their Real Answer Was Usage Limits A Codex product feedback thread reveals frustration with usage limits, Pet, Chat vs Work confusion, approvals, quota visibility, and agent UX. Canonical URL: https://aiidelist.com/blog/codex-users-want-usage-limits-removed Language: en Published: 2026-09-14 Updated: 2026-09-14 ## Key Takeaways - OpenAI product leader Tibo Sottiaux asked Codex users which feature should be removed because it is no longer useful. - The strongest community reaction was not about removing a traditional feature. Users repeatedly asked OpenAI to remove **usage limits**, especially the five-hour and weekly quota constraints. - **Pet / Show Pet** emerged as one of the clearest actual feature-removal candidates because some users see it as a novelty rather than part of the core coding workflow. - Multiple replies exposed a larger usability problem: users still struggle to understand the boundaries between **Chat, Work, and Codex**. - Developers also complained about approval interruptions, agent questions that break task flow, hidden usage information, and weak visibility into long-running agent work. - The thread suggests that Codex's next UX challenge is no longer simply generating better code. It is reducing friction around **autonomy, quota management, task orchestration, and product complexity**. ![Image](https://cdn.aiidelist.com/api/image/L6E9nbyYWYzUa-lWVRB0d.webp) ## What Did OpenAI Ask Codex Users? Tibo Sottiaux, who works on OpenAI's Codex and ChatGPT products, posted a deliberately simple product question: > What is a feature we should remove from Codex that is not useful anymore? The question was framed around feature removal, but the replies quickly turned into a broader review of the current Codex experience. Instead of identifying dozens of obsolete coding features, users repeatedly focused on several sources of friction surrounding the product itself. The pattern matters because feature-removal discussions can reveal more than feature-request threads. Asking users what they would delete forces them to identify what interrupts the core job they are trying to accomplish. For Codex users, that core job is increasingly straightforward: **Give an agent a substantial software task, let it work for as long as necessary, intervene only when useful, and clearly understand what it is doing and how much capacity remains.** The current complaints show where that workflow still breaks down. ## The Most Popular Answer: Remove the Usage Limit The most visible theme in the discussion was a joke that was only partly a joke: users treated the **usage limit itself as the feature that should be removed**. Replies repeatedly mentioned: - The five-hour Plus limit - Weekly usage limits - Quota exhaustion during intensive coding sessions - Reset timing - Difficulty predicting remaining capacity This is important because it changes how Codex's product problem should be interpreted. Users are not primarily saying: **Codex cannot complete useful software-development work.** Many are effectively saying the opposite: **Codex is useful enough that the limits interrupt real work.** That is a very different product signal. When an AI coding system is occasionally useful, quotas feel like an account-management detail. When developers start delegating multi-hour implementation, debugging, testing, refactoring, and repository exploration to it, quota becomes part of the development workflow itself. A developer may now plan work around questions such as: - Can this task finish before the current window is exhausted? - Should a large refactor be started now or after the next reset? - Will using a higher-reasoning model consume too much capacity? - Should the agent investigate several approaches or immediately implement the most likely one? - How much quota remains before a long-running task is interrupted? This turns usage limits into a form of **compute scheduling** rather than ordinary subscription administration. ![Image](https://cdn.aiidelist.com/api/image/CsdP9cP1akba3d_834eD7.webp) ## Why the Five-Hour Limit Creates More Friction for Coding Agents Traditional chat interactions are relatively short. A user asks a question, receives an answer, and starts another conversation later. Agentic coding behaves differently. A single development task may involve: 1. Reading a repository 2. Searching for relevant files 3. Understanding existing architecture 4. Forming an implementation plan 5. Editing multiple files 6. Running tests 7. Inspecting failures 8. Revising the implementation 9. Running additional tests 10. Reviewing the diff 11. Fixing edge cases 12. Preparing the final result The value of the system increases when these steps can happen continuously. A quota interruption in the middle of this process has a higher cost than a quota interruption after a normal chatbot response because the user may lose momentum, agent state, or the opportunity to continue an active debugging loop. This explains why usage complaints appear so prominently among heavy Codex users. ## Pet and Show Pet Are the Clearest Actual Removal Candidates Once quota jokes are separated from traditional feature feedback, **Pet / Show Pet** appears repeatedly as a genuine removal candidate. Some users describe it as unnecessary decoration inside a professional development environment. Others suggest the concept could remain only if the implementation becomes significantly better. The feedback exposes a familiar productivity-software problem: novelty features compete for attention with high-frequency actions. In a coding agent, the highest-value interface elements are usually things such as: - Current task status - Repository context - Changed files - Terminal output - Tests - Approvals - Remaining usage - Agent activity - Background tasks - Pull requests A decorative Pet feature therefore has to justify occupying interface space that could otherwise surface operational information. This does not necessarily mean playful features are inherently bad. They can contribute personality and make technical tools feel less sterile. The problem is **information hierarchy**. If developers cannot immediately see remaining usage or what an agent is doing, while a novelty control remains prominent, the interface can feel misprioritized. ## Chat vs Work vs Codex Is Still Confusing One of the most important pieces of feedback was not about deleting a small feature at all. Users questioned the distinction between: - **Chat** - **Work** - **Codex** The underlying question is simple: **Which mode should a user choose for a particular task?** This becomes increasingly difficult as ChatGPT gains overlapping capabilities. For example, a user may want to: - Analyze a repository - Research a technical issue - Modify code - Run commands - Use a browser - Work across multiple files - Delegate a long-running task If Chat, Work, and Codex can all participate in parts of this workflow, users have to understand OpenAI's internal product boundaries before deciding where to start. That increases cognitive load. A powerful product can therefore feel more complicated even while its underlying models become more capable. ## The Deeper Problem: Users Do Not Want to Choose the Agent Architecture The strongest version of the simplification argument is not merely to rename the modes. It is to remove the need for users to think about modes at all. An ideal interface could infer the execution environment from the task. For example: - A factual question stays in normal Chat. - A repository-editing request automatically activates coding tools. - A long multi-step assignment becomes an agent task. - A browser-dependent task activates browser capabilities. - A project with several independent subtasks creates parallel workers. From the user's perspective, there would simply be **one conversation with escalating capabilities**. This is increasingly important as AI products move from chatbot interfaces toward general-purpose agents. Users generally care about completing the task, not selecting the correct internal orchestration layer. ## Approval Prompts Are Another Major Source of Friction Several comments pointed at the repeated approval process used when Codex wants to perform certain actions. Approvals are necessary for security. An autonomous coding agent may execute commands, modify files, access external services, or perform other consequential operations. The UX problem appears when approval frequency becomes too high. Consider a workflow where an agent needs permission every few minutes: ```text Agent starts task → asks for approval → continues → encounters another operation → asks for approval → runs command → pauses again → asks for another decision ``` At that point, the user is no longer delegating the task. The user is supervising the agent continuously. That defeats much of the productivity benefit of autonomous coding. ## Better Approval Systems Need Risk-Based Permissions A more scalable model is likely to involve **risk-based permission levels** rather than identical confirmation requirements for every action. For example: ```text Low risk Read files Search repository Run tests Inspect logs Medium risk Install dependencies Modify configuration Access network resources High risk Delete important data Publish code Deploy production changes Modify billing or credentials ``` Users could then grant persistent permission for low-risk actions while reserving confirmation for consequential operations. This preserves safety without turning every long-running task into an approval loop. ## Agent Questions Can Break the Flow of Long Tasks Another complaint focused on how Codex asks users questions while working. This sounds like a minor interaction detail, but it becomes important for asynchronous agents. The ideal interaction is: ```text User assigns task ↓ Agent works independently ↓ Agent encounters a genuine ambiguity ↓ Agent asks one precise question ↓ User answers ↓ Agent continues from the same state ``` The frustrating version is: ```text Agent asks question ↓ Workflow pauses unexpectedly ↓ User answers later ↓ Conversation state changes ↓ Task requires additional switching or restarting ``` The difference determines whether Codex feels like an independent engineering assistant or simply a chatbot with terminal access. ## Usage Information Should Probably Be More Visible, Not Less Another notable request was to bring usage information back into the main Codex experience rather than hiding it inside settings. For casual users, quota information may be secondary. For heavy users, it is operational data. A serious coding-agent interface could expose information such as: ```text Current usage window: 63% consumed Estimated reset: 2h 18m Weekly allocation: 41% remaining Current task estimate: Medium ``` Even approximate visibility would help developers decide whether to start another large task. The same principle already exists in other developer infrastructure. Cloud platforms show resource consumption, CI systems expose build minutes, APIs expose rate limits, and hosting providers show bandwidth usage. Once AI agents become infrastructure, **compute visibility becomes part of the developer experience**. ## Reset Behavior Is Becoming a Product Feature of Its Own Some replies also complained about how reset behavior interacts with future usage cycles. This is more significant than it initially appears. Users increasingly think about Codex capacity in terms similar to API rate limits: - Current window - Next reset - Weekly allocation - Temporary bonus capacity - Model-specific consumption Any ambiguity around those mechanics creates uncertainty. This is particularly painful when a user receives an exceptional reset or temporary capacity increase but does not know whether accepting it changes the timing of the next normal cycle. A mature agent product should make reset behavior explicit rather than forcing users to infer it through experimentation. ## Plan Mode Was Also Mentioned as Removable Some users suggested removing **Plan Mode**. This raises an interesting design question because planning itself remains extremely important for coding agents. The issue may therefore be less about removing planning and more about whether **planning needs to exist as a separate mode**. Modern coding agents increasingly perform an implicit sequence such as: ```text Understand → Plan → Implement → Test → Review ``` If the agent can automatically determine when deeper planning is required, a dedicated Plan Mode becomes less necessary. The broader UX trend is toward reducing explicit switches and allowing the model to dynamically allocate reasoning effort based on task complexity. ## Users Also Want Easier Image Pasting Some participants used the thread to request missing capabilities rather than removals, including direct image pasting through `Ctrl+V`. That request reflects how modern software development increasingly involves visual context. Developers may paste: - Bug screenshots - Browser errors - UI mockups - Design references - Charts - Logs captured as images - Mobile screenshots Image input is especially useful for frontend development because a coding agent can compare the current implementation against a visual target. A frictionless paste workflow therefore fits naturally into Codex rather than behaving like a secondary multimodal feature. ## The GrokBot Comparison Reveals Demand for Visible Multi-Agent Workflows One particularly interesting comment referenced the experience of working with multiple smaller agents that can collaborate with each other. That feedback points toward a different interface model for coding agents. Instead of showing one opaque agent conversation, the UI could expose a small team: ```text Main Agent ├── Repository Analyst ├── Frontend Agent ├── Backend Agent ├── Test Agent └── Research Agent ``` The user would not necessarily need to manually manage every agent. The benefit is visibility. Users could understand: - What work is happening in parallel - Which agent is blocked - Which agent found an issue - Which task completed - Where human input is needed This is especially useful for large repositories where independent subtasks can be executed concurrently. ## Developers Want a Task Dashboard, Not Just Pull Requests Another strong idea from the replies was replacing some of the emphasis on Pull Requests with a broader **project activity dashboard**. A useful Codex project interface could look more like a lightweight engineering management system: ```text Backlog → In Progress → Needs Input → Dev Complete → Testing → Review → Done ``` For more complex work, a timeline or dependency view could show: ```text Database migration ────────┐ ├── API update ─── Frontend integration Authentication refactor ──┘ ``` This becomes increasingly valuable when agents can work for tens of minutes or hours without continuous supervision. The user no longer needs only a chat history. The user needs a **control plane for agent work**. ## Why Pull Requests Alone Are Not Enough Pull Requests are optimized for reviewing code changes. They are not optimized for understanding everything an autonomous agent is doing before code reaches the review stage. An agent may spend significant time: - Researching - Reproducing a bug - Comparing implementation options - Running benchmarks - Investigating test failures - Waiting for another task - Reopening completed work A project dashboard can represent these states more clearly than a list of Pull Requests. This suggests an important shift in developer tooling: **The unit of AI-assisted development is moving from the message toward the task.** ## Windows Remote and Resource Consumption Also Appeared in the Feedback Some feedback focused on Windows Remote behavior, including excessive memory use and swap consumption. This category of complaint is important because agentic development environments place unusual pressure on local systems. A coding agent may simultaneously operate: - Repository indexing - Terminal processes - Development servers - Browser automation - Language servers - Build tools - Test runners - Remote execution environments Resource leaks that would be moderately annoying in a normal editor can become severe during multi-hour autonomous sessions. For Codex to function as persistent development infrastructure, stability and resource cleanup become as important as model intelligence. ## Chat Archive Management Is Another Sign of Increased Agent Volume Users also asked for better management of archived chats, including bulk deletion and more consistent behavior across devices. This may appear unrelated to coding quality, but it reveals another consequence of agent adoption: **conversation volume increases dramatically**. When every coding assignment becomes its own agent task, users can accumulate hundreds of conversations and project runs. The interface therefore needs stronger information-management tools: - Search - Project grouping - Bulk archive - Bulk delete - Labels - Status filters - Completed-task cleanup Chat history was originally designed for conversations. Agent history increasingly behaves like a work queue. ## Astra Usage Complaints Highlight the Cost of High-Reasoning Models Some users also reported rapidly exhausting their allocation while using stronger reasoning configurations such as Astra. This illustrates another challenge for AI coding products: users do not naturally understand the relationship between **task complexity, model capability, reasoning effort, and quota consumption**. A developer may reasonably ask: - Does Medium reasoning consume twice as much capacity as Low? - Is a long repository search expensive? - Does parallel agent execution consume quota independently? - Is model usage measured by tokens, compute time, tool calls, or another abstraction? Without clear feedback, users may disable valuable capabilities simply to conserve quota. A better interface could provide an approximate cost indicator before launching expensive tasks: ```text Task complexity: High Expected runtime: Long Expected usage: High Recommended model: Astra Medium ``` The estimate does not need to be perfectly precise to improve decision-making. ## What This Thread Says About the Future of Codex The most interesting part of the discussion is how few complaints focus on raw code generation. The dominant issues are instead about managing an increasingly capable agent. The feedback clusters into five categories. ### 1. More Available Compute Users want fewer interruptions from five-hour and weekly quotas. ### 2. Less Product Complexity Users want clearer relationships between Chat, Work, and Codex — or preferably fewer mode decisions altogether. ### 3. Fewer Interruptions Approval prompts and agent questions should appear only when human judgment is genuinely necessary. ### 4. Better Agent Observability Users want to know: - What the agent is doing - Which tasks are running - What has finished - What failed - What requires attention - How much usage remains ### 5. Less Non-Essential UI Features such as Pet receive criticism because users would rather spend interface space on high-value operational information. ## Codex Is Becoming an Agent Operating System The thread also reveals a larger shift in how developers perceive Codex. The earliest AI coding tools were essentially autocomplete systems. The next generation became conversational coding assistants. Current systems are evolving into autonomous software-development agents. The progression looks roughly like this: ```text Autocomplete ↓ Chat assistant ↓ Repository-aware coding assistant ↓ Task-based coding agent ↓ Parallel agent system ↓ Software engineering control plane ``` At the later stages, model quality is only one part of the product. The interface must also handle: - Scheduling - Permissions - Observability - Usage management - Agent coordination - Persistent project state - Human escalation - Review workflows That is why seemingly small complaints about quota indicators, approvals, dashboards, and task status deserve attention. They are not isolated UX problems. They are symptoms of the transition from **AI chat to AI-operated workflows**. ## What OpenAI Should Probably Remove First If the feedback is interpreted literally, Pet is one of the clearest conventional features that users believe could disappear. If the feedback is interpreted strategically, however, the most important things to remove are not individual features. They are layers of friction: - Remove unnecessary mode selection. - Remove avoidable approval prompts. - Remove uncertainty around quota resets. - Remove hidden usage information. - Remove unnecessary interruptions during long-running tasks. - Remove interface elements that compete with task-critical information. The ideal Codex experience should feel increasingly simple as the underlying system becomes more sophisticated. That is difficult product design, but it is also a strong indicator of where coding agents are heading. ## Conclusion A simple question about deleting a Codex feature produced a surprisingly clear picture of what power users currently care about. The loudest request was to remove **usage limits**, particularly the five-hour and weekly constraints. Pet was one of the most frequently mentioned actual features, while deeper comments focused on confusing Chat/Work/Codex boundaries, approval interruptions, hidden quota information, agent questions, reset behavior, multi-agent coordination, and the lack of a richer project dashboard. The broader signal is more important than any individual complaint. **Codex users increasingly trust the agent to do substantial engineering work. Their frustration now comes from everything that prevents the agent from continuing that work smoothly.** The next stage of competition among AI coding tools may therefore depend less on adding another visible feature and more on building the cleanest possible control layer for autonomous development: fewer interruptions, clearer usage, better task visibility, stronger multi-agent coordination, and enough available compute to finish the job.