There are two ways to run Claude Code without paying per token: point it at models on your own hardware, or point it at someone else's hardware that happens to be free. I have done both, and they fail in opposite directions. Local inference hits a hardware ceiling. Free cloud inference hits a rate-limit ceiling. Knowing which ceiling you are about to hit is the whole game, and most guides on this topic never mention either one.
This post covers the cloud half: routing Claude Code through OpenRouter's free model catalog. The setup takes about ten minutes. The judgment about what to actually run through it is what I care about more, because I pay for a Claude Max plan and still keep this configuration around. It is not a replacement for paid Claude. It is a different tool with a different shape.
Why Cloud Free Beats Local Free on Normal Hardware
I wrote up my two-week local trial with Ollama separately, so the short version: my machine is a MacBook Pro with an M3 Pro and 18GB of unified memory. On that hardware, the realistic ceiling is a model around 20B parameters, and even that means closing Docker first. The models small enough to run comfortably are noticeably below what Claude Code's agentic loop needs for multi-step work.
OpenRouter inverts the constraint. The free catalog includes NVIDIA's Nemotron 3 Super, a 120B-parameter mixture-of-experts model (12B active per token, hybrid Mamba-Transformer architecture, released March 2026). I could not load that model on my laptop at any quantization. Through OpenRouter it runs on proper GPU infrastructure and answers in a few seconds.
That is the real value of the free tier, and it is not "saving money on tokens." It is access to a model class your hardware cannot reach. If your alternative was a 7B local model, the free cloud tier is not a slightly better option; it is a categorically different one.
The reason it can be free at all: NVIDIA, Meta, and Alibaba release open-weight models because adoption feeds their actual businesses, and OpenRouter subsidizes free access as a growth funnel. Neither incentive is going away, but individual model IDs rotate in and out of the free collection, which matters for your config later.
The Setup: Three Variables and One Logout
Claude Code separates its agent framework from its model. File reads, shell execution, planning loops, sub-agents — that is all framework, and it runs the same no matter what answers the API calls. So redirecting the API calls is all you need.
Create a free OpenRouter account, generate a key (it starts with sk-or-v1-), and add this to your shell profile:
export ANTHROPIC_BASE_URL="https://openrouter.ai/api"
export ANTHROPIC_AUTH_TOKEN="sk-or-v1-your-key-here"
export ANTHROPIC_API_KEY=""
export ANTHROPIC_DEFAULT_SONNET_MODEL="nvidia/nemotron-3-super:free"
Then source ~/.zshrc, launch claude, and run /status to confirm the endpoint and model.
Two of those lines deserve explanation, because they are the ones people skip.
The empty ANTHROPIC_API_KEY is not decoration. If you have ever authenticated Claude Code against a real Anthropic account, credentials are cached, and when both sets exist the failure mode is not always an error. The nasty version is that everything works and your requests quietly route to Anthropic's paid API while you believe you are on the free tier. Blanking the key explicitly tells Claude Code to ignore cached credentials.
The second half of the same trap is OAuth. If you signed in through the browser flow, run /logout inside Claude Code once before relying on the env vars, because the cached OAuth token can outrank them. The /status check afterward is the only proof that counts. I learned to treat "did /status show OpenRouter" as a hard gate after seeing how plausible the silent-billing failure is — it produces no symptom until the invoice.
The ANTHROPIC_DEFAULT_SONNET_MODEL variable maps Claude Code's default working tier to your chosen model. There are sibling variables for the Opus and Haiku tiers, so you can map each tier to a different backend if you want the model switcher to keep meaning something.
The Rate Limits Are the Product
Here is the part most write-ups get wrong, sometimes by a wide margin. OpenRouter's free tier limits, as of this writing: 20 requests per minute, and 50 requests per day if you have never purchased credits. Buy $10 of credits once — ever, not monthly — and the daily cap rises to 1,000 free-model requests and stays there.
Now put those numbers next to how Claude Code actually behaves. An agentic tool is the worst possible client for a request-capped API. One "task" is not one request. A prompt like "add a settings page with tests" fans out into planning calls, file reads, generation calls, tool-result follow-ups, test runs, and correction loops — dozens of API requests for one unit of human intent. At 50 requests per day, a single medium task can end your day before lunch.
The per-minute limit bites differently. Claude Code's loop fires follow-up requests in rapid bursts right after tool results come back, which is exactly the pattern a 20-per-minute throttle punishes. The symptom is an agent that works in stop-and-go traffic: fast burst, stall, fast burst. It still finishes, but the rhythm is nothing like paid-tier flow.
So the honest advice is blunt: the $10 deposit is not optional if you intend to use this for real work. It is a one-time refundable-in-spirit deposit that takes the daily ceiling from "one task" to "a full workday." At 1,000 requests per day I have not hit the wall in normal use.
Which Free Model to Pin, and Why Pinning Matters
I pin nvidia/nemotron-3-super:free as the default. The reasoning is about architecture, not fandom: a 120B MoE with 12B active parameters is the current best answer to "as much capability as a free tier can serve without the economics collapsing," and NVIDIA built this one explicitly for agentic workloads. Qwen3 Coder is the other free model worth knowing; on OpenRouter it has been the strongest pure-code option in the free collection, and if your usage is overwhelmingly code generation it is a reasonable default instead.
What I would avoid for Claude Code specifically is the auto-router option that picks a free model per request. For a one-off chat question it is fine. Inside an agent loop it means consecutive steps of the same task can be answered by different models with different formatting habits and different tool-calling reliability, and the framework has no way to compensate. Agent loops want a consistent counterpart. Pin one model.
Two operational notes from running this config. First, free model IDs shift as OpenRouter rotates the catalog; if Claude Code suddenly throws errors on launch after weeks of working, check the model string before debugging anything else. Second, if you use a CLAUDE.md file (you should), remember it was probably tuned against Claude models. Smaller or differently trained models follow long nuanced instructions worse; flattening instructions into short explicit steps recovers a surprising amount of reliability.
What I Route to Free Models, and What I Refuse To
I run my client and production work on the Max plan, and I am not pretending otherwise. The free-cloud configuration earns its place for a specific band of work:
- Throwaway prototypes and spikes. Anything I might delete tomorrow does not deserve paid tokens.
- Boilerplate and scaffolding. Component skeletons, test file stubs, config plumbing. Low reasoning, high typing.
- Bulk templated tasks. Repetitive transformations where the prompt is tight and the failure mode is obvious on sight.
- Experiments with the agent framework itself. Trying a new workflow shape, a new skill, a new prompt structure — iteration is free, so I iterate more.
And the refusal list: anything security-sensitive, anything touching Git history beyond plain commits, and any large-codebase change where cross-file reasoning is the actual job. Free models hold big context windows physically but reason across them noticeably worse than frontier models, and in an agent chain one weak step compounds — the model writes a slightly wrong file, the next step builds on it, and you spend your savings debugging. I laid out the general math of matching model tier to task value in my AI agent cost optimization guide; the one-line version is that a free model that needs three attempts is more expensive than a paid model that needs one, because your time is the denominator.
The less obvious benefit is psychological. When every call is metered, you self-censor: fewer exploratory runs, fewer "try it a second way" passes. With a free lane available, the speculative experiments actually happen, and some of them turn out to be the right answer. That change in behavior has been worth more to me than the line-item savings.
Where This Sits in the Free-Backend Landscape
OpenRouter is one of three free-or-cheap backends I have run Claude Code against; the others are NVIDIA's own endpoint and local Ollama, and I compared all three head-to-head in my free Claude Code proxy write-up. The short ranking for most people: OpenRouter for the model selection and the tolerable limits after the $10 unlock, local Ollama for privacy-bound or offline work, and everything paid for the work that pays you. If you are still budgeting the paid side, my token management habits cover the other half of the bill.
Ten minutes of setup, three environment variables, one /logout, one /status check. After 8+ years of building for clients I default to boring, verifiable configuration over clever proxies, and this is exactly that: no middleware to babysit, and undoing it is deleting four lines.
The next decision after this setup is routing policy: which work goes to the free lane, which stays on paid models, and what prevents the two from silently swapping places mid-project. I design that split for teams, boundaries included, through my services.
