# Why GPT-5.6-Luna returned 502

> The error was not a broken proxy: one Freebuff account exposed models it was not allowed to open in its limited free session.

_Source: Reproduced in the iyu Freebuff2API Workers deployment; the limitation is account-specific upstream free-session policy, not a general statement about GPT-5.6-Luna availability · 2026-08-09 · 5 min read · Verified against primary sources_

Canonical: https://iyu.app/e/freebuff-gpt-5-6-luna-session-mismatch

## The 60-second version

The 502 came from an upstream free-session permission mismatch, not a dead proxy.

**Key points**

- The tested account allowed only DeepSeek V4 Flash and MiMo 2.5 on the limited free route.
- GPT-5.6-Luna was listed by the gateway but rejected when its upstream session was created.
- Silently downgrading a requested model would hide a routing error and change the result.
- A reliable gateway advertises tested capabilities and returns an explicit unsupported-model error.

**Verdict.** For this account, use DeepSeek V4 Flash or MiMo 2.5; Luna requires a different permission tier or provider.

## Full explainer

> **⚑ Caveat:** This conclusion is specific to the tested Freebuff account and its limited free upstream session policy. It does not establish that GPT-5.6-Luna is unavailable through every account or provider.


### The short version — The proxy was alive; the session was not allowed

The service returned HTTP 502 because the upstream refused to create a free session for GPT-5.6-Luna. The same account successfully handled DeepSeek V4 Flash, while the upstream explicitly named DeepSeek V4 Flash and MiMo 2.5 as the permitted limited-free models.

- **2** — models permitted by the tested free account
- **1** — advertised model that failed: GPT-5.6-Luna
- **400** — better client error for unsupported capability


### Where the mismatch happened — A model list is not a permission check

The gateway's /v1/models response listed many identifiers, including Luna. That only proved the proxy knew their names and routing metadata. It did not prove the account could create an upstream session for each one. The failure appeared later, when session creation reached the provider.

- **Model discovery:** The gateway recognizes a model identifier.
- **Session authorization:** The upstream account permits a session for that model.
- **Inference:** The active session can complete the requested chat.
- **What failed here:** Luna was discoverable but rejected at session authorization.


### Why not silently downgrade — A fallback answer can still be wrong

Mapping a Luna request to DeepSeek would hide the error, but it would also violate the caller's model choice. The output quality, reasoning behavior, latency, and usage accounting could all change. A gateway should either serve the requested model or state clearly that it is unavailable.


### The practical fix — Advertise only what the account can use

- **1.** Test every advertised model through the real session and chat path.
- **2.** Remove models rejected by the current account tier from /v1/models.
- **3.** Return a clear 400 model_not_supported error for explicit unsupported requests.
- **4.** Keep session, agent, and upstream model mappings aligned and expire stale session caches.

> Capability discovery is a contract. If the gateway lists a model, callers will expect the next request to work.


## Primary sources

- [Freebuff2API Workers deployment](https://github.com/pingmike2/freebuff2api-wokers)
- [Codebuff / Freebuff upstream](https://www.codebuff.com)

---
_Published by iyu (https://iyu.app) — the day's AI news, checked against primary sources and rewritten in plain language. Free to quote with attribution and a link to the canonical URL._