Before picking a replacement, decide what you are replacing. Almost every list on this query answers with a different tool — and three of the top five are vendors nominating their own. That is a fine answer to one of the three reasons people search this, and an expensive answer to the other two, because it asks you to relearn a workflow in order to fix a bill.
Three reasons, three different answers
| What is actually wrong | The cheapest fix |
|---|---|
| You hit the plan's usage window mid-task | Keep the tool, change the endpoint — no window on per-token billing |
| The monthly cost is more than your actual usage | Keep the tool, change the endpoint — a quiet week then costs nothing |
| The tool is wrong for you — wrong surface, wrong editor, wrong lab | Change the tool. This is the case the lists are written for |
Two of those three rows are billing problems wearing a tool costume. They are worth separating out first, because the fix takes about a minute and does not cost you the workflow you have already learned.
If the tool is fine and the bill is not
Claude Code takes its endpoint from two environment variables. Setting them replaces the subscription with per-token billing and removes the usage window entirely — same binary, same commands, same habits:
# If the tool is fine and the bill is not, this is the whole change.
# Same binary, same workflow, same muscle memory — different biller.
export ANTHROPIC_BASE_URL=https://api.kunavo.com
export ANTHROPIC_AUTH_TOKEN=sk-kn-...
# Background steps do not need the flagship model:
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5
claude # no usage window, no plan, billed per tokenThe arithmetic for whether that is actually cheaper for you is on what Claude Code costs, and the limits it removes are the subject of Claude Pro and Max limits. Below a few hours of agent work a week a subscription usually wins; the ceiling is what people run into first, and it is the thing per-token billing does not have.
If the tool really is the problem
Then change it — and here the lists are right, they just skip the part about which axis you are moving along. All of these are open source except where noted, all are bring-your-own-key, and none of them runs a model of its own:
| Tool | Shape | Pick it when |
|---|---|---|
| opencode | Terminal agent | You want Claude Code's shape with every provider treated as first-class |
| Cline | VS Code extension | You want the diff in the editor with a review step before it applies |
| Kilo Code | CLI + VS Code + JetBrains | You are not in VS Code, or you move between editors |
| Aider | Terminal, git-native | You want every change to land as a commit you can read and revert |
| Codex CLI | Terminal agent (OpenAI) | You want a GPT model as the primary, not a Claude one |
| Zed | Editor with an agent built in | You want one fast native editor rather than a plugin on top of one |
Because every one of these takes a custom endpoint, the choice is reversible and the provider decision is separate from the tool decision. That is the part worth keeping: pick the tool on how it feels to work in, pick the endpoint on what it charges, and never let one decide the other.
What this page will not tell you
Which one writes better code. We have run no controlled comparison of these agents on identical tasks, and there is no honest way to rank them on output from the outside — the occupants of this query that do rank them are, for the most part, ranking their own. If output quality is the deciding factor, install two, run the same real task in each on the same endpoint, and read the charges and the diffs. That is an afternoon, and it answers the question for your codebase, which is the only place the answer holds still.
Direct comparisons if you have already narrowed it down: opencode vs Claude Code, Cline vs Claude Code, Claude Code vs Codex and Claude Code vs Cursor.
FAQ
What is the best Claude Code alternative?
It depends which part you are replacing, and most lists skip that question. If you hit the subscription's usage window, the cheapest fix is not another tool — it is pointing Claude Code at a per-token endpoint with two environment variables, which keeps the workflow you already know. If you want the agent inside your editor rather than a terminal, Cline is the closest open-source equivalent. If you want a terminal agent that treats every provider as first-class, opencode is the closest. If you want an agent that is not Anthropic-shaped at all, Codex CLI and Gemini CLI are the first-party options from the other two labs.
Is there a free alternative to Claude Code?
The tools are free; the model calls are not. Cline, opencode, Aider, Kilo Code and Crush are all open source and cost nothing to install, but each still needs a provider key, and that is where the spend actually is. The genuinely free tier in this space is Gemini CLI's included quota, which is real and has a daily ceiling — useful for light work, and it hands you the same per-token question the moment you pass it.
Can I keep Claude Code but stop paying for a subscription?
Yes, and this is the option the comparison lists usually omit. Claude Code reads ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN at startup, so pointing it at any Anthropic-compatible endpoint is a configuration change rather than a migration — no plan, no usage window, billed per token instead. On Kunavo that is $1.20 / $6.00 per 1M tokens for Claude Sonnet 4.6 and $0.40 / $2.00 for Claude Haiku 4.5.
What is the closest open-source equivalent to Claude Code?
For the terminal, opencode — same shape (an agent you run in a shell, not an editor plugin), open source, and provider-agnostic by design, so switching models or providers is a config line rather than a fork. For the editor, Cline, which is the most-installed open-source coding agent in VS Code and has been bring-your-own-key since its first release. Kilo Code covers both surfaces plus JetBrains.
Does switching tools lower my model costs?
Not by itself. No agent runs a model — every one of them sends requests to a provider, and the provider sets the rate. What changes cost when you switch tools is how much context that tool re-sends per step, which varies with your repo more than with the tool's name. If the goal is a smaller bill, changing the endpoint is the direct lever and changing the tool is an indirect one.
When is changing tools actually the right answer?
When the tool itself is the problem: you want the diff reviewed in your editor before it applies rather than approving steps in a terminal, you need JetBrains or a non-VS-Code editor, you want a model from a different lab as the primary, or you want to read and patch the agent's own source. Those are real reasons and no amount of endpoint configuration fixes them. Cost and usage limits are not on that list.