Dr Hernani Costa

Posted on Mar 29 • Originally published at radar.firstaimovers.com

Claude Desktop vs Terminal: Config Without Chaos

#ai #programming #productivity #automation

Misconfigured routing variables don't just break Claude Code—they create operational liability across your entire development stack. When ANTHROPIC_API_KEY or ANTHROPIC_BASE_URL leak into global settings, your desktop loses native authentication, MCP tool discovery breaks, and your team can't tell whether Claude, OpenRouter, or the shell is the problem.

Keep Claude Native on Desktop and Experimental in the Terminal

How do you keep the desktop experience on real Claude, while using the terminal for cheaper or experimental models?

For anyone using Claude Code seriously, this Claude Code configuration question shows up fast. Claude Code now runs across the terminal, IDEs, desktop, and browser. It also uses a real settings hierarchy: user settings in ~/.claude/settings.json, project settings in .claude/settings.json, and personal project overrides in .claude/settings.local.json. On top of that, the env block in settings applies environment variables to every session, not just one shell window.

That is why people accidentally wreck a clean setup.

They add OpenRouter globally, test one model in the CLI, and suddenly everything feels off. Their desktop sessions are no longer clearly native. Their auth path gets muddy. MCP behavior changes. Then they wonder whether Claude, OpenRouter, or their shell is the problem.

Here is the cleaner way to think about it.

The Claude Code Configuration Mistake Most People Make

The common mistake is treating routing variables like a harmless convenience.

They are not.

In Claude Code, ANTHROPIC_API_KEY is especially powerful. When it is set, Claude Code uses that key instead of your Claude Pro, Max, Team, or Enterprise subscription. Anthropic also documents that ANTHROPIC_BASE_URL overrides the API endpoint, and when it points to a non-first-party host, MCP tool search is disabled by default unless you explicitly re-enable it.

That means a global gateway setup is not just "one more option." It changes the behavior of your overall Claude Code environment.

So the real goal is not "make OpenRouter work."

The real goal is contain the routing change to the exact sessions where you want it.

What the official docs actually support

Anthropic's docs are clear on the baseline. Claude Code supports logging in with Claude.ai accounts, including Pro and Max, and it supports multiple surfaces, including terminal and desktop. If your account supports it, Opus 4.6 and Sonnet 4.6 can expose a 1M token context window, with availability depending on plan and model selection. You can inspect the active model with /status, and the same command also shows account and connectivity information.

OpenRouter's Claude Code integration guide is also clear. Their recommended connection method is:

ANTHROPIC_BASE_URL="https://openrouter.ai/api"
ANTHROPIC_AUTH_TOKEN="<your OpenRouter key>"
ANTHROPIC_API_KEY=""

They explicitly recommend checking the connection with /status.

So yes, the routing pattern is real.

But there is an important caveat.

OpenRouter also states that Claude Code with OpenRouter is only guaranteed to work with Anthropic first-party providers, and that Claude Code is optimized for Anthropic models and may not work correctly with other providers. That is the part many people skip when they jump straight to qwen/qwen3-coder:free or another non-Anthropic model.

That does not mean experimentation is impossible.

It means you should treat non-Anthropic models inside Claude Code as experimental, not as the baseline you build your daily workflow on.

The clean split that actually works

If your goal is:

Desktop app: real Anthropic login, premium Claude quality, clean native experience
Terminal: cheap or experimental sessions on demand

then the most reliable pattern is this:

1. Keep your user-level Claude settings neutral

Do not hardwire gateway routing into ~/.claude/settings.json unless you want it everywhere.

A minimal user file is enough:

{
"env": {}
}

That keeps your global user scope clean and avoids pushing routing variables into every Claude Code session. The reason this matters is simple: the env block in settings is applied to every session.

2. Use shell-scoped launch functions for the terminal

This is the part most people should copy.

Put this in ~/.zshrc or ~/.bashrc:

Native Claude session in the terminal

claude_native() {
env -u ANTHROPIC_BASE_URL \
-u ANTHROPIC_AUTH_TOKEN \
-u ANTHROPIC_API_KEY \
-u ANTHROPIC_MODEL \
claude "$@"
}

Experimental OpenRouter session in the terminal

claude_free() {
ANTHROPIC_BASE_URL="https://openrouter.ai/api" \
ANTHROPIC_AUTH_TOKEN="$OPENROUTER_API_KEY" \
ANTHROPIC_API_KEY="" \
ANTHROPIC_MODEL="qwen/qwen3-coder:free" \
claude "$@"
}

Then reload your shell:

source ~/.zshrc

Now your split is intentional:

claude_native
claude_free

This works because the routing change is no longer global. It only exists for the shell session that launches claude_free. Anthropic documents that ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, and ANTHROPIC_MODEL control routing and model behavior, while OpenRouter documents the exact base URL and auth pattern Claude Code expects.

3. Use project-local settings only for project experiments

Claude Code supports .claude/settings.local.json as a personal, gitignored, repo-specific override. That is useful if you want one repository to behave differently from the rest of your machine.

Example:

{
"env": {
"ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
"ANTHROPIC_AUTH_TOKEN": "${OPENROUTER_API_KEY}",
"ANTHROPIC_API_KEY": "",
"ANTHROPIC_MODEL": "qwen/qwen3-coder:free"
}
}

But here is the practical truth: project-local settings are good for per-repo experiments, not for a clean desktop-versus-terminal split.

If your goal is surface separation, shell-scoped launch functions are cleaner.

The caveat nobody should ignore

If you want the CLI to run through OpenRouter and stay highly reliable inside Claude Code, the safer move is to route Anthropic models through OpenRouter, not Qwen or DeepSeek first.

OpenRouter's own docs say Claude Code compatibility is only guaranteed with Anthropic first-party providers, and they even show the recommended model overrides using Anthropic model IDs like anthropic/claude-opus-4.6 and anthropic/claude-sonnet-4.6. Anthropic also supports custom model entries and explicit model environment variables for gateway deployments, which is useful if you want controlled routing without losing the normal Claude model picker behavior.

So the mature version of this stack looks like this:

Desktop: native Claude login
Terminal default: native Claude
Terminal experimental: OpenRouter with a non-Anthropic model only when you are explicitly testing
Terminal routed but stable: OpenRouter with Anthropic models when you want budget controls, failover, or usage visibility without leaving the Claude family

That is a much better operational model than turning your whole machine into a permanent gateway experiment.

How to verify your setup in 30 seconds

Once you launch either mode, check it.

Run:

/status

Anthropic documents /status as the place to see version, model, account, and connectivity. OpenRouter's Claude Code guide specifically shows /status reflecting the OpenRouter base URL and auth token when the routing is active.

If you are using premium Claude and want long-context work, check your model selection too. Anthropic documents that supported accounts can use 1M context variants like opus[1m] and sonnet[1m].

My take

This approach aligns with professional AI Tool Integration and workflow automation design principles: keep your best workflow boring and your experimental workflow isolated.

That means:

keep user-level config clean
route the terminal per session
treat non-Anthropic models in Claude Code as experiments
use /status every time you change routing
keep native Claude available at all times

If you do that, you get exactly what most serious builders want:

real Claude when quality matters, experimental models when cost or curiosity matters, and far less configuration chaos in between.

DEV Community