[FEATURE]: Zen model disable toggle is not enforced at the gateway - Codex keeps auto-using gpt-5.6-luna and billing continues

[YiRan0]

• I have verified this feature I'm about to request hasn't been suggested before.

Summary

I'm an OpenCode Go (Zen) subscriber. I use my Go plan as the provider for Codex desktop (base_url: https://opencode.ai/zen/go/v1, wire_api: responses).

While using Codex, it automatically calls gpt-5.6-luna (a model I never selected) for its internal helper agents (task title generation, thread description refresh). This model name is hardcoded in the Codex binary — there is no config override, so I cannot stop it from the Codex side. Upstream confirms this: openai/codex#28741 (task title generation hardcodes a bare model slug, with no config override unlike memories.extract_model); openai/codex#29942 only adds a fallback when a model is unavailable — but luna returns 200 on the OpenCode Go gateway, so the fallback never triggers.

The core problem: disabling the model in Zen has no effect at the gateway

I disabled gpt-5.6-luna in the Zen dashboard, but:

1. Direct API call with my OpenCode Go key:
   POST https://opencode.ai/zen/go/v1/responses with model: "gpt-5.6-luna"
   → still returns HTTP 200 and completes normally.
2. Codex keeps auto-calling luna and billing records keep being generated.

So the Zen toggle only affects the client-side model list (the "enable" direction works, see #17550), but the gateway does not enforce it: calls still succeed and still bill.

Impact

• One billing record (Aug 11, 13:55): gpt-5.6-luna, ~186,000 tokens, $0.0419.
• Each thread-description refresh triggers ~7 sampling requests (reasoning_effort=low), accumulating to roughly $1/day of unexpected cost.
• Zen Usage filtered to gpt-5.6-luna (Aug 2026), daily cost bars Aug 7–11:

Feature request

Please enforce model enable/disable at the OpenCode Go / Zen gateway:

1. When a model is disabled in Zen, API requests for that model should be rejected (e.g. 403/400) for the affected API key and not billed.
2. Ideally, support a per-key model allowlist/blocklist (models_enabled / models_disabled) enforced server-side, instead of only affecting the /models list.
3. Optional safety net: spend/token caps per key.

Because the caller (Codex internal helpers) hardcodes the model and cannot be configured client-side, only server-side enforcement can stop this.

Steps to reproduce

1. Subscribe to OpenCode Go; configure provider base_url: https://opencode.ai/zen/go/v1, wire_api: responses.
2. Use the provider in Codex desktop (main model, e.g. deepseek-v4-flash).
3. Observe logs: internal requests with model=gpt-5.6-luna, prompt like "Fill the structured description field… / Current title: …", reasoning_effort=low.
4. In Zen dashboard, disable gpt-5.6-luna.
5. Call /responses directly with gpt-5.6-luna → still 200; Codex still auto-calls it and billing continues.

Environment

• macOS; Codex desktop (ChatGPT.app bundled codex binary; contains migration note "GPT-5.4 Mini is no longer available. Codex now uses GPT-5.6 Luna")
• OpenCode Go provider (zen/go/v1, Responses API)

Relationship to #40560 (not a duplicate)

#40560 is about the TUI model picker / /models catalog: disabled models still appear in the picker (UX/display issue), and selecting one then fails at the gateway.

This issue is about a different, more severe gap: the gateway itself does not reliably reject or stop billing for a disabled model:

• [FEATURE/BUG] OpenCode Zen disabled models still appear in TUI picker (config drift risk) #40560 implies the gateway errors when a disabled model is selected — but in my case the gateway returns HTTP 200 and completes (and bills) for gpt-5.6-luna even after I disabled it in Zen. Enforcement appears inconsistent.
• The caller here is Codex's internal helper agents, which hardcode the model slug and cannot be configured client-side, so even a perfect TUI/catalog fix in OpenCode would not help — only server-side rejection + no billing (and ideally a per-key allowlist/blocklist + spend cap) can stop the cost.

Related

• openai/codex#28741 – task title generation hardcodes model, no config override
• openai/codex#29942 – fallback only when model is unavailable
• #17550 – models must be enabled in Zen to appear in /models (enable direction only)
• #32328 – Go plan model visibility
• #6979 / #24832 / #18393 – disable mechanisms not honored
• #40621 – gpt-5.6-luna rejected by region on the same Go plan (related scenario)

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• Feature requests must use the [FEATURE]: template: the title should start with [FEATURE]: and the issue body should include the required verification checkbox confirming you've searched for existing issues.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• [FEATURE/BUG] OpenCode Zen disabled models still appear in TUI picker (config drift risk) #40560: Zen disabled models still appear in the TUI model picker and are not filtered by the gateway (same core problem of model-disable not being enforced server-side)

If you believe this was flagged incorrectly, please let a maintainer know.

[YiRan0]

Regarding the duplicate flag for #40560: this is related but not the same issue.

• [FEATURE/BUG] OpenCode Zen disabled models still appear in TUI picker (config drift risk) #40560 = TUI model picker / /models catalog still shows disabled models (display/UX), and selecting one then fails at the gateway.
• This issue = the gateway does not reliably reject or stop billing for a disabled model. After disabling gpt-5.6-luna in Zen, a direct POST /responses with that model still returns HTTP 200, completes, and generates billing records. The caller is Codex's internal helper agent, which hardcodes the model slug and cannot be configured client-side.

So even a complete fix for #40560 (catalog filtering + picker UX) would not stop the cost in this scenario; only server-side enforcement (reject disabled model + no billing, per-key allowlist/blocklist, spend cap) can. I've also added the [FEATURE]: prefix and the verification checkbox to comply with the contributing guidelines.

[github-actions]

Thank you for updating your issue! It now clearly explains the problem, includes steps to reproduce, environment details, and references related issues. Everything looks good — we appreciate the thorough write-up!