I may have genuinely pushed ChatGPT Pro into territory most people never reach.

I've had a question for the past two weeks:
Exactly how much capacity does ChatGPT's Chat have?
Because my Codex / Work can often burn through the weekly allowance down to 0, while Chat keeps working normally.
I searched online for a while, but the answers were all over the place: some said Pro was unlimited, some said dozens of messages every few hours, some treated figures obtained from plugin statistics as official limits, and others assumed that once Work was used up, you could switch to Codex and keep getting more.
So I decided to check my own account.
The result was more interesting than “exactly how many messages”:
ChatGPT's capacity actually needs to be understood as at least two completely different systems.
The first: Chat.
Instant, manually selected Sol reasoning, and Sol Pro do not simply share one “N messages per week” allowance.
Instant's official wording is close to “basically unlimited,” but it is still subject to anti-abuse mechanisms.
The genuinely expensive manual Sol and Sol Pro have separate capacity pools.
The problem is:
OpenAI has not published an absolute total capacity for individual Pro users.
I even inspected the models and account used by the ChatGPT client in actual requests, along with common usage- and limit-related interfaces.
The client can tell you “whether this model can be used,” but unlike Codex, it does not directly expose:
“You have used XX%; the total capacity is XX”
So many claims online such as:
“ChatGPT Pro gets XXX messages per week”
are currently difficult to treat as reliable conclusions.
I also specifically dissected an open-source ChatGPT capacity-tracking tool.
I found that it essentially just listens for how many requests you send, then counts them according to a manually maintained capacity configuration.
For some Pro models, even the total capacity is itself unknown.
In other words, it can answer:
“How many requests have I sent?”
But it cannot answer:
“How much did OpenAI actually give me?”
But the second capacity system is completely different:
Work + Codex.
These are not two separate allowances.
They share the same Agent execution capacity pool.
I just directly read the platform-side rate_limits returned by Codex on my own machine:
used_percent = 100%
window_minutes = 10080
credits = 0
10080 minutes is exactly 7 days.
That means my Codex weekly allowance has now been completely burned through.
Opening Work at this point does not suddenly provide another allowance.
Because fundamentally, both are drawing from the same pool.
OpenAI publishes much more information about the Work / Codex pool: the official documentation provides broad estimates for different Pro tiers and different models within a 5-hour window, and clearly explains that task context, tool rounds, and duration all affect the amount that can actually be completed.
I will put the full figures in the accompanying image. What really matters here is that Work / Codex at least exposes the window and measurement logic of Agent execution capacity more clearly, while the total capacity for higher-tier Chat models remains hidden.
Even more absurdly, I had previously recorded in full how I burned through this pool once:
About 45 hours,
from 0% → 100%.
I later broke down all my local Codex session logs and recalculated everything.
At first I even reached the wrong conclusion:
Was it because I used too many high-tier models?
But after recalculating based on the actual tokens used in each round, I found that:
The truly terrifying factor was not that “the model was expensive,” but long sessions + lots of rounds + parallel Agent expansion.
One session reached 1258 rounds. During the entire capacity-consumption window, a large amount of the usage came from this kind of long-running Agent workflow.
But there is one more interesting thing here, and it is what actually changed the way I use it this time.
A few days ago, I conducted another round of real-world testing.
At the time, I essentially froze my main Codex workflow for 25.5 hours to see whether the regular Chat side could continue taking on real work.
The final data was:
Main Codex tier: 23 rounds (turns)
Regular Chat execution entry point: 10,558 tool calls / 218 execution traces
These figures cannot be directly divided. Rounds, tool calls, and execution traces are not the same unit of measurement, and they cannot be used to prove “how many times more efficient Chat is than Codex.”
The only thing that can really be confirmed is:
While the main Codex workflow was almost completely stalled, the Chat side was still continuously doing real work.
Why?
Because I had previously taken the open-source MCPX project from someone else and experimented with it.
MCPX was not written by me.
It is the open-source project opentokenz/mcpx, essentially an MCP runtime used to connect clients such as ChatGPT, Claude, Cursor, and Grok to local development environments.
What I did was adapt it, deploy it, get it running, and then connect it to my actual workflow.
So my Chat does not merely mean “I can keep chatting.”
Through MCPX, it can read the workspace, read and write files, run commands, call tools, operate a browser, read execution results, and then continue making judgments in the next round.
One boundary must be made clear here:
I am not saying Chat = Codex.
They are not the same product, nor do they use the same underlying capacity system.
What is actually happening is:
Chat handles reasoning, task decomposition, and orchestration.
MCPX is responsible for sending these decisions to a real environment for execution.
But in terms of whether “today's task can actually continue moving forward,” Chat + MCPX can already cover a large portion of similar execution work handled by Work / Codex.
So my understanding of ChatGPT Pro has changed as well.
Previously, I would simply divide it like this:
Chat = thinking pool
Work / Codex = execution pool
But this binary division is incomplete.
A more accurate description would be:
Work / Codex = OpenAI's native Agent execution pool.
Chat = another independent model capacity pool.
And Chat + MCPX can be expanded into a second practical execution surface.
That is the biggest change in my understanding after this research.
The official enterprise pricing table can also provide a rough reference for calculating computational costs: Chat Pro itself is also expensive computation; it simply consumes a different capacity pool. I will also put the specific credit-cost comparison in the accompanying image rather than mechanically calculating an “efficiency multiplier” from figures belonging to different pools in the main text.
So if you are only researching, analyzing, writing, or discussing plans, you can of course stay in Chat.
But now, even when you genuinely need to:
Read and write projects
Run commands
Automate browsers
Make cross-file modifications
Execute Agent workflows
it does not mean that once the Work / Codex weekly pool is burned through, the entire work system has to stop.
At least that is not what happens in my actual workflow.
As for what everyone most wants to know:
“So how many Sol / Sol Pro messages can the $200 Pro Chat actually send?”
My answer for now is instead:
I don't know.
And whenever someone gives you a precise number directly, I would first ask: which model, which reasoning tier, which Pro tier, which time window, were tools called, and was it verified across two reset cycles?
If these variables are not controlled, that figure has very limited meaning.
What I can confirm at present is: Chat and Work / Codex are not the same capacity pool; Work and Codex share the same Agent execution pool; Codex's weekly pool directly exposes used_percent and a 7-day window; and the total capacity of Chat's higher-tier models has not yet been made public.
So what I truly care about now is no longer:
“How many messages does ChatGPT Pro actually give me?”
But three other questions:
How many independent capacity pools did I actually buy?
How much does each pool have left right now?
Can I find a way to make every pool genuinely do work, instead of having only one pool connected to an execution environment?
I plan to keep using it normally, without deliberately spamming junk prompts.
When I naturally hit Chat's first real limit someday, I will add the complete data.
With this kind of thing, burning through it yourself once is far more useful than copying ten online articles titled “The Complete Guide to ChatGPT Usage Limits.”
And my most practical conclusion this time is:
Codex burned out, but my work system did not stop.
I used to think MCPX was simply very convenient.
Only after actually burning Codex to 100% this time did I truly realize what it means for me.