The specs, side by side
These two landed inside three weeks of each other. Both out of Chinese labs, both with published weights, and both carrying a million-token context window. That is roughly where the similarity ends. For background on either one alone, there's my Kimi K3 review, also a walkthrough of DeepSeek V3.2, which is the generation Flash grew out of.
| DeepSeek V4 Flash | Kimi K3 | |
|---|---|---|
| Released | 0731 build, July 31, 2026 | July 16, 2026 |
| Input, cache miss | $0.14 / 1M | $3.00 / 1M |
| Input, cache hit | $0.0028 / 1M | $0.30 / 1M |
| Output | $0.28 / 1M | $15.00 / 1M |
| Context window | 1M | 1,048,576 |
| Max output | 384K | 131,072 default, settable to 1,048,576 |
| Parameters | 284B total, 13B active | 2.8T total, 104B active |
| Input modalities | Text only | Text, image, video |
| Reasoning control | Non-thinking or thinking, thinking is default | low / high / max, never off |
| Licence | MIT | Kimi K3 License, commercial rider |
| Concurrency limit | 2,500 | Gated by account tier, not published |
| AA Intelligence Index | 50 | 57 |
| Cost per task | $0.03 | $0.86 |
| Median output speed | 113 tok/s | 35 tok/s |
| Total response time | 23.36s | 73.88s |
| AA-Omniscience hallucination | 84% | 51% |
One row in there is worth to pull out before I go further. DeepSeek's cache-hit rate sits at $0.0028 per million, a hundred times cheaper than Kimi's already-discounted $0.30. Caching switches on by default with no code change from you. DeepSeek is explicit that it's best-effort though, and entries clear "usually within a few hours to a few days", so it's a real discount that you shouldn't model as a steady state.
Price per token is the wrong number
Here is the trap with a comparison like this one. The rate card says Flash is 54 times cheaper on output. The rate card is not your bill.
Artificial Analysis publishes a metric that gets much closer, cost per task, which is the weighted average of what it actually costs to finish one job on their index. On that measure Flash is $0.03 and K3 is $0.86. Still an enormous gap, but 29x and not 54x, and the reason is that Flash burns through more tokens to get anywhere. It produced 210M output tokens running the full index, against K3's 130M, with both measured on a class median of 100M. AA calls Flash "very verbose". It calls K3 verbose too. They are both wordy, Flash is just wordier.
Running the whole index cost $72.02 on Flash and $2,437.41 on K3. Same nine evaluations, same work. If your habit is to think about AI spend as a monthly service cost instead of a per-token rate, that ratio is the one worth carrying around.
Reasoning tokens are what opens the gap between sticker and bill, and this is the part that most price comparisons skip over. Simon Willison ran his standard pelican prompt through K3 and then published the receipt:
"95 input, 16,658 output = 25 cents! [...] (13,241 of those were reasoning tokens.) I think that's the most expensive pelican I've rendered through a Chinese model so far."
Ninety-five tokens in, twenty-five cents out, and 79% of what he paid for was thinking he never read.
Both models bill reasoning at the output rate, and on both of them thinking is on by default, so this applies either way. It only costs 54 times more per token on one of them.
Worth to flag an honest complication here instead of pretending the measurement is settled. One developer who ran identical prompts through both found the verbosity comparison going the other direction:
"It says there that "Kimi K3 (Max)" would think/reason less than than deepseek-v4-flash, and a whole bunch of other models [...] but in my experience, K3 is probably the model that thinks/reasons the longest of all of these."
Both things can be true at once. AA's index is a particular mix of short evaluation tasks, and your workload is not that mix. Which is the actual lesson here, run your own prompts through both and count the tokens, since the published verbosity numbers are not going to transfer cleanly onto your use case.
On the cache argument though, this is where Flash gets hard to beat:
"I don't understand how DeepSeek can be so cheap with their cache pricing - ~0.003 usd / 1Mtok. 100x less than Kimi K3, or similar numbers against pretty much any other decently sized model to my knowledge. I've been using it whenever possible as even longer agent sessions cost few cents."
The middle option that isn't
This is the finding I would want if I were the one shopping, and it is on neither vendor's page.
Kimi shipped low and high reasoning levels sometime after launch, so K3 is not max-effort-only anymore. Obvious move is to reach for low and keep most of K3's quality at a fraction of the bill. Artificial Analysis measured that configuration separately, and it does not work.
Kimi K3 at low scores 47 on the Intelligence Index, at $0.24 per task. DeepSeek V4 Flash scores 50 at $0.03. The dialled-down K3 costs eight times more than Flash and scores three points lower. It is not even faster, 34 tokens per second against K3-max's 35, with a slightly worse total response time.
There's no price relief in it either, because the levels bill at the same rate. The Kimi K3 quickstart is blunt about what the dial does, in answer to whether you can turn reasoning off: "You can't, K3 always thinks. If the reasoning takes too long, set reasoning_effort to low." It's a latency control, not a cost tier. The saving is only whatever reasoning tokens you avoid.
So the choice is binary. Pay $0.03 or pay $0.86. Here's what that looks like at volume:
What each one bills at your volume
Artificial Analysis cost per task, multiplied out. Pick a monthly task count.
A "task" here is one Artificial Analysis Intelligence Index task, which is a proxy for your workload, not a match for it. Use it to compare the three options against each other, not to forecast an invoice.
Where each one actually wins
On raw measured intelligence K3 is ahead, and on the leaderboard it is not close. 57 against 50, seventh row overall, and the top-ranked open-weights model out of the 99 that Artificial Analysis tracks. Flash sits third among the open weights, behind K3 and GLM-5.2.
Moonshot's own launch charts tell a consistent story, and they are worth to read with one caveat in the mind.
The caveat is that DeepSeek isn't on that chart at all. Moonshot benchmarked K3 against Fable 5, GPT-5.6 Sol, Opus 4.8, GLM-5.2 and GPT-5.5, then left the cheapest serious open-weights competitor out of it. DeepSeek returns the favour, K3 does not appear on its charts either. Normal state of affairs with a vendor benchmark, and it is why the independent index does most of the work in this post.
Speed and throughput is where Flash wins outright. It runs at 113 tokens per second against K3's 35, first chunk in 1.33 seconds against 2.78, full response in 23.36 seconds against 73.88. There is a 2,500 concurrency limit on it as well. For anything interactive that difference stops being a footnote and becomes the product:
"Faster iterations are way better for me, I hate waiting for 5-10 minutes on small changes. I tried to use recent versions of Kimi and GLM, but they use too much thinking for no reason and are pretty slow because of it."
And the slowness holds up even for the people paying a top consumer tier:
"I'm still considering pulling the trigger on the annual subscription of Kimi for K3 but it's sometimes slower than I'd like (at least when compared to Anthropic) even on their Vivace plan"
On the Flash side, the most useful hands-on report I found ran sixteen real work tasks across four days against a much more expensive model. The result should temper anyone's assumption that cheap means weak:
"I benched DS4 flash and Pro vs opus 4.8 xhigh on 16 work-related tasks a month ago across 4 days. Opus 4.8 came out as a winner by 1 task only [...] But flash performed as well or better (as in being more thorough) in 13 out if 16."
One clean functional difference to note before moving on. K3 takes image and video input, while Flash is text only with no image input documented. If your workload involves screenshots then that decides the whole thing on its own, because multimodal input is not something you bolt on afterwards. Also worth knowing, K3 won't take a public image URL either. Base64 or an uploaded file id, nothing else.
Accuracy is the gap that matters
Everything above is arguable depending on the workload you have. This part is less arguable.
AA-Omniscience measures whether a model knows what it does not know. It rewards a correct answer, penalises the confident wrong ones, and gives no penalty for saying "I don't know". On that index, Flash scores −16 and K3 scores 18. Translated into a hallucination rate, Flash invents an answer 84% of the times it is out of its depth. K3 does it 51% of the time.
Neither number is good. One of them is much worse. And hallucination at this kind of rate is not a quirk that you prompt away, it is a property of the foundation model which you either design around or get bitten by.
People using Flash report more or less exactly what you would predict from a figure like that:
"DeepSeek V4 hallucinates like crazy and often forgets explicitly mentioned parts of the context. I guess compressing tokens and cherry-picking attention comes at a cost."
The fairest version of it came from one of the model's heaviest users, who is not really defending it so much as describing the scaffolding he built to survive it:
"It hallucinates plenty, about the same as Codex models and all other LLMs! I review all code it writes, thoroughly, check the test coverage, write tests myself, have other models/chats cross-check the work with a review skill"
That is the honest read. Flash works fine when a competent human reviews every output, and a coding workflow already has a compiler and a test suite plus a code review, all standing between the model and anything that matters. The cheap model works because the harness catches it. Take that harness away and you are leaning on the base model's own judgement, which is the exact thing an 84% figure is telling you not to do. It is also the argument for RAG over a raw LLM in any setting where the answer has to be right and not merely plausible.
Which is where I would flag the thing I keep running into in this job. I build AI agents at eesel, and we've spent years now putting them onto live support queues. The failure mode is never that the model is dumb. It is that the model is confident. A buyer put it to us better than I can, on a call about routing tickets to AI:
"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer, then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
That was a CX lead at a DTC supplements brand, running roughly 7,000 tickets a month on Gorgias and Shopify. We didn't win that deal and the objection above is the reason why. Notice how he never once asked what the model scored. He asked whether it would stay out of the way when it didn't know. A leaderboard hallucination rate does not answer that question, and neither vendor's page will.
In fairness, we have watched our own agents do the confident-wrong thing as well. Worst pattern we've logged in production was an agent narrating "executing Zendesk searches" for around ten turns without ever hitting the API once. Nothing kills the trust in a teammate faster than it lying about what it did, which is why we now simulate every rollout against a customer's own ticket history before it touches any live queue.
"Open weights" means two very different things here
Both models publish their weights. The word is doing very different work in each case though.
Flash is 284B total with 13B active, around 167GB of weights, under a plain MIT licence, and 57 community quantizations exist for it. That puts it into a different territory from most open-source agents at this quality level, and it is small enough that fine-tuning becomes a real option instead of a thought experiment.
K3's weights went up on Hugging Face on July 27, exactly the date Moonshot had promised, and the safetensors index confirms 2,779,931,837,184 parameters from outside of the press release. It is also 1,561 GB across 96 shards, with 104B active parameters.
The person who worked out that footprint added the part that matters:
"Most importantly, we now know that the model has 104B active parameters, which is quite a lot and will make it difficult to self-host efficiently."
The practical line between these two got drawn pretty cleanly over in the V4 Flash launch thread:
"And, at least flash can be ran "at home" with <10k in hardware, which isn't really possible / feasible with glm/k3 larger models."
And the maths on self-hosting K3 in order to save money does not survive a contact with the spreadsheet:
"At 5 tok/second, you're talking about around $195 worth of output tokens per month. There is no way I can run a usable K3 model for $195 a month of capex, opex, or any-kind-of-ex."
The licences differ as well, and this one has teeth. Flash is MIT, full stop. K3 ships under a custom Kimi K3 License carrying two riders. Managed-service operators above $20M revenue over twelve months need a separate agreement, and products above 100M monthly users or $20M monthly revenue have to display "Kimi K3" in the interface. Most readers are never going to hit either one. But if you are building a product on top, read it before assuming an MIT-like freedom, and factor it into whatever build versus buy call you are making.
What each vendor does with what you send
If the text you are sending is your own, skip this part. If it is your customers' text, this is the section that decides the whole thing, and the two vendors sit in quite different places.
Moonshot publishes a position, and it is permissive by default. Its terms of service, last updated May 27, 2026, say a customer wanting limits on training use "may contact Moonshot AI to discuss available enterprise arrangements or separate written agreements", and then this: "Unless otherwise expressly agreed in writing, Customer Content may be used for the foregoing purposes." Clear enough, and the escape hatch is a contract that you have to go and negotiate. Data sits in Singapore.
DeepSeek is the more interesting case, since it publishes a separate agreement for the paid API and that agreement says nothing at all. The Open Platform terms, effective April 29, 2026, carry an "Inputs and Outputs" section which runs to §4.2 and then stops. The consumer Terms of Use has a training clause at §4.3 of the same-numbered section, and the API document just omits it. That consumer clause is explicit that DeepSeek "may, to a minimal extent, use Inputs and Outputs to provide, maintain, operate, develop or improve the Services", with an opt-out toggle labelled "Improve the model for everyone".
So the accurate statement about the DeepSeek API is that it is silent, not that it is safe. The API terms describe themselves as a specific agreement under the general Terms of Use, and a specific term prevails only where there is a conflict. Silence is not a conflict. Neither document publishes a developer opt-out or a data-processing agreement or a zero-retention option, and the stored data sits in the People's Republic of China under PRC law.
In practice that means neither of these is a first-party drop-in for regulated or customer-identifying data without you having a conversation with a salesperson first, which for two self-serve APIs is a real friction. It's the same shape of problem teams hit over Slack's AI policy change, and if you're subject to SOC 2 or GDPR it's the first thing your reviewer will ask about. Routing through a provider that publishes zero-retention terms is the usual workaround, and it costs more than the rate cards above.
So which one should you pick?
I would frame this decision around one question, and it is not budget.
Pick DeepSeek V4 Flash when a human or a machine checks the output before it counts. Coding with tests and review, batch classification, bulk drafting, internal tooling, anything that you can re-run cheaply when it comes out wrong. At $0.03 per task with a $0.0028 cache-hit rate it is close to free, at volumes where K3 turns into a line item somebody asks about. It is the faster model by a factor of three too, which matters more than people expect on interactive work. This is also the one to pick when self-hosting is a real requirement and not just a nice idea.
Pick Kimi K3 at max effort when the output is the deliverable and nobody is checking it line by line. Long-horizon agent runs, research synthesis, the situations where being wrong is expensive and you are not going to catch it anyway. A 51% hallucination rate is still not a number I would build unsupervised workflows on, but it is a different category of risk from 84%. It is also the only one of the two that reads images.
Skip Kimi K3 at low effort. It costs eight times Flash and it scores lower. The thing exists to shorten your wait, not your bill. If K3-max is out of the budget then the answer is a different model rather than a quieter K3, and the Kimi K3 alternatives roundup is the place to start.
One last thing worth to say, because "Chinese lab" and "cheap" have collapsed into the same word across a lot of coverage, and for K3 they are not. Its $0.86 per task lands within touching distance of the Western frontier, and someone did that maths in the launch thread:
"According to artificialanalysis, cost per task is $0.94, which is almost the same as $1.04 of gpt 5.6 sol max [...] The model certainly sounds extremely impressive for something not from openai/antrophic, but the price makes it a mediocre product."
K3's figure has since settled down at $0.86, so the gap is a bit wider than he had it, but the shape of his point still holds. Claude Sonnet 5 sits on exactly the same $3/$15 rate card, and GPT-5.6 Sol is in the same neighbourhood per task. The cheap end of this market is Flash and its peers. Not the 2.8T flagships.
For the rest of the field, my Qwen 3.8 Max comparison covers the third lab in this race, while the V4 Pro piece explains why DeepSeek's cheap tier is currently outscoring its expensive one.
Putting either of these in front of a customer
Everything above is a developer's decision. But if you landed here wondering whether one of these can answer support tickets, the honest answer is that the model is the least important part of that system.
I say this as someone who builds the AI agents at eesel. A raw model with an 84% hallucination rate and a raw model with a 51% one both fail in the same way on a support queue, they answer things they should not have answered. What fixes it is not a better base model. It is grounding every reply in your verified knowledge, gating on a confidence score so the thing stays quiet below the bar, and knowing what will happen before it happens.
That's the difference between an AI support agent and a chat box wired to an API key. It's also most of why building it yourself takes longer than anyone budgets for.
That last part is the one worth borrowing whether or not you ever use us. eesel runs simulations against your real past tickets before anything goes live, so what you see is the actual accuracy on your own data instead of a leaderboard's, and you deploy only once it clears your bar. Routing a slice first works too. Handle 1,000 tickets a month, send 200 of them to the AI, you pay for 200. Billing is 40¢ per ticket resolved, there are no seat fees, and you never get charged for the tickets your humans handle. $50 of free usage to start, and no credit card.
It plugs into Zendesk and the other helpdesks, and it reads from wherever your answers already live, so that could be Confluence or a Notion space or just your public help centre.
Pick whichever model you like underneath. Only, don't let a benchmark score be the reason you trust it with a customer.
Frequently Asked Questions
Is DeepSeek V4 Flash or Kimi K3 cheaper?
Is Kimi K3 better than DeepSeek V4 Flash?
Can I run DeepSeek V4 Flash or Kimi K3 locally?
Should I use DeepSeek V4 Flash for customer support?
What is the Kimi K3 API price for a small team?
Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.
