Codex Token Drain: The /goal Bug Was Never the Whole Story

The data shows a reset. Not a fix. This morning, OpenAI announced it had addressed eight distinct issues in Codex responsible for excessive consumption of paid usage limits. For every paid Codex and ChatGPT Work user, the weekly meter has been zeroed. According to Tibo, a Codex representative, the same usage limit is now expected to last anywhere from 10% to 50% longer, depending on the user’s workflow. But I have spent enough years auditing protocol balance sheets and token flow logs to know that an official announcement is never the evidence. Silence is just data waiting for the right query. Let’s rewind. Codex is OpenAI’s agentic coding environment, a product that sits somewhere between a chatbot, an autonomous developer, and a remote desktop. Users issue commands in natural language. The system reads files, edits code, runs terminal commands, takes screenshots, and summarizes what it saw. All of that activity consumes tokens. But unlike a standard API where every token is metered and billed line by line, Codex operates on a weekly usage limit — an opaque allocation that users cannot independently verify. This is the fundamental structural flaw. When a user hits their cap, the system simply stops. The user cannot see exactly where their tokens went. OpenAI is the sole auditor, judge, and reset switch. That context matters because the current conversation is being framed as a benevolent bug fix. The reality is more uncomfortable. The bug list reads like an audit report from a DeFi protocol with a dozen undocumented smart contracts. The worst offender, according to Tibo, is the /goal command. In some instances, after a task has been completed, /goal fails to stop processing. The agent keeps looping, re-reading files, re-running commands, and re-summarizing results. The consequence is catastrophic: a single runaway /goal instance can consume between 15% and 70% of a user’s entire weekly limit. Read that number again. In the worst case, one command, executed once, burns more than two-thirds of seven days of allocated compute. If this were a blockchain project, we would call it a drain. We would trace the wallet. We would quantify the loss. The fact that this happened inside a closed system does not make it less serious. The second biggest leak is the Computer History feature. In certain situations, Codex’s habit of summarizing historical operations consumes about 20% of the weekly limit. That is especially dangerous because the feature is ambient — it runs in the background, ostensibly to help the user understand what the agent has done. But as any data scientist can tell you, the cost of generating a summary is not trivial. Every historical operation must be re-encoded, re-processed, and then rewritten as a human-readable narrative. That is a token multiplier, not a convenience tool. Beyond those two, OpenAI identified additional consumption anomalies in image compression, background memory, automated tasks, sub-agents, and MCP (Model Context Protocol) integrations. The list is notable for what it reveals about Codex’s architecture. This is not a single bug. It is a class of problems stemming from the same root cause: the system’s inability to distinguish between “task accomplished” and “keep going.” In agentic systems, the decision to stop is as important as the decision to start. If the termination condition is not robust, every feature becomes a potential sieve. From a data perspective, the most interesting signal in the announcement is not the bug fix. It is the expected improvement range: 10% to 50% longer per limit. That range is incredibly wide. It tells me that OpenAI itself is not fully confident in the fix. A precise fix would produce a narrow range. A vague fix produces a range wide enough to cover poor outcomes. This is the inverse of what I expect from a mature auditing process. When I review a smart contract’s upgrade, I want exact state transitions. When Tibo says “depending on usage method,” he is admitting that the fix’s efficacy is workload-dependent. That is not evidence of a cure. That is evidence of a partial mitigation. Let me be clear about what I did after reading the announcement. I pulled up my own historical usage patterns from the Codex interface, cross-referenced session timestamps with token consumption estimates, and attempted to reconstruct where my weekly limit disappeared. I cannot share exact numbers because OpenAI does not expose the raw meter. But the pattern is consistent with the reported bug. My longest /goal session, which should have ended after generating a test suite, kept running. I stopped it manually after noticing the token counter. In that single session, I lost roughly 40% of my weekly allocation. This happened before the fix. And I have no way to know whether it has actually happened again since the reset, because the interface still does not present a live token-by-token breakdown. This brings me to the broader structural problem. OpenAI has reset the limits for all paid users, which is generous on its face. But a reset is not an apology, and it is not a fix. A reset is an accounting adjustment. It makes the problem disappear from the user’s immediate view, but it does not make the consumption model transparent. If Codex were a financial protocol, the equivalent would be a governance proposal to reissue tokens after a burn event, without publishing the burn addresses. The community would not accept that. Yet in the AI ecosystem, users are expected to trust the vendor’s telemetry. This is why I keep returning to the on-chain mindset. Truth is found in the hash, not the headline. When I audit a DeFi protocol, I demand the specific transaction hash, the block number, the wallet address. With Codex, there is no public ledger. Users are being asked to accept an invisible meter that only OpenAI can read. The user milestone subplot makes this more interesting. Yesterday, Tibo hinted that Codex was close to a new user milestone and suggested a celebration. Today, after the bug fix and the early reset, he said the button has already been pressed and the celebration is being moved to tomorrow. Historically, OpenAI has distributed reset rewards when Codex reached 15 million and 20 million users. That establishes a pattern. If a 25 million milestone is crossed this weekend, another reset is likely. For the average user, that would be good news: a double reset in one week. But I want to be honest about what a milestone reset actually means. It is a user acquisition tool. It is not a refund. It does not compensate users who lost time and productivity to /goal loops. It resets the meter precisely at the moment when the largest possible number of people are evaluating whether to remain subscribed. This is not conspiracy. It is behavioral data. Here is the deeper issue. The reset, combined with the weekend timing, creates an illusion of a fresh start. Users who ended the week with zero credits because of the bug are now granted a new allocation. They feel generous. Meanwhile, the underlying metering system remains unchanged. There is still no way to verify that the eight fixes actually reduce consumption for any individual workflow. The only way to test the hypothesis is to run a controlled experiment: take a fixed task, run it twice under identical conditions, measure the token consumption. But because Codex does not expose granular token counts, users cannot run that experiment accurately. They can only observe whether their limit lasted longer. And that observation is confounded by task complexity, session length, and memory retention. In my experience auditing liquidity pools and lending protocols, the most dangerous bugs are not the ones that are visible. They are the ones that quietly adjust the denominator. A fixed percentage drain is worse than a single catastrophic drain, because it grows over time. The /goal bug, as reported, is a catastrophic drain — one instance, 15-70% of weekly limit. But the Computer History issue, image compression, background memory, sub-agents, and MCP integrations are continuous drains. They do not announce themselves. They nibble. If OpenAI fixed only the loud bugs, the silent ones will remain. The 10-50% improvement estimate may simply be the difference between a catastrophic leak and a background leak. This is where the contrarian view begins. Most users will interpret the announcement as good news. I see it as a warning. Consider the incentive structure. OpenAI benefits when users consume more tokens, because it conditions them to expect a higher limit, and it justifies future price increases. The usage limit is not a ceiling designed to protect users; it is a demand-management tool designed to allocate scarce compute. When OpenAI says a bug caused excessive consumption, it is implicitly admitting that its own metering system failed. But it has not admitted how the metering determines “excessive.” It has not published a breakdown of the eight bugs. It has not identified specific session IDs. It has not provided a reimbursement model. It has simply reset the counter. That is why I keep coming back to the fundamental principle I learned during the ICO audit days. If you cannot reproduce the data, you do not have evidence. You have a press release. Silence is just data waiting for the right query, and the right query here would start by asking: how many unique users were affected? What is the distribution of losses across usage patterns? Did the /goal bug disproportionately impact heavier users? Without those numbers, the 10-50% improvement estimate is a marketing claim, not a measured conclusion. Let me attempt a reconstruction of the likely bug mechanics. The /goal command probably works by creating a long-running context loop. The agent receives a goal, breaks it into subtasks, executes them, and then re-evaluates whether the goal is met. The failure occurs when the evaluation function does not produce a “done” state. In code, this is called a missing terminal condition. The agent continues to check for completion, but every check triggers additional context generation. Each loop iteration adds tokens. Because the agent’s context window has a finite length, longer sessions also require summarization or compaction, which costs extra tokens. Over time, the token burn compounds. This is not a subtle bug. It is a classic infinite loop, made worse by the fact that each iteration uses a powerful LLM. Every iteration is expensive. The Computer History feature follows a similar pattern. To produce a summary of prior operations, the system must reconstruct the timeline, extract key decisions, and rewrite them. If the history is long, the summary is long. In a 100-step session, the summary could easily consume 20% of a weekly limit. This is a design flaw: the feature is supposed to help users, but it does not account for the metering cost of its own output. It is like a wallet app that sends a transaction receipt as an NFT, and the NFT mint consumes the user’s gas. Nobody would accept that. Image compression, background memory, automated tasks, sub-agents, and MCP integrations all share the same pattern. Each one generates metadata and context that must be processed and stored. In the absence of a transparent token budget per feature, users cannot predict which features will cost more. That unpredictability is itself a risk. In DeFi, we call this “slippage.” In Codex, we call it “usage limits.” The lesson is the same: if you cannot query the state of the system before you act, you are operating blind. This weekend, users may receive another reset. That would be welcome. But the celebration should be directed at the company’s user growth, not at the product’s reliability. The question for the market is whether OpenAI’s agentic coding tool can be trusted with mission-critical work when its core metering system is opaque. The users who hit the /goal bug lost time, not just tokens. The users who rely on Codex for production workloads cannot easily calculate the cost of an agent session. The reset does not change that. The next-week signal I am watching is not the reset. It is the presence of a public usage log. If OpenAI truly wants to solve the consumption problem, it should publish a per-session token breakdown, a list of the eight bugs with their impact, and a dashboard that lets users audit their own consumption. Until then, the phrase “fixed eight issues” must be treated as a peer-reviewed hypothesis, not a fact. I say that as someone who has spent years teaching developers to verify protocol claims with SQL queries and on-chain data. In the absence of a transparent ledger, the only rational stance is skepticism. Truth is found in the hash, not the headline. And the hash, in this case, is still missing. So enjoy the reset if it comes. But do not confuse a generous reset with a responsible metering system. A reset is a button. A fix is a root-cause analysis. OpenAI has pressed the button. The analysis remains to be seen.