Watch where a Claude Code session actually spends money and the split is not subtle. A small slice is genuinely hard: deciding the approach, spotting that the bug is in the caller rather than the function, choosing what not to build. The rest is typing — renaming across forty files, filling in the obvious half of a test suite, applying a decision that was already made. Both halves bill at the same rate.
Contents
- What the switch is worth
- The part worth copying: never put the key in a file
- Switching without losing your Anthropic login
- How it works in practice
- Where this does and does not make sense
So I stopped paying the same rate for both. I keep an inexpensive Claude plan for the thinking and point Claude Code at MiniMax for the heavy mechanical work, with a single command to flip between them.
What the switch is worth
Comparing monthly plans, as of October 2026:
- $200/mo Max — all the thinking and all the typing, all at top rate. Against $20 Claude + $132 MiniMax = $152. Saves about $48 a month.
- $100/mo Max — cheaper, still paying premium rates for keystrokes. Against $20 Claude + $55 MiniMax = $75. Saves about $25 a month.
Check both providers' current pricing before you act on those numbers — this is a fast-moving market and the figures above are a snapshot, not a quote. The shape of the argument survives the specific prices, though: you are paying a reasoning premium on work that needs no reasoning.
The part worth copying: never put the key in a file
The obvious way to point Claude Code at another provider is to paste a base URL and an API key into ~/.claude/settings.json. Do not do that. It puts a live credential in plain text, in a file that gets backed up, synced, screen-shared and occasionally committed by accident.
Claude Code supports apiKeyHelper — a command it runs to fetch the key at runtime rather than a field holding the key itself. On macOS that means the key can live in the Keychain and be read on demand:
security find-generic-password -a "$USER" -s minimax-api-key -wPoint apiKeyHelper at that and the settings file never contains a secret — only an instruction for where to find one. The key is stored once, protected by the OS, and revocable in one place.
Switching without losing your Anthropic login
The other half of the problem is reversibility. A provider switch that costs you a re-login every time is a switch you stop making. Your Anthropic credentials already sit in the Keychain, and nothing about pointing Claude Code at a different base URL needs to disturb them — so a clean switch edits the base URL, the model and the key helper, and leaves the login alone. Switching back is then instant rather than another sign-in.
Three rules make it safe to do often:
- Back up the settings file before every change, so a bad switch is one copy away from undone.
- Record what to restore — the model and settings you had — in state kept separately from the secret.
- Strip any key that has leaked into the settings file on each switch, so an earlier manual edit gets cleaned up rather than quietly persisting.
One more detail specific to long-context models: the auto-compact threshold that suits a 200K window is wrong for a 1M one. Raise it when you switch, or you will compact conversations that had plenty of room left.
How it works in practice
I wrapped all of this in a small shell tool, claude-provider, with five commands — status, claude, minimax, toggle and set-token. The first run asks for the key once, with hidden input, and writes it to the Keychain. Every run after that is a single word. Claude Code has to be restarted after a switch, since it reads these settings at startup.
status is the command that earns its place: it prints the active provider, the base URL, the model, where the key is coming from, and whether your Anthropic login is still valid — so "which model am I actually burning money on right now" is never a guess.
Where this does and does not make sense
This is not an argument that one model replaces another. It is an argument that a single session contains work of very different value, and that routing all of it to the most capable model available is a pricing decision rather than a technical one. Plan, architect and debug where the reasoning is best. Do the mechanical follow-through somewhere cheaper. Keep the switch to one command so the friction never talks you out of it.
The approach is macOS-specific as written, because it leans on the Keychain and the security command. The idea ports anywhere with a real secret store — the thing worth keeping is not the script, it is refusing to write the credential into a file.
Key takeaways
- A session contains work of very different value, and billing all of it at the same rate is a pricing decision, not a technical one.
- apiKeyHelper reads the key at runtime, so the settings file never contains a secret.
- Back up the settings file on every switch, and record what to restore separately from the secret.
- Strip any key that has leaked into the settings file on each switch.
- Raise the auto-compact threshold when moving to a long-context model.
- A status command that names the active provider and model stops the switch being a guess.
FAQ
Why not just put the API key in settings.json?
Because that puts a live credential in plain text, in a file that gets backed up, synced, screen-shared and occasionally committed by accident. apiKeyHelper fetches the key at runtime instead, so the file holds an instruction, not a secret.
Do I lose my Anthropic login when I switch?
No. The Anthropic credentials stay in the Keychain untouched, so switching back is instant rather than another sign-in.
Does this work on Linux or Windows?
Not as written — it leans on the macOS Keychain and the security command. The idea ports to any real secret store; the part worth keeping is refusing to write the credential into a file.
Are those cost figures current?
They are a snapshot from October 2026. Provider pricing moves quickly, so check both providers before acting on the numbers. The argument survives the specific prices.
Working on something similar?
If you are wiring AI into the tools your team already uses, I am happy to look at it with you. Thirty minutes, no deck — bring the workflow that costs your team the most time and we will work out whether it is automatable. Get in touch.