An agent that handled a difficult change last week now stops halfway through a small one. You repeat the requirement, it answers an earlier message, and another chunk of the usage meter disappears. When this happens several times, checking whether the service has changed is reasonable.
That is the context behind the September discussion about GPT-6 Astra becoming less reliable. There is a substantive official acknowledgment: OpenAI has described and said it fixed several issues affecting Astra's behavior. Public reports also contain useful examples of worse results and faster quota consumption.
The stronger claim circulating alongside them—that GPT-6 requests are being broadly substituted with GPT-5.6 Luna—still lacks sufficient public evidence in the sources we reviewed through September 15, 2026. A poor result deserves investigation even when its backend cause remains unknown.
What OpenAI actually acknowledged
In a September 12 UTC update, OpenAI's Tibo Sottiaux described three problems:
- Some older Skills triggered too broadly or discouraged checking work.
- An opt-in context-management experiment could cause early stopping or replies to older messages. It was disabled; the estimated affected population for that experiment was 4,000–5,000 users.
- Misconfigured engines associated with measured degradation on some traffic were removed.
This establishes that identifiable problems existed. The post does not identify Luna substitution as their cause, publish a service-wide quality score, or establish how many people experienced all three issues combined. Its repair announcement also cannot tell us whether a particular later failure has the same cause.
The distinction matters when reading screenshots. “OpenAI acknowledged degradation” has support. “OpenAI confirmed that every Astra subscriber was downgraded to Luna” does not follow from that update.
The public reports are useful, with limits
The OpenAI community discussion includes accounts of repeated instructions, unfinished tasks, and results that felt worse than launch week. It is a user forum, so those posts document experiences rather than company findings.
A more detailed Codex GitHub report, #44851, compares SVG-generation runs before and after account-capacity errors. It records client versions and requested models. The author also acknowledges the important missing field: the actual served model was not visible in the inspected records. Shorter output and a worse drawing show a change worth checking; they do not identify which model produced it.
The discussion about silent model degradation makes the uncertainty especially clear. Some participants report problems, others report normal behavior, and resemblance to Luna output is being used as a clue. Resemblance can suggest a test. It cannot settle a routing question.
These reports should not be dismissed because they are imperfect. They give investigators task examples, approximate onset times, and configurations to compare. What they cannot provide is a denominator: how many comparable users and requests worked normally during the same period. Without that, we cannot calculate a failure rate or call the problem universal.
Four complaints are getting mixed together
The phrase “Astra got worse” can refer to different changes. Keeping them separate makes a support report much more actionable.
A quota meter falling twice as fast does not by itself show that the model became less capable. A correct answer produced quickly does not show that a smaller model replaced it. Conversely, an unchanged model label does not prove unchanged task performance.
For a Coding Agent, the result also depends on the surrounding software: which instructions were loaded, whether a tool returned the expected file, how earlier context was retained, and whether the agent checked its patch. The model is an important part of that chain. The whole chain is what the user experiences.
What would strengthen the Luna-routing claim?
Start with a specific request. Preserve the selected configuration, the outgoing model identifier if available, and the model identifier in the provider's response if exposed. Associate them with the same response or request ID. A child agent, retry, and parent answer may each be separate calls.
If a tool only records the requested model, describe that limitation. Asking the assistant “which model are you?” produces another generated answer; it does not reveal a server record. Our model-routing verification guide walks through these evidence levels and includes a report template.
Even a mismatch requires interpretation. A configured fallback, an explicit child-agent setting, a gateway mapping, and an unexplained provider-side substitution are different events. The useful question is where the choice changed, with evidence from that boundary.
What to do before spending another evening testing
Choose one task that failed and save its starting files, exact instructions, and acceptance conditions. Preserve the failed output as well. Changing the prompt repeatedly until one attempt works loses the comparison you were trying to make.
Then choose a small diagnostic budget. Repeat the task in fresh, equivalent sessions with the same model, reasoning setting, tools, and code baseline. Record whether it passes, how much manual repair it needs, and the total usage including failed attempts. A handful of runs is a useful screening exercise; it is too small to establish a population-wide degradation rate.
If you suspect old instructions, inspect the relevant rules before altering them. Our AGENTS.md and Skills review gives a narrow starting point. Test an instruction change separately from a model change, or you will not know which one helped.
If the main symptom is allowance disappearing, use the quota-consumption breakdown. If the main symptom is unreliable code, use a task-based regression check. Neither requires burning an entire subscription to prove a point.
Keep the project moving while the cause is investigated
A production deadline rarely waits for a complete backend explanation. After preserving a reproducible failure, it can be sensible to give the same bounded task to another compatible model or another Agent harness, such as Claude Code. Record that change as a different working configuration.
In Agent.Space, multiple Sessions can work with the files in a persistent Workspace, and supported model choices depend on the selected harness. That makes it practical to retain the project and move the next task to another Session. For comparisons that modify files, prepare independent copies or branches first; shared Workspace files do not automatically isolate concurrent edits.
The useful outcome is a working patch and a report someone can investigate. Keep the failure evidence, check the replacement's result, and use a short handoff if you need to continue elsewhere. A change of tool may restore progress even before the original incident is explained.
Reporting cutoff: September 15, 2026. This article reviews public statements and user reports; Agent.Space did not independently reproduce those users' incidents. The diagnostic workflow is our own.