Fix GPT-5.6 Model Not Found

When GPT-5.6 fails in Codex, the error rarely tells you what to fix. The key may not expose the model, the /v1 route may be wrong, or a direct Responses request may work while the provider rejects metadata added by Codex. Running the same command again usually reproduces the symptom; by itself, it does not identify the failing layer.

This free kit tests those possibilities layer by layer. It verifies the exact model IDs, basic Responses output, an exact SSE text marker and terminal response.completed event, and the named function with exact JSON arguments. It then runs Codex with temporary provider settings from an empty working directory and writes one sanitized JSON report. Direct checks send only fixed markers; the Codex smoke test leaves your existing configuration unchanged. The kit checks compatibility; it does not benchmark model quality.

Match the GPT-5.6 error before changing configuration

Do not paste one error into a random configuration workaround. A direct API 404, a Codex model metadata warning, and a provider cooling down message describe different layers. The checks below preserve that distinction.

What the kit proves

The checks are deliberately layered:

1. GET /v1/models confirms that the key can see each exact model ID.
2. A minimal non-streaming Responses call confirms basic generation and verifies the returned model ID.
3. An SSE check requires an exact text marker and a terminal response.completed event.
4. A strict function check requires the named function and exact JSON arguments.
5. An isolated codex exec run tests the installed Codex CLI through the same provider.

Passing one layer does not imply that the next passes. That separation is the useful part: if direct API checks pass and only codex_cli_smoke fails, changing the API key or model ID is unlikely to fix the actual problem.

Run it without touching your existing setup

Put check.mjs and the launcher for your shell in the same directory. In Bash or Zsh, read the key without putting its literal value in shell history:

chmod +x run.sh
printf 'OmniaKey API key: ' >&2
IFS= read -r -s OMNIAKEY_API_KEY
printf '\n' >&2
export OMNIAKEY_API_KEY
./run.sh
unset OMNIAKEY_API_KEY

On Windows PowerShell:

$secureKey = Read-Host 'OmniaKey API key' -AsSecureString
$env:OMNIAKEY_API_KEY = [System.Net.NetworkCredential]::new('', $secureKey).Password
.\run.ps1
Remove-Item Env:OMNIAKEY_API_KEY
$secureKey = $null

The default run tests basic Responses output on Sol, Terra, and Luna, then streaming, function-call emission, and Codex end to end on Sol. That is five fixed direct generations plus one isolated Codex turn when Codex is installed. API usage can be billed even though the kit is free.

Use --full to repeat the deeper checks on all three models. That makes nine direct generations and three Codex turns. Direct API retries and both Codex provider retry limits are zero; the kit does not try to manufacture a 429. If a model ignores the fixed no-tool instruction and starts a tool loop, a Codex turn can make another model request and the report marks it as failed:

./run.sh --full

To test one model without invoking Codex:

./run.sh --model gpt-5.6-terra --skip-codex

The key is accepted only through an environment variable and is never a command-line argument. The silent input commands above keep its literal value out of shell history; like any process environment variable, it can still be inspected by local processes with sufficient permission while it is set. Before writing the report, the script redacts the exact key plus common Bearer and sk-... forms from every provider-controlled string field.

What the report records

Every report includes the kit version, UTC timestamp, endpoint origin and base path, operating system, architecture, Node and Codex versions, selected models, both timeout values, and the explicit zero-retry limits. Depending on the layer and outcome, applicable check fields include:

• requested and reported model IDs;
• pass, fail, or skip status;
• HTTP status and allowlisted response headers for request IDs and rate limits;
• response ID and token usage when the endpoint returns them;
• elapsed time and the precise failed contract or skip reason;
• a normalized error category without the API key or raw response body.

The output file is created with owner-only permissions on POSIX systems. Request IDs are not credentials, but review the report before sharing it because they can help a provider trace a request.

Exit code 0 means every executed check passed. 1 means at least one executed check failed. 2 means the arguments, key environment, URL, or another prerequisite was invalid. A missing Codex installation is reported as skip, not disguised as an API failure.

The verified GPT-5.6 facts

OpenAI currently documents these exact API IDs and roles:

The gpt-5.6 alias currently routes to gpt-5.6-sol. For diagnostics, use the explicit IDs: an alias adds a routing question that the compatibility test does not need.

The three current model pages all list a 1,050,000-token API context window, 922,000 maximum input, 128,000 maximum output, and a 2026-02-16 knowledge cutoff. They also list Responses, Chat Completions, and Batch support, plus streaming, structured outputs, and function calling. See the primary pages for Sol, Terra, and Luna.

Those are API model limits, not a promise that every Codex client configuration exposes the full window. Codex has its own model catalog, model_context_window, and automatic compaction behavior. This kit does not send a million-token prompt or infer an effective Codex window from the API headline.

A minimal Codex provider configuration

Current Codex configuration uses a user-level ~/.codex/config.toml for custom providers. The current configuration reference lists responses as the supported wire_api value. A minimal OmniaKey example is:

model = "gpt-5.6-sol"
model_provider = "omniakey"

[model_providers.omniakey]
name = "OmniaKey"
base_url = "https://api.omniakey.com/v1"
env_key = "OMNIAKEY_API_KEY"
wire_api = "responses"

env_key and requires_openai_auth are alternative authentication modes. Current Codex authentication documentation says that requires_openai_auth = true makes Codex ignore env_key; do not add it to this provider block.

Back up a real config before editing it:

cp ~/.codex/config.toml ~/.codex/config.toml.before-gpt56

PowerShell equivalent:

Copy-Item "$HOME\.codex\config.toml" "$HOME\.codex\config.toml.before-gpt56"

The compatibility checker does not require you to edit that file or use its provider settings. Its Codex smoke test ignores user configuration, creates a temporary CODEX_HOME, passes the provider settings only to that process, uses an empty working directory and read-only sandbox, then removes the directory. It passes only the key plus an allowlist of runtime, locale, temporary-directory, proxy, and TLS environment variables; the report records their names, never their values.

Read-only sandboxing prevents writes, not every possible read. The fixed no-tool prompt is checked, but it is not a hard security boundary. Use --skip-codex or run the kit inside an isolated container or VM if the machine has files that the Codex process must not be able to read.

See the Codex configuration reference and the OmniaKey coding-agent guide before making permanent changes. For the product decision rather than troubleshooting, read the Claude Code vs Codex comparison.

If Codex is already chosen and the decision is Sol, Terra, or Luna, use the GPT-5.6 model guide for Codex.

For the broader family facts and official API pricing, see the GPT-5.6 review; this kit remains focused on compatibility troubleshooting.

Read failures by layer, not by guesswork

Do not collapse 401 and 403 into the same diagnosis. A 401 normally points to authentication; a 403 can mean that a valid identity lacks permission. Likewise, a 404 can be a wrong /v1 base path or a valid path with an unavailable model.

OpenAI's error guide recommends checking request shape for bad requests, pacing calls for rate limits, and briefly retrying server errors. This kit intentionally leaves retries to you so the first failure remains visible.

The current custom-provider trap

Two open Codex reports, #31870 and #31882, document GPT-5.6 failures through Azure/custom providers on Codex 0.144.x. In the reported cases, direct Responses calls succeeded while Codex requests failed with 400 errors mentioning X-OpenAI-Internal-Codex-Responses-Lite or the reserved collaboration namespace.

These issues are field reports, not proof that every custom provider fails. They are exactly why the kit runs direct and Codex layers separately.

If your report shows that split:

1. Record codex_version, the exact error category, and request ID.
2. Upgrade to the latest stable Codex release and rerun the same kit version.
3. Check whether the two issues are still open and whether a maintainer has published a fix.
4. Send the sanitized report to your provider or Codex support if the failure persists.

Issue #31882 describes a full model-catalog override that disables Responses-Lite and multi-agent metadata. It is brittle: the override replaces catalog metadata, can drift after an upgrade, and may disable behavior you rely on. Version 1.0.0 of this kit detects the reported failure signatures but deliberately does not patch Codex or recommend a silent downgrade.

What this kit does not measure

This is a compatibility probe, not a model-quality benchmark. It does not compare coding accuracy, long-context behavior, cache hit rate, production latency, progressive SSE flush timing, billed price, image input, hosted tools, multi-agent work, or a complete function-call continuation loop. A green report means the tested contracts worked once with the recorded versions and endpoint. It does not predict every workload or provide process-level filesystem isolation.

For reproducibility, keep the generated report and the exact kit files. Verify downloads with SHA256SUMS, rerun after a Codex or provider change, and compare individual checks rather than only the final status.

Frequently asked questions

Why does Codex say model metadata was not found?

Codex could not match the selected model to catalog metadata and fell back to generic values. Check whether a direct Responses request works before changing credentials. If only Codex fails, record the Codex version and run the isolated CLI check.

Why do I get model not found or a 404 for GPT-5.6 Sol?

Confirm that the base URL ends in /v1, then inspect GET /v1/models for the exact lowercase ID gpt-5.6-sol. A valid key does not guarantee access to every model.

Why is GPT-5.6 not available with my ChatGPT Codex login?

ChatGPT-authenticated Codex and an API key through a custom provider are separate access paths. Availability in one does not prove availability in the other.

Should I retry an all-credentials-cooling-down error?

Follow the provider's retry or reset signal. Repeated immediate retries do not fix an exhausted credential pool and can add more load.

When should I run the compatibility kit?

Run it when the message alone does not identify whether model access, the Responses API, or Codex is failing. Keep the sanitized report when you need provider or Codex support.

Sources checked

• Using GPT-5.6
• GPT-5.6 models in Codex
• GPT-5.6 Sol model page
• GPT-5.6 Terra model page
• GPT-5.6 Luna model page
• Codex configuration reference
• Codex authentication for alternative providers
• OpenAI API error guide
• Codex issue #31870 and #31882, both open when checked