Dispatch: Kimi K3 licensing, Liquid AI, and stacked PRs on GitHub
3 stories you might've missed from the last 2 weeks in software + AI.
Between product launches, model updates, new companies, giant funding rounds for so-called “business context for your agent” companies, and the dreaded license change, I can safely say that this is the craziest time for developer tools + infra news maybe ever.
We’re going to start breaking some of what’s happening down in the signature Technically style.
Today, we’ve got 3 news stories to break down:
Intrigue in AI model licensing
A new AI lab to watch
A newly accessible way to ship better code
Enjoy! Feedback welcome on this format.
Business model watch: open weight models as a service
A couple weeks back, the AI lab Moonshot published the weights for Kimi K3. It made waves for being fairly close in performance to frontier models from the big labs, but also because it carried with it a very…unusual new license.
The model has 2.8 T parameters, a 1M token context window, and is pretty smart according to the independent model analysis group Artificial Analysis (although they should start grading on a curve, 60 doesn’t inspire confidence).
Within a few days you could rent servers running it from Modal, Baseten, Fireworks, DigitalOcean, RunPod, Together AI, Databricks and probably others. You could not rent it from Blockbuster, because Blockbuster is, famously, out of business.
All of the providers charged the same rate for it, which is not-coincidentally the rate Moonshot charges through their API: $3 per million input tokens, $15 per million tokens out. This is drastically cheaper than the latest and greatest from Anthropic ($10/in, $50/out) and their ilk, while only being slightly less good.
Prior to this, open weight models were priced as a commodity. The inference provider, rather than the lab training the model, set the price. So they were pretty cheap to run, b/c competition (see Kimi 2.7 Code, Moonshot’s last model generation, above for comparison).
Why is this?
License innovation. Kimi K3 shipped not under the Apache 2.0 license (or any other flavor of open source license), but rather the innovatively named Kimi K3 License.
💰Sidenote: On open source commercialization
Licensing around open source stuff (code, now model weights + data) is the game within the game of enterprise tech.
Companies are constantly jockeying for position - a more permissive open source license grants the company a distribution advantage, a closed source license maximizes revenue. There’s a constant tension within orgs participating in the open source ecosystem between the 2 poles of distribution + commercialization.
Each time you sway too far in one direction or the other, the company is less fun to run, so you try to stay balanced somewhere in the middle. It’s like the opposite of a see-saw.
I’m not a lawyer, but I did watch Law & Order a few times, so let’s try and unpack this:
The Kimi K3 license stipulates that if you:
Run a “Model as a Service” business (like those inference providers above)
Clear $20mm in revenue over 12 months (unclear whether that’s total, or just with a Kimi K3 service, lawyers help me out)
Are not a “certified partner”
Then you need to negotiate a (presumably commercial) license with Moonshot.
This is basically the freemium model, but for the relationship between frontier AI labs + inference providers. To be clear, you as a user (or developer of AI products) must pay either way (to buy your own chips, or more likely rent them from a cloud provider).
But why bother with all this complexity? If you’re Moonshot, why not just be like OpenAI and Anthropic and rent out your model directly to users / developers as an API?
Because the inference providers are much better than a lab like Moonshot at, well, inference.
When Moonshot released Kimi K3, the overwhelming demand for that piping-hot 60 intelligence score left them unable to keep it online:
So, the splendor of comparative advantage unfolded.
Moonshot worked with the inference providers to package up their model as a service, to deliver it reliably. And that’s actually great in other ways too.
The inference providers are competing on speed (in terms of tokens/second, tps), which they achieve by optimizing every tiny little piece of the system (eeking out literally tiny edges in performance, it’s impressive engineering work). This is what they do well, about 4x faster than Moonshot in Modal’s case (with Fireworks and others not far behind).
Company to watch: Liquid AI
Kimi K3 (as mentioned above) needs about 1.4TB of memory and some of NVIDIA’s newest GPU chips to run.
Liquid AI is an AI lab going the other way, training models that run on your device (on the mythical edge) on a plain old CPU. I try to not run on (or near) edges, but we can talk about that another time.
Last week they released LFM2.5-2.6B. It’s a paltry 2.6B parameters (Anthropic’s Fable is rumored to be in the trillions), and ergo fits on 2.5 GB of disk, which my laptop and phone hypothetically should have if I cleared videos properly out of my iMessage.
It’s also fast - Liquid AI reports 220 tokens/second (tps) on an M5 Max. Like actually fast - Fable is 40 tps according to OpenRouter, although Opus 5 Fast’s 115 tps is a better comp.
Why?
Like we’ve covered before, GPUs are very good at doing thousands of small calculations simultaneously. That advantage is large when you’re training a model.
But during inference, if a model is small enough, you can eke out sufficient (maybe better) performance from a CPU as well.
So a laptop (or a phone, or toaster) with enough RAM (again, not mine, but hypothetically someone’s) can run a model like LFM2.5.
I can’t speak to how great of a model LFM2.5’s is, and tbh it doesn’t really matter. You are almost certainly not going to use it, I am not going to use it, but, BUT! You will very likely use a similar model, running on your device, quite soon, and it’ll unlock new AI use cases + business models.
One interesting sidenote: LFM2.5’s license allows you to run the model as part of your commercial product, so long as your company makes less than $10mm.
>$10mm in revenue, you need to negotiate a license with them. Seems pretty fair, and we need a way for smaller AI labs to be commercially successful (or else we’ll have less innovation).
New tool alert: Stacked pull requests on GitHub
Last week GitHub released stacked pull requests, and if you use a coding agent it’s worth checking out.
To understand why, let’s go back to the early days of coding agents - when Cursor was just a few months old, and the brief but monumental “Cursor for X” startup wave hadn’t yet washed ashore.
It was September 2023, and a startup called Graphite (later acquired by Cursor later acquired by SpaceXAI) launched stacked git branches and pull requests for their GitHub integration to little fanfare.
They were early to a problem that coding agents created:
Coding agents can write a lot of code quickly.
You + your team can not review that code as quickly.
A coding agent’s code is like those crab legs you ambitiously scooped up at the Wynn buffet in Vegas. Fun at the start, tedious AF at the finish.
There are 3 solutions to this:
Don’t review the code and just ship it to production anyway (YOLO mode).
Have AI review the code. Lots of startups (including later Graphite) and now every coding agent do this.
Split the code into smaller chunks that are easier to review.
#3 is a useful approach in any area of work, but the problem comes when those small chunks of work depend on each other.
You have to then keep track of the order in which those changes need to be shipped, and that becomes difficult on a team.
Stacked pull requests codify the order in which changes need to be deployed.
So you (more likely your coding agent) can lock in small wins, then when you’re ready to actually deploy your big batch of work, GitHub (or any git provider that supports stacked PRs) will merge those dependencies in the right order.
If we’re going to enlist coding agents to work independently for long periods of time, these are the types of DevOps adaptations we need to keep them on track.
–
This is all just our take though. Wdyt?
And thanks to our faithful Technically correspondents, especially Sam Schneider, for their notes.
-David, Justin and the Technically team