# claude-code-proxy keeps the Claude Code client and swaps the model behind it > claude-code-proxy is an MIT licensed Rust proxy that sits between Claude Code and a subscription-backed provider, translating Anthropic API traffic so the same client can run against a ChatGPT Plus or Pro account, Kimi, Grok, OpenCode Go or Cursor Agent. It also ships a terminal monitor for sessions and token usage, and it carries a warning from its own author about account risk, because these are unofficial clients. **raine/claude-code-proxy** — Use Claude Code with your ChatGPT, Kimi, Cursor or Grok subscription via a local Anthropic-compatible proxy - Repository: https://github.com/raine/claude-code-proxy - Website: https://claude-code-proxy.raine.dev/ - Stars: 665 · Forks: 157 - Language: Rust - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/raine-claude-code-proxy ## One client, several subscription-backed models claude-code-proxy is a local Anthropic-compatible proxy. Its stated purpose is to let Claude Code run against OpenAI Codex, Kimi, Grok, OpenCode Go or Cursor Agent instead of Anthropic's own models. The reasoning in the project documentation is about the client rather than the model. Claude Code is described as an excellent coding harness with strong tools, skills, hooks, subagents and editor integrations, and the proxy keeps that client experience while translating its Anthropic API traffic for subscription-backed provider services. So the split is clean. The harness stays exactly as it is, tools and skills and hooks and subagents included, and what changes is the endpoint it talks to and the wire format on the way there. The proxy handles provider authentication, model-based routing, protocol translation, streaming responses and diagnostics in one local process. The audience is a developer with one or more subscriptions to those services who wants to use them from Claude Code, either to compare models on the same task or to avoid a second billing relationship. It is a personal tooling project rather than a platform, and the built-in monitor is designed for one person watching their own sessions: it shows sessions, active and recent requests, errors, token usage and throughput. The implementation is Rust, the licence is MIT, and the last push was on 2026-10-10 with the v0.1.45 tag published the same day. ## Five providers, and how model names are resolved The provider table in the README lists what account each backend needs and how models are named, and the naming is not uniform because the underlying services are not. Codex expects a ChatGPT Plus or Pro account, and exposes the registered gpt-* models along with -fast and -ultrafast variants. Kimi expects a kimi.com account with Kimi Code access, and exposes kimi-for-coding and its aliases. Grok expects a grok.com account with the registered Grok models. OpenCode Go expects an OpenCode Go subscription and gives non-conflicting IDs plus the opencode-go/ form. Cursor Agent expects a Cursor account and exposes Cursor aliases with cursor: prefixes. The two commands to explore this are short. Running claude-code-proxy models gives the current catalog, and adding the --full flag lists every dynamic Cursor alias, which matters because the Cursor aliases are not a fixed list. The distinction between a subscription and an API account is the crux of the whole design, and the documentation is explicit about it for Codex: sign in with a ChatGPT Plus or Pro account, not an OpenAI API account. The proxy is built around the consumer products, which is also where the account risk comes from. ## Installing the binary and pointing Claude Code at it Installation on macOS or Linux is a Homebrew formula: ```sh brew install raine/claude-code-proxy/claude-code-proxy ``` or the release installer: ```sh curl -fsSL https://raw.githubusercontent.com/raine/claude-code-proxy/main/scripts/install.sh | bash ``` Windows and other prebuilt artefacts come from the GitHub releases page. Authentication happens per provider. For Codex it is: ```sh claude-code-proxy codex auth login ``` The proxy then runs in its own terminal: ```sh claude-code-proxy serve ``` and Claude Code is started against it with environment variables rather than a configuration file: ```sh ANTHROPIC_BASE_URL=http://127.0.0.1:18765 \ ANTHROPIC_AUTH_TOKEN=unused \ ANTHROPIC_MODEL=gpt-6-sol[1m] \ ANTHROPIC_SMALL_FAST_MODEL=gpt-6-luna[1m] \ CLAUDE_CODE_AUTO_COMPACT_WINDOW=272000 \ CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 \ CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK=1 \ claude ``` The auth token is literally unused, because the proxy authenticates to the provider itself and does not authenticate the local client. The two model variables point at the small and large model slots, the auto compact window and the two Claude Code switches adjust the client's own behaviour, and the port 18765 is the proxy's default loopback listener. For a background service the documentation offers claude-code-proxy serve --no-monitor, and you attach later with claude-code-proxy monitor. Closing an attached dashboard leaves the proxy running, which is the behaviour you want if the monitor is a window you open and close rather than the process itself. ## Image generation is opt-in and spends the account's quota The proxy also exposes an images endpoint, and it is off unless you turn it on. The environment variable CCP_CODEX_IMAGES_API=1 enables it, and the endpoint is called on the same local port: ```sh CCP_CODEX_IMAGES_API=1 claude-code-proxy serve curl http://127.0.0.1:18765/v1/images/generations \ -H 'Content-Type: application/json' \ -d '{"prompt":"A paper-cut fox","model":"gpt-image-2"}' ``` Two behaviours are worth reading twice. The response carries base64 image data, and it consumes the image quota of the signed-in account rather than any separate API credit. And image prompts and payloads are excluded from the traffic captures, so the monitor does not record what you asked the image model to draw. That second point is a privacy decision rather than a technical limit, and it cuts both ways. It keeps generated prompts out of the diagnostics, which is good for a shared screen or a captured log, and it also means the traffic view is not a complete record of what went through the proxy. The HTTP API documentation holds the generation and edit schemas for the endpoint. ## The warning about accounts is the most important paragraph The README carries a warning block, and it is the paragraph to read before anything else. The proxy accepts local requests without client authentication. It binds to 127.0.0.1 by default. If you expose it on anything other than the loopback interface, you must protect it with a firewall or an authenticating reverse proxy, because there is nothing between an unauthenticated local API and the provider credentials the proxy holds. Then there is the part that no firewall fixes. Provider subscriptions, model access, terms and account enforcement remain under each provider's control, and unofficial clients may carry account risk. That is a blunt statement and it is the honest one. The mechanism works by presenting a consumer subscription to a client that expects a different interface, and the provider decides what to do about that. A provider can change the behaviour it depends on, restrict the account, or withdraw access, and the proxy has no way to prevent it. The version tags show a project moving quickly, v0.1.45 on 2026-10-10, v0.1.44 on 2026-10-07 and v0.1.43 on 2026-09-30, and a fast-moving client against a moving target is exactly the situation where that risk shows up. For anyone whose work depends on a subscription they pay for, this is a risk to price rather than a technical detail to ignore. The project says so itself, which is more than many tools of this shape do. ## A Rust service with a terminal UI and a justfile The implementation is a modern async Rust service, and the dependency list in the package manifest describes the shape of it. The HTTP side is axum with the macros and multipart features, on tokio with the multi-threaded runtime, with tower and hyper-util for the service and proxy plumbing. The outbound side is reqwest with rustls TLS, streaming and multipart enabled, and with socks support. WebSocket traffic goes through tokio-tungstenite, again over rustls, with the ring provider. The interface is ratatui with crossterm, and there is a jiff dependency for time and time zone handling, plus tiktoken for token counting. The manifest is explicit that this is an application rather than a library. It is marked publish = false, the version is 0.1.45, the edition is 2024 and the licence field says MIT. Development runs through a justfile, which is worth reading because it shows how the project checks itself. Project checks run through a tool called checkle with separate recipes for format-check, clippy, build and test, and a check-ci recipe that fails if the checks leave uncommitted changes, which is the standard way to make a formatter part of the gate. There are recipes to install git hook shims, to install the release binary with cargo install --offline --path . --locked, to install a debug build as a symlink into the cargo bin directory, and to run the application with cargo run. The documentation has its own dev server, run with bun and given a port starting at 4321, with the recipe scanning upward for a free port. The repository also has a hooks/ directory, a scripts/ directory, a meta/ directory with the screenshots used in the README, a tests/ directory and a flake.nix, so the project is reproducible from Nix as well as from a package manager. ## When not to use it, and what to check first The fit is narrow enough to state plainly. claude-code-proxy is for a developer who wants the Claude Code client with a different model behind it, on a machine they control, and who accepts that the account is at risk. It is not a way to share one subscription across a team, it is not a supported integration, and it is not something to point at a workload where an outage has a cost. The alternative approaches split into two groups. The first is to use the provider's own client or SDK, which means losing the Claude Code harness, its skills, hooks, subagents and editor integrations, and keeping the provider's own interface. The second is to use Anthropic's own models with Claude Code, which is the configuration the harness was built for and the one with no account risk attached to it. In between sits the proxy, and what it buys is continuity of workflow rather than anything about the model itself. If you take the middle path, three things are worth checking before you commit to it. The first is the listener, keep it on 127.0.0.1, because the proxy has no client authentication of its own. The second is the account terms, read what your provider says about unofficial clients, since the proxy's warning is a summary of someone else's policy. The third is the model catalogue, run claude-code-proxy models and models --full, because the available names differ per provider and per subscription tier, and a configuration that points at a name the account does not have will fail at the first request rather than at startup. ## Conclusion claude-code-proxy suits a developer who wants to keep the Claude Code client and skills while billing a different subscription, and it is the wrong choice for a team that needs a supported, contractual path to those models, because the proxy itself warns that provider terms and account enforcement stay with the provider. Before adopting it, read the warning in the README, keep the listener on 127.0.0.1 as it binds by default, and decide in advance what you will do if a provider blocks the account. ## FAQ ### What does claude-code-proxy do? It is a local Anthropic-compatible proxy that translates Claude Code's API traffic to a subscription-backed provider, so the same Claude Code client can run against OpenAI Codex, Kimi, Grok, OpenCode Go or Cursor Agent. One process handles provider authentication, model routing, protocol translation, streaming and diagnostics. ### How do I install claude-code-proxy and connect Claude Code to it? Install it with brew install raine/claude-code-proxy/claude-code-proxy or the release installer script, sign in with claude-code-proxy codex auth login, run claude-code-proxy serve, and start Claude Code with ANTHROPIC_BASE_URL set to http://127.0.0.1:18765 along with the model environment variables. ### Is using claude-code-proxy risky for my provider account? The project warns that provider subscriptions, model access, terms and account enforcement remain under each provider's control and that unofficial clients may carry account risk, because the proxy presents a consumer subscription to a client that expects a different interface. ### How do I see which models are available through claude-code-proxy? Run claude-code-proxy models for the current catalog, and claude-code-proxy models --full to list every dynamic Cursor alias. Model naming differs per provider, with gpt-* models for Codex, kimi-for-coding and aliases for Kimi, and cursor: prefixes for Cursor Agent. ### Can claude-code-proxy generate images? Yes, as an opt-in feature enabled with CCP_CODEX_IMAGES_API=1. The endpoint at /v1/images/generations returns base64 image data and consumes the image quota of the signed-in account, and image prompts and payloads are excluded from the traffic captures. ## Sources - [License: MIT](https://github.com/raine/claude-code-proxy/blob/main/LICENSE) - [Project website](https://claude-code-proxy.raine.dev/) - [raine/claude-code-proxy on GitHub](https://github.com/raine/claude-code-proxy) - [README](https://github.com/raine/claude-code-proxy/blob/main/README.md) - [Releases](https://github.com/raine/claude-code-proxy/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/raine-claude-code-proxy