Over the past couple of weeks, I have been experimenting with using Codex to modernize and add AI capabilities to an old MUD game.
The project is fairly unusual because it involves a large legacy LPC/MudOS codebase, old game mechanics, saved-world data, transportation systems, NPC logic, a Python AI bridge, and some graphical client work.
During my first week with ChatGPT Plus, Codex felt surprisingly durable. I sometimes worked with it for around 10 hours in a day and only occasionally hit the 5-hour limit.
Then, around September 1, my usage started depleting much faster.
At first I thought something had changed with Codex limits. Later I realized that I had begun using GPT-5.6 Sol much more often, usually with Medium reasoning and occasionally High.
After doing some controlled testing with my one-time rate-limit reset, I now have a clearer picture.
Sol is expensive, but extremely capable
For my project, Sol is clearly the strongest model.
It is much better at understanding old architecture, reasoning across many files, identifying incorrect assumptions, and repairing problems that require understanding how the original game system actually works.
The downside is that it consumes quota very quickly.
With my current usage pattern, I can realistically burn through a weekly Plus Codex allowance in about two days if I rely heavily on Sol.
Luna uses very little quota, but its coding ability is not reliable enough for complex work
Luna is dramatically cheaper in terms of quota consumption.
However, on my project, its coding and architectural reasoning are often not good enough.
One example happened today.
I first used Sol to build a correct sample city and define the rules for how the city’s rooms should connect.
After that, I asked Luna to follow the existing sample and the rules already designed by Sol to build another city.
Even with a correct reference implementation and clear rules, Luna still created the room connections incorrectly.
This is not just a matter of needing one or two corrections. In more complex cases, Luna or Terra can repeatedly make incorrect changes, misunderstand the original game logic, and sometimes pollute the existing code or saved data.
Eventually, I have to switch back to Sol.
Then Sol has to:
-
understand the original problem;
-
identify what the weaker model changed incorrectly;
-
revert or repair those changes;
-
and then complete the original task correctly.
At that point, the lower-cost model has not actually saved quota.
It has created extra work.
Terra has the same problem, just to a lesser degree
Terra is stronger than Luna, but I have seen the same pattern.
In one recent case, Terra failed more than ten times while trying to repair a city-loading problem in my MUD project.
When I switched to Sol, Sol quickly realized that the previous approach had misunderstood the game’s original architecture.
Instead of repairing the city-loading mechanism, the previous work had effectively started redesigning the transportation system.
Sol then had to roll back the changes, clean up incorrect data, and reconstruct the solution based on the original game mechanics.
So the real cost was:
many Terra attempts + cleanup + Sol analysis + Sol rework
That can easily cost more than using Sol from the beginning.
The important distinction is not cost per attempt, but cost per completed task
This is the biggest lesson I have learned from testing the three models.
A cheaper model may consume much less quota per message or per attempt.
But if it requires repeated retries and then needs a stronger model to fix the damage, it can be more expensive overall.
In other words:
lower quota cost per attempt does not necessarily mean lower total quota cost to complete the task.
For simple, mechanical work, Luna is useful.
For normal production coding, Terra can be useful.
But for old codebases, ambiguous bugs, multi-file reasoning, architecture, or systems where one wrong assumption can contaminate many files, I now prefer to use Sol early rather than trying to save quota with a weaker model.
This also affects how I think about upgrading to Pro
I am actually willing to upgrade from Plus to Pro because Codex has become very useful for this project.
My concern is not that Sol is expensive.
If Sol solves difficult problems correctly, I am willing to pay more quota for it.
The problem is that with heavy Sol usage, the Plus weekly allowance can disappear very quickly, while relying on Luna or Terra to save quota sometimes causes enough rework that the savings disappear anyway.
So for users working on complex real-world codebases, the practical choice can become:
-
use Sol and burn quota quickly;
-
or use cheaper models, risk repeated failures, and then pay for Sol anyway.
I think it would be very useful if Codex could better detect when a task is beyond the reliable capability of Luna or Terra and recommend switching to Sol earlier.
Even a warning after several failed iterations would help reduce wasted quota and code pollution.
For now, my own strategy is becoming:
-
Luna for simple repetitive or mechanical work;
-
Terra for straightforward development;
-
Sol for anything involving architecture, ambiguous bugs, legacy systems, or multiple interconnected files.
I would be interested to know whether other developers using Codex on large or old codebases are seeing the same pattern.
PS:
My original plan was actually to use the models in a very deliberate division of labor.
I wanted Sol to handle one city first: understand the old MUD architecture, solve the difficult edge cases, build a correct sample city, and define a clear set of rules for room connections, transportation, exits, and related logic.
Then, once that reference implementation and rule set were stable, I planned to use Luna for the repetitive part: generate the remaining cities by following the Sol-created sample and the already-established rules.
In theory, this should have been a very good use case for a cheaper model. Luna would not need to invent the architecture or solve ambiguous problems; it would only need to reproduce a known pattern correctly.
But in practice, Luna still struggled even with this reduced scope. In one test, Sol had already completed the Xiapi city as a working sample and defined the connection rules, but when I asked Luna to build another city by following that sample and those rules, it still created incorrect room connections.
This was disappointing because it means Luna is not only unreliable for complex reasoning; in my project, it can also fail at structured replication tasks even when the difficult design work has already been completed by Sol.
That undermines the workflow I originally hoped to use: Sol for design and problem-solving, Luna for low-cost batch execution.
If the cheaper model cannot reliably reproduce a validated sample, then the user still has to review and repair the output with Sol, which again reduces or eliminates the expected quota savings.
