# What Works with Codex Hosted (and What Doesn't)

If a tool accepts an OpenAI base URL, it works with Codex Hosted. The caveats, honestly: complete responses, Codex's model surface, and what stays on your API key.

*Published 2026-06-12 · https://proxyllm.ai/blog/codex-hosted-for-openai-compatible-apps*

Compatibility with Codex Hosted comes down to one rule: if a tool lets you set an OpenAI base URL, it works, because the endpoint speaks the standard OpenAI request and response shape. The honest caveats are three. The Codex lane returns complete responses rather than streams, the model list is whatever Codex currently serves, and API-platform features like embeddings and fine-tunes stay on your own key.

This page is the capability map: what runs, what runs with a caveat, and what should not move at all. If you want the feature definition first, [what is Codex Hosted?](/blog/what-is-codex-hosted) covers it in two minutes.

## The one-line compatibility test

If a tool accepts an OpenAI base URL and can wait for a complete response, it can run on a ChatGPT subscription. The swap is two values:

```bash
export OPENAI_BASE_URL="https://api.proxyllm.ai/v1"
export OPENAI_API_KEY="pllm_your_key_here"
```

Everything downstream of those variables, request format, response parsing, error handling, behaves like the OpenAI API it was written for. The five-minute walkthrough is in [the setup guide](/blog/codex-hosted-setup-guide).

## The capability table

| Capability                               | On the Codex lane                   | Where it runs instead       |
| ---------------------------------------- | ----------------------------------- | --------------------------- |
| `/v1/chat/completions`                   | Yes, standard payloads              | n/a                         |
| Official OpenAI SDKs (Python, Node)      | Yes, base URL swap                  | n/a                         |
| Automation platforms (n8n, Make, Zapier) | Yes, custom base URL or HTTP module | n/a                         |
| Agent frameworks (LangChain, LlamaIndex) | Yes                                 | n/a                         |
| Plain curl and HTTP clients              | Yes                                 | n/a                         |
| Streaming (`stream: true`)               | No, complete responses only         | API-key lane, which streams |
| Full API model catalog                   | No, Codex's model surface           | Your OpenAI key             |
| Embeddings                               | No                                  | Your OpenAI key             |
| Fine-tuning                              | No                                  | Your OpenAI key             |
| Parameters outside Codex's surface       | No                                  | Your OpenAI key             |

The left column is where the flat-plan economics live. The right column is why a good setup keeps a key configured even when the subscription does the bulk work.

## Complete responses, not streams

The Codex lane returns the whole response at once. We say this everywhere because it is the one behavioral difference your code can observe, and pretending otherwise would cost you a debugging afternoon.

Most programmatic workloads never notice. Cron jobs, agents, pipelines, document processing, CI checks, and webhook handlers all consume the finished text; a stream would be buffered into a string anyway. What notices is a human watching a screen: a chat interface that renders tokens as they arrive will feel broken waiting on a complete payload.

The split that works in practice: bulk and background traffic on the Codex lane, interactive chat on an API-key lane. Both lanes live behind the same endpoint, and the request log shows which lane served each call.

## The model surface

The endpoint serves what Codex serves. OpenAI decides that set and rotates it as models ship, so we refuse to hardcode a list that would be stale by autumn. Ask the endpoint instead:

```bash
curl -s "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY"
```

If your workload depends on a specific API-only model, a tuned snapshot, or sampling parameters Codex does not expose, that traffic belongs on your key. Raw request and response anatomy, including error shapes, is covered in [the curl walkthrough](/blog/curl-openai-compatible-api).

## What stays on your API key

Three categories, stated plainly so nothing surprises you in production:

1. **Embeddings and fine-tunes.** API-platform features with no Codex equivalent.
2. **Streaming interfaces.** Anything where perceived latency is the product.
3. **Catalog and parameter edge cases.** Models or options outside what Codex serves.

Your key can route through ProxyLLM as a passthrough lane with no markup, which keeps every request, flat or metered, in one log. That is also the fallback path when plan windows are exhausted.

## App-by-app guidance

**SDK codebases** change two constructor arguments and are done. **Automation platforms** point their OpenAI credential's base URL field, or an HTTP module, at the endpoint; the n8n version is worked through in [using your ChatGPT subscription in n8n](/blog/use-chatgpt-subscription-with-n8n). **Agent frameworks** configure a custom endpoint once and inherit it everywhere, which matters because agent loops are where per-token billing hurts most. **Chat products** should split traffic as described above rather than forcing one lane to do both jobs.

Tool-specific configuration pages live in [integrations](/integrations).

The capability map is honest because the economics survive honesty: the workloads that fit the Codex lane are exactly the high-volume programmatic ones that make per-token bills painful. If that sounds like your bill, the [calculator](/calculator) prices the move in thirty seconds.