SSC-STUDIO / Ai-Model-Gateway

Codex CLI Gateway

Route Codex CLI and OpenAI-compatible coding-agent traffic through one self-hosted gateway with provider fallback, telemetry, request logs, config publishing, and rollback.

If this fits your Codex routing workflow, star the repository after evaluation so other operators can find it.

Codex entry point

Use AI Model Gateway where Codex expects an OpenAI-compatible endpoint.

AI Model Gateway keeps upstream provider keys in local gateway config. Codex uses a gateway client key and sends OpenAI-compatible requests to the data-plane listener.

Codex config

Set openai_base_url in ~/.codex/config.toml to the gateway origin plus /v1.

Gateway auth

Use a gateway client key for Codex instead of copying upstream provider keys into local tool config.

OpenAI-compatible route

Route chat-style traffic through /v1/chat/completions and related OpenAI-compatible entry points.

Operations layer

Keep fallback, telemetry, request logs, provider health, and rollback in one self-hosted runtime.

Local setup

Point Codex at one self-hosted OpenAI-compatible gateway.

For a default local runtime, use the gateway origin plus /v1. Start with one non-production request, then inspect logs, telemetry, and provider health before routing real work.

openai_base_url = "http://127.0.0.1:18080/v1"
openai_api_key = "$GATEWAY_API_KEY"
Open Codex setup details
AI Model Gateway overview workspace after routing Codex CLI traffic

Scope

Evaluate the exact Codex workflow before relying on it.

The gateway supports OpenAI-compatible client traffic and local operations workflows around routing, fallback, telemetry, and config publishing. It does not claim to replace every OpenAI platform feature, hosted model marketplace, or Codex account workflow.

Good fit

  • You want Codex CLI to enter a local OpenAI-compatible gateway.
  • You need provider fallback and route telemetry for coding-agent traffic.
  • You want provider keys, routing policy, logs, and audit records to stay local.
  • You need preview, diff, publish history, and rollback for gateway config.

Check first

  • Your workflow depends on a hosted account feature outside OpenAI-compatible API traffic.
  • Your client requires exact streaming, tool, or multimodal behavior from a specific upstream.
  • You need a hosted model marketplace to own provider billing and access.
  • You only need a thin wrapper without admin, telemetry, or rollback workflows.

Config workflow

Use generated snippets or dry-run local Codex updates.

The CLI can print client snippets or apply supported config updates for local tools. Use dry-run mode first and keep backups enabled unless another system already owns those files.

  1. Start runtime. Use the release archive, Docker Compose path, or source build.
  2. Print snippets. Run aigw clients print and inspect the Codex config values.
  3. Dry run. Use aigw clients apply -tools codex -dry-run before changing local files.
  4. Smoke test. Send one request and inspect request logs, provider health, and telemetry.

Review evidence

Check installability, quality, and security before adopting it.

Release archive install

Try the packaged v1.4.4 runtime with checksum verification, local config, runtime directories, and supervised startup commands.

Open release install path

Quality evidence

Review CI gates, local reproduction commands, runtime smoke checks, feature proof points, and current capability boundaries.

Open quality evidence

Security and trust model

Inspect admin auth, same-origin browser writes, provider-key handling, SSRF defenses, telemetry sensitivity, and update trust.

Open security model

Next step

Route one Codex request, then decide whether the gateway earns a star.

Use a local gateway and non-production request first. If the project fits your self-hosted coding-agent routing workflow, starring the repository helps similar teams find it.