A Model List Does Not Prove a Codex Relay Supports the Responses API

AI Relay Check — Fri, 02 Oct 2026 16:40:22 +0000

An OpenAI-compatible /v1/models response is useful discovery evidence, but it
does not prove that the same key can complete a Codex workflow. Model discovery,
Chat Completions, the Responses API, streaming, tool calls, and client-specific
gateways may use different routes or permissions.

AI Relay Check therefore records compatibility as a specific combination of:

provider;
model ID;
recorded protocol;
test key and route;
timestamp;
generation outcome.

Current evidence scope

The current public Codex guide contains GPT-family samples from six paid test
accounts. Three providers have samples recorded with the Responses protocol.
Across those Responses-labeled records, 50 of 64 requests completed
successfully. The latest included GPT sample is dated October 1, 2026.

These figures are dated test samples. They are not uptime percentages and do not
prove that every Codex client feature or route group works.

Five checks before choosing a Codex relay

1. Confirm the exact base URL

Use the HTTPS base URL assigned to the tested product and route group. A
provider may expose different endpoints for a general OpenAI-compatible API,
Codex-only keys, subscriptions, and pooled routes.

2. Test the generation endpoint

Determine whether the route uses /v1/responses,
/v1/chat/completions, or a client-specific gateway. A model-list request can
pass while the required generation endpoint returns 400, 404, 429, or 503.

3. Fix the model ID and key group

Run the exact model needed by the project and record the group assigned to the
test key. A successful request from one group should not be attributed to a
different provider-published price group.

4. Verify streaming and tools separately

A basic text response does not establish streaming, tool calls, structured
output, or the complete Codex client workflow. Test the features the application
actually depends on.

5. Keep compatibility and billing separate

Preserve returned token fields and compare a controlled request with the
provider's account meter or wallet. A successful response does not prove that
the published input, output, cache, or subscription rate was applied.

Public evidence

Conclusion

The right question is not whether a relay lists a GPT model. The useful question
is whether the exact model, key group, generation endpoint, and required Codex
features completed under recorded conditions. Billing and model identity still
require separate evidence.

Disclosure: AI Relay Check has referral relationships with some tested
providers. Referral status is excluded from request outcomes and ranking
weights. Unverified model identity, route provenance, and billing remain
explicitly labeled.

A Relay Website Can Be Online While Its AI API Still Returns 400, 404, 429, or 503

AI Relay Check — Tue, 29 Sep 2026 08:34:21 +0000

Opening an AI API relay provider's website proves only that its web entry point is reachable. It does not prove that a specific model, route, and protocol can complete an API request.

At AI Relay Check, every result is scoped to a provider + model + protocol + timestamp. This keeps one failed model from being misreported as a provider-wide outage.

Current evidence scope

The public dataset currently contains 231 privacy-reviewed API samples: 168 passed and 63 failed. Failure sequences grouped by the same provider, model, and protocol form 13 observed failure episodes. The dataset includes HTTP 400, 404, 503, and timeout samples.

These are dated observations, not a guarantee of future behavior and not evidence about routes that were not tested.

Four checks that should not be collapsed into one score

Evidence	What it establishes	What it does not establish
Website or console responds	The web service was reachable	A target model can generate
Model ID appears in `/v1/models`	The key can see that model ID	Generation permission, identity, or stability
Minimal generation request passes	That key, route, protocol, and model worked at that time	Long-term reliability or billing accuracy
Account meter or ledger changes	The tested request produced an observed account charge	Pricing on other routes or subscription plans

HTTP 400: request or compatibility mismatch

A 400 response may mean that the route rejects the model name, request fields, tool-call format, or another protocol-specific parameter. Start with a minimal request using a fixed model and protocol, then add parameters one at a time.

One 400 sample is not evidence that the entire provider is down.

HTTP 404: not necessarily a missing website

An API can return 404 while the provider homepage still returns 200. Common causes include a wrong endpoint, an unavailable model route, or a protocol path such as /v1/responses that the provider has not implemented.

Record the endpoint, model, and protocol together. Homepage status alone cannot diagnose an API 404.

HTTP 429: rate limit, quota, or account state

A 429 response can indicate request-rate limits, concurrency limits, route quota, or account allowance. The status code alone cannot reliably distinguish temporary throttling from insufficient balance.

Useful evidence includes the account-side usage record, the route's pricing rule, and a later independent retest.

HTTP 503: no usable upstream at that moment

A 503 response often means that the current route had no available upstream or that the gateway was temporarily unavailable. The next successful sample for the same model and protocol is useful recovery evidence.

However, next observed pass is not the exact recovery time. The interval between two tests remains unobserved.

A reproducible failure record

Each record should include:

test timestamp;
provider and route group;
exact model ID;
protocol;
HTTP status and a privacy-reviewed error category;
the next observed pass for the same scope.

Do not publish API keys, account identifiers, full request bodies, raw responses, or collection credentials.

Public evidence

Conclusion

Website uptime, API reachability, model compatibility, and account billing are four different questions. A useful result preserves the conditions under which it was observed and relies on repeated samples, rather than turning one error into a permanent provider-wide verdict.

Disclosure: AI Relay Check has referral relationships with some tested providers. Referral status is excluded from test outcomes. Unverified model identity, cache behavior, pricing, and billing remain explicitly unverified.

DEV Community: AI Relay Check

A Model List Does Not Prove a Codex Relay Supports the Responses API

Current evidence scope

Five checks before choosing a Codex relay

1. Confirm the exact base URL

2. Test the generation endpoint

3. Fix the model ID and key group

4. Verify streaming and tools separately

5. Keep compatibility and billing separate

Public evidence

Conclusion

A Relay Website Can Be Online While Its AI API Still Returns 400, 404, 429, or 503

Current evidence scope

Four checks that should not be collapsed into one score

HTTP 400: request or compatibility mismatch

HTTP 404: not necessarily a missing website

HTTP 429: rate limit, quota, or account state

HTTP 503: no usable upstream at that moment

A reproducible failure record

Public evidence

Conclusion