.svg)
.svg)
Free guide for CIOs and engineering leaders
How to cut your AI coding costs without switching models
Open-weight models are now within five points of the frontier on agentic coding. However, that doesn’t mean self-hosting them will save you money. This guide gives you the math, the meaningful benchmarks, and a six-step plan to cut spend without giving up capability.
Written by FullStack engineers who run this decision for clients every week. No vendor sponsorship. 40+ sources, all checked August 2026.
Why now
AI models are changing too rapidly for Enterprise Procurement to keep up
A few months ago, the gap between open-weight and frontier models made the decision feel more straightforward. On the August 19th Terminal-Bench 2.1 leaderboard, Kimi K3 scored 80.9%, compared with 85.8% for the top model at the time. Now, the gap is narrow enough that boards are asking why the company is still paying frontier-model prices while engineering teams consider what it would take to run an 8-GPU node themselves.
The model choice is only part of the cost picture. In software development workflows, prompts can carry far more than a developer’s request: system instructions, tool definitions, repository context, and prior work all add tokens. Agents may retry failed steps, and new sessions can require the agent to rebuild context before it can continue.
This guide looks at how to compare frontier and open-weight models with the numbers that affect production decisions: workload fit, infrastructure costs, token usage, reliability, and the operational work required to run either option.
What’s inside
Key Findings
814 tokens per second, every second of the month.
That’s what an 8×B200 node would need to sustain to match Kimi K3’s API price. Most coding workloads idle at night.
$10 vs. $200 per million tokens.
The same self-hosted model costs about $10 per million output tokens at 100% utilization and about $200 at 5%.
10 to 26 points from the harness alone.
Change the agent harness and the same model’s coding benchmark score moves more than the gap between the models you are comparing.
SWE-bench Verified is retired.
59.4% of audited problems had flawed tests, and models could reproduce full diffs from task IDs alone. If a vendor comparison is built on it, don’t use it for procurement.
A 10% price cut moves usage 0.5%.
Teams don’t switch on price. They switch when switching is safe, measurable, and reversible.
5% to 60%.
Coinbase’s cache-hit rate went from 5% to 60%, and spend roughly halved while token usage grew.
Key takeaways from this guide
After reading this guide, you’ll be able to:
Tell open weights and self-hosting apart and price each one for your actual workload, so nobody on your team confuses a cheaper API with a GPU purchase.
Run the break-even math on any model using the utilization curve, the published API price, and your real token volume, before anyone requests hardware.
Read a benchmark without being fooled by contaminated tests or harness effects, and know which numbers (SWE-rebench, SWE-bench Pro, Terminal-Bench 2.1) apply to which kind of work.
Decide which of the four operating models fits each workload: Frontier API, hosted open-weight API, self-hosted open weights, or a fine-tuned proprietary model.
Stand up a control plane in 30 days: One gateway, routing rules in configuration, an eval set built from your own work, and three numbers you can defend to your CFO (token mix by task, cost per completed task, cache-hit rate).
Who this guide is for
CIOs, CTOs, and VPs of Engineering whose AI coding spend is growing faster than their engineering team. Heads of Platform and AI Engineering who own the gateway. FinOps and procurement leads who own the bill. Security and legal teams who need a clear view of model origin, hosting jurisdiction, and the supply-chain risk inside a downloaded model package.
If you’ve ever been asked “why don’t we just self-host DeepSeek” in a leadership meeting, this is for you.
From the engineers who wrote it
It’s not necessarily a question of ‘do I change the model out here.’ It’s that your context is not efficient for the model to consume, and you’re starting over with fresh context every single time you kick a task off.
Most people use Opus for everything, and that’s why the costs are really, really high.
Table of contents
Start here: the four common paths (comparison matrix)
Five things to know before you choose a path
Separate open weights from self-hosting
Analyzing the bill before you change models
The capability gap depends on the task
Where open weights make sense first
Self-hosting usually doesn’t save money on coding workloads
Why price isn’t the whole decision
What to do next: building the control plane first (six steps)
What we still don’t know, FAQ, and a fully sourced bibliography
Two ways to get the guide.
Read it yourself. Enter your name and work email, and the PDF is yours. There’s no sales follow-up unless you ask for it.
Talk it through with us. Book a 30-minute call with FullStack. We’ll walk through where your spend is going and what a control plane would look like for your stack. As a thank-you for your time, we’ll send you a pair of Apple AirPods.*
*Note: One pair per company. Offered to engineering, technology, and finance leaders at companies with 200 or more employees. AirPods ship after the call takes place. Not available where prohibited by your employer’s gift policy.
Get the guide
FAQ’s
Is self-hosting an open-weight coding model cheaper than the API?
Usually not at realistic utilization. Kimi K3 needs an 8×B200 node at about $32,100 a month, and break-even is about 2.14 billion output tokens a month. Self-host for a hard data boundary, not because it sounds cheaper.
Where does the quality gap still matter?
TODO — answer copy needed (not provided in the Figma design).
Do we have to build the routing layer ourselves?
TODO — answer copy needed (not provided in the Figma design).
Is the guide sponsored by a model vendor?
TODO — answer copy needed (not provided in the Figma design).