How to Change the Model in Claude Code (Any Provider)

Claude Code is a harness, not a model.

That distinction is worth more than it sounds. The terminal, the file editing, the tool calls, the sub-agents, your / commands, your MCP servers, your skills: none of that is Claude. It is Claude Code. The model is one HTTP endpoint sitting behind all of it, and you are allowed to point that endpoint somewhere else.

Once that clicks, the tool and the model become two separate decisions. You keep the workflow you already know and you swap the engine whenever it makes sense to.

Here is how to actually do it.

The short answer#

Claude Code reads three environment variables. Set them and it talks to whatever you point it at:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://your-provider.example/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "your-api-key",
    "ANTHROPIC_MODEL": "the-model-id"
  }
}

Drop that into .claude/settings.local.json in a project folder and run claude there. That is the whole mechanism. Everything else in this post is detail around those three lines.

Two things trip people up on the first attempt.

The base URL is a host root, not a full path. Claude Code appends /v1/messages itself. If you paste a URL that already ends in /v1 or /messages you get a 404 that looks like an auth problem but isn't.

It has to be an Anthropic-compatible endpoint. Not every provider has one. An OpenAI-format endpoint will not work here, because Claude Code speaks the Messages API shape. Providers who want the Claude Code crowd ship a dedicated Anthropic-compatible URL specifically for this, and it is usually a different URL from their main API.

Do it per folder, not globally#

This is the part most tutorials skip, and it is the difference between a reversible experiment and breaking your setup.

If you export those variables in your shell profile, every Claude Code session on your machine changes. That is almost never what you want. You end up running a cheap model on the one project where you actually needed the expensive one.

Use .claude/settings.local.json inside a single project folder instead. The config applies to that directory and nothing else. Open a terminal in any other project and you are back on your normal Anthropic setup, untouched, like nothing happened.

That scoping is what makes this safe to try. Worst case you delete one file.

For a throwaway test you can also set the variables inline for a single command rather than writing a file at all. Same effect, nothing persisted.

Confirm which model you are actually on#

Do not skip this. A misconfigured base URL frequently fails silently back to your default, and then you spend an hour convinced a model is faster than it is.

Inside a session, two commands answer it:

• /status shows the endpoint it is talking to. You want to see your provider's host, not api.anthropic.com.
• /model shows the model identifier it resolved to.

Asking the model "what model are you?" is a weaker check. Models routinely get their own identity wrong, and a wrapper can answer that question convincingly while routing you somewhere else entirely. Trust /status over the model's self-report.

Pick the model for the job, not the benchmark#

The useful mental model is cognitive load, not leaderboard position.

Frontier models earn their price on ambiguous work: a vague spec, a gnarly refactor across unfamiliar code, a first-pass design where taste matters. That is where the gap between a top model and a good-enough one is still obvious.

Most of what a coding agent actually does all day is not that. It is boilerplate, wiring, test scaffolds, renaming, reading a codebase and reporting back, running the same operation across forty files. That work needs a model that is smart enough and does not stop.

Matching the model to the load is the same principle behind the three-tier model cascade I used to run Hermes Agent for $8 a month and behind running 19 OpenClaw agents for $2 a month. Different tools, identical logic: stop paying frontier prices for work that does not need frontier reasoning.

What you can point it at#

Broadly four categories.

Open-weight models over a hosted Anthropic-compatible endpoint. The most common reason people do this. Several of the large Chinese labs now ship an Anthropic-compatible URL aimed squarely at Claude Code users, usually attached to a flat monthly coding plan rather than per-token billing. MiniMax, DeepSeek, Moonshot's Kimi models and Z.ai's GLM line all sit in this bucket. Check the provider's own docs for the exact endpoint, because these change and a stale URL from a blog post is the most common failure.

A local model on your own machine. Ollama, LM Studio, llama.cpp and vLLM can all sit behind a local address. Free at the margin, fully offline, and genuinely useful for private codebases. Be realistic about the tradeoff: local models are much weaker at long agentic tool-calling chains, which is most of what Claude Code does. Great for a contained task, frustrating for a long autonomous run.

A router or gateway. Services that sit in front of many models and expose one endpoint. You get model choice and spend visibility in one place, at the cost of another hop and another bill.

Anthropic through a cloud provider. Bedrock and Vertex are the same Claude models via a different door. This is a billing and compliance decision, not a model decision.

I would not treat that list as a ranking. The right pick depends on whether you want a flat monthly bill, per-token control, or no bill at all.

The one I actually run#

I use MiniMax M3 for this, on their $20 a month plan, because it is the setup I have put the most real hours on.

The config is the same three lines:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.minimax.io/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "your-minimax-key",
    "ANTHROPIC_MODEL": "MiniMax-M3[1m]"
  }
}

There is a fourth line worth adding for large codebases:

"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000"

Claude Code compacts your context when it thinks you are near the limit. If your model has a bigger window than the default assumption, that compaction fires early and interrupts you for no reason. Raising it to match the real window is the difference between finishing a long task and getting cut off in the middle of one.

I wrote up the full walkthrough with both build prompts and the real usage numbers in what happened when I ran MiniMax M3 in Claude Code for a week, including where it lost to Claude. If you want the plan itself, it's here with 12% off, and the free step-by-step setup guide is on Gumroad.

When to switch back#

Swapping the model is cheap. Being stubborn about it is not.

I still move back to Claude for genuinely ambiguous problems, for anything where the first pass at visual design has to be good, and for long chains where tool-call reliability matters more than token price. The failure mode of a cheaper model is rarely "wrong answer." It is "jumpier agent": more retries, more re-prompting, more of you in the loop. On hard work that erases the savings.

The honest version is that you are choosing per task, not once and forever. Two lines in a file per project is a small enough cost to make that choice often.

One more lever most people miss#

If your front ends keep coming out looking like every other AI-generated site, that is usually a prompting problem, not a model problem. I have run the same vague prompt on a frontier model and a cheap one and gotten the same flavor of generic from both.

The fix is giving it a system to follow instead of a vibe. I open-sourced the component library I use for exactly this, and pointing any coding agent at it changes the output far more than changing the model does. It's free at Open Glass UI, with a live demo and docs here.

Once the model is a variable rather than a fixed cost, the interesting question stops being "which model is best" and becomes "which model is enough for this." That is a much cheaper question to answer.

If you want to see the rest of what I run this harness for, I've written up deploying a site live from inside Claude Code and running a whole agent team on a $7 VPS.