Codex CLI: your own key instead of a subscription

Codex is not just an editor suggestion tool, but an independent executor. You state the task in words, and it decides for itself which files to read, which commands to execute, and what to change. It has about a dozen tools at its disposal: running commands, reading files, maintaining a work plan, requesting clarification from the user, and spawning child agents for subtasks.

Two modes of operation. Interactive — codex without arguments, a dialogue in the terminal showing every step. Non-interactive — codex exec "task", a one-time run until completion: convenient in scripts and CI.

Security 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 everything" to a fully autonomous run with write access to the working directory.

Another feature is the dialogue state. Codex does not ask the server to remember anything: it keeps the entire feed itself and sends it back in its entirety with every turn. For you, this means that the correspondence does not settle on the model provider's side, and changing the endpoint does not break an ongoing session.

The difference from Claude Code and other terminal agents is precisely the protocol. Codex communicates with the model via Responses API, where the correspondence is not described as a flat list of messages, but a feed of elements: text, tool call, call result, reasoning block. For a tool, this provides a stricter dialogue model, and for you, it necessitates an endpoint that understands this protocol.

Codex stores settings in ~/.codex/config.toml. Your 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 be able to assemble 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 is not written to the file: env_key names the environment variable from which Codex will take it. The variable name is unique, not OPENAI_API_KEY — so this setting does not intercept your other tools working with OpenAI.

export JOINGONKA_API_KEY=jg-your-key

The model field sets the default model, and model_provider sets which of the described blocks to use. Both can be overridden at launch time, so one config easily serves several providers: production, experimental, and backup.

The key is issued in the personal cabinet after registration, where balance and usage can also be viewed. If you prefer not to touch the global config, the same block can be passed once via -c: codex -c model_provider=joingonka …. And to keep several independent configurations, specify the settings directory via the CODEX_HOME variable.

The fastest way to ensure the pipeline works is a one-off test run:

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

In the response header, Codex prints who it is working with: model, provider: joingonka, sandbox mode, and session ID. If your provider is there and an answer arrives at the bottom, the connection is live.

Next, you should test the main thing Codex is installed for—working with files. Place a small file with an obvious error in the directory and ask it to find it:

codex exec "Read calc.py and say in one sentence if there is an error."

The agent should automatically call the read tool, open the file, and answer substantively—indicating the line number. If this happens, the full agent loop (request → tool call → result → answer) is correctly assembled through the gateway.

If something goes wrong, the diagnosis is usually readable directly from the message:

The first request in a session may take several seconds: Codex sends a large system prompt and a description of all its tools, and the network node needs to accept the task. Subsequent responses arrive faster.

All network models are available at a single 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) via Codex on each model.

The default recommendation is DeepSeek V4 Flash: agent work quickly runs into context limits, and 380K tokens allow holding many files in memory at once. If you want extremely short responses, take Kimi K2.6. The model can be changed with one line model in the config or the flag -c model=… without editing the file.

The current list of network models is always available at 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.0047 per million input and $0.014 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.