OpenAI Codex Fast Mode Bug: Why Your Usage Was Higher Than Expected

Mar 27, 2026

Problem

I noticed my OpenAI Codex usage was burning through credits much faster than expected. I was being careful with my prompts, avoiding unnecessary requests, but my usage stats kept climbing at an alarming rate.

When I checked the community forums, I found I wasn’t alone. A user named Party_Link2404 on Reddit discovered the cause: the /fast mode was staying active even when explicitly turned off.

"They have alot to answer for. They gaslighted us for weeks and it seems
the usage bug was found. /fast being always on even when turned off."

This bug was tracked in GitHub issue #14593 and affected users for weeks before being identified.

What the /fast Mode Bug Did

OpenAI Codex has a /fast mode that provides quicker responses but consumes more credits per interaction. The idea is simple: you toggle it on when you need speed, off when you want to conserve credits.

But the bug prevented the “off” state from actually working.

User Action:           /fast off
Expected:              Fast mode disabled, normal credit consumption
Actual (with bug):     Fast mode stayed ON, higher credit consumption

I thought I was saving credits by disabling fast mode. In reality, I was paying the premium rate for every single interaction.

How I Discovered Something Was Wrong

My usage patterns didn’t match my behavior:

I turned off /fast mode at the start of each session
I avoided complex, long-running requests
I used concise prompts to minimize token usage
Yet my credits depleted 2-3x faster than expected

The disconnect between my careful usage and the actual consumption was the first red flag. But like many users, I assumed I was misunderstanding how credits worked.

The Impact on Users

This bug hit users in several ways:

1. Direct Financial Cost

Fast mode uses more credits per interaction. Users who paid for Plus subscriptions found their allocation disappearing faster than it should.

Normal Mode:           1 credit per interaction
Fast Mode (actual):    ~2-3 credits per interaction

If you made 100 interactions:
Expected (normal):     100 credits
Actual (bug active):   200-300 credits

2. Misleading Dashboard

The usage dashboard didn’t reflect the actual mode state. It showed /fast as off, but the backend processed requests as if it were on.

3. Trust Erosion

Users reported feeling “gaslighted” because when they raised concerns about high usage, they were told to check their settings—settings that appeared correct but weren’t functioning.

Why This Bug Was Hard to Catch

Several factors made this bug difficult to identify:

1. Invisible State

The UI showed the correct toggle state. There was no visual indication that fast mode remained active.

2. Gradual Accumulation

Usage creep isn’t immediately noticeable. A few extra credits per day doesn’t raise alarms until you hit your limit unexpectedly early.

3. Assumption of User Error

When users complained, the default response was to check settings. Since settings appeared correct, users were left confused.

4. No Direct Credit Visibility

Users couldn’t see real-time credit consumption per request. The usage stats were aggregated, making it hard to pinpoint which specific interactions were more expensive.

What Fast Mode Actually Does

To understand why this bug was costly, I looked at what fast mode changes:

Fast Mode ON:
  + Faster response times
  + Priority queue access
  - Higher credit cost per interaction
  - May use more capable/expensive model variants

Fast Mode OFF:
  + Normal credit consumption
  + Predictable usage patterns
  - Potentially slower responses
  - Standard queue access

For users who intentionally turned fast mode off, they wanted the normal credit consumption. The bug forced them into premium pricing without consent.

Community Response

The Reddit thread revealed the timeline:

Weeks 1-3:   Users notice higher-than-expected usage
             Support suggests checking settings
             Settings appear correct

Week 4:      User discovers /fast toggle wasn't working
             GitHub issue #14593 created
             Bug confirmed by multiple users

The phrase “gaslighted for weeks” from the Reddit comment reflects the frustration users felt. They reported a problem, were told to check something that looked fine, and only later discovered the root cause was a backend bug.

Lessons I Learned

After seeing this bug play out, I changed how I monitor AI tool usage:

1. Track Usage Independently

Don’t rely solely on the tool’s dashboard. Keep a rough log of your interactions and compare against reported usage.

2. Test Settings with Verification

When I toggle a setting, I should verify it’s actually working:

1. Toggle /fast off
2. Make a test request
3. Check response time (should be slower)
4. Check credit consumption (should be normal rate)
5. If behavior doesn't match setting, report bug

3. Check Community Forums Early

If something feels off, check Reddit, GitHub issues, and community discussions. Others likely experienced the same issue.

4. Report Anomalies Promptly

Don’t wait weeks to report usage discrepancies. Early reporting helps identify bugs faster.

How This Affects AI Tool Evaluation

This incident made me think about how I evaluate AI coding tools:

Transparency Requirements

I now look for tools that provide:

Real-time credit consumption per request
Clear logging of what features are active
Independent verification options

Vendor Communication

How a company handles bugs matters as much as whether bugs exist:

Quick acknowledgment of issues
Transparent timeline for fixes
Clear communication about impact

Cost Predictability

Hidden costs erode trust. Tools should make it clear:

What each feature costs
When features are active
How to verify your actual usage

This isn’t the first usage-related issue in AI tools:

ChatGPT Plus users have reported unexplained usage spikes
Claude Pro users discovered that simple questions cost more than expected due to system prompt overhead
API users often find costs differ from estimates

The common thread: users lack visibility into actual consumption.

What OpenAI Should Do

Based on this incident, here’s what would help prevent future issues:

1. Real-Time Credit Display

Show credit cost before and after each request, not just aggregated totals.

2. Setting Verification

When a user toggles a setting, provide a way to verify it’s actually working:

> /fast off
[Verified] Fast mode disabled. Next requests will use normal credits.

> /fast on
[Verified] Fast mode enabled. Next requests will use 2x credits.

3. Usage Anomaly Detection

Alert users when their usage pattern suddenly changes without corresponding behavior changes.

4. Transparent Bug Reporting

Public changelog noting when bugs like this are fixed, with clear impact explanation.

Summary

In this post, I explained the OpenAI Codex /fast mode bug that caused higher-than-expected credit consumption for users who had explicitly disabled fast mode.

The bug stayed active for weeks before being identified through community investigation. Users who thought they were conserving credits were actually paying premium rates for every interaction.

This incident highlights the importance of independent usage monitoring and community forums for AI tools. When the dashboard says one thing but the backend does another, only cross-referencing with other users can reveal the truth.

If you noticed unexplained high usage on Codex during this period, this bug was likely the cause. And for future reference: always verify that your settings are actually working, not just displayed correctly.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 GitHub Issue #14593
👨‍💻 Reddit: Usage Bug Discovery

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!