Claudish: Running Claude Code Against Non-Anthropic Models Through a Local Proxy
Claude Code. Any Model. The most powerful AI coding agent now speaks every language.
At a glance
- What is it?
- Claudish is a TypeScript CLI that starts a local Anthropic-API-compatible server and points Claude Code at it, so the same interface can drive Gemini, OpenAI, Kimi, GLM, OpenRouter models or a local Ollama instance. The trade-off is that you now own a proxy process, provider credentials and whatever the upstream model does with your prompts.
- Who is it for?
- Adopt Claudish if you already have Claude Code installed, want to keep its interface, and either hold a subscription the login flow supports or an API key for a provider you trust. Skip it if you need a documented rollback path, a published licence file in the repository you are reading, or a guarantee that the proxy stays protocol-compatible with every Claude Code release.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Claudish Actually Solves
Claude Code is a terminal agent built around Anthropic's API. If you want to drive that same agent loop with a different model, you normally have two bad options: rewrite your tooling around a second CLI, or give up the agent's file editing, permission prompts and `.claude` configuration. Claudish takes a third path. It is a CLI tool that, in the README's own words, "allows you to run Claude Code with any AI model by proxying requests through a local Anthropic API-compatible server."
The audience is narrow and specific. You are already a Claude Code user. You have a subscription or key that is not Anthropic's, or you want a local model for privacy reasons. The README frames the motivation as cost: it tells readers to "stop paying for multiple AI subscriptions" and lists mapping commands for Gemini Advanced, ChatGPT Plus/Codex, Kimi, GLM, MiniMax, OllamaCloud, OpenCode Zen and Qwen Plan. The offline case is stated plainly: `claudish --model ollama@qwen3-coder:latest "your task"` keeps code on your machine.
That is the whole pitch. It is an adapter, not a new agent. Everything you know about Claude Code's behaviour stays; only the model behind it changes.
How the Proxy Mechanism Works
The architecture is a shim. Claudish starts a local HTTP server that speaks the Anthropic API shape Claude Code expects, receives Claude Code's requests, translates them into whatever the target provider's API wants, and streams the response back. The README calls this "1:1 compatibility with Claude Code communication protocol" and describes the server as "Anthropic API-compatible."
Provider selection happens through a routing syntax the README documents as `provider@model[:concurrency]`, for example `google@gemini-2.0-flash`. Shorthands exist for common providers: `g@` for Gemini, `oai@` for OpenAI, `kimi@`, `glm@`, `mm@` for MiniMax, `oc@` for OllamaCloud, `zgo@` for OpenCode Zen, `qc@` for Qwen Plan, and `ollama@` or `lmstudio@` for local runtimes. Models without a prefix, such as `gpt-4o` or `llama-3.1-70b`, are auto-detected and routed to their native APIs.
Two details matter more than the feature list. First, each instance gets its own isolated proxy, which is what makes parallel runs possible. Second, the proxy is a process you are now responsible for: it holds provider credentials, sits between your editor and the network, and must stay in step with Claude Code's protocol. The README also documents a monitor mode that proxies to the real Anthropic API and logs traffic, which is the honest debugging tool for when a translation breaks.
There is also a vision proxy: for models that cannot accept images, Claudish routes image content through Claude to produce a description first. That is a clever workaround, but it means a supposedly offline local run is not fully offline when images are in play.
Installing Claudish and Running a First Task
Claudish requires Claude Code to be installed already, plus at least one API key or a supported subscription. The README lists four install routes. The npm one is the least surprising:
npm install -g claudishAfter that, the README's first-time step is to initialise a skill inside your project directory. This writes files under `.claude/skills/claudish-usage/`, and the README says it enables automatic sub-agent delegation and enforces file-based instruction patterns. Run it from the project root, not from your home directory:
cd /path/to/your/project
claudish --initThe README notes you should reload Claude Code afterwards so it discovers the skill. If you would rather not install anything, the README gives a no-install path through npx:
npx claudish@latest --model x-ai/grok-code-fast-1 "your prompt"For a subscription login instead of a key, the README documents an interactive picker plus named shortcuts. `claudish login` opens a picker of every provider you can log into; `claudish login codex` is described as ChatGPT Plus/Pro through OpenAI's own PKCE flow, and `claudish login antigravity`, `claudish login grok` and `claudish login kimi` map to those plans. Once logged in, you name the model directly: `claudish --model cx@gpt-5.5 "implement user authentication"`.
For a fully local run, the README's own example is `claudish --model ollama@qwen3-coder:latest "your task"`. What you should see is Claude Code's normal interface, with the model answering from your local runtime.
Where the Translation Layer Breaks Down
A proxy that translates between two API shapes is only as good as its coverage of the differences. Anthropic's API exposes features that other providers do not have equivalents for, and the README does not document how each one is handled. Tool-calling schemas, system prompt placement, stop sequences, token accounting and streaming event types all differ between providers. The README claims protocol compliance but does not publish a compatibility matrix, so you cannot tell from the documentation which Claude Code features degrade on which provider.
The vision proxy is the clearest example of a silent compromise. If you are running `ollama@` for privacy, sending an image causes Claudish to call Claude to describe it. Your image leaves the machine. The README presents this as a feature ("every model can 'see'") and it is, but it is not the same guarantee as a local-only run.
Context window behaviour is another gap. Claude Code's context inheritance, sub-agent delegation and file-based instruction patterns assume a certain context budget. A model with a smaller window, or one that handles long system prompts poorly, will produce different results from the same commands. The README does not say what happens when the target model's window is smaller than what Claude Code is trying to send.
Finally, the README does not document rollback. If a version of Claudish breaks your setup, there is no documented downgrade procedure, no `claudish doctor`, and no stated way to pin the proxy to a Claude Code version. The repository has a CHANGELOG.md, so the information may exist there, but the README does not point to it as a recovery path.
How Claudish Differs From a Plain API Wrapper
The obvious alternative is a wrapper that calls a provider's API directly and reimplements an agent loop around it: Aider, Cline, or a homegrown script. The difference is not the model access. It is what you keep. A wrapper gives you its own file-editing strategy, its own permission model, its own configuration format. Claudish gives you Claude Code's, unchanged, because Claude Code is still the thing running. Your `.claude` directory, your agents, your permission settings and your keybindings all keep working.
The cost of that choice is the proxy. With a wrapper, the provider's API is the only moving part. With Claudish, there is a local server process between Claude Code and the provider, and that process is versioned separately from both. The README's monitor mode exists precisely because this layer can fail invisibly.
A second alternative is provider-native tooling: Gemini CLI, Codex CLI, or whatever a vendor ships. Those are maintained by the vendor against their own model, so translation bugs are not a category of problem. They also lock you into one provider, which is the thing Claudish is built to avoid. If you only ever use one model, the native CLI is the simpler tool. If you switch between providers mid-project, which the README lists as a feature, Claudish is the one that keeps the interface stable.
Maintenance, Licence and Upgrade Cost
The repository is not archived, and the last push was on 2026-09-15. Three releases landed in the two days before that: v9.3.1 and v9.3.2 on 2026-09-14, and v9.4.0 on 2026-09-15. The version in the root `package.json` is 9.4.0, matching the latest release. That cadence tells you the project is moving quickly, which cuts both ways: fixes arrive fast, and so do changes to the proxy's behaviour.
Upgrade cost is real because of the three-way version dependency. Claudish must stay compatible with Claude Code's protocol and with each provider's API. Any of the three moving can break a working setup. The README does not document a version pinning strategy, a compatibility table, or a supported Claude Code version range. If you adopt this, budget time for a re-test after upgrades rather than assuming a patch bump is inert.
The licence situation is worth checking yourself. The README carries an MIT badge linking to a LICENSE file, but the repository metadata available here lists the licence as unknown, and no LICENSE file appears in the top-level entries. That is a discrepancy you should resolve by reading the repository before you depend on the tool. Nothing here is legal advice; the point is simply that the badge and the repository contents do not currently agree, and the badge is not the authoritative source.
Editorial conclusion
Adopt Claudish if you already have Claude Code installed, want to keep its interface, and either hold a subscription the login flow supports or an API key for a provider you trust. Skip it if you need a documented rollback path, a published licence file in the repository you are reading, or a guarantee that the proxy stays protocol-compatible with every Claude Code release. Before committing, run `claudish --init` in one throwaway project, check which provider the login picker actually offers you, and confirm in the repository that the licence badge in the README matches a LICENSE file you can read.
Frequently asked questions
What is Claudish?
It is a CLI tool that runs Claude Code with any AI model by proxying requests through a local Anthropic API-compatible server, according to the README. It supports cloud providers such as OpenRouter, Gemini, OpenAI, Kimi and GLM, plus local runtimes including Ollama, LM Studio, vLLM and MLX.
How do you use Claudish?
Install it with npm, Homebrew, the shell script or bun, then run `claudish --init` in your project directory to install the usage skill and reload Claude Code. After that you name a model with the `provider@model` syntax, for example `claudish --model g@gemini-3-pro-preview`, or log in with `claudish login` to use a subscription you already have.
Does Claudish work with a local model?
Yes. The README gives `claudish --model ollama@qwen3-coder:latest "your task"` as the offline example and lists Ollama, LM Studio, vLLM and MLX as supported local runtimes with `ollama@` and `lmstudio@` syntax. Note that the vision proxy sends images through Claude for description, so image tasks are not fully local.
Community notes