Please to Keep GPT‑5.5 Available as a Legacy Option in Codex

Codex Feature Requests
, , ,
1

Dearest OpenAI,

I’m a Pro subscriber and rely on Codex for my day‑to‑day coding work. I recently noticed the announcement that GPT‑5.5 Thinking is scheduled for retirement on October 14. I’m reaching out to kindly ask if you could keep GPT‑5.5 accessible inside Codex for longer, ideally as a legacy option for existing users.

I fully understand your mission to deliver increasingly capable models, and I appreciate the progress made with GPT‑5.6 variants. That said, GPT‑5.5 still serves a critical practical role that none of the current GPT‑5.6 models can replicate for real‑world production workflows.

In my daily coding practice, GPT‑5.5 is fast, consistent, and surprisingly dependable. It grasps the task at hand, sticks closely to given instructions, and delivers working implementations with minimal oversight — requiring very little follow‑up rework. While GPT‑5.6 Sol achieves superior results on some benchmark evaluations, it often performs poorly for ordinary, routine development tasks. It frequently over‑reasons, adopts indirect workarounds, expands task scope beyond what was requested, and consumes substantially more time and quota, without delivering proportionally better output.

Sol is also not a drop‑in replacement. When Sol launched, a large number of experienced Codex users voluntarily switched back to GPT‑5.5. This is not random user preference; it is actionable product feedback reflecting real‑world practical shortcomings.

My personal experience is not an isolated anomaly. Multiple independent users have documented consistent, reproducible issues on GitHub, under controlled testing conditions:

• One user reported GPT‑5.5 High and Very High consistently respects constraints, completes work efficiently and outputs predictable results. They returned to GPT‑5.5 after Sol produced worse outputs despite running for far longer. (Issue #36538)

• In controlled side‑by‑side testing with identical hardware, prompts, tool access, permissions and network settings, GPT‑5.5 successfully triggered web search and completed assigned workflows across all three test runs. Sol and Terra did not invoke search at all and completed zero reports across the same three trials. (Issue #32162)

• Multiple users observe simple tasks degrade in speed, as Sol unnecessarily initiates sub‑agents and extra delegation steps that add overhead with no tangible benefit. (Discussion #32065)

• There are concrete scenarios where GPT‑5.6 tool‑calling fails entirely, while GPT‑5.5 operates correctly under identical environmental conditions. (Issue #32759)

Some of these failures may originate from the Codex harness, orchestration layer, or model‑specific tool implementation, rather than the base model itself. However, for paying end‑users, this technical distinction is irrelevant. We do not consume isolated base models; we use the complete end‑to‑end Codex product. If GPT‑5.6 is unreliable or inefficient in workflows where GPT‑5.5 performs reliably, GPT‑5.5 remains functionally irreplaceable for those use‑cases.

This brings up an important point: a model can have higher aggregate capability on benchmarks, yet still be a worse tool for specific production workflows. Benchmark performance measures maximum potential, but it does not measure real‑world reliability, consistency, or overhead. A model that excels on hard challenges may still be unfit for everyday, high‑throughput coding work.

As paying Pro subscribers, many of us treat Codex as a production tool, not a playground for experimental models. We build workflows, scripts and routines around model behaviour. Removing GPT‑5.5 would force us to rebuild those workflows from scratch, incurring real productivity costs.

With all that in mind, I would like to humbly request the following:

1. Keep GPT‑5.5 available within Codex as a legacy option for existing Pro subscribers, even if it comes with reasonable usage caps.

2. Do not retire GPT‑5.5 until a genuine successor can match its real‑world speed, instruction adherence, reliability, quota efficiency, and low rework rate.

3. Evaluate potential replacement models against complete, real‑world development workflows, not only benchmark metrics or maximum problem‑solving complexity.

4. Provide a minimum of 90‑day advance notice once a truly equivalent replacement has been validated.

Removing GPT‑5.5 would mean removing a proven production tool that many users actively prefer after direct head‑to‑head comparisons against newer alternatives.

I hope you will consider that “newer” does not automatically mean “fully replaced.” Could we please give GPT‑5.5, and all the workflows built around it, more time?

Sincerely,

A Pro subscriber and daily Codex user

2

Thank you for writing this. I strongly agree that GPT-5.5 should remain available as a legacy option in Codex.

From my own experience, GPT-5.5 is not simply “older” or “less capable” in practical workflows. In Codex and related agentic environments, it has a very valuable combination of reliability, instruction adherence, tool-use judgment, speed, and low rework. A newer model may score higher on certain benchmarks, but that does not automatically make it a drop-in replacement for established workflows.

For users who have built real work processes around GPT-5.5, removing it means more than switching a model name. It means losing a known and trusted interaction pattern, re-testing workflows, changing prompts, adapting expectations, and potentially paying more quota/cost for less predictable results.

I would also support:

  • keeping GPT-5.5 as a legacy option for existing users,
  • evaluating replacements on complete real-world Codex workflows, not only benchmarks,
  • giving substantially longer notice before retiring models that people actively rely on.

“Newer” should not mean that a proven production tool is treated as disposable.

3

GPT-5.5 shipped on April 23. You are pulling it from every subscription tier on October 14. That is 174 days. I build on these models. 174 days is not a lifecycle, it is a bait and switch.

Let me be precise about what you are taking away, because “users prefer the old model” is not what is happening here.

For weeks I thought OpenAI had quietly cut my subscription quota. My usage was evaporating on work that produced almost nothing. I changed exactly one variable — I switched the model back to 5.5 — and my consumption returned to normal. The quota was never the problem. The models you want me to move to are.

5.6 Sol burns fine until it decides to over-engineer, and it decides to over-engineer constantly. It will run a pile of tests and deliver almost no working code, and it can chew through a weekly quota at the rate of a 5-hour window. Astra is worse: it is expensive per unit of work, full stop. People are telling me a 200 dollar Pro plan is not enough to let Astra do real work. Think about what that sentence means. You have built a tier where the answer to “is this enough” is no.

And for what? On benchmarks, yes, 6 wins. But most of my work is not a benchmark. In ordinary engineering tasks 5.5 and 6 do not differ meaningfully in what they actually deliver. So the extra burn buys me nothing. It is not a better result at a higher price. It is the same result at a higher price.

So from where I sit this does not read as a technical decision. 5.4 is gone. 5.5 is next. Every replacement burns more. The one model that was both capable and economical is the one that has to go. If that is a coincidence, it is a remarkably consistent one.

I am not writing this expecting you to reverse it. I am writing it so it is on the record that the people who actually shipped things with 5.5 saw exactly what this is.

And you should know the pressure does not work the way you think. I am not stuck choosing between your tiers. Claude, Kimi, GLM, DeepSeek are all sitting right there. What you are actually teaching me is not to build on top of anything you can pull in 174 days.

4

Similar things were said about deprecation of older models in the GPT-4 series.

I’m afraid we have to build applications that are as model agnostic as possible and we need to accept the pace of change is yet to slow down.

I don’t think it’s realistic to expect OpenAI or any firm for that matter to hang on to their older line-up longer than 6 months …

5

I am model agnostic — that is exactly why I wrote this. Kimi, GLM, DeepSeek and Claude are all on my desk, and my workflow is not hard-wired to 5.5.

Being model agnostic solves portability. It does not solve quota. My code runs fine on 5.6; what does not survive the swap is a week of work fitting inside a week of allowance. Same task, same prompts, one variable changed — I tested it. That is not something an abstraction layer can paper over.

Nobody is asking you to freeze the pace of change. I am asking you not to call it an upgrade when the replacement does the same job and bills me three times for it.

6

Gotcha, yes that’s annoying!

I’m using 4.1 and I dread to think of the bill change when that goes …

7

Hi and welcome to the community!

I just wanted to add that 5.5 will still be available via the API after October 14. A deprecation date for the API has not been announced, and there should be a six-month period between the announcement and the final deprecation date.

8

Just to be clear where I’m coming from — I’m not an enterprise customer. I’m one humble subscriber and one fairly desperate developer :neutral_face:

My complaint isn’t that a model is being retired. Models come and go, that’s fine.

It’s the trend. Each generation burns more quota than the last for the same work. 5.6 does what 5.5 did, and when it decides to over-engineer it can drain a weekly allowance in two days. 6 is worse — a $200 Pro plan doesn’t cover it. And the one model that did the job efficiently is the one being pulled out of the subscription. :head_shaking_horizontally:

So the direction is: the efficient option leaves, and what stays costs more to do the same thing. That’s what I’m objecting to. Whether 5.5 lives on in the API is a separate question — it doesn’t fix this one.

9

what they literally dont understand is now if they choose to be greedy, because lets be honest, thats exactly whats happening, they want to put limits on usage and get poeple to spend more on credits etc… they are gonna lose ALOT OF SUBSCRIPTIONS .. AND I MEAN ALOT. Because the main plus of using codex and open ai wasnt that there models were necessariliy better than claudes.. it was that they had more open usage and customers were able to complete way more tasks… if we have to deal with subpar models and usage limits, we mise well just switch to claude. Its going to bite them where the sun dont shine. But clearly they are too greedy to realize the economy we are in.

10

Nothing to add, my guy. You’re just right. :saluting_face:

The open usage was the product. Everything else was a bonus. And “bite them where the sun don’t shine” is honestly the polite version.

11

The actual suggestion here is to switch to 5.6 Luna with High/Extra High/Max reasoning and benchmark its performance and costs against 5.5.

Make sure to follow the model-specific guidance: Model guidance | OpenAI API

I’m sure this will help many others who are also looking for the best way forward.

12

Thanks for the pointer, I did go through the model guidance.

I think the recommendation may be aimed at a different seat than the one 5.5 is leaving. Luna and DeepSeek 4.1 Flash are excellent executors and they make very good subagents. The seat that opens up when 5.5 goes is not an executor seat.

A main agent is not really judged on raw coding ability. It is judged on project management. Holding the architecture. Keeping the direction straight when the work starts to drift. Sizing tasks and drawing the permission boundary around each one. Doing acceptance properly. Knowing when to send a chunk back and when to just patch the hole yourself. Knowing what the stop-loss is after a subagent has failed the same chunk twice.

Delegate the big blocks. Patch the small holes yourself. Guard the boundaries. Never skip acceptance.

That is not a contest for whoever writes the best code. It is a contest for whoever can judge who should be doing what.

There is also a structural reason the two seats are not interchangeable. An executor receives a small task with clear boundaries, so its context stays short and inertia never accumulates. A main agent sits inside a context that only gets longer, and has to keep making judgment calls from inside it. The longer that context runs, the cheaper it becomes to continue in the direction already established rather than stop and re-evaluate. Smaller models take that discount more readily. It is not that a larger model never drifts. It drifts less easily, because it has more room to stop and check itself. And the single most valuable thing a main agent does, saying this is wrong and sending it back, is exactly the move that inertia wants to skip.

On benchmarking: I would if the seat could be measured that way. A benchmark scores bounded single-turn tasks. It does not measure whether the work was split correctly, whether the permission boundary held, or whether acceptance was done honestly instead of waved through. Those only show up across a long project, and they are precisely what the main agent seat is for.

I run a lot of models through my workflow every day, so I am answering from that rather than from preference. I also cross-checked it against people who ship projects daily. Of what is available right now, only two can realistically take the main agent seat from 5.5: GPT 5.6 Sol and Claude Fable 5.1. Both of them cost me something extra to sit there.

Sol needs strict project rules and skills to keep it from over-engineering, and in practice the rules alone are not enough. I end up restating the constraints in the middle of the work, every time. That supervision is itself part of the cost.

Fable thinks more openly, takes real initiative, and does not over-engineer. It burns just as much quota.

So the comparison you are suggesting has already been run on my side, and that is what it returned. Every replacement currently on the table asks the subscriber for something extra, either attention or quota. I am putting it here because you are right that other people are looking for a way forward, and this is what the way forward looks like from where I am sitting.

14

I 100% agree gpt-5.5 is a reliable workhorse. Works consistently better than 5.6 or 6.

Please keep it on.

15

With respect, this recommendation still misses the category of replacement being requested.

We are not asking for another executor. Luna can be a capable executor when it receives a small, clearly bounded task, but it is fundamentally reactive: it advances one prompted step at a time. It does not reliably hold the architecture of a long project, recognize when the current direction has become wrong, redraw task boundaries, enforce acceptance criteria, or decide independently that a failed piece of work must be sent back.

Increasing Luna’s reasoning effort to High, Extra High, or Max only makes it spend more compute on each local step. It does not transform a reactive executor into a main agent with project-level judgment.

The cost we are describing is not merely token consumption. It is the human attention required to keep decomposing the work, prompting the next step, correcting drift, restating constraints, and checking whether completion claims are actually true.

GPT-5.5 could carry the intent of a project across a long context and make useful judgment calls without needing to be pushed forward at every turn. That is the capability being retired. “Try Luna at Max” does not replace it; it substitutes a more heavily reasoned executor for a project lead.

16

This is exactly my experience. I never have received that many “You exceeded your quota” with 5.5. I also opt for keeping this alive, because 5.6 torpedoes even “normal” work

17

Exactly this. 5.5 just does the work and gets out of the way. 5.6 turns a simple task into a research project, and the quota is gone before the real work even starts. :melting_face:

What keeps bothering me is the pattern. The one model that is both good and cheap to run is the one being taken out of subscriptions.

18

This is exactly it. Two of us arrived at the same conclusion independently, from running actual projects. That is worth noticing on its own.:melting_face:

And if the lead role could be filled by an executor, I would already be using a much cheaper one for it. The one thing this world is not short of is cheap, capable executors. :squinting_face_with_tongue:

19

I was about to create this topic when I saw that someone had already created it, so I came to show my support. And I think they should extend this to ChatGPT and not just Codex.
The 5.6 models are great; we’re all using them.
But, in my honest opinion, deprecating the model without actually having a successor that is better at everything is not a good path.
GPT 5.5 does some things much better than the 5.6 models. Health-related knowledge, theory of mind, state perception, psychology knowledge, creative writing, handoffs. ChatGPT 5.5 is still the guy for these topics. Keep it available, even if only through hard-to-find settings, like a /model chatgpt-5-5 command or an environment variable—that is, make it something few people will use because only those who want to use it will look for it. That might be a good middle ground between costs and meeting users’ needs.

20

For long-running personal and professional threads, the issue is not just raw capability but continuity of tone, judgement, memory use, and interaction style. GPT-5.5 Thinking has a distinctive balance of reasoning, tact, humour, and restraint that newer models do not currently reproduce reliably. Retirement without a close replacement will disrupt established workflows and long-running support threads. Please consider extending access / offering a legacy toggle

21

So will gpt-5.3-Codex come back? It was the last “Codex” model that truly impressed me.