Repo of the day: opencodex, any LLM inside Codex and Claude Code

💡 What opencodex is: an API translator that lives on your machine

opencodex is a local daemon written in TypeScript (runtime Bun, bundled with the npm package: requires only Node 18+) that listens on localhost:10100 and acts as an interpreter: Codex CLI, App and SDK speak their Responses API, the proxy converts it into the protocol of the provider you choose. Five adapters cover Anthropic Messages, Google Gemini, Azure OpenAI, Responses passthrough and any Chat Completions-compatible endpoint: in practice 40+ providers out of the box, including DeepSeek, Groq, OpenRouter, Mistral and local servers like Ollama, vLLM and LM Studio.

The part I find most polished is the «history-safe» injection: on local installation the proxy points Codex's native openai provider to itself with a single line of openai_base_url, so existing threads don't get relabeled and a dirty shutdown leaves no residue. ocx stop restores Codex's original configuration without orphaned processes. Streaming, tool calls, reasoning tokens and images pass in both directions.

repo       lidge-jun/opencodex · licence MIT
stars      ~370 in less than a month (created June 18, 2026)
package    npm install -g @bitkyc08/opencodex · command ocx
port       localhost:10100 · web dashboard with ocx gui
adapter    Anthropic · Google · Azure · Responses · OpenAI-compatible
platforms  macOS · Linux · Windows (launchd / systemd / Task Scheduler)

⚙️ How to install it: three commands and Codex doesn't notice

Installation is the least dramatic part: a global npm package, an interactive ocx init that writes configuration and injects it into Codex, and ocx start to launch the proxy. From that point on you use codex exactly as before — only who responds from the other end changes. For providers the most convenient addition comes via the web dashboard (ocx gui): you pick from 40+ presets or insert a custom endpoint, paste the API key (or do OAuth for Anthropic, xAI and Kimi) and models are auto-discovered from the /v1/models endpoint without restarts.

For autostart there are two routes: the system service (launchd, systemd or Task Scheduler, for the proxy always on) or the shim that wraps the Codex launcher and starts the proxy on-demand at first invocation. Uninstall is symmetric: ocx uninstall stops everything, removes service and shim and brings Codex back to native state.

# 1) install (the Bun runtime comes bundled: only Node 18+ required)
npm install -g @bitkyc08/opencodex

# 2) interactive setup: config, injection into Codex, autostart
ocx init

# 3) start the proxy (auto-fallback if port is occupied)
ocx start

# from here Codex is used normally
codex "Write a hello world in Rust"

🔀 Model routing: provider/model and the proxy does the rest

The core operation is the provider/model syntax: any configured provider becomes reachable with codex -m "anthropic/claude-opus-4-8" or codex -m "google/gemini-3-pro", and without a prefix the proxy routes to the default provider or auto-matches based on name pattern (claude-* → Anthropic, gpt-* → OpenAI). Routed models also appear in the Codex App model picker, with reasoning effort controls per model: from outside they look like native models.

There's also a more ambitious layer: from the dashboard you can «showcase» up to five models in Codex's subagent picker, to delegate the right task to the right model — a reasoning model for complex problems, a budget model for quick tasks. It's the same principle I wrote about discussing multi-agent orchestration: the novelty is seeing it applied to routing between different providers inside a single harness.

# Claude Opus via Anthropic
codex -m "anthropic/claude-opus-4-8" "Explain this stack trace"

# Gemini via Google
codex -m "google/gemini-3-pro" "Write unit tests for auth.ts"

# GLM via Ollama Cloud
codex -m "ollama-cloud/glm-5.2" "Write a SQL migration"

# local model via Ollama: source code never leaves your machine
codex -m "ollama/llama3" "Refactor this function"

🧩 And Claude Code too: same proxy, opposite direction

The feature that made me pick this repo is the Claude Code extension: the same daemon also serves Anthropic Messages API (/v1/messages plus count_tokens), so ocx claude launches Claude Code already wired to the proxy, and routed models appear in its native /model picker as aliases claude-ocx-<provider>--<model>. In other words: Codex can talk to Claude, and Claude Code can talk to Gemini, DeepSeek or a local model, with slots and model maps configurable from the Claude page of the dashboard.

It's an idea I've already encountered in more handcrafted form on the blog with claude-code-router; here the perimeter is wider — two harnesses, five protocols, one dashboard — and the direction is declared in the project's name: «make codex open». For anyone wanting to understand how truly separable a harness is from its model, this repo is the most complete test bench I've seen so far.

🏠 Local models and SMEs: the use case that convinces me most

The use case I'd focus on, especially from an SME perspective, is routing to local models: pointing opencodex to an Ollama, vLLM or LM Studio server on your machine (or on an internal server) means keeping the Codex workflow — planning, tool calls, diffs — while running inference inside the company perimeter. For a software house working on code under NDA, or for projects in regulated sectors, it's the difference between «we can't use agents» and «we can use them with a model that doesn't leave our network».

Configuration is a JSON block in ~/.opencodex/config.json with local baseUrl and empty API key. It's worth being honest about limits: a mid-range local model isn't Claude Opus, and on complex tasks the difference is felt. But for scoped refactoring, tests and boilerplate the tradeoff is often acceptable — and the marginal cost is zero, a theme I'd already touched on talking about token limits and rationing.

{
  "port": 10100,
  "defaultProvider": "ollama",
  "providers": {
    "ollama": {
      "adapter": "openai-chat",
      "baseUrl": "http://localhost:11434/v1",
      "authMode": "key",
      "apiKey": "",
      "defaultModel": "llama3"
    }
  }
}

⚠️ What to know before adopting it: ToS, account pooling and network surface

Here's where it gets serious. The README states without hedging that some providers — Anthropic first and foremost — can suspend or limit accounts that route traffic through third-party proxies: before connecting a provider, read its Terms of Service, and responsibility stays with you («use at your own risk»). This isn't a boilerplate clause: it's the concrete risk of losing an account you use for work. The ChatGPT account pooling feature — multiple Codex accounts with auto-rotation to the least loaded — is technically well done (thread affinity, 429 cooldowns, failover), but it's also the area where I'd be most careful about terms of use.

On the security front the project behaves well: loopback bind by default, and if you expose it on LAN it refuses to start without a bearer token (compared in constant time). Cautions remain from a young project: a single main maintainer, less than a month old, and an experimental Cursor adapter that keeps native execution disabled by default precisely because it would bypass Codex's sandbox and approvals.

• Terms of Service: Anthropic and other providers can suspend accounts passing through third-party proxies; read the ToS before connecting a provider.
• Account pooling: useful for quota telemetry, but it's the most delicate area regarding ChatGPT/Codex terms of use.
• Network exposure: loopback by default; on LAN you need OPENCODEX_API_AUTH_TOKEN and it must be treated as a secret.
• Young project: created June 18, 2026, high release cadence but bus factor to consider for team use.

🗺️ Why it's interesting and where to start

Beyond the tool, opencodex seems to me the clearest signal of a trend: the harness is becoming independent of the model. Codex and Claude Code are valuable for their agentic loop — planning, tools, sandbox, diffs — and projects like this show that the «brain» under that loop is interchangeable. For developers it's a negotiating and technical advantage: you pick the model for the task, not the subscription. For an SME it's a way to experiment with agents while keeping options open, including the local model when data can't leave the premises.

The path I'd suggest: first, try it on a secondary machine with a single API-key provider (save the OAuth path for later, once you've read the ToS). Second, test routing to a local model with Ollama, the zero-risk use case. Third, if you need the reverse path — Claude Code with alternative models — compare it to claude-code-router, which I wrote a complete tutorial for: the smaller the perimeter, the easier to see where traffic flows.