The page in this thread most worth understanding. By the end, "wiring up a relay" stops being a skill and becomes three knobs — and every later tool in this thread turns the same three.
In this pagethe mechanism, three knobs, what it cannot do, what you hand over, how to verify. No comparison or ranking of relay services — reason in §7. Nothing about what I connect to either.
Claude Code, Codex, and the always-on agents later in this thread all do the same plain thing when calling a model: POST some JSON to an address, wait for JSON back.
Only three things in that request are variable:
Which is all a "relay" is — you changed the first one. The service at that address takes the request, forwards it to a real model, and hands the answer back.
Because the shape of the request is a public protocol, not a private format. Two families are in practical use:
| Family | Who | Note |
|---|---|---|
| OpenAI-style | A great many services advertise "OpenAI compatible" | Internally split into chat-completions and responses — not the same thing, see §4 |
| Anthropic-style | The Claude messages interface | Claude Code speaks this one |
"Compatible" precisely means: it accepts JSON of the same shape and returns JSON of the same shape. The client neither knows nor cares who is on the other end. It checks the shape.
It sounds like a proxy or a workaround. From the client's point of view it is simply a normal API endpoint, protocol-identical to the official one. The only difference is that the service behind it forwards your request somewhere else.
This table is the skeleton of the thread. Every later page that points at an endpoint comes back to it.
| Tool | ① Address | ② Key | ③ Model | Written where |
|---|---|---|---|---|
| Claude Code | ANTHROPIC_BASE_URL | ANTHROPIC_AUTH_TOKEN or ANTHROPIC_API_KEY | ANTHROPIC_MODEL / model | Env, or the env block of settings.json |
| Codex | base_url | env_key (names an env var) | top-level model | ~/.codex/config.toml, [model_providers.X] |
| Hermes | base_url | OPENAI_API_KEY | model | ~/.hermes/config.yaml, key into ~/.hermes/.env |
Three tools, three file formats, one concept. Hermes says it outright: every model slot it has — main, auxiliary, compression, fallback — uses the same three keys. Per-tool mechanics are on the next page.
The OpenAI family splits into chat-completions and responses.
Endpoint supports one, client sends the other, and you rarely get a clean error —
you get strange field errors, empty replies, or tool calling that silently stops working.
Codex exposes this as an explicit wire_api key precisely because the trap is common.
Before pointing at any non-official endpoint, find out which protocol it speaks.
The model name in the response is a string the other end wrote; the client just displays it. "I configured A and the UI says A" proves nothing.
How to check is §6. But note the shape of it: this layer runs on trust, not on protocol.
You now have a relationship with the relay. Your relationship with the original vendor does not vanish or transfer. Quota, terms and liability sit exactly where they sat — changing an endpoint changed none of it.
Important enough for its own section.
An agent request is not one question, it is a pile of context: source files it read, directory structure, error output, your project memory file, everything you typed.
All of that is readable in the clear by the relay. Not a flaw — it is the definition of forwarding. It has to understand the request to forward it.
The right question is: "am I willing for every party on this path to see this?"
A workable split — route by job rather than sending everything down one path:
🟢 open source, public docs, practice code → any path is fine
🟡 your own private projects → think first; at minimum know who you are talking to
🔴 company code, customer data, environments holding keys →
compliance question before technical question
The same test applies to an editor's bring-your-own-key — that route also changes who handles your data.
| Check | How | Watch for |
|---|---|---|
| Does it connect | One minimal request, no tools | A correctly shaped reply. Rule out protocol problems before anything else |
| Does tool calling work | Ask for something requiring a tool (read a file) | Many endpoints chat fine and fail at tool calls — which for an agent means unusable |
| Does long context work | Feed it a large file | Some endpoints truncate or crawl on long context; short requests never reveal it |
The most common useless test. A model's self-report is unreliable by nature — it may be wrong, may name something from training data, may be overridden by a system prompt. Treating it as evidence produces false conclusions in both directions.
The only real approach is capability profiling: run a few tasks you know well where tiers differ visibly, and see whether the behaviour fits. Not proof either — but far better than asking.
This site has a fixed rule: claim no neutrality and you owe no disclosure; the moment a page is about the economics of a business you are in, you must disclose.
A head-to-head is the archetypal neutrality claim. I use one of these paths myself — in that position no ranking comes out clean, whichever way it lands.
So: this page gives mechanism and criteria and lets you rank; the next one gives the mechanics and states plainly which one I use. Facts can be stated. Conclusions are yours.
ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN /
ANTHROPIC_API_KEY, ANTHROPIC_MODEL, settable in the env block of
settings.json. Codex: [model_providers.ID] in ~/.codex/config.toml with
base_url / env_key / wire_api, plus top-level model and
model_provider. Hermes: every model slot uses provider / model /
base_url, with the official note that base_url "points at a custom OpenAI-compatible
endpoint, uses OPENAI_API_KEY for auth". All three vendors' docs, checked 2026-08-21.wire_api takes responses or
chat-completions — direct evidence that "OpenAI compatible" splits internally.