ChatMock: an OpenAI and Ollama compatible API in front of Codex

The gap ChatMock fills between Codex and your chat client

Codex models are reachable through OpenAI's own clients. Many other tools, from Raycast to agent terminals, instead expect an OpenAI-compatible base URL or an Ollama host. ChatMock sits in that gap: it signs in with a ChatGPT account, then serves the account's Codex models over endpoints those tools already understand. The README states the goal plainly: it "Allows Codex to work in your favourite chat apps and coding tools."

That framing matters for who should care. If you already use an OpenAI-compatible client and want the Codex models in it without changing the client, ChatMock is the adapter. If you want to build a product on top of Codex, this is not a hosted gateway; it is a local bridge bound to one account's credentials.

How the ChatMock server turns a ChatGPT login into an API

The mechanism is a two-step process. First, chatmock login performs an OAuth sign-in against the ChatGPT account and stores the credentials. The repository's .env.example points the auth directory at CHATGPT_LOCAL_HOME, and docker-compose.yml mounts a named volume there, so the signed-in state lives on disk rather than in memory. Second, chatmock serve starts a Flask application (the dependency list pins flask and flask-sock) that listens on port 8000 by default and speaks the OpenAI-compatible /v1/responses protocol over both HTTP and WebSocket, plus Ollama-compatible endpoints.

Model discovery is dynamic rather than hardcoded. With CHATGPT_LOCAL_MODEL_SYNC set to true (the default), the server discovers the models available to the signed-in account and refreshes that list every CHATGPT_LOCAL_MODEL_REFRESH_INTERVAL seconds, 3600 by default. That is why the README describes the supported model list as a catalog that "commonly includes" certain slugs rather than a fixed set: what you see depends on your account. Reasoning is a separate concern from the model itself. Flags such as --reasoning-effort and --reasoning-summary control how hard the model thinks and how verbose the returned summary is, while --reasoning-compat decides the wire format the client receives (legacy, o3, or think-tags). If a client does not understand thinking output, that last flag is the one to change.

Installing ChatMock and making a first request

The README gives four installation routes: Homebrew, pipx or pip, a GUI download from the releases page for macOS and Windows, and Docker. The pipx path is the shortest for a Python 3.11 or newer environment, which pyproject.toml requires. After install, the README's getting-started sequence is a login followed by a server start.

pipx install chatmock
chatmock login
chatmock serve

On a headless server the README says to append --headless to the login command. Once the server is running it listens at http://127.0.0.1:8000, and the base URL to give an OpenAI-compatible client is http://127.0.0.1:8000/v1. For an Ollama-style client such as the Raycast extension described in the README, the host value is 127.0.0.1:8000 and you then sync models to register the available slugs.

Two request-level features are shown as JSON bodies in the README. Web search is enabled per request by including a responses_tools entry, and fast mode by setting fast_mode. Both are also available as server flags, --enable-web-search and --fast-mode, with matching environment variables. If you would rather not pass the flag on every request, set the environment variable once.

{
  "model": "gpt-5.4",
  "messages": [{"role": "user", "content": "latest news on ..."}],
  "responses_tools": [{"type": "web_search"}],
  "responses_tool_choice": "auto"
}

Where ChatMock stops being the right tool

The default configuration binds the server to 127.0.0.1. That is a sensible default for a bridge holding account credentials, but it means ChatMock does not give you a shared endpoint out of the box. docker-compose.yml exposes CHATMOCK_PUBLISH_HOST, with a comment in .env.example noting that 0.0.0.0 is for remote access, so remote exposure is possible, but it is a deliberate change you make rather than the shipped behaviour.

There is a second limitation that follows from the design: everything is tied to one ChatGPT sign-in. The README's important notice says to use the project responsibly and at your own risk, and states that it is not affiliated with OpenAI. It does not describe multi-user accounts, per-key quotas, or a way to serve several distinct identities from one process. If your requirement is a shared internal gateway with separate credentials per team, this is the wrong shape.

Finally, the model catalog is not guaranteed. Because discovery depends on the signed-in account, a model slug that appears for one user may not appear for another, and the README presents the list as what the catalog "commonly includes." Build against slugs you have confirmed on your own account, not against the README's example names.

ChatMock compared with running Ollama locally

The obvious alternative for someone who wants an OpenAI-compatible local endpoint is Ollama running models on your own hardware. The difference in approach is where the compute happens. Ollama downloads weights and runs inference locally, so latency and capability depend on your GPU and memory, and nothing leaves the machine. ChatMock runs no model at all; it forwards requests to the Codex models available to your ChatGPT account and translates the responses into OpenAI and Ollama shapes. You get frontier-model capability without local hardware, at the cost of a network round trip and a dependency on that account remaining valid.

That also explains why ChatMock advertises Ollama-compatible endpoints at all. It is not competing with Ollama on local inference; it is presenting itself as an Ollama host so that tools already configured for Ollama, such as the Raycast integration in the README, can point at it instead. If your reason for using Ollama is data residency or offline operation, ChatMock is the wrong answer.

Maintenance, licensing and upgrade cost

ChatMock is MIT licensed, which permits commercial and private use with the usual requirement to retain the licence and copyright notice. That is a permissive starting point, but it says nothing about the terms of the ChatGPT account you sign in with, which are governed separately; the README's notice that the project is not affiliated with OpenAI is the relevant caveat here.

The repository is not archived, and the last push was on 2026-09-01, so the project has seen recent activity. Recent releases are versioned tightly around model generations: v1.2 for quality-of-life improvements, v1.3 for the GPT-5-Codex release, and v1.35 for the GPT-5.1 series and GPT-5.1-Codex-Max. That release pattern is the upgrade cost in practice. When a new Codex generation ships, expect a version bump, and expect to re-check whether your client's reasoning-compat setting still matches what the server returns. The dependency pins in pyproject.toml are exact rather than ranges, which keeps installs reproducible but means dependency updates arrive with project releases rather than on your own schedule.

Editorial conclusion

Adopt ChatMock if you want the Codex models reachable from tools that already speak the OpenAI or Ollama protocol, and you are comfortable running a local server tied to a personal ChatGPT sign-in. Do not adopt it as a shared, multi-tenant gateway: the README describes a single-account login and a localhost-bound default. Verify first that your ChatGPT account actually exposes the model slugs you need, because the catalog is discovered per account rather than fixed.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. RayBytes/ChatMock on GitHub
4. README
5. Releases