Shift Log: Codex CLI on a Relay365 Base URL

Codex CLI is local; its model endpoint can change

Codex CLI runs in your terminal and works with files, commands, and a remote model. The terminal application and the model service are separate parts of the setup. A base URL tells the application where to send its model requests.

Pointing Codex at an OpenAI-compatible service changes that destination. It does not move your repository to another terminal or replace Codex with a different coding tool. You still control the local working directory and permission settings, while the configured service handles model requests.

Relay365 fits this arrangement as a pay-as-you-go relay desk for multiple model families. Its API base is https://api.api365relay.com. For an OpenAI-compatible client configuration, the base URL includes the version prefix: https://api.api365relay.com/v1.

The base URL is only one part of the connection

Three settings need to agree: the endpoint, the credential, and the model identifier. The endpoint selects the service. The credential authorizes requests there. The model identifier asks that service for a particular model.

Use a Relay365 API key for the Relay365 endpoint. An existing login for another provider should not be assumed to authorize requests through the relay. Likewise, use the exact API model identifier published by the relay, rather than guessing it from a display name.

For example, if you want to use GPT-6.1 Sol, first check its current identifier and whether Relay365 exposes it through the API features Codex requires. A model appearing in a catalog does not, by itself, establish compatibility with a coding agent.

Configure a named provider in Codex

Codex supports custom providers through its configuration file, normally ~/.codex/config.toml. Check the documentation for your installed Codex version before editing, and preserve any existing settings you still need.

A custom-provider configuration makes the routing explicit. The relevant entries are:

• Set the top-level model_provider value to "relay365" so Codex selects your custom provider.
• Set the top-level model value to the exact supported model identifier supplied by Relay365.
• Create a TOML table named [model_providers.relay365] and give its name field a readable value such as "Relay365".
• Inside that table, set base_url to "https://api.api365relay.com/v1" and env_key to "RELAY365_API_KEY".
• Set wire_api to "responses", and confirm that the relay supports the Responses API behavior needed by your Codex version and selected model.

The env_key setting names an environment variable; it does not contain the secret itself. Set RELAY365_API_KEY in the environment that launches Codex. Keep the key out of repository files, committed configuration, screenshots, and shared terminal output.

TOML placement matters: top-level settings belong before provider tables unless you deliberately use another supported configuration structure. Avoid defining the same provider twice while experimenting.

Check Responses support before testing repository work

OpenAI-compatible does not mean every OpenAI API feature is implemented. A service may accept chat requests from an SDK while lacking the Responses API, streaming events, or tool interactions expected by Codex. A successful request from another client is useful evidence, but not a complete Codex compatibility test.

Start Codex in a disposable directory and ask for a short text response. Next, test a small file-reading task and an explicitly approved edit. This separates basic authentication and routing problems from failures involving tools or longer agent workflows.

• If authentication fails, check that the environment variable is available to the Codex process and contains a valid relay key.
• If the endpoint is not found, check the /v1 prefix and the requested API route.
• If the model is rejected, verify its exact identifier and account access.
• If streaming or tool use fails, investigate protocol support before changing the task prompt.

Keep the relay choice operationally deliberate

Relay365 is worth considering when you want pay-as-you-go access to several model families through a shared service. It also works with Claude Code, Gemini CLI, and OpenAI SDK clients, although each client still needs its own correct configuration.

Before using it with private code, review data handling, available spending controls, and which repository content Codex may send. Local approval settings do not replace checking the remote service’s policies.

Create a Relay365 account when you are ready to verify model access and run a small compatibility test. Once authentication, Responses support, and a basic edit work together, move to a real repository with a limited task and review the resulting diff.