This is not just the model “feeling weaker.” The returned model identifier is a different, lower-tier model. GPT-5.6 Luna is the cost-efficient tier in the previous family; GPT-6 Astra is the current flagship. I did not request Luna and I am not using a router / auto model.
Questions
Why does a request for gpt-6-astra get resolved to gpt-5.6-luna?
Is this expected fallback (capacity, rollout, safety / abuse review, account eligibility), or a routing bug?
If it is account-related, what actually fixes it? For example:
waiting for capacity / rollout
raising usage tier / organization verification
changing password
enabling 2FA
adding a hardware security key / passkey
something else on the account or org side
I can tighten account security if that is the real requirement, but I do not want to guess.
When this happens, is billing / quota still charged as gpt-6-astra, or as the model that actually ran?
How can a developer reliably detect this in production? Is response.model the official source of truth for the model that served the request?
Is there a way to fail the request instead of silently falling back, so we are not billed or evaluated as if we got Astra?
What I have already checked
Request body explicitly sets “model”: “gpt-6-astra” (not auto, not a custom alias).
Same payload on another account / org returns gpt-6-astra as expected (if that applies to you — keep or delete this line).
Reproduced across multiple requests, not a one-off.
Not explained by model self-identification in the assistant text; the mismatch is in the response metadata.
Ask
Please confirm whether this is a known account-level or capacity routing issue for Astra, what the intended behavior is, and what the account owner should do to receive gpt-6-astra as requested.
Happy to provide request I, organization ID, timestamps, and redacted response JSON privately to staff.
Yea I’ve just noticed this too. Look into your usage stats. When I switched to Astra, my usage multiplied even with the same workflow. 5x is not enough anymore.
And now look at the model usage. I was using Astra exclusively, but under the hood Luna was used extensively for some reason. I wonder if my actual usage was consumed by Luna or Astra.
Your Analytics screenshot is useful, but I would keep one important evidence boundary:
“Analytics shows substantial Luna usage while I selected Astra” is not automatically the same thing as “this foreground Astra request was served by Luna.”
Analytics can include work done by different internal features/workers, so the strongest routing evidence is still request-level:
request body/model = Astra;
response model field = Luna;
request ID + timestamp;
same request path/surface.
There is already a current Community thread with a stronger direct-endpoint specimen where the official Codex request explicitly asked for Astra and the returned response metadata reported Luna:
If you already have response JSON/metadata for one of your affected requests, preserve that privately and compare it with the Analytics date/model attribution. That would tell us whether you have:
actual request-level Astra → Luna resolution;
Astra foreground requests with Luna appearing only in background/internal attribution;
or both.
I would also keep the usage-burn question separate from the routing question until OpenAI explains the accounting. Seeing Luna in Analytics does not tell us whether your allowance was charged at Astra weighting, Luna weighting, or some normalized compute accounting.
No need to deliberately burn more quota to reproduce this. Existing request IDs/response metadata + the Analytics screenshot are the valuable pieces.
