This is the first post in the JJ’s LLM Insight series. The series is built on real experience navigating the LLM market and will cover the more trend-relevant technical stuff around it. Along the way, I’ll also walk through, one post at a time, the advantages Kimchi brings to the table given where the market is heading.

---

Okay, real talk – is there even a winner in the frontier model war?

Between September 1st and 3rd, 2026 – just 72 hours – four frontier models dropped back to back. Anthropic’s Claude Fable 5.1 (Sep 1), Meta’s Muse Spark 1.3 and Google’s Gemini 3.8 Flash (Sep 2), and OpenAI’s GPT-6 Astra (Sep 3). People in the industry were genuinely saying things like “this might be the most packed release cycle ever (positive crazy!).”

 

Model	Developer	Context	Input price / 1M tokens	Output price / 1M tokens	AA Intelligence Index
Claude Fable 5.1	Anthropic	1M	$10	$50	~66
GPT-6 Astra	OpenAI	1.05M	$10	$50	~61
Muse Spark 1.3	Meta	1M	$1.25	$4.25	~61–62
Gemini 3.8 Flash	Google	1.05M	$0.75	$3.75	~59

(Based on the Artificial Analysis Intelligence Index, as published in September 2026.)

 

What actually matters in this table isn’t the ranking – it’s how scattered the results are. If you break it down benchmark by benchmark, here’s who actually takes the top spot:

Benchmark (what it measures)	#1 model	Score	How the rest compare	Source type
General intelligence (Artificial Analysis Intelligence Index)	Claude Fable 5.1	65.7	GPT-6 Astra 61.2, GPT-5.6 Sol 60.9, Claude Opus 5 63.1	Independent third-party
Coding (Artificial Analysis Coding Agent Index)	Claude Fable 5.1	70.4	GPT-6 Astra 67.0, Muse Spark 1.3 64.2	Independent third-party
Math (FrontierMath Tier 4 v2)	GPT-6 Astra	97.6%	Claude Fable 5.1 87.8%, GPT-5.6 Sol 83.0%, Claude Opus 5 73.2%	OpenAI self-reported
Cybersecurity (ExploitBench)	GPT-6 Astra	100%	GPT-5.6 Sol 78.5%, Claude Opus 5 70%	OpenAI self-reported
Computer use (OSWorld 2.0)	GPT-6 Astra	72.6%	Claude Opus 5 70.2%, GPT-5.6 Sol 65.7%	OpenAI self-reported
GPQA Diamond (grad-level science knowledge)	GPT-6 Astra	95.8%	Gemini 3.8 Flash 95.4%, GPT-5.4 Pro 94.6%	BenchLeader independent verification (as of 2026-09-18)

So to sum it up: Claude Fable 5.1 leads on general intelligence and coding, while GPT-6 Astra takes the crown on math, cybersecurity, and computer use. GPQA Diamond is basically a toss-up between Astra and Gemini 3.8 Flash – both sitting in the mid-90s, which really just tells you the benchmark is close to saturated at this point. Worth flagging: the math, cybersecurity, and computer-use numbers are all self-reported by OpenAI. The general intelligence index, the coding index, and GPQA Diamond, on the other hand, come from independent outfits like Artificial Analysis and BenchLeader – so they’re not the same caliber of evidence, credibility-wise.
And here’s the kicker: Gemini 3.8 Flash costs roughly 1/13th of Fable’s price, yet it still lands a close second on GPQA Diamond. That’s what makes its price-to-performance ratio stand out so much. Bottom line – whoever’s “#1” keeps flipping depending on which benchmark you pick.

So the conclusion the industry keeps landing on is basically the same everywhere: the question isn’t “which model is the best” anymore, it’s “which model goes on which job.” A bunch of analysts are all converging on the same advice – split your workloads across models (workload segmentation) instead of betting everything on one.

But there’s a question that keeps getting left out of this routing conversation: what exactly are you feeding these models, and where does that data actually go?

---

What is open-weight, anyway? “Downloadable” and “fully transparent” are two very different things.

People usually frame this as “open source vs. closed,” but in reality there are three tiers.

Component	Closed (GPT, Claude, Gemini)	Open-weight (Kimi, DeepSeek, GLM, etc.)	Open source (per OSAID 1.0)
Weights	Private, API access only	Public, downloadable	Public
Training code	Private	Private	Public
Training data	Private	Private	Public, or detailed enough info to reproduce it
Self-hosting	Not possible	Possible	Possible

The Open Source Initiative (OSI) published the Open Source AI Definition (OSAID 1.0) back in October 2024, and it requires all three things – weights, training code, and training data info. Almost no LLM actually clears that bar. Even Meta’s Llama doesn’t release its training dataset, so it doesn’t qualify as “open source” – and Meta itself declined to endorse OSAID. In other words, most of what the market casually calls “open” is really open-weight. You can get the weights, but how they were actually produced stays a black box for the most part.

There’s one more distinction worth making here: what gets released and what you’re allowed to do with what’s released are two separate questions. Llama, for instance, releases its weights, but its license bans companies with over 700 million MAU from using it. DeepSeek and GLM, on the other hand, release their weights and ship under MIT, so there’s basically no restriction at all. Lumping everything together under “open” hides just how different the actual terms are, model to model.

Still, there’s one thing open-weight models all share in practice: once you have the weights in hand, you can run that model on your own infrastructure. That one line is really the whole point of the next section.

---

The structural weak spot of frontier models – for enterprise LLM use, security can matter more than raw performance.

Using a frontier model through an API means, by definition, that every prompt and every response passes through the vendor’s servers. That’s true regardless of how good the model is, and for certain industries and organizations, it’s a structural problem in its own right.

First, the mere fact that your data crosses into someone else’s infrastructure is a risk by itself. Every API call sends your internal code, customer data, and internal documents off to a third party’s servers – and that server might not even sit in the country where the data is supposed to be used. Even if the vendor’s terms say “we don’t train on your logs,” the fact that your data physically passed through their cloud can’t be undone after the fact. In industries like finance, healthcare, defense, and the public sector, where regulations flat-out prohibit data from leaving the building, this alone is often where adoption stalls.

Second, vendor policy is a variable you don’t control. Data retention windows, who can access the logs, the terms of service – the vendor can change any of it whenever they want, and you find out after the fact. On top of that, legal demands from whatever jurisdiction the vendor happens to operate in (a law-enforcement subpoena, say) can override whatever your contract’s privacy clause promises. That’s not a contract problem – it’s a jurisdiction problem.

Third, you end up with a single point of failure baked into your supply chain. Any API-based workflow is ultimately at the mercy of the vendor’s uptime. Outages, pricing changes, country-specific service restrictions – none of that is your call, it’s theirs. And the longer your agentic workflows run, the more that dependency costs you.

Fourth, there’s no way to audit it. With a closed model, you simply can’t verify what it referenced or how it arrived at a given answer. Compliance audits in regulated industries routinely ask “what data and what logic produced this decision” – and a model hidden behind an API can’t fundamentally answer that.

---

What open-weight offers instead: “your data never has to leave in the first place”

What open-weight models actually give you isn’t just “free” or “cheap.” It’s more accurate to say they offer a fundamentally different security model.

• Self-host it, and data never leaves at all. Prompts, responses, internal code – none of it crosses outside your company’s infrastructure. The question “how much do I trust this vendor” simply gets replaced by “the data was never sent out to begin with.” Some open-weight models have actually been banned in certain countries over security concerns – but self-hosting removes that specific risk, since the underlying problem was data flowing to the vendor’s own servers, not the weights themselves.
• It can run fully air-gapped – no internet required. Download the weights, deploy on-prem, and you can run the whole thing with zero outside network connection. In finance, defense, and public-sector environments where internet access itself is regulated, this is often the one factor that decides whether a tool can be used at all. (More on this later in the series.)
• A permissive license means zero vendor lock-in. Models released under MIT or Apache 2.0 – GLM, DeepSeek, early MiniMax M2, and so on – aren’t affected by pricing changes or service shutdowns, because you’re the one controlling the infrastructure.
• You can actually audit and reproduce it. With the weights in hand, you can reproduce exactly why the model produced a given output for a given input, and your internal audit team can verify it directly. NVIDIA’s Nemotron takes this even further by shipping training data and recipes alongside the weights (under the OpenMDW-1.1 license), which makes it that much more transparent.
• You can fine-tune on your own data without it ever leaving the building. Fine-tuning a closed model means uploading your domain data to the vendor’s fine-tuning API. With open-weight, the entire training loop stays inside your own infrastructure.

Of course, none of this comes for free – it’s a real tradeoff. Self-hosting an open-weight model takes serious GPU infrastructure and ops know-how, and there’s still a genuine capability gap versus the top frontier models on certain tasks. But “performance” and “data sovereignty” are two entirely different axes, and for regulated industries or security-first organizations, the latter often outweighs the former.

---

Five open-weight models worth watching right now (as of Sep ’26)

All five models below have publicly released weights, meaning they can be self-hosted – and each one takes a different approach to the same underlying question: how do you get frontier-level performance out of an open-weight model?

Model	Developer	Architecture	License	Core strategy
Kimi (K2 line)	Moonshot AI	MoE, 1T total / 32B active	Modified MIT (per K2 Thinking – attribution required above $20M monthly revenue or 100M MAU)	Built for ultra-long agentic tool-call chains (200–300 sequential calls)
MiniMax (M2 line)	MiniMax	MoE, 230B total / ~10B active	MIT, with commercial restrictions tightened starting M2.7	Minimizes active parameters to make single-node self-hosting realistic
GLM (4.x/5.x line)	Zhipu AI	MoE, ~355B total / 32B active	MIT – the most consistently permissive of the bunch	Tuned for coding and tool use, with a free Flash tier lowering the barrier to entry
DeepSeek (V3.2/V4)	DeepSeek	Sparse Attention (DSA), Causal Encoder-Decoder	MIT	Cuts serving costs by aggressively shrinking the KV cache each generation (~389KB → 890B per token)
Nemotron (3 Ultra/3.5)	NVIDIA	Mamba-Attention hybrid, 550B total / 55B active	OpenMDW-1.1 – releases weights, data, and training recipes	Keeps a fixed-size KV cache even at long context lengths; the most open license among these five

I’ll go deeper into each model’s architecture, benchmarks, and license terms in future posts.

---

Where does CAST AI’s Kimchi fit into all this?

As we’ve covered, the market’s central question has shifted from “which model is the best” to “which model, for which task, under what security constraints.” Kimchi is an AI coding agent built to answer exactly that question head-on. It isn’t locked into a single model – it runs multi-model orchestration so you can pick the right model per task, uses a sub-agent architecture that splits exploration, planning, implementation, and review across separate agents to avoid context pollution, and supports deployment flexibility spanning everything from open-weight models to fully self-hosted environments. You can find the full breakdown in the docs: https://docs.kimchi.dev/

---

Up next

This post covered why open-weight can be the structurally better choice. Next time, I’ll look at how these open-weight models are actually being used in the real AI coding agent market (Cursor, Copilot, Claude Code, etc.), and what problems those tools still haven’t solved.

---

(Note: most of the benchmark numbers in this post are self-reported by the respective companies and may differ from independent third-party verification. License terms reflect publicly available documents as of the research date (September 2026) and are subject to change – if you’re evaluating adoption, double-check the latest license text yourself.)