Live data from Hacker News

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

huggingface.co

61–70 of 254 posts

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

#61
post #30
post #14

Earlier quoted context omitted.

The Kimi problem is it doesn’t follow instructions and goes off track often. Other than that it’s pretty decent (for the price).

Sounds like it was distilled from Claude. I don't understand the appeal of an agent that does whatever it wants.

If you ask Claude in Chinese to introduce itself, it will claim it's Kimi :)

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

#62
post #43

Personally, when I use open code or routers, I feel that beyond a certain level, the models don't make a huge difference to me. Except for expensive and mediocre models like Gemini. In that sense, Chinese models are pretty good. I usually write code in function or method units and then design and assemble them together. GPT series models are more thorough and better, but I'm not sure if the difference is enormous. It…

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.

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

#64
post #43

Personally, when I use open code or routers, I feel that beyond a certain level, the models don't make a huge difference to me. Except for expensive and mediocre models like Gemini. In that sense, Chinese models are pretty good. I usually write code in function or method units and then design and assemble them together. GPT series models are more thorough and better, but I'm not sure if the difference is enormous. It…

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.

You are right. I agree.It may seem like a kind of bias, but I hadn't thought of that part. Thank you for pointing out my bias.

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

#65
post #2

I was wondering how does Anthropic and likes keep competitive when Opus is ($5 / $25) 5x times more expensive compared to Kimi K2.6 ($0.7 / $3.4) or other Chinese models, while being only marginally better. My theory is that US enterprise just can't send data to Chinese and that's understandable, but is that "the moat"?

API token price is one thing, but subscriptions on Claude are a good value. Weirdly everyone says that Claude subscriptions are subsidized because of the API price, even though (1) no one actually knows Claude's cost of inference, and (2) Chinese providers are also able to provide cheap inference, so why do they think Claude can't?

I also wonder if Enterprises have deals for other API pricing that is not posted publicly, so all we see is a high API sticker price.

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

#66
post #49

Earlier quoted context omitted.

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

Ah is that what it is? I don't use Cursor, never saw it as being relevant to me, but would not surprise me.

Cursor's composer models are finetuned kimi

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

#67
post #3

I am still very new to the open-weight/source models. If anyone is using them full-time, I’d really love to hear about the setup and how they perform, as I am considering moving my org off Anthropic products.

I created this and I would say glm-4.7 accounts for 80% of the code in https://github.com/gitsense/gsc-cli

If you look at a file like:

https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r...

you can see that I attribute the models used. What I found was 4.7 was not very good at `go` code which was why you started to see `Gemini 3 Flash` in the attributions.

4.7 is what Cerebras provide and for me, speed in iterations is a lot more important. Having played around with MiMo v2.5.0-Pro, I am 100% sure it could have done what Gemini 3 Flash did.

There were a few points where I was stuck and needed Sonnet to explain things to me, but I think the dirty secret that Anthropic and OpenAI won't tell you is, if you know how to code, the models are honestly good enough.

Based on my experience with MiMo and what others are saying about GLM 5.1, we are now in a hardware race. The Chinese Models are 100% drop in replacement for Claude if you know how to program but want to AI to help amplify what you know. What I will consider now is what provider can provide the fastest inference.

MiMo-v2.5.0-Pro-Ultraspeed is really good at generating good results quickly and burning your money as fast.

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

#68

Earlier quoted context omitted.

Ah is that what it is? I don't use Cursor, never saw it as being relevant to me, but would not surprise me.

Cursor's composer models are finetuned kimi

They are unusable (unless you want to deliberately destroy your codebase). So if Cursor's models are Kimi based, then well. I'll skip them altogether.

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

#69

I think any new model not demonstrably maybe 20-30% over Deepseek v4 capabilities priced over the price per token of Deepseek is almost automatically deprecated as low use model (maybe for Planning).

Is Deepseek just eating cost or are people able to host their open models for comparable costs?

These things enormously benefit from economies of scale. I am fairly certain their margins might be low but they don't actually sell API at loss, however that doesn't mean your cost footprint would be anywhere as low.

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

#70

Earlier quoted context omitted.

Cursor's composer models are finetuned kimi

They are unusable (unless you want to deliberately destroy your codebase). So if Cursor's models are Kimi based, then well. I'll skip them altogether.

I wouldn't skip at least testing the original. Model distilling done by Cursor could be the culprit.
Post reply on HN