Codex CLI: your own key instead of a subscription

Codex isn't an editor autocomplete — it's an autonomous executor. You describe the task in words, and it decides on its own which files to read, which commands to run, and what to change. It has about a dozen tools at its disposal: running commands, reading files, maintaining a work plan, asking the user for clarification, and spawning child agents for subtasks.

Two modes of operation. Interactive — codex with no arguments, a terminal dialogue showing every step. Non-interactive — codex exec "task", a one-off run to completion: handy in scripts and CI.

Safety is built in: by default the agent runs in a sandbox and asks for confirmation before making changes. The level of control is set in the configuration — from "ask about everything" to a fully autonomous run with write access to the working directory.

Another distinguishing feature is conversation state. Codex doesn't ask the server to remember anything: it keeps the entire thread locally and sends it in full with every turn. For you, that means the conversation doesn't linger on the model provider's side, and changing the endpoint doesn't break an ongoing session.

The difference from Claude Code and other terminal agents is precisely the protocol. Codex talks to the model via the Responses API, where the conversation is described not as a flat list of messages but as a stream of items: text, tool call, tool result, reasoning block. For the tool, this yields a stricter dialogue model; for you, it means you need an endpoint that understands this protocol.

The fast path — the installer. The command npx @joingonka/setup --tool codex writes a provider block into ~/.codex/config.toml with wire_api = "responses", the model and its real context window, preserving your comments and other settings, and then verifies the key and model with a live request. If another provider is already selected in the config, the installer won't touch it and will suggest a command for a one-off run. It puts the key directly in the file (permissions 600), in the experimental_bearer_token field — the only one where Codex can store a key as a literal; Codex itself considers it experimental. The manual option below gets by with an environment variable.

Codex stores settings in ~/.codex/config.toml. A custom provider is described by a [model_providers.*] block, and the key field here is wire_api: without it Codex will try to speak Chat Completions and won't complete the agentic loop.

# ~/.codex/config.toml
model_provider = "joingonka"
model = "deepseek-ai/DeepSeek-V4-Flash-0731"

[model_providers.joingonka]
name = "JoinGonka Gateway"
base_url = "https://gate.joingonka.ai/v1"
env_key = "JOINGONKA_API_KEY"
wire_api = "responses"

The key isn't written to the file: env_key names the environment variable Codex will take it from. The variable name is your own, not OPENAI_API_KEY — that way the setup doesn't intercept your other tools working with OpenAI.

export JOINGONKA_API_KEY=jg-your-key

The model field sets the default model, and model_provider — which of the described blocks to use. Both are overridden at launch time, so a single config can comfortably serve several providers: work, experimental and backup.

The key is issued in your account dashboard after registration, where you can also see your balance and spend. If you'd rather not touch the shared config, the same block can be passed one-off via -c: codex -c model_provider=joingonka …. And to keep several independent configurations, point the settings directory with the CODEX_HOME variable.

The quickest way to confirm the integration works is a one-off run:

codex exec "Answer in one line: what is 17*3?"

At the top of its reply, Codex prints who it is working with: the model, provider: joingonka, the sandbox mode and the session ID. If it shows your provider and an answer comes back at the bottom, the connection is live.

Next, check the thing Codex is really installed for — working with files. Drop a small file with an obvious bug into the directory and ask it to find the bug:

codex exec "Read calc.py and tell me in one sentence whether it has a bug."

The agent should call the read tool on its own, open the file and give a substantive answer, line number included. If that happens, the full agent loop (request → tool call → result → answer) is routing correctly through the gateway.

If something goes wrong, the diagnosis is usually right there in the message:

The first request in a session can take a few seconds: Codex sends a large system prompt plus a description of all its tools, and the network node has to accept the task. Subsequent replies come faster.

All network models are available at the same price, so the choice is about behavior, not budget. Below is the result of a live run of the same task (reading a file and finding an error in it) through Codex on DeepSeek V4 Flash and MiniMax M2.7; GLM-5.3 Flash joined the network after the run—its model properties are provided.

The default recommendation is DeepSeek V4 Flash: agent work quickly hits context limits, and 380K tokens allow holding many files in memory at once. If the task requires thinking through complex logic, use GLM-5.3 Flash, but set aside a buffer for max_tokens: part of the response budget goes to reasoning. The model can be changed with a single model line in the config or the -c model=… flag without editing the file.

The current list of network models is always available via GET https://gate.joingonka.ai/v1/models.

Agent tools consume tokens differently than chat: for each of your phrases, Codex adds a system prompt and a description of all tools, then carries out a multi-step dialog with the model. In a live run, a simple task like "read a file and find an error" cost about 18-20 thousand tokens. This is a normal price to pay for autonomy, which is exactly why the price per token matters.

Via JoinGonka Gateway, tokens cost $0.0069 per million input and $0.021 per million output—the price is identical for all network models and is fetched on this page from a live source.

For comparison, here is how paid options are structured at Codex itself and among competitors:

Payment is for actual consumption, without a monthly subscription or request quotas: no five-hour windows, "prompt" limits, or peak-hour multipliers. The balance is topped up with crypto; the remainder and daily usage are visible in the personal dashboard. A detailed breakdown of the economics is in the article about the cheapest AI API.

Codex itself maintains the conversation history. It sends the entire history with every request and does not ask the server to remember anything — and we do not store chat logs. Your code and prompts do not remain on the gateway after a response is provided.

Web search is active. Codex declares a search tool in every request, and the gateway accepts it: the search is performed on our side, and the results are injected into the model's response.

Tools are local, not cloud-based. Codex executes commands and reads files locally on your machine, so access to your project does not depend on the model provider.

Sandbox. On Linux, Codex uses bubblewrap to isolate executed commands. If it is not on your system, Codex will warn you and use a built-in copy — this does not affect performance, but installing the package via your standard package manager is more convenient.

If you need image processing — interface screenshots, diagrams in photos — use a tool with a vision-capable model for such tasks: models in the Gonka network are text-only. This is not a limitation for code, commands, and files.

Other terminal agents, if Codex was not the right fit: the API quickstart shows how to connect any compatible tool in a couple of minutes.