Dated reports from Codex and Work users describe long waits, weaker outputs and rapid allowance depletion after GPT-6 Astra’s launch. The accounts are specific and worth examining, but they do not establish a universal regression.
Post-launch reports point to three different pain points
GPT-6 Astra arrived on September 3 with a strong official performance story. In the days that followed, however, some users began documenting experiences that did not resemble that launch narrative: slow progress in agentic runs, results they judged less consistent, and usage allowances disappearing faster than expected.
These posts are facts in a limited but important sense: identifiable users published dated accounts with plan, setting, timing or task details. They are not a representative survey, and they do not reveal what happened inside OpenAI’s systems. The evidence supports saying that users reported problems—not that Astra deteriorated for everyone.
A slow Codex run with a responsive interface
In Codex GitHub issue #44258, opened September 9, a Pro 20x user on macOS described an Astra Ultra run with Fast enabled and three subagents. A captured Goal/Plan task showed about 10% progress at 5 minutes 31 seconds and 20% at 5 minutes 44 seconds, while still reading and searching files.
The reporter said the interface remained responsive and stressed that the percentages were the task’s own estimates, not a throughput benchmark. The issue contained no launch-era server traces. It raised routing, queueing or throttling, service tier, and app or backend changes as possibilities to investigate, but did not identify a cause.
Uneven output after a capacity message
A separate Pro user, writing in Codex issue #44851 on September 11, said their account had been blocked by a “Selected model is at capacity” message for roughly seven hours on September 10 in UTC+8, then intermittently afterward. The user associated that event with shallower SVG coding runs and output and reasoning token totals that were roughly half their earlier levels.
The account also supplies its own limits. It compared two runs before the event with six afterward; SVG output is noisy; some prompts differed; and client logs showed the requested model, not which model actually served a request. The report therefore documents a within-account association, not evidence that capacity pressure caused a model change.
Similar concerns appeared in a September 11–12 OpenAI Developer Community thread. One user said simple tasks required repeated instructions. Another compared the same prompt and High setting on an SVG task, reporting a substantially worse result in 36 seconds versus 2 minutes 52 seconds five days earlier. A commenter noted that routing, system behavior and task handling remained possible variables. This was an informal comparison, not a standardized benchmark.
One detailed session shows how orchestration can consume allowance
A September 8 Reddit telemetry report from a Plus user offered a different kind of evidence. In one roughly 33-minute Astra Low parent run coordinating two GPT-5.6 Luna X-High workers, five-hour usage rose from 53% to 100% and weekly usage from 9% to 16% before the task completed.
The user counted 47 parent waits, each timing out after 30 seconds, and attributed 7.13 million parent input tokens—about 68% of that parent’s input—to those checks. That detailed single-session account suggests polling and orchestration can amplify consumption in that workflow. It does not show that every Astra task, or Astra alone, consumes allowance at the same rate.
Published allowances explain why experiences can differ
OpenAI’s usage guidance for Astra in Work and Codex says the products share a plan allowance and that usage varies with plan or seat, model, task and settings. Its five-hour “local messages” figures are estimates rather than fixed limits. For Astra, the published ranges are 5–45 on Plus, 25–225 on Pro 5x and 100–900 on Pro 20x. For Sol, the respective estimates are 10–100, 50–500 and 200–2,000. Both five-hour and weekly limits can apply, depending on the plan.
Those ranges provide context, not an audit of any user’s run. They also help explain why a complaint about “fast-burning” limits needs its plan, workload and settings attached. A local message estimate cannot be converted into a universal cost per task.
The launch benchmark remains a baseline, not a post-launch retest
OpenAI’s September 3 launch announcement described Astra as state of the art across coding, computer use, browsing, science and professional work. It reported a 57.9% score on Terminal-Bench 4.0, compared with 37.3% for GPT-5.6 Sol.
That result is relevant, but it does not resolve the newer accounts. OpenAI’s footnote says evaluation scores are maximum-at-any-effort and can differ from production ChatGPT because environments and tools differ. The number is a launch evaluation baseline, not a post-launch retest of the product conditions described by users.
A positive report cuts against a universal verdict
Not all contemporaneous feedback was negative. In a September 10 Developer Community reply, one user said Astra was doing thorough work in Codex and VS Code at Extra High, with Fast both enabled and disabled. A single positive account is no more representative than a single complaint, but it directly cautions against treating the negative reports as universal.
A resolved Work Mode incident is separate context
OpenAI’s status page recorded elevated errors affecting Work Mode in ChatGPT, with mitigations reported September 14 and recovery declared September 15 at 03:11 in the page’s time. The incident names ChatGPT Work as the affected component. It does not attribute the errors to Astra and does not explain the separate speed, quality or quota reports.
What the evidence supports now
The defensible conclusion is mixed experience under uncertain conditions. Several users documented slow execution, weaker or less consistent results, or unexpectedly rapid allowance depletion. Another reported thorough work. OpenAI published a strong launch benchmark, variable usage estimates and a resolved Work Mode incident, but none is a controlled answer to the post-launch reports.
Key takeaways: the complaints are reportable firsthand evidence; their dates and concrete details matter; their samples and comparisons are narrow; and no cited source confirms a systematic capability regression, silent model substitution, or one cause linking all three symptoms.
Image disclosure: The featured image and inline different-experiences illustration are AI-generated editorial visuals. Neither represents benchmark data or an actual user interface.