Dispatch: Kimi K3 licensing, Liquid AI, and stacked PRs on GitHub

Moonshot AI released the weights for its Kimi K3 model with 2.8 trillion parameters and a 1M token context window under a new Kimi K3 License, which allows inference providers like Modal, Baseten, Fireworks, DigitalOcean, RunPod, Together AI, and Databricks to offer it at a fixed price of $3 per million input tokens and $15 per million output tokens, matching Moonshot's own API pricing. This marks a shift from commodity pricing for open-weight models, as the license restricts how providers can price the model, potentially setting a precedent for AI model commercialization.

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 https://www.moonshot.ai/ published the weights for Kimi K3 https://huggingface.co/moonshotai/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 https://artificialanalysis.ai/models/kimi-k3 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 https://modal.com/blog/kimi-k3-by-moonshot-now-available-on-modal , Baseten https://www.baseten.co/blog/how-to-build-a-day-zero-api-for-kimi-k3/ , Fireworks https://fireworks.ai/blog/kimik3-on-fireworks , DigitalOcean https://www.digitalocean.com/blog/serving-kimi-k3-inference-engine , RunPod https://www.runpod.io/kimi-k3 , Together AI https://www.together.ai/blog/together-ai-announces-strategic-partnership-with-moonshot-ai-to-natively-serve-kimi-models , 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 https://technically.dev/posts/whats-an-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 https://technically.dev/posts/beginners-guide-to-open-source-licenses , but rather the innovatively named Kimi K3 License https://huggingface.co/moonshotai/Kimi-K3/blob/main/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 https://www.pcgamer.com/hardware/bambu-labs-go-f-yourself-3d-printing-company-currently-under-fire-for-reportedly-blocking-3rd-parties-from-its-software-legal-threats-and-drama-aplenty/ , 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 https://huggingface.co/moonshotai/Kimi-K3/blob/main/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 http://technically.dev/posts/whats-cloud . 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 https://artificialanalysis.ai/models/kimi-k3/providers 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 https://www.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 https://huggingface.co/blog/LiquidAI/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 https://openrouter.ai/anthropic/claude-fable-5 providers , although Opus 5 Fast’s 115 tps https://openrouter.ai/anthropic/claude-opus-5-fast is a better comp. Why? Like we’ve covered before, GPUs are very good at doing thousands of small calculations simultaneously https://technically.dev/posts/whats-a-gpu . That advantage is large when you’re training a model. But during inference https://technically.dev/posts/whats-an-inference-provider , if a model is small enough, you can eke out sufficient maybe better performance from a CPU https://technically.dev/universe/cpu-processor as well. So a laptop or a phone, or toaster https://www.youtube.com/watch?v=l Wf7SqBB4w 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 https://huggingface.co/LiquidAI/LFM2.5-2.6B/raw/main/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 https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/ , 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 https://www.reddit.com/r/git/comments/16nb8zj/launching graphite stacked git branches and pull/ 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 https://technically.dev/posts/what-are-code-reviews . 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 http://technically.dev/universe/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 http://technically.dev/universe/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