gpt-5.6-terra and gpt-5.6-luna on Sume: which still run, as what

Of the three GPT 5.6 ids, only Sol is moved unconditionally: it runs on GPT-6 Sol. GPT 5.6 Luna moves to GPT-6 Luna wherever that id is admitted and otherwise keeps running as itself, and GPT 5.6 Terra has no successor, so a stored Terra pick or API id keeps running as Terra. All three are gone from the pickers.

What happened to each GPT 5.6 id?

The retirement came in the change that added the GPT-6 rows. The registry records it per row, with a rule for where the successor applies:

• "Admitted" means the catalog gate for that id is open in your environment. GPT-6 Luna is listed behind the same catalog gate as the Anthropic rows, not on every catalog.
• GPT 5.6 Sol is also kept as a runtime slug for the generic envelope and for Auto's fallback path, so some stored runs still read as GPT 5.6 Sol.

Why does Terra still run?

Because no replacement exists. The registry comment says there is no GPT-6 Terra, so remapping Terra to a different tier would silently change the model's behavior and price. Sume leaves it running as itself and drops it from the picker, which stops new users from choosing it.

Sume's registry gives Terra no successor, so if OpenAI retires it the row will need a change before the id works again. If you depend on it, treat Terra as a model you must migrate on your own schedule, not one Sume will move for you.

How do I see which one ran?

On a Format run, the receipt's model field is the catalog id the orchestrator ran on, defined in Runs and results. After a retirement remap it shows the successor, not the string you sent. For an explicit gpt-5.6-sol request the retired Sol post shows the proof.

History keeps the original: a thread served on GPT 5.6 Sol still prints and prices as GPT 5.6 Sol, so old cost reports do not shift when you read them today.

How should I audit my stored configs?

Search your code, automations and saved payloads for the three strings. A short script that lists every distinct model string you send is enough, and the receipts you already log will show where each one lands.

Fix the Luna case first, because it is environment dependent: the same gpt-5.6-luna string can run GPT-6 Luna in one workspace and GPT 5.6 Luna in another, depending on whether the gated catalog is open. That makes cost and behavior differ between staging and production without any change in your code. Pinning the exact GPT-6 id removes the ambiguity.

What should I send instead?

Name the GPT-6 id you want. gpt-6-sol and gpt-6.1-sol are listed on every catalog; gpt-6-luna appears where the gated catalog is open. OpenAI's GPT-6 Sol page gives a 1,050,000-token window, 128,000 max output and $2 and $10 per million input and output tokens; use the Sume receipt for what a run costs. An id that is not in the catalog is refused with 400 invalid_request, per the errors page, so a typo never lands on another tier.