Use Claude Code With Open Source Models: Keep the Harness

Search “use Claude Code with open source models” and you get two kinds of page: a hobbyist walkthrough that exports two environment variables and points the CLI at a laptop running Ollama, and a model vendor’s announcement that its API now speaks the same format. Both are right about the mechanism. Neither is written for the person who actually asks this question at work, which is an engineering leader with thirty developers on Claude Code, a bill that jumped when the default model moved to Opus, and a security lead who wants to know where the tokens go.

One disambiguation first, because the search results blur it: this post is about keeping the Claude Code harness and swapping the model behind it. It is not about open-source replacements for Claude Code, which is a different decision with a different cost. If your developers like the CLI, the question is whether the model has to be Anthropic’s, and the answer is no.

This post is for that reader. The mechanism first, read from Anthropic’s own gateway docs in October 2026 and linked, including the sentence those walkthroughs leave out. Then which model families fit, with dated prices. Then where the arithmetic breaks, because it does. Then the part no walkthrough covers: what changes when it is a team rather than one terminal, which is where YAGNI’s wire adapter comes in, and why the same meter ends up carrying an Agent Team.

Can you use Claude Code with open source models?

Yes, and the reason is structural rather than a hack. Claude Code is a harness: the CLI, the tool loop, the permission prompts, the CLAUDE.md and skills it loads, the compaction logic. The model behind it is reached over one HTTP endpoint, Anthropic’s Messages API at /v1/messages. Anthropic built the harness to work through an LLM gateway, which is a proxy an organization runs between the CLI and the model provider, and documented exactly which variables point it there. Any server that answers the same format, with any model behind it, is indistinguishable to the CLI from Anthropic’s own API.

The sentence the walkthroughs skip is in Anthropic’s gateway docs, as of October 2026: Anthropic “doesn’t endorse, maintain, or audit third-party gateway products, and doesn’t support routing Claude Code to non-Claude models through any gateway.” Read that as a statement of ownership, not a prohibition. The harness is built to be pointed elsewhere; when you point it at an open-weight model, compatibility becomes the gateway’s job. The harness adds request fields with each release, and a gateway that does not forward or strip them correctly breaks the matching feature. Somebody has to keep up. That is the whole question for a team, and we come back to it.

How do you point Claude Code at an open-weight model?

Two variables, per Anthropic’s connect page, as of October 2026. ANTHROPIC_BASE_URL is where requests go. The credential goes in ANTHROPIC_AUTH_TOKEN if the endpoint reads a bearer token, ANTHROPIC_API_KEY if it reads an x-api-key header, or an apiKeyHelper command in your settings file if the credential rotates. A shell export lasts one terminal; the env block of ~/.claude/settings.json applies everywhere Claude Code runs, including background agents, and .claude/settings.local.json scopes it to one project.

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://gateway.example.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-gateway-key"
  }
}

Start claude, run /status, and the Status tab shows an Anthropic base URL line and an Auth token line naming the variable. If the base URL line is missing, the variable did not reach the session. Three details decide whether the next hour goes well:

• Your subscription stops applying. While a gateway credential is active, requests carry it instead of your claude.ai login, and the plan’s limits do not apply to them. The traffic is billed by whoever owns the endpoint. This is the point for a team, and a surprise for a developer who thought the Max plan was still paying.
• The model names are Claude’s. The CLI asks for opus, sonnet, or haiku. Either the gateway maps those names to models it runs, or you pin them on the client with ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL, and ANTHROPIC_DEFAULT_HAIKU_MODEL, or the gateway publishes its own list through model discovery (CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1) so the /model picker shows them. The Haiku pin matters more than it looks: background work such as session titles runs on it.
• Pre-release fields cause 400s. The CLI sends beta headers and fields that an upstream open-weight server may reject, with errors like Extra inputs are not permitted or Input tag 'adaptive' found. CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 suppresses most of them. A gateway that enforces a smaller context window than the model’s native one also rewrites the too-long error, so auto-compaction stops firing and /compact becomes a manual step unless you set CLAUDE_CODE_AUTO_COMPACT_WINDOW to the gateway’s limit.

Three kinds of endpoint will answer. A model vendor’s own compatible route, which several open-weight labs now publish. A proxy you run, such as a self-hosted router that translates to OpenAI-format backends. Or a managed proxy that does the mapping, the credential, and the attribution for you, which is what YAGNI’s wire adapter is, and what the rest of this post is about.

Which open source models work with Claude Code?

The ones trained for agentic tool use, served behind a compatible endpoint, by a host you trust with your repository. The model families engineering teams run through Claude Code in October 2026, named publicly by their labs: DeepSeek’s V4 line, whose API docs list an Anthropic-format base URL; Z.ai’s GLM 5 line; Moonshot’s Kimi K2 line; and Alibaba’s Qwen3 Coder line. Meta’s Llama and OpenAI’s open-weight releases run too, through a translating proxy; test them on the long tool loops a coding session is made of before trusting them with one.

Two cautions. First, the same weights vary in price and quality across hosts: quantization, context limits, and tool-call formatting differ, and a cheap host that drops a tool call mid-session costs more than the one that did not. Second, benchmarks age in weeks. The one public figure worth carrying is from a real codebase rather than a leaderboard: in July 2026, Databricks benchmarked coding agents on its own multi-million-line repository, and GLM 5.2, an open-weight model, was statistically tied with Opus 4.8 on quality at $1.28 per completed task against Opus’s $1.94. The same study found the harness a model is called from moved cost per task by more than two times at a fixed model. Read both findings together: the model matters, and the thing around the model matters as much.

YAGNI’s own routing runs across vetted US-hosted open-weight models and does not publish which models serve which lane, because the lanes are upgraded as better models land and the rate does not move. If a vendor tells you which open-weight model is best this month, the honest answer is that it will be a different one next month, which is the case for buying a lane rather than a model.

What does it cost compared with Claude’s own models?

The list prices, per million tokens, read from each vendor’s page in October 2026 and linked:

Model	Input	Output	Source
Claude Opus 5.5	$4.00	$20.00	Anthropic
Claude Sonnet 5.5	$2.00	$10.00	Anthropic
Claude Haiku 5.5 (prompts up to 100K tokens)	$0.10	$0.50	Anthropic
DeepSeek V4 Pro, peak hours	$1.32	$3.96	DeepSeek, half price off-peak
GLM-5.3	$1.40	$4.40	Z.ai

Against Opus 5.5, which Anthropic’s model configuration docs list as the default on Pro, Max, Team, Enterprise, and the API since Claude Code v2.1.280, as of October 2026, the open-weight rows are roughly two thirds cheaper on input and four fifths cheaper on output. Against Sonnet 5.5 the input gap closes to about a third and the output gap to a bit over half. That is the per-token story, and it is the one every vendor announcement tells.

The per-task story is different, and it is the one a manager budgets in. A coding session resends its whole context on every turn, so cache reads dominate input cost, and the cache-read discount differs by vendor. A weaker model reads more files, runs more tests, and takes more turns to the same diff. In the Databricks study, Sonnet 5 was about 1.7 times cheaper per token than Opus 4.8 and cost more per completed task, because it used 1.9 times the tokens and completed six points fewer tasks. Token price predicted almost nothing. We did the full arithmetic for a ticket in LLM router: how model routing cuts AI coding cost, and the sticker prices for every Claude plan in how much does Claude Code cost; the short version is that the saving is real and smaller than the price list says, and it depends on which steps you route where.

YAGNI’s claim is deliberately the floor rather than the ceiling: vetted US-hosted open-weight models at 60% or more under comparable frontier API rates, metered on one rate card, no seats, a developer with zero usage costing zero. The rate card is shared on a call, not published, and the only public number is that floor.

Where does the open-weight math break?

Four places, in the order they will bite.

Hard tickets. On the top difficulty tier, a frontier model that finishes in one attempt beats an open-weight model that finishes in three, even at a fifth of the token price. Databricks found open models could handle its highest tier, and also that most daily engineering work does not need the most capable model. The lesson is not “open weights everywhere” but “route the step”, which is why a router that escalates the plan and the review to a stronger lane while the reads and test runs go cheap is the shape that holds.

Tool-call fidelity. A coding session is hundreds of tool calls. A model that emits a malformed call one time in fifty costs you a stuck session and a developer’s attention, and that cost never appears on an invoice. Test the model on your repository with your skills loaded before you roll it out.

Caching. Claude Code is built around the prompt cache. An endpoint with no cache, or a shorter cache lifetime, charges full input price on every turn, and a long session can end up costing more than the list-price gap suggests. Check the cached-input column on the vendor’s page, not just the input column.

Compatibility drift. Every CLI release can add a field the gateway has to handle. The gateway docs say so plainly, and it is the reason a proxy somebody set up in an afternoon stops working on a Tuesday. Whoever owns the gateway owns this. A few features also switch off the moment the base URL points elsewhere: Remote Control, voice dictation, and fast mode are unavailable behind a non-Anthropic host, per the same connect page, and the CLI’s cloud and Slack surfaces do not read the gateway variables at all, so that traffic never reaches your gateway.

There is a fifth consideration that is not arithmetic. A lab’s own endpoint is hosted wherever the lab is, and several of the labs behind the best open-weight coding models are outside the United States. The same weights are served by US hosts, and that is the version an engineering org with a security review should be evaluating. YAGNI’s lanes run on vetted US-hosted open-weight models for that reason.

None of these is an argument against open-weight models for a coding agent. They are the reasons the decision belongs to the organization rather than to each developer’s shell profile.

What changes when it is a team and not one developer?

Everything the walkthrough does not mention. One developer with two exports in .zshrc has a cheaper afternoon. Thirty developers with thirty different exports have a security problem, a visibility problem, and a support problem.

Question	One developer’s proxy	A gateway the org runs	YAGNI’s wire adapter
Who holds the provider key	The developer, in a dotfile	The gateway, server side	YAGNI; the developer holds a rotating token bound to their workspace login
Who can see spend per developer	Nobody	The gateway’s logs, if someone built the report	The Usage page, per developer and per Agent, beside the savings against the frontier benchmark
Where inference runs	Wherever the cheapest host is	Wherever the admin pointed it	Vetted US-hosted open-weight models
Who keeps up with Claude Code releases	The developer, when it breaks	The platform team	YAGNI
What offboarding takes	Finding the dotfile	Revoking one gateway credential	Removing the person from the workspace
What the record shows	A session on a laptop	A request log	The same meter the Agent Team’s tickets run on, with a case file per ticket

Anthropic’s own rollout guidance, as of October 2026, is the second column: deploy a gateway, give it the provider credential, issue each developer their own credential so usage is attributed and offboarding revokes one thing, and distribute the base URL through managed settings so nobody configures anything. Since Claude Code v2.1.285 a managed settings file can also set allowedProviders to ["customEndpoint"], after which the CLI refuses a session pointed anywhere but the base URL in that file, including a developer’s own proxy. That is good advice, and it is a platform team’s project. The third column is the same shape with the project done.

Whichever column you pick, run the evaluation before the rollout, and make it one you can rerun when the models change. Take twenty tickets from last month that span your real mix, from a config flip to a multi-file migration. Run each through Claude Code twice, once on the frontier model and once on the open-weight lane, with the same CLAUDE.md and skills. Record three numbers per ticket: did it reach a mergeable pull request, how long did the reviewer spend, and what did the session cost. The split you find, the tickets where the open-weight lane held and the ones where it did not, is your routing policy. It is not a swap; it is a split, and the hard tickets stay on the strongest lane.

How does YAGNI connect Claude Code to open-weight models?

One command from a terminal where the developer has signed in to YAGNI:

yagni connect claude-code

It writes the three things Claude Code needs into the CLI’s own settings file: the base URL of YAGNI’s model proxy, an attribution header so the Usage page can tell a Claude Code session from a YAGNI Code session, and an apiKeyHelper that fetches a rotating token on demand, so no secret is ever baked into a file and a rotated token is picked up without the developer running anything. Everything else in the settings file stays as it was. --project writes to the repository’s local settings instead of the user’s, for the one team that should run this way and the one that should not yet. --off removes exactly the keys YAGNI wrote. Restart Claude Code and the session runs on YAGNI’s models.

The model picks map onto YAGNI’s four lanes. Claude Code’s opus pick lands on Advanced, sonnet on Standard, haiku on Efficient, and fable on Peak, so a developer who already runs /model by habit keeps the habit and the meaning. Under the lanes, a router places each step on the cheapest lane that holds quality and escalates when it would not; the developer sees the same harness they had yesterday. The same adapter exists for Codex, and the YAGNI MCP server gives either harness the decision ledger and the connected tools as grounding, which is the part of the cost story that lives upstream of the model: an agent that reads why the ticket exists before it plans takes fewer retries, and we wrote up where that context lives in context engineering for coding agents.

For the manager, the adapter answers the question the walkthroughs cannot. Every session a developer runs through it, and every run a named Agent makes on a Team, bills on the same rate card and shows up beside each other on the Usage page: spend, the benchmark of what the same work would have cost parked at the frontier, and the savings, per developer and per Agent, with each Agent’s spend broken out by the job that spent it. A daily spend ceiling in Workspace settings is the brake. If you are budgeting the rollout, the seat arithmetic is in Claude Code Team plan: budgeting a rollout for your org; the adapter is the line in that budget that moves.

What does the same meter carry beyond the CLI?

A developer’s Claude Code session is one door into YAGNI. The other is an Agent Team, which mirrors one of your engineering teams and reports to one accountable person. A ticket moves through six stages, each owned by a named Agent, on the same open-weight lanes and the same rate card as the developers: Bailey, the Product Manager, proposes it from the Jira or Linear backlog with evidence; Reeve, the Staff Engineer, plans it, reading the ticket, the linked Slack thread, and the Team’s decision ledger first; a person approves the plan; Wright, the Builder, builds it to a draft pull request in a sandbox; Proctor, the Reviewer, posts one review a person can read on the GitHub pull request; Fletcher, in beta, boots the environment and walks the change in a browser; and a person merges. Harper, the Chronicler, posts what shipped to Slack with the receipts attached.

That is what the open-weight question looks like once it is managed. The developer keeps the harness they chose. The organization keeps the key, the record, and the bill. The hard tickets still get the strongest lane, and the merge is still a person’s click, every time. The managed version of the whole story is in AI agents for software development, and the offer itself is on the home page. The cost side, from seats to tokens to tickets, is the guide to what AI coding tools cost.

If you want to see your own numbers, book 30 minutes and bring your current Claude plan, the number of active developers, and one ticket you consider hard. We will connect a session on the call, run the ticket, and send the arithmetic back with the rate card.