How to Use Other Models in Claude Code and Codex

Why you might want a different model in your coding agent

Claude Code and Codex are built around their makers' own models, and for most work that is the right default. There are still good reasons to point them somewhere else some of the time:

• Cost: a long agent session resends the whole conversation every turn, and open-weight models such as DeepSeek V4.1 Flash cost a small fraction of frontier rates.
• Data control: you may need a provider with a particular retention policy, region or contract.
• Refusals: security, trust-and-safety and red-team work often trips a mainstream model's filters. A provider with a different policy may complete it.
• Comparison: running the same task through two models is the fastest way to learn whether the expensive one earns its price.

This guide covers the three ways to do it, using SolCard Inference as the worked example. It speaks both the Anthropic and OpenAI formats, so it works in both tools. The same steps apply to any compatible provider or gateway. More important than the commands is the last section: what changes when you do this. Several of those changes are not obvious.

ReplacePoint all of Claude Code's traffic at another endpoint.

All or nothing

Add besideA local routing proxy keeps Claude and adds other models.

Both available

Add to CodexA custom provider in Codex's user config.

A separate profile

First, Anthropic's position

Claude Code accepts a custom endpoint through ANTHROPIC_BASE_URL, and Anthropic documents it carefully for organizations that run an LLM gateway. The same documentation is explicit: Anthropic "doesn't support routing Claude Code to non-Claude models through any gateway".

That is a support statement, not a technical block. It works, and many people do it. But Claude Code is tuned for Claude's tool-calling behaviour, and new Claude Code releases add request fields a third-party endpoint may not understand. When something breaks, you are on your own. Codex is more open: custom model providers are a documented, first-class feature of its config file.

Option 1: replace the model in Claude Code

The simplest approach points all of Claude Code's traffic at the other provider. You need its base URL and a key. For SolCard Inference, the Anthropic-format base URL is https://api.solcardinference.ai (no /v1, because Claude Code appends /v1/messages itself). Keys start with sk-si-.

1. Test the endpoint before touching Claude Code. In a terminal:

export ANTHROPIC_BASE_URL=https://api.solcardinference.ai
export ANTHROPIC_AUTH_TOKEN=sk-si-your-key
curl -sS -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" -H "content-type: application/json" \
  -d '{"model":"solcard-inference-fast","max_tokens":16,"messages":[{"role":"user","content":"Reply with ok"}]}'

A JSON reply means the URL and key work. A 401 means the key is wrong, or the provider expects it in the other header. Claude Code sends ANTHROPIC_AUTH_TOKEN as Authorization: Bearer and ANTHROPIC_API_KEY as x-api-key. SolCard accepts both.

2. Choose the models. Claude Code asks for Claude model names by default, so tell it what to use instead:

export ANTHROPIC_MODEL=solcard-inference-large
export ANTHROPIC_DEFAULT_OPUS_MODEL=solcard-inference-large
export ANTHROPIC_DEFAULT_SONNET_MODEL=solcard-inference-large
export ANTHROPIC_DEFAULT_HAIKU_MODEL=solcard-inference-fast

The Haiku setting matters more than it looks. Claude Code uses the small-model tier for background jobs such as session titles. Pinning it to the cheap model keeps those jobs off your expensive one, and keeps them off Anthropic entirely.

3. Fit Claude Code to the provider's limits. SolCard caps replies at 32,768 tokens, and Claude Code doesn't know that. Set CLAUDE_CODE_MAX_OUTPUT_TOKENS below the cap. If you see errors about unrecognised fields, set CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1. If a provider enforces a smaller context than the model's native window, set CLAUDE_CODE_AUTO_COMPACT_WINDOW to that limit, so Claude Code compacts the session in time instead of failing.

4. Make it persistent, carefully. Shell exports last for one terminal. To keep the setup, move the variables into the env block of ~/.claude/settings.json (all projects) or .claude/settings.local.json (one project). Never put a key in a project's .claude/settings.json, because that file is committed to the repository.

5. Verify. Start claude, send a message and run /status. The Status tab should show an Anthropic base URL line with the provider's address, and an Auth token line naming your variable. If the base URL line is missing, the variable didn't reach the session.

To undo, remove the variables and restart. Your saved claude.ai login is still on the machine and takes over again.

Option 2: keep Claude and add other models beside it

Option 1 is all or nothing: while it is active, every request goes to the other provider. Often you want both. Claude for hard reasoning, a cheap open model for bulk work, and a choice per task in the /model picker.

Claude Code can't send different models to different endpoints by itself, so the pattern is a local routing proxy. Claude Code talks to a proxy on your own machine. The proxy sends Claude model names to Anthropic, passing your own login header through, and sends other names to the other provider. SolCard's installer (paste "Add SolCard Inference to my models: solcardinference.ai/install" into Claude Code started from a terminal) is a good reference implementation. We read its runbook in full. It:

• downloads CLIProxyAPI 8.0.46, an open-source proxy, and refuses it unless its SHA-256 matches a pinned value;
• runs it as a login service listening only on 127.0.0.1, behind a key generated on your machine;
• adds ANTHROPIC_BASE_URL=http://127.0.0.1:<port> and that local key (as a custom header) to your shell profile, rather than to Claude Code's settings, so the desktop app's own sessions are unaffected;
• adds the extra models to the picker with modelPicker.options in ~/.claude/settings.json, plus a SessionStart hook that starts the proxy if it isn't running;
• leaves ANTHROPIC_AUTH_TOKEN unset. Your claude.ai login stays the active credential, the proxy forwards it to Anthropic for Claude models, and the proxy never stores it.

You can build the same thing by hand with any routing proxy. The design choices worth copying:

A request in the side-by-side setup

Claude CodeBase URL set to localhost

Local proxyRoutes by model name

The right vendorClaude, or the other provider

• bind to localhost only;
• require a local key;
• pass the vendor's Authorization header through instead of storing a login;
• turn request logging off;
• scope the base URL to terminal sessions.

Option 3: add a provider to Codex

Codex supports custom providers in its user config, ~/.codex/config.toml (or under CODEX_HOME). Project-level .codex/config.toml files can't define providers. A clean setup defines the provider once and selects it with a profile, so your default stays as it is:

# ~/.codex/config.toml (added; leave the rest alone)
[model_providers.solcard]
name = "SolCard Inference"
base_url = "https://api.solcardinference.ai/v1"
env_key = "SOLCARD_INFERENCE_KEY"
wire_api = "responses"

# ~/.codex/solcard.config.toml (a profile)
model_provider = "solcard"
model = "solcard-inference-large"
model_reasoning_effort = "medium"

Export SOLCARD_INFERENCE_KEY in your shell, then run codex --profile solcard, or codex exec --profile solcard "review this diff" for one-off jobs. Plain codex keeps using your ChatGPT models.

A few rules apply. Custom provider IDs can't be openai, ollama or lmstudio. In Codex 0.134.0 and later, profiles live in their own ~/.codex/<name>.config.toml files; older [profiles.<name>] tables are no longer read. Codex's Responses requests carry fields some providers reject. SolCard, for example, refuses previous_response_id and store: true. If you see 400 errors naming those fields, the provider is the limit, not your config.

SolCard's own Codex installer takes the side-by-side route instead. It makes a local proxy (SolCard's fork of CLIProxyAPI) Codex's provider, so ChatGPT and SolCard models share one picker. That requires a ChatGPT login rather than an API key, and in the ChatGPT app it turns Apps (connectors) off while installed. The profile approach above has neither restriction, but you switch models by switching profiles rather than in the picker.

What changes when you swap the model

This is the part most guides skip.

Billing moves. In Claude Code, as soon as ANTHROPIC_AUTH_TOKEN, ANTHROPIC_API_KEY or an apiKeyHelper is active, your claude.ai subscription stops applying. Every request is billed per token to whoever owns that key. Setting only ANTHROPIC_BASE_URL keeps your subscription login active, which is why proxy setups like Option 2 keep your plan working. Know which of the two you have configured.

Features switch off. Remote Control and voice dictation depend on a claude.ai identity and are unavailable while a gateway credential is set. Remote Control is also off while ANTHROPIC_BASE_URL points at a non-Anthropic host, even through a local proxy. The Claude desktop app ignores ANTHROPIC_BASE_URL and uses its own third-party inference settings.

Traffic you didn't move keeps flowing. The model requests go to your new provider, but Claude Code still sends version checks, telemetry and similar background requests to Anthropic and to services such as GitHub. If the point of the exercise is that nothing leaves your control, set CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1. That also turns off auto-updates, so plan another update path. Both tools also keep local session history on disk, wherever the tokens came from.

The agent's behaviour changes. Coding agents depend on reliable tool calls over long sessions. Open-weight models have improved enormously, but they don't behave like the model the agent was tuned for. Expect different habits around when to read files, when to run tests and when to stop. Evaluate on your own repository, not on a benchmark. Our guide to evaluating an LLM feature gives a method.

Limits change. Context windows, output caps, rate limits and input types are the provider's, not Claude's or ChatGPT's. SolCard, for example, is text-only, so screenshots pasted into the session will fail. It allows 60 requests a minute on pay-as-you-go, which a busy agent with parallel subagents can hit.

Cost structure changes. Agent sessions are mostly cached input, so the cached-token rate decides the bill far more than the headline price. Compare providers on that number. How to control AI API costs covers measuring it.

A quick decision guide

Whichever route you take, keep provider keys in environment variables or a secrets manager, never in a committed file. Give every key an agent can reach a spend limit; SolCard and most gateways support per-key caps. The habits in how to handle secrets and API keys apply here unchanged.

Common questions