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.
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.
The short versionThe 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.
Where the mismatch happenedA 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 downgradeA 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 fixAdvertise 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 sourcesFreebuff2API Workers deployment·Codebuff / Freebuff upstream