Moonshot AI published the full weights of Kimi K3 on 27 July, after releasing the model in mid-July. Roughly 2.8 trillion parameters, a one million token context window, and benchmark results that sit behind the leading closed models without being far behind.
It went to the top of the trending charts within half an hour. Moonshot’s daily revenue reportedly grew by a factor of at least six since launch.
The interesting question for an agency is not whether it is good. It is good enough. The question is whether you should run it yourself, and the answer turns on something other than performance.
Key takeaways
- Open weights at frontier level change the deployment question, not the capability question.
- Self-hosting means no data leaves your environment, which resolves a real class of client objection.
- It also means you own the infrastructure, the uptime and the upgrade path.
- For most agencies the honest answer is a hybrid: hosted API by default, self-hosted for the accounts that require it.
What open weights actually buy you
Three things, and only one of them is about money.
Data never leaves. This is the big one. When a client in a regulated sector asks where their data is processed, “on our own infrastructure, and it does not leave” ends the conversation. No processing agreement to negotiate, no sub-processor list to maintain, no transfer mechanism to justify. For some accounts this is the difference between a project happening and not happening.
No dependency on someone else’s roadmap. A hosted model can be deprecated, reprised or repriced. Weights you downloaded cannot. If a workflow depends on specific model behaviour, owning the weights means owning the stability.
Cost, above a volume threshold. Per-token pricing beats infrastructure until it does not. The crossover point sits higher than most people expect, because the honest calculation includes the engineer who keeps the deployment running.
What it costs you
Running 2.8 trillion parameters is not a laptop exercise. You need serious hardware or a rented equivalent, and someone who understands inference optimisation, quantisation trade-offs and how to keep a service available.
That person is expensive and they are not doing marketing work while they do this. For most agencies, that is the real cost, and it rarely appears in the comparison.
There is also an upgrade tax. When the next frontier model arrives, a hosted API gives it to you by changing a string. A self-hosted deployment gives it to you after an evaluation, a migration and a re-tuning of everything you built on the previous behaviour.
AI FOR YOUR TEAM
Decide where your models should run
We help teams work out which workloads justify self-hosting and which do not, then build whichever setup the answer points to.
Where the crossover actually sits
The cost comparison gets quoted a lot and calculated rarely. Here is the honest shape of it.
On the hosted side you pay per token, and nothing else. No hardware, no availability to maintain, no upgrade project. The bill scales with use, which is uncomfortable at volume and forgiving when you are quiet.
On the self-hosted side you pay for capacity whether you use it or not, plus the person who keeps it running. That person is the line everyone forgets. They are not writing your prompts or building your workflows while they are tuning inference.
Two consequences follow, and they are what matter.
First, sporadic usage makes self-hosting badly uneconomic. Infrastructure sitting idle overnight and at weekends still costs what it costs. Most agency workloads are exactly this shape: heavy during reporting week, quiet otherwise.
Second, the crossover point moves with salaries, not with token prices. Every time a hosted provider cuts its rates, the argument for self-hosting gets weaker. Every time you hire someone able to run the infrastructure for other reasons, it gets stronger.
If you cannot say roughly how many million tokens you consume per month, you cannot run this calculation, and that is the first thing to fix.
How to evaluate it on your own work
If you do test it, test it properly. Published benchmarks tell you how a model ranks on tasks that are not yours.
Build a small set of your real cases. Twenty is plenty. Take work you have already done and whose quality you can judge: a monthly report you wrote, a set of ad variants you shipped, a client brief you turned into a plan.
Run them through the candidate model and through what you use today, blind if you can manage it. Score on whether you would send the output to a client after a light edit, which is the only threshold that matters commercially.
Two things this surfaces that benchmarks never do. How the model handles your specific vocabulary, client names and internal conventions. And how it behaves when the input is messy, which describes most real marketing data.
We have seen a model that ranks lower publicly win comfortably on this kind of test, because the task was closer to its strengths. The reverse happens too. Either way you learn something about your work rather than about a leaderboard.
The sovereignty argument, examined honestly
There is a strand of commentary framing open Chinese models as a sovereignty play: free frontier capability that reduces dependence on American providers.
The argument holds, with a caveat worth stating plainly. Downloading weights developed in China and running them in your own data centre creates no data transfer, because nothing leaves. The compliance question attaches to hosted APIs, not to the origin of a file you run locally.
What weights do carry is training data and alignment choices you cannot inspect. That matters less for summarising campaign performance than for anything touching content judgement or safety. Evaluate on your own tasks rather than on published benchmarks, because benchmark position and usefulness on your specific work are only loosely related.
Open weights do not make the model free. They move the cost from a per-token line to a headcount line. MyDigipal
What we actually recommend
For the large majority of marketing work, keep using a hosted API. The quality is there, the operational burden is zero, and your engineering time is better spent on the data layer that feeds it.
Self-host when one of three conditions is true. A client contractually requires that data stays in your infrastructure. Your volume is high enough and stable enough that the crossover maths genuinely works. Or you need a specific model behaviour frozen in place for a production workflow.
For everyone else, the useful takeaway is not “download Kimi K3”. It is that a credible open alternative at this level puts a ceiling on what hosted providers can charge, and that is good for you whether you ever run it or not.
If you are weighing this for a client account with real data constraints, our AI solutions team does the evaluation, and our training covers the decision framework so your team can run it next time. Before either, make sure the data feeding the model is consistent, because no model fixes contradictory inputs.
Sources: VentureBeat on the Kimi K3 release - Rest of World on open models and sovereign AI - Fortune on Kimi K3 benchmark position - Quartz on the open-weights download
