Codex Through a Relay vs Official: Features, Pricing and Data Compared

Wokey Team · 2026-09-24

Short answer: using Codex through a relay means running Codex in custom-provider mode. Everything that happens on your machine works exactly as before: writing code, running commands, editing files. The differences come down to three things:

• Cloud features that need a ChatGPT account are unavailable.
• Features that depend on OpenAI's servers are reduced. These include context compaction, the usage limits in /status and Fast mode.
• Billing changes from subscription allowances to pay-per-token.

Each difference is covered below. Codex behaviour comes from its source code and official docs, and Wokey behaviour from the gateway code.

Three ways to connect Codex

A relay is the third mode. The first two talk to OpenAI's own services; in the third, a gateway you choose receives the requests. For setup, see the Codex config.toml guide.

What stays exactly the same

Most of Codex runs on your own machine, so these don't depend on the model provider:

• Reading and writing files, running commands, editing code with apply_patch
• Sandboxing and approval modes
• AGENTS.md, MCP servers and local Skills
• Session history and codex resume
• IDE extensions and non-interactive codex exec

So for writing code, how a relay compares with the official service depends mostly on which model you use and whether it runs natively on the Responses API, not on whether the service is official.

Features that need a ChatGPT account

These run in OpenAI's cloud and require a ChatGPT sign-in:

• Codex cloud (cloud tasks). With an API key or a custom provider, codex cloud says:

  Not signed in. Please run 'codex login' to sign in with ChatGPT, then re-run 'codex cloud'.
  

• @codex in GitHub and automatic GitHub code review

• Slack and Linear integrations

• Voice input, Connectors and plugin sharing

• Remote control from your phone

If you mostly use Codex in a terminal or IDE to write code, none of this matters. If you rely on cloud tasks or GitHub integration, you need a ChatGPT account.

What changes with a custom provider

Compaction happens locally. With a ChatGPT sign-in, OpenAI's servers compact the context when it fills up. With a custom provider, Codex writes the summary locally using your current model. The feature still works; summary quality depends on the model.

No image generation. The image generation tool isn't offered with a custom provider.

No usage limits in /status. The 5-hour and weekly limits in /status come from x-codex-* usage headers on OpenAI's responses. A relay doesn't report ChatGPT plan usage, so that section shows as unavailable. Check usage and balance in the relay's dashboard instead.

No Fast mode. Fast mode requires a ChatGPT account.

HTTPS streaming only. With a custom provider, Codex doesn't use WebSockets. Requests are plain HTTPS with SSE.

Web search depends on the gateway and model. Codex still sends the web_search tool to a custom provider; whether it works depends on the gateway and the upstream. On Wokey, models with native Responses support pass the tool through to the upstream unchanged, and models translated to Chat Completions drop it.

Model metadata. Codex ships with context lengths, reasoning levels and other details for official models. If the model name isn't in its built-in list, you see:

Model metadata for `{slug}` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.

Codex then runs on fallback values:

• A 272k context, with auto-compaction at about 244,800 tokens.
• No apply_patch tool, so file edits fall back to shell commands, which is noticeably less efficient.

Codex matches this metadata by model name, so on a relay prefer names identical to OpenAI's official ones, such as gpt-6-sol. Third-party models such as Grok and DeepSeek aren't in the built-in list and trigger the warning. For those, set model_context_window and model_reasoning_effort in config.toml, or supply full model details with model_catalog_json.

Retries and errors

A relay and the official service share the same retry logic:

• Failed requests are retried up to 4 times (request_max_retries).
• Dropped streams reconnect up to 5 times (stream_max_retries).
• The stream idle timeout is 5 minutes (stream_idle_timeout_ms).

The exception is 429. By default Codex does not retry a 429, and rate limiting ends with:

exceeded retry limit, last status: 429 Too Many Requests

A good relay retries on another route when the upstream is rate-limited or overloaded, before deciding to return an error. Wokey does this, so at busy times clients usually see fewer 429s and 529s.

Other errors show as unexpected status … followed by the gateway's JSON. For troubleshooting, see the 529 error guide and the timeout guide.

Comparing prices

An official subscription is a fixed monthly fee for an allowance. Plus is $20 a month, Pro starts at $100 a month, and there are Go, Business and other tiers. The allowance is counted over 5-hour and weekly windows; when it runs out, you wait for the window to reset. Check OpenAI's site for current prices and limits.

A relay charges per token, with no windows: you pay for what you use. As a rough guide:

• Steady, heavy daily use, and the limits are acceptable: an official subscription is usually better value.
• Uneven usage, frequent 5-hour limits, or switching between GPT, Grok, DeepSeek and other models in the same Codex: a pay-as-you-go relay fits better.

Wokey's prices are on each model page, for example GPT-6 Sol.

Data and trust

With the official service, OpenAI handles your data according to your account settings. With an API key, your API organization's data retention settings apply.

With a relay, requests pass through the relay before reaching the upstream. So there are two questions to ask of any relay: does it swap the model, and does it alter the content?

Most relays can only ask you to trust them. Every Wokey response carries a cryptographic proof you can check offline on your own machine:

• The code fingerprint matches the publicly audited source.
• The response signature comes from an AWS Nitro hardware enclave, and nothing was altered.

See Verifiable AI API. For how Wokey sources upstream capacity, see this post.

Using both

Your official account and a relay can live side by side on one machine, without editing config back and forth:

1. Keep ~/.codex/config.toml on the official setup and sign in with ChatGPT.

2. Put the Wokey provider in its own ~/.codex/wokey.config.toml:

   model = "gpt-6-sol"
   model_provider = "wokey"
   
   [model_providers.wokey]
   name = "Wokey"
   base_url = "https://api.wokey.ai"
   env_key = "WOKEY_API_KEY"
   wire_api = "responses"
   

3. Run codex to use your official allowance. When it runs out, or you want another model, run codex --profile wokey.

Don't set requires_openai_auth = true in the Wokey provider. That option makes Codex use your ChatGPT sign-in and ignore env_key, so requests go out without your Wokey key.