Open-Weight Model Pricing: Why Choose Them, and How to Measure Cost

For a few years the default was simple: pick the strongest model you can buy and send every task to it. That habit is getting expensive, and it is no longer the only option that works.

The better question in 2026 is: which model finishes this task, at the lowest useful cost? That question is not "open or closed." It is not "which is the best model." It is the right model for the work in front of you.

I walked through that shift in an Agentic Hour briefing, with a live agent building a small product while we talked. The examples here are open-weight models, because that is where the price drop is most visible, and because the habit of always picking the largest option exists there too. The rule is the same if the candidate is Claude, GPT, Gemini, Kimi, or DeepSeek.

The question changed twice

In 2023 the question was "which model is best?" One frontier model for chat, code, and everything else.

In 2024 and 2025 it became "which agent is best?" The harness and the vendor were the same thing. You bought Claude Code, Codex, or whatever came bundled with the API you already paid for.

Now the useful question is "which model for this step?" Easy work can go to a smaller model. Mid-size work can go to a mid-tier coding model. Architecture, hard debugging, and the first breakdown of a messy problem still belong on a stronger model. Defaulting the whole mix to the largest option, proprietary or open, is how teams burn 60 to 80 percent of an AI budget on routine edits.

Forbes reported that Uber exhausted its 2026 AI budget in four months after putting unrouted Claude Code in front of about 5,000 engineers. That is what "use the best model" looks like at company scale.

Open is not free, and open-weight is not local

"Open-source model" gets used as a synonym for "free model you run on a laptop." Both parts are wrong for the models that matter in production.

Open weights mean you can get the weights. You still pay for inference. A 3-trillion-parameter class model is not something you casually host on a developer machine, and renting enough GPU to serve it yourself is often more expensive than a hosted API.

In practice there are three ways to run them:

1. Hosted inference. Pay per token through Groq, Together, DeepInfra, OpenRouter, MixLayer, OpenCode's gateway, and similar providers.
2. Dedicated inference. Your own GPU instances when you need guaranteed throughput or data residency.
3. Local execution. Ollama or vLLM on a workstation, for smaller models and cases where nothing can leave the machine.

The argument for open weights is not "open equals free." It is open equals competition and optionality. You can change provider without rewriting the product. You can shop on price, latency, and privacy. You can keep code and documents off a closed API when that is a real constraint.

Free tiers exist, and they are fine for a spike. Treat them as a trial, not as production. Those endpoints often reserve the right to train on the prompts you send. If the work is a proprietary app, pay for a plan that does not do that.

Why open-weight is now part of the mix

You still pick the model that can finish the task. Open-weight belongs on that list now because capability caught up enough that the lock-in story is weaker than it was.

DeepSeek's V3 report put the final training run at $5.576 million and 2.788 million H800 GPU-hours. That number excludes earlier research, so it is not a full lab budget. It was still enough, on 27 January 2025, for Reuters to report a 17 percent drop in Nvidia and about $593 billion of market value gone in a day. The market had assumed that only brute-force spend produced frontier quality.

By 2026 the open-weight field is not one underdog. Qwen3-Coder is built for multi-file repo work. DeepSeek kept pushing Mixture-of-Experts serving and low inference prices. GLM has been competitive on agentic terminal tasks. Kimi K3 is a 3T-class model with a 1-million-token context window and vision, and Moonshot's own benchmarks put it next to frontier proprietary models on several coding and agent tests. Vendor benchmarks are vendor benchmarks. They are a reason to try the model, not a reason to trust it blindly.

On the company side, the pattern is the same: move routine volume off the frontier API.

• Amazon's Werner Vogels has said teams are sending routine work to cheaper open-weight models and choosing models by task.
• Axios reported that Lindy moved to DeepSeek V4 and claimed millions in savings plus better results on core work.
• Harvey reported a 3× drop in inference cost, with no quality drop in the test, by mixing Opus with GLM 5.1.
• A vendor case study from distil labs says Knowunity cut 68 percent of inference cost on selected tasks with a specialized Qwen fine-tune.

Those are attributed claims, not a guarantee for your workload. They are enough to put open-weight models on the same table as the proprietary ones, and then still choose by task.

Cost per token is the wrong number

A model at $0.20 per million tokens that needs seven attempts, 45 million tokens, and twelve minutes of an engineer cleaning up after it is not cheap. A model at $3.00 per million tokens that finishes in one shot, with 8 million tokens and no correction, is often cheaper.

The number that matters for agents is cost per successful task, or cost per accepted pull request. Token price is an input. Retries, cache, human rework, and whether the model follows the spec are the rest of the bill.

Cursor published a useful example. They rebuilt SQLite from an 835-page manual in Rust, using different mixes of planner and worker models. Both setups they highlight passed 100 percent of a held-out suite. The published cost range was $1,339 to $10,565, about a 7.9× spread for the same result. Worker models ate more than 90 percent of the tokens. In the cheaper mix, more money went into planning than into execution, which is the point: planning is where a stronger model earns its keep. Almost any decent model can follow a good plan. A weak plan is expensive no matter what runs it.

If you only look at the price list, you pick the $0.20 model. If you look at finished work, you pick a mix.

A single-shot test

During the briefing I started an OpenCode agent on a spec and left it running. Same spec for both models. No follow-up prompts. One shot.

A prior calibration run of that spec:

Flash used about twice the tokens and still cost roughly eight times less.

The two runs built the same project. On following the instructions, respecting the spec, and giving the correct output, they were the same. Kimi was a bit better in UI and UX. That polish does not justify being almost eight times more expensive than DeepSeek.

$3.70 and $0.47 are not production AI product costs. They are the cost of building a small app, including tests and the agent's own retries. The app itself does not call a model.

This is the part I want to make obvious. You do not need the largest model to finish the task. The test used two open-weight models, a large one and a cheaper, smaller one, because that size gap exists inside open-weight too, not only between a closed frontier API and everything else. Both followed the spec. The extra money bought layout, not a different product.

Keep the harness. Swap the model.

If the agent product and the model vendor are the same contract, you cannot route. You pay their price, hit their caps, and rebuild if you leave.

A model-agnostic harness (OpenCode is one example; Codex, Grok, and others can sit next to it) is what makes routing a real option. Same AGENTS.md, same skills, same permissions. Different model per role:

• Explore: a cheap, fast model for grep, file listing, and gathering context.
• Implement: a coding model for edits, tests, and refactors.
• Plan and review: a stronger reasoning model for architecture and catching the cases the worker will miss.

Cursor's SQLite mix is this idea with published numbers. Opus (or whatever you trust for planning) thinks. A cheaper worker does the volume. In that experiment the cheapest mix was about 7.5× less than the most expensive option on the table.

Self-hosting is a later decision. You gain data control and portability. You also own GPU capacity, uptime, security, upgrades, and SLAs. Start on a hosted open endpoint. Self-host when volume, residency, or resilience actually pays for that work.

Public leaderboards are a starting filter, not the eval. Models get trained to look good on those boards. Run the same spec, the same tools, the same retry budget, and the same review rules on a task you already do every week. Track pass rate, tokens, wall time, and human rework together.

When you should still pay for a larger model

The largest model, open or proprietary, is the wrong default when:

• The task is planning across a messy codebase, with tradeoffs the cheaper model will not notice.
• A failed run is expensive in human time, so one-shot quality is worth the token premium.
• You have already measured your own tasks and the cheap model does not follow the spec.

The strategy is not "switch everything to open-source because it is cheaper," and it is not "always use the best model." It is: match the model to the task. Stop sending formatting, search, and boilerplate to the most expensive API you have. Keep the expensive model for the work that actually uses it.

How to try this without a research project

Pick one recurring task: a migration, an API endpoint, a refactor you have done before. Run it on the model you already use, then on a smaller one, open-weight or not, in whatever agent can point at another provider. Kimi K3, DeepSeek V4 Flash, and GLM are easy open-weight starting points. Compare cost and the actual diff, not the vibes.

If you want a low-friction start, OpenCode Go is a $10/month subscription for a list of open coding models (the first month was $5 when I checked). OpenCode Zen is pay-as-you-go. Bringing your own key is the most control. None of that is mandatory. The mandatory part is measuring cost per finished task on your work.

For production inference, shop the hosted providers. In the session, people who had already moved production chat off OpenAI onto MixLayer reported about a 10× drop, using Kimi and GLM, with quality that was good enough and sometimes better after prompt work with the vendor. That is one team's number. Do the same comparison on your traffic before you commit.

The short version

Pick the model that finishes the task. Open-weight models are in that mix now, and they are cheap enough that defaulting to the largest option, proprietary or open, is usually waste. The single-shot test is the short version of that: DeepSeek and Kimi built the same project from the same spec, both followed the instructions, and the nicer layout from Kimi did not earn an 8× bill. Do not pick a model because the token price looks small, and do not pick the biggest model just because it looks safer. Measure successful work. Keep your harness independent of the vendor. Pay for privacy. Leave a stronger model in the loop for planning and for the cases where a cheap model fails the spec.

That is also how we scope AI work at A1 Lab. A prototype on real tasks tells you which model, which harness, and which monthly token bill you are actually buying. The cost ranges for infra and tokens still apply. Model choice is the lever that moves the monthly number fastest, once the system exists.

If you want help running that comparison on a real process, describe the task and the volume. That is enough to start.

See also:

• How much it costs to implement AI
• AI agents vs. automation
• Why prototype before the full project
• AI agents