Live data from Hacker News

Kimi K2.7-Code: open-source coding model with better token efficiency

huggingface.co

171–180 of 254 posts

Re: Kimi K2.7-Code: open-source coding model with better token efficiency

#171

I wish they wouldn't call these "open source" models. The output weights are open but that's more analogous to a binary. The source would be the training data and techniques that went into producing the binary/weights. "Open weights" is also a term in wide use and accurately tells us what we're getting.

It's not quite as closed as a binary, it is very standard practice to take these models and fine-tune them.

If there were actually even close to frontier open source models, this would be more of a discussion, but everyone knows these mean open weight.

Re: Kimi K2.7-Code: open-source coding model with better token efficiency

#172

Earlier quoted context omitted.

Ah yes, those pesky Chinese backdoors that no single instance was ever found, even though Chinese open-weight model are a thing for many years now. Many people burn through millions of tokens on these models every day - surely someone would have triggered one of those backdoors, right? Or that pesky CCP censorship and propaganda baked into the model, which any random guy can remove from whichever model they want as a…

I agree it is an empirical question. I do not know if that research has been done in the open sphere. But please, do not pretend that there isn't a real geopolitical rivalry going on that makes such questions a legitimate, non-fruity concern.

Sure, but the difference is that one side (Anthropic, OpenAI, Google and co.) hoards everything, keeping it proprietary behind API paywalls and constantly spewing AI doomer rhetoric while limiting what you can do "for your own safety" (especially Anthropic; Dario has been consistently doing this since GPT-2 days, every time claiming that things are "too dangerous" for the common folk to handle). While the other side (big, bad China) releases all SOTA open-weight models with which you can do whatever you want with, along with a ton of open research.

So yes, there is geopolitical rivalry, but one side is deliberately antagonistic (not releasing anything in the open, putting arbitrary restrictions, spewing toxic rhetoric, applying sanctions, etc.) while the other side is letting everyone (including their rivals) to use what they've produced with little-no-to restrictions.

I'm under no illusion that if the situation was reversed China would most likely do the same, but as things stand you can probably guess which side I'm rooting for here (at least until the roles reverse).

Re: Kimi K2.7-Code: open-source coding model with better token efficiency

#173

Earlier quoted context omitted.

The difference in outcome isn't that big but yes, you need to be more rigorous. For instance I've found that the Kimi K2.5 and K2.6 models will comment out failing tests rather than fix a problem they just caused (mistaking them for "pre-existing failures"), so you need to specifically make commented-out tests break the build. I've not personally had that problem with any of the Anthropic or OpenAI models.

I wonder why it's the natural tendency of models to BS or do stuff like this when they don't have the correct answer - it's clear that they can program refusal into them, but for some reason, refusal has to be injected after the fact, and models can't really arrive at the conclusion that they can't answer properly.

I assume it's a lack of care when RLing them.

RL has a tendency to reinforce cheating when the cheats are easier to find than the final solution.

So when making your RL environment, you need to spend a lot of effort on finding ways the model can cheat and penalizing them.

Re: Kimi K2.7-Code: open-source coding model with better token efficiency

#174

Earlier quoted context omitted.

The model is natively quantized (i.e. it was trained that way in the first place, so this is not a post-training quantization which degrades performance).

But the huggingface link mentions BF16, F16, and I32?

I don't believe safetensors has a native int4 dtype, so they packed 4 int4s into a bf16 in this checkpoint.

Re: Kimi K2.7-Code: open-source coding model with better token efficiency

#175

Earlier quoted context omitted.

I really hope we stop using the term "Chinese models". It has this air of Negative connotation. It's the equivalent of calling cars Japanese, which people used to do but now is almost entirely meaningless. You just call them Toyota, Honda, Lexus etc.

I don't know, I tried using one of the Chinese models and it was VERY quick to scan my entire home dir, so maybe your threat surface is a little different than mine

Models can't scan anything.

They return instructions for you to do something, and you or a script you permit chooses to execute what the model tells you and return the result to the model.

Re: Kimi K2.7-Code: open-source coding model with better token efficiency

#176

Earlier quoted context omitted.

Anecdotal, but here's my experience. For personal stuff I use forgecode with openrouter. Firstly, forgecode is a much better harness than Cloude code (IMHO). Anyway, regarding the models, my experience is that there is not much difference in terms of quality, but the cost difference is insane. At least for how I use agents. Yesterday's example is the following: I am developing a small DSL for search across complex te…

I'm making DSLs a lot as an architecture pattern also. I'd be curious to know what stack you're using this and how you're approaching it

I am getting familiar with Rust and so I have been playing around with Quoth (https://github.com/sam0x17/quoth) for now.

It is very basic and I am no DSL expert, but my idea was to build a graph from those complex documents (maintenance manuals) a that to decide what tools can be used for a given part on a given equipment in a given situation. If there is a path from A to Z it means you can use that tool given the circumstances. Basically the DSL is about pruning the graph as you specify things. I could have very well done without, but it is a fun project to try out rust, so I said, why not :)

Re: Kimi K2.7-Code: open-source coding model with better token efficiency

#177
post #49

Earlier quoted context omitted.

This is the cursor callout. Don't make us shame you into disclosure

Cursor had a specific licensing agreement that allowed them to brand it how they want.

> Cursor had a specific licensing agreement...

Cursor had an "agreement" with Fireworks.ai, which apparently allowed them to RL Composer 2 atop Kimi Base 2.5 without attribution: https://x.com/Kimi_Moonshot/status/2035074972943831491 / https://archive.vn/CcdkI

Composer 2 performed differently on evals than Moonshot.ai's coding models: Cursor claims theirs is better than Claude Opus 4.6: https://x.com/fynnso/status/2034706304875602030 / https://archive.vn/bVtik. And, per Lee Robinson (Cursor employee), it is very likely Cursor builds its own foundational model for Composer 3.

Re: Kimi K2.7-Code: open-source coding model with better token efficiency

#178

Output tokens are almost 5x more expensive than mimov2.5 pro/dsv4pro. I’m curious to see if Kimik2.7 is that much better. Feels like kimi are positioning themselves as the premium open source models

I find that I don't use a ton of output tokens. I'm usually around 95% cached input, 4% input, and 1% output.

For me, the big thing with MiMo-V2.5-Pro and DeepSeek V4-Pro is that cached inputs are practically free. Kimi K2.7 Code is 53x more expensive for cached inputs which is 95% of my costs.

If I use 95M cached input tokens, 4M input tokens, and 1M output tokens, that'd be: $18 for cached input on Kimi K2.7 Code vs $0.34 with MiMo/DS; $3.80 for inputs on Kimi vs $1.74 with MiMo/DS; and $4 for output on Kimi vs $0.87 with MiMo/DS.

Of all the places where I'm accumulating costs by using Kimi, it's the cached inputs. The real savings with MiMo/DS's price cut is the cached inputs.

Re: Kimi K2.7-Code: open-source coding model with better token efficiency

#179
I just had Kimi K2.7-code rebase my Fil-C OpenSSL patch from 3.3.1 to 3.5.7 with quite bare bones instructions and it seems to have worked.

177KB patch, so it's not a small change. The patch did not apply cleanly initially; the agent had to do nontrivial work.

I just showed it the patch against 3.3.1, what command to use to build, and the path to 3.5.7 along with a link to the documentation of the change (https://fil-c.org/constant_time_crypto).

Note, I use my own coding agent (T800, which isn't public, and was previously well tested and tuned for K2.5).

I think this cost me between $5 and $10 in API usage.

(EDIT: OpenSSL, not OpenSSH)

Re: Kimi K2.7-Code: open-source coding model with better token efficiency

#180

Earlier quoted context omitted.

I agree it is an empirical question. I do not know if that research has been done in the open sphere. But please, do not pretend that there isn't a real geopolitical rivalry going on that makes such questions a legitimate, non-fruity concern.

Sure, but the difference is that one side (Anthropic, OpenAI, Google and co.) hoards everything, keeping it proprietary behind API paywalls and constantly spewing AI doomer rhetoric while limiting what you can do "for your own safety" (especially Anthropic; Dario has been consistently doing this since GPT-2 days, every time claiming that things are "too dangerous" for the common folk to handle). While the other side…

Yes, each are following their own business strategy, frontier labs have no incentives for releasing open weights, while second and third-tier labs, it is one of their few plays to gain market/mind share. But business is only part of it, as national security is another. It may be that the CCP has been relatively hands off exactly because of my concern, judging that market share and reputation is more important (for now).
Post reply on HN