100% of What, Exactly? The GPT-6.1 Sol Quota Rug Pull

I want to tell you about a five-hour window that lasted a little over an hour.

That sentence sounds like the opening move in a philosophy seminar, but this one came from the percentage meter inside OpenAI Codex.

A week or two ago, GPT-6.1 Sol was absurdly generous. I could run it at Max reasoning for hours. Real autonomous software engineering. Long context. Tool use. GitHub work. Tests. Commits. The kind of work for which a two-hundred-dollar AI subscription is supposed to earn its keep.

Then Sol started eating quota like somebody had quietly replaced the gas tank with a shot glass.

The most recent run finally made me stop staring at the percentage bar and start auditing the machine. I had already done the respectable thing. I blamed myself.

Maybe my prompts were too large.

Maybe my agent was reading too much.

Maybe my project instructions were bloated.

Maybe context compaction was forcing expensive rehydration.

Maybe I was making the model reconstruct the whole dependency graph.

Maybe Max reasoning was the problem.

Maybe cached context was not as cheap as I thought.

So I stripped the workflow down.

I made each GitHub issue independently executable. I stopped hydrating the global work graph. I constrained reads to the current ticket and its direct prerequisites. I constrained retries. I told the agent not to preload future work. I removed subagents. I stayed in a warm session so the cache remained hot. I dropped the model from Max to Medium.

The remaining 44 percent of the five-hour allowance disappeared in minutes.

At that point, continuing to blame my prompt engineering would have been less like debugging and more like Stockholm syndrome with YAML.

So I opened the Codex logs.

That changed the argument.

The meter has receipts

Codex stores rollout logs locally. They contain a great deal more information than the cheerful little percentage bar OpenAI gives the customer.

Among other things, the logs record:

the model;
reasoning effort;
timestamps;
input tokens;
cached input tokens;
output tokens;
reasoning-output tokens;
the primary allowance percentage;
the allowance reset timestamp;
and the primary allowance window size.

The primary window in the runs I examined is explicitly recorded as 300 minutes.

Five hours.

That gave me something much better than memory, vibes, or screenshots of a shrinking progress bar. I could reconstruct the actual quota windows and compare what the model did inside them.

I found two unusually clean runs.

Same model: GPT-6.1 Sol.

Same reasoning setting: Max.

Same primary allowance: 0 percent used to 100 percent used.

Same 300-minute quota window type.

No other Codex model or session sharing either of those reset windows.

One was October 4, during what I am going to call the honeymoon.

The other was October 16.

Here is what 100 percent of the same primary allowance bought me.

Logged quantity	October 4	October 16	October 16 as share of October 4
Model	GPT-6.1 Sol	GPT-6.1 Sol	same
Reasoning	Max	Max	same
Primary allowance consumed	100%	100%	same
Logged time to exhaustion	174.7 min	69.6 min	39.8%
Uncached input	1,300,707	711,453	54.7%
Cached input	33,678,848	17,744,896	52.7%
Total input	34,979,555	18,456,349	52.8%
Total output	254,397	85,866	33.8%
Reasoning output	126,346	40,044	31.7%
Non-reasoning output	128,051	45,822	35.8%

Read the table from right to left if you enjoy nausea.

On October 16, the same model at the same Max reasoning setting exhausted the same full five-hour-window allowance while processing about 47 percent less total input.

It produced about 66 percent less total output.

It produced about 68 percent less reasoning output.

It exhausted the allowance about 60 percent faster.

Every visible token bucket went down.

The meter still reached 100 percent.

This is the part where an institution normally sends in a person wearing an extremely sensible cardigan to explain that usage is complicated.

Yes.

Usage is complicated.

Arithmetic is not.

This is not a story about the model simply doing more work faster

I initially chased the most charitable explanation.

Maybe the newer runtime was simply faster.

That would make intuitive sense. If Codex can issue model calls faster, run tools faster, and cycle through work faster, then a nominal five-hour window can disappear sooner in wall-clock time without the economics changing. A faster engine empties the fuel tank sooner even if the miles per gallon stay constant.

For a few minutes, that explanation looked good.

In one direct comparison, the newer run was indeed chewing through fresh context several times faster per minute.

Then I looked at the output.

The October 4 Max run produced 254,397 output tokens before the meter hit 100 percent.

The October 16 Max run produced 85,866.

The earlier allowance bought almost three times as much output.

Reasoning output was worse. October 4 produced 126,346 reasoning-output tokens. October 16 produced 40,044.

The earlier allowance bought more than three times as much reasoning output.

And this happened while October 16 also used less uncached input and less cached input.

So no, the newer runtime was not merely burning the same quota-denominated workload faster.

If the quota meter were a fixed nonnegative combination of the token categories Codex logs, then a later run with less of every category could not consume the same full allowance.

Something else changed.

Either the effective weights changed, or OpenAI began charging the allowance for some consequential quantity the local telemetry does not expose.

From the customer’s perspective, the distinction is mostly academic. If the company changes the invisible conversion function, or adds a new invisible term to it, the result is the same:

100 percent stopped buying the same thing.

That is the product.

The maddening part is that OpenAI had already told people it was changing the meter

This did not begin with GPT-6.1 Sol.

On September 9, weeks before the Sol 6.1 launch, an OpenAI Community user named alyx posted one of the better pieces of amateur billing forensics I have seen. They compared local request logs against allowance movement and reported a spectacular discontinuity.

Their description was blunt:

“my weekly Codex allowance suddenly started draining much faster despite a substantial drop in recorded token usage.”

Their September 8 to 9 comparison showed 2.18 billion recorded tokens consuming six percentage points, followed by 472.9 million recorded tokens consuming another 65 points. They correctly refused to call that a literal 50x billing multiplier, because the two periods differed in model mix and routing. The important fact was the discontinuity.

Then something even more interesting appeared in the same thread.

On September 22, another user reported what OpenAI Support had told them:

“There have also been changes to how Codex usage is measured.”

According to that posted Support response, Codex credit consumption had been linked more directly to token usage instead of approximate per-turn averages.

There it is.

Not a leaked Slack message.

Not a shadowy anonymous source in a parking garage.

A customer reporting that OpenAI Support explicitly told them the company had changed how Codex usage was measured.

A week later, the company reopened its $200 Pro plan and publicly changed the economics again.

A September 29 post preserved a statement from OpenAI’s Tibo Thielemans:

“we are also changing how we calculate the usage for it.”

The quoted announcement said the new Pro $200 calculation would work out to roughly half the API-dollar-equivalent spend of the old plan.

OpenAI’s own Help Center now says the quiet part with less personality. New Pro $200 subscriptions receive a lower usage allowance than previously offered, the price remains $200, and eligible existing subscribers keep the prior allowance only through October 29. The stated justification is “increasingly efficient models.”

That is a fascinating retail proposition.

We halved the amount of the thing you receive because the thing is more efficient now.

You are welcome.

This is why “they would never secretly change the weighting” is not a serious rebuttal

I spent too much of this investigation entertaining a standard of proof that would make any opaque platform immune from criticism.

Can I prove which internal coefficient changed?

No.

Can I see OpenAI’s billing service?

No.

Can I inspect the server-side feature flags?

No.

Can I tell whether the hidden term is cached-context weighting, inference compute, context-window occupancy, service-tier normalization, request-level overhead, routing, or something else?

No.

That is not exculpatory evidence.

That is the power imbalance.

OpenAI controls the meter, the denominator, the server-side accounting rules, the rollout cohorts, the internal model routing, and the data required to distinguish a deliberate pricing change from a metering bug.

Customers get a percentage.

Then, when the percentage behaves differently, we are invited to prove which proprietary mechanism caused it before forming an opinion.

What evidence, exactly, is the customer supposed to produce?

A subpoena?

A whistleblower?

A screenshot of “quota multiplier equals quota multiplier times three” from somebody’s production console?

This is not a criminal trial. I am not asking a jury to deprive anyone of liberty.

I am deciding what I think a company did to a product I pay for.

For that purpose, observed behavior, chronology, known precedent, company incentives, and corroborating reports are evidence.

The fact that the decisive internal records are inaccessible to the customer does not transform every external inference into superstition.

Then GPT-6.1 Sol launched, and the honeymoon was spectacular

OpenAI launched GPT-6.1 Sol on September 29 with an extremely attractive pitch: “Near-Astra intelligence for a fifth of the price.”

That was not marketing fluff around the edges. Cost efficiency was the product story.

OpenAI’s launch page put the numbers directly beside each other: $2 per million input tokens and $10 per million output tokens for Sol, versus $10 and $50 for Astra. Cached Sol input was advertised at $0.10 per million tokens.

The company explicitly said the cheaper cached input gave developers “more room to build and run capable agents that reuse context across requests.”

That promise matters because persistent coding agents are almost entirely about context reuse. A model can be brilliant in a benchmark and economically useless if every long-running session burns through the subscription before lunch.

For a lot of users, early Sol 6.1 appeared to deliver exactly what OpenAI was selling.

On October 2, in an r/codex thread asking for a verdict on the model, u/The_Oracle___ wrote:

“Insanely cheap, feels like my weekly limits are endless on 100$ plan, but painfully slow”

That thread is a time capsule of the launch experience.

Another user, E72M, said they had left Sol 6.1 working on one task for 38 hours. They started at 48 percent weekly usage and were still at about 16 percent.

Another commenter wrote:

“It’s slow but man you can run it all day.”

Another said five Sol 6.1 High agents had worked for fifteen hours and only moved a $200 Pro allowance down to 73 percent.

Another wrote that detailed website work had run for an hour and “usage has barely moved.”

In a separate October 2 thread specifically about Max reasoning, u/egomarker wrote:

“6.1 max uses about 3-4x less quota than 5.6 max.”

The thread’s premise was already that Sol 6.1 was “super light on tokens.”

That was the buzz.

People were not merely saying the model was good.

They were saying the economics were insane.

There is a difference.

A developer telling another developer “this model is smart” is useful marketing.

A developer saying “I can run Max all day and the meter barely moves” changes behavior.

You build bigger workflows.

You stop rationing long-running agents.

You migrate work from competitors.

You tolerate the model being slow because the slowness feels almost charming when the quota barely moves. The machine can think all night. You will make coffee.

That is adoption fuel.

OpenAI did not have to write the copy.

Its customers did.

The early reports were contradictory, which is exactly why I do not expect a single worldwide switch

Here is where the chronology gets more interesting.

The honeymoon was real for many users, including me.

It was not universal.

On September 29, the day Sol 6.1 launched, one Reddit user published a measured complaint titled “GPT 6.1 brought another nerf to usage - table update.”

They measured a fresh five-hour window twice and estimated the included usage at about $7.50 to $7.80 of current API-equivalent spend.

Four days later, on October 3, another r/codex user described a sudden change immediately after a reset. Before the reset, they said numerous agents over 24 hours had moved the meter about 30 percent. After the reset, continuing with Sol 6.1 High:

“I am down to 74% remaining in just a couple hours. Huge usage increase.”

The thread included another Pro 20x user saying Astra exhausted a weekly allowance in eight hours on work that had previously lasted about a day and a half.

Meanwhile, other users were still reporting almost endless Sol usage.

That does not make me less suspicious.

It makes me more suspicious.

Massive consumer infrastructure does not normally deploy consequential changes by having an engineer stand up at noon and press the giant red FUCK EVERY CUSTOMER SIMULTANEOUSLY button.

It uses staged rollouts.

Canary cohorts.

Feature flags.

Regional waves.

Account buckets.

Percentage allocations.

Rollback groups.

Experiments.

If the effective quota economics were being recalibrated across millions of users, I would expect the public evidence to look messy.

One user gets hammered on September 29.

Another after an October 3 reset.

Another still thinks Sol is practically free on October 4.

Another sees the change on October 11.

Then a large cluster starts screaming around October 16 and 17.

That is not a clean laboratory breakpoint.

It is exactly the kind of weather pattern I would expect from a staged platform change viewed by people standing outside the datacenter fence.

October 16 is where the complaints start sounding eerily like my logs

My clean Max-to-Max comparison crosses October 4 to October 16.

That second date matters because unrelated users started naming the same date.

On October 17, a Plus subscriber opened an OpenAI Developer Community thread titled “GPT-6.1 Sol suddenly consuming much more Plus usage since October 16.”

The opening report said:

“Starting yesterday, October 16, I noticed a dramatic increase in how quickly it consumes my usage allowance.”

That is twenty words. It is also almost exactly what my local telemetry says.

The replies got more specific.

A user named McDonalds_Mouse reported continuing the same task with GPT-6.1 Sol at Medium reasoning:

“I was literally continuing the exact same task with the exact same model and reasoning settings”

They said the allowance suddenly began running out much faster and was exhausted within five hours.

Another user, Ni-Ni, estimated that their five-hour limit had started draining:

“roughly 4 to 5 times faster by my estimate”

They said the workload was comparable, Standard service was in use, and they had disabled several possible background contributors.

Another user said comparable tasks were consuming about twice as much allowance. Another said Sol 6.1 Low, which had previously never exhausted the five-hour limit, was suddenly running out in roughly half an hour.

And this was happening on OpenAI’s own forum.

Not a competitor’s Discord.

Not a crypto Telegram channel.

OpenAI’s house.

The analytics themselves started looking haunted

Then came a report that should make anyone responsible for billing telemetry sit upright.

On October 20, a Pro user posted an OpenAI Community bug report saying they only used GPT-6.1 Sol in Codex, but the usage analytics began attributing most of their activity to Astra.

Their summary:

“usage attributed to gpt-6-astra, a model I never selected.”

The posted numbers showed 79.4 percent of October 17 usage and 82.6 percent of October 18 usage attributed to Astra in the model chart.

At the same time, the per-chat breakdown reportedly showed the top five chats as 99 to 100 percent Sol.

This does not prove that OpenAI secretly routed Sol requests through Astra and billed them as such.

It proves something more immediately relevant to the customer:

the company’s own usage surfaces could not agree on what model consumed the usage.

That matters because the customer is being asked to trust a hidden denominator whose visible attribution can contradict itself.

If my electric company sent a bill saying 82.6 percent of my consumption came from the industrial arc furnace I do not own, while the room-by-room breakdown said my refrigerator accounted for everything, I would not begin by apologizing to the utility for my insufficient understanding of electrical engineering.

I would ask them to fix the fucking bill.

By October 21, the language had changed from “amazing value” to “what am I paying for?”

Reddit is not a scientific instrument.

It is, however, a very good place to watch product sentiment mutate in public.

On October 2:

“Insanely cheap, feels like my weekly limits are endless”

By October 21, an r/OpenaiCodex poster opened with:

“GPT-6.1 Sol is still burning through my included usage way too fucking fast.”

The thread is not subtle.

One commenter wrote:

“6.1 sol used to not use much quota now it rips through it”

Another said that at the beginning of the month they could get a lot of use before the five-hour limit, while now they were lucky to get four or five tasks.

Another described analyzing thousands of documents and said the same class of work had gone from two or three days of usage to exhausting the $200 weekly quota in hours.

Another Plus user said the five-hour limit had lasted a few hours the prior week, but that day lasted only three medium-difficulty prompts.

There are also dissenting comments in the same thread. One user said they were still hammering Sol High without making much of a dent.

Again: good.

That is what a cohort rollout looks like from outside.

If every user had crossed the line at the same second, I would be looking for a global configuration flip.

If different users report different effective economics across adjacent days, resets, plans, and sessions, I start looking for staged assignment.

The heterogeneity is part of the hypothesis.

The company has already trained customers to expect invisible economic changes

This is not occurring in a vacuum.

On September 23, before GPT-6.1 Sol launched, a highly upvoted r/codex post was titled:

“Okay, they literally cut our quota by half. GPT 6 Sol got hit too.”

The author had been estimating API-dollar equivalents per percentage point and concluded:

“YOU, as the user, now got a 50% cut of whatever your subscription was worth.”

Then came September 29, when OpenAI itself announced the new Pro $200 economics.

Then came the current Help Center language, which says a new Pro $200 subscription includes a lower usage allowance than previously offered while the monthly price remains $200.

OpenAI’s justification is that models are increasingly efficient.

That sentence deserves to be mounted over the entrance to the Museum of Subscription Economics.

Imagine your mobile carrier announcing:

Our network became twice as efficient, so your 100 GB plan now includes 50 GB at the same price.

Perhaps the network really is more efficient.

Wonderful.

Whose efficiency dividend is that?

The customer’s, in the form of more value for the same money?

Or the vendor’s, in the form of lower cost plus a smaller allowance plus the same subscription fee?

OpenAI has answered that question with a pricing page.

“100 percent” is not a unit

The underlying problem is not merely that I think OpenAI tightened Sol 6.1’s effective quota economics.

The underlying problem is that OpenAI has designed a metering system where customers cannot independently establish what they bought.

A user on OpenAI’s own community forum asked Support what absolute quantity sits behind the 100 percent meter after the Pro 200 reduction.

Their report of Support’s answer was extraordinary in its ordinariness:

the quantity behind 100 percent is not disclosed as a customer-visible absolute unit;
it is not defined as a fixed number of messages, tokens, tasks, or published compute credits;
OpenAI does not document a fixed absolute equivalent for 5x, 10x, or 25x;
and the documentation does not guarantee that the multipliers always map to one stable internal baseline.

That is not merely a documentation problem.

It is the economic architecture of the product.

The customer sees a percentage.

The company controls what the percentage means.

If the company changes the function underneath it, the label on the gauge does not have to change.

Still says 100%.

Still says five hours.

Still says Sol.

The car just stops seventy minutes later.

The current documentation almost reads like a legal wrapper for arbitrary effective pricing

OpenAI’s current Work and Codex usage guidance says the allowance “does not correspond to a fixed number of messages or tasks.”

It says usage depends on the model, task, settings, context, reasoning, tools, information retrieval, caching, and speed.

Those are all legitimate variables.

They are also an extraordinarily large discretionary surface.

The more dimensions that feed an undisclosed normalized meter, the easier it becomes to change the economic behavior without changing any customer-facing quantity.

Suppose cached tokens become twice as expensive against the allowance.