mimo2codex: a local Responses-to-Chat-Completions shim for the latest Codex CLI

The Codex wire_api mismatch that mimo2codex exists to paper over

The README states the problem plainly: MiMo's official Codex integration only supports `wire_api = "chat"`, and newer Codex versions hard-error on that setting. So you have two bad options. Stay on an old Codex build, or give up the upstream model. mimo2codex is the third option: a process that listens locally and pretends to be a native Responses backend, so Codex never learns that the other side speaks Chat Completions.

The audience follows from that. It is for people who have already decided to run Codex as their client and want a specific non-OpenAI model behind it, most obviously Xiaomi MiMo V2.5 or DeepSeek V4 Pro, both of which the project ships as built-in providers. It is also for the broader group running Qwen, GLM, Kimi, vLLM, Ollama or LM Studio, since the generic provider mechanism covers anything that exposes an OpenAI Chat Completions endpoint. The README positions the project as a thin protocol shim, a sibling to OpenRouter and claude-code-router, which is an honest framing: this is plumbing, not a model and not an agent.

How the translation and per-request routing actually work

Codex sends a request in the Responses API shape. mimo2codex receives it, translates it into the upstream's Chat Completions shape, forwards it, then translates the reply back. The routing decision is made per request, using the `model` field the client sent, so a single running process can serve MiMo, DeepSeek and several generic providers at once without restarting.

Providers are declared in `providers.json`, and the README notes that each declared provider needs its `envKey` environment variable populated. For the simple case there is a shortcut: a single provider named `generic` can be declared entirely through environment variables, with `GENERIC_BASE_URL`, `GENERIC_API_KEY` and `GENERIC_DEFAULT_MODEL`, plus optional `GENERIC_SHORTCUT`, `GENERIC_DISPLAY_NAME`, `GENERIC_WIRE_API` and `GENERIC_FORCE_DEFAULT_MODEL`. That last flag matters: with it set, an unknown `model` value is rewritten to `GENERIC_DEFAULT_MODEL` instead of failing.

The feature list is more than string rewriting. The README claims function and parallel tool calls, MCP namespace handling, MiMo's native `web_search`, vision, and a correct multi-turn `reasoning_content` round-trip. That last item is the one to scrutinise in your own testing, because reasoning fields are the part of the Chat Completions surface that vendors implement most inconsistently. The admin console, served at `http://127.0.0.1:8788/admin/`, exposes a model catalog, chat logs, token stats and provider configuration, persisted in sqlite. That is where you check whether the round-trip is behaving.

Installing mimo2codex and pointing Codex at it

The README gives a three-command CLI path, and it is the shortest route to a working proxy. Node 18 or newer is required, per the engine field in `package.json`.

npm install -g mimo2codex     # 1. install (Node >= 18)
mimo2codex init               # 2. add your API key, then edit ~/.mimo2codex/.env
mimo2codex                    # 3. start the proxy on 127.0.0.1:8788

After `mimo2codex init` you edit `~/.mimo2codex/.env`. The shipped `.env.example` explains the keys: `MIMO_API_KEY` for Xiaomi, where `sk-*` keys go to the pay-as-you-go host and `tp-*` keys go to the token-plan host, and either `DS_API_KEY` or `DEEPSEEK_API_KEY` for DeepSeek, with `DS_API_KEY` taking precedence when both are set. The example file also warns that variables already present in your shell are overwritten by the file, which is worth knowing if you keep keys in a shell profile.

Once the proxy is up, Codex has to be pointed at it. The README says this is one click on the admin UI's Codex Enable page, or you copy the printed `config.toml` and `auth.json` into `~/.codex/`. A separate document covers running Codex CLI in isolation on Windows so that Codex Desktop stays untouched. For a container instead of a global install, the repository's `docker-compose.yml` pulls `ghcr.io/7as0nch/mimo2codex:latest`, maps port 8788, reads a `.env` file and mounts `./.mimo2codex` at `/data`.

Where mimo2codex breaks: connectors, Docker builds and the localhost assumption

The most concrete limitation is stated by the project itself. Codex Desktop connectors such as GitHub and Gmail cannot be proxied, and the documentation points to a fallback rather than a fix. If your workflow depends on those connectors, this proxy does not cover it.

The second is the trust boundary. The proxy runs on `127.0.0.1`, and your upstream API key lives in a `.env` file or in the container's environment. That is fine for a single developer machine. It is not a multi-tenant gateway, and the README's own Docker notes describe the intranet case as requiring user login, BYOK and OAuth, which is a different deployment shape from the three-command CLI path.

The third is build complexity. The Dockerfile is unusually defensive: it forces the builder stage onto the native build platform, pins `npm_config_target_platform=linux` and `npm_config_target_libc=musl`, and passes `npm_config_target_arch` so that better-sqlite3's prebuilt `.node` binary can be fetched per architecture. The comments explain that without this, arm64 builds under QEMU with Node 20 and Alpine frequently hit SIGILL. That is a maintenance surface you inherit if you build your own images rather than pulling the published one.

Finally, the upstream is the real constraint. mimo2codex can only translate what the upstream supports. A provider with a half-implemented tool-calling or reasoning field will produce failures that look like proxy bugs but are not.

How it differs from OpenRouter and claude-code-router

The README places mimo2codex alongside OpenRouter and claude-code-router, and the difference is where the translation happens. OpenRouter is a hosted service: your requests leave the machine, and the routing and protocol adaptation happen on someone else's infrastructure. mimo2codex runs on `127.0.0.1` and does the adaptation locally, which is why the README emphasises that the upstream key never leaks in the Docker deployment. The trade-off is that you now operate a process, and you own its upgrades.

claude-code-router is the closer sibling in shape, but it targets a different client. It exists to route Claude Code to other models. mimo2codex exists because Codex moved to the Responses API and dropped `wire_api = "chat"` support. The two are not interchangeable: one is built around Claude Code's request format, the other around Codex's. If you are not running Codex, mimo2codex has no reason to be in your stack.

Maintenance, licence and the upgrade path you are signing up for

The repository is not archived, and the last push was on 2026-07-04, with the most recent release `v0.5.29-desktop` tagged the same day. That is roughly two and a half months before the date of this article, so it is recent but not continuous. The version numbering is worth reading carefully: `v0.5.29`, `v0.5.29-desktop` and `v0.5.28-desktop` are separate tags, which suggests the CLI package and the desktop packaging are released on their own cadence. The `v0.5.29` release note is short, reading "mimo模型升级", so the changelog detail lives in the tag log document rather than in the release itself.

The upgrade cost is structural. Codex is the moving part here, and the project's entire reason to exist is that Codex changed its wire protocol once already. Every future Codex release that touches the Responses API is a potential break, and you are relying on this project to track it. The `wire_api` badge in the README, set to `responses`, is the contract being maintained.

Licence is MIT, which permits commercial and private use, modification and redistribution with the licence text retained. This is not legal advice; check the LICENSE file and your organisation's own policy before shipping it internally.

Editorial conclusion

Adopt mimo2codex if you want to keep the current Codex CLI or desktop app and still route requests to MiMo V2.5, DeepSeek V4 Pro or another OpenAI-compatible endpoint, and you accept running a local service on 127.0.0.1:8788. Skip it if you only ever talk to OpenAI's own Responses API, or if you need Codex Desktop connectors such as GitHub or Gmail proxied, which the documentation says cannot be proxied and only offers a fallback for. Before committing, verify that your upstream actually implements the tool-calling and reasoning_content round-trip you depend on, and confirm your Codex build accepts the config.toml and auth.json that the admin UI prints.

Frequently asked questions

Official sources

1. 7as0nch/mimo2codex on GitHub
2. License: MIT
3. Project website
4. README
5. Releases