Live data from Hacker News

Kimi K2.7 Code is generally available in GitHub Copilot

github.blog

151–160 of 201 posts

Re: Kimi K2.7 Code is generally available in GitHub Copilot

#151
post #57

Gotta say, I've lost all interest in cloud-based AI products. Too many cool features and workflows that I was once excited about that I can't or don't use anymore for a variety of reasons (price hikes, subjectively nerfed, disappeared altogether, replaced,...) for me to even remember. It's tiring. I've set up a small rig, mostly settled on Qwen3.6 and I'm slowly adding features myself. It probably can't compete with…

Same here, been happy throwing Qwen3.6 on my old MBP - no it's not as fast as Claude which I use at work, but it works well enough locally and I don't have to worry about credits or shit like the rug getting pulled under me in terms of capabilities.

Re: Kimi K2.7 Code is generally available in GitHub Copilot

#152
post #57

Gotta say, I've lost all interest in cloud-based AI products. Too many cool features and workflows that I was once excited about that I can't or don't use anymore for a variety of reasons (price hikes, subjectively nerfed, disappeared altogether, replaced,...) for me to even remember. It's tiring. I've set up a small rig, mostly settled on Qwen3.6 and I'm slowly adding features myself. It probably can't compete with…

I often feel like we're nowadays mostly pushing AI developments in the ways of finetuning differences. Like how new editions of Claude are tuned for agentic coding which might even be detrimental if you're using it for non-agentic coding. Or how Fable 5 in fact do look great but at a huge cost for inference and a high likelihood of post-launch nerfs or limit/price revisions. How Gemini 3.5 has more liberal limits but on the other hand underperforms a bit.

It's like we're mostly treading mud at this point. New editions are released, a version number increases, but I have to wonder if all steps are forward or they're more just tuned differently with similar actual perf per dollar as when this year began.

Most in fact seem to be happening to me with small models. Like your Qwen. Or Gemma 4 31B which is kinda magic especially when considering multilingual abilities. So yes, in that sense I can see "development" probably as we refine data sets and training methods but I see it less on the big hulking beasts with daily limits (unless you turn it up to 11 like Fable).

Edit: As I posted this, I saw a "before and after" comparison for Fable and the reintroduced version is seeing a catastrophic drop in BridgeBench performance as they're still mucking with the model. Go figure... https://x.com/Hesamation/status/2072692225100612032

Re: Kimi K2.7 Code is generally available in GitHub Copilot

#154
post #153

Much better value by using K2.7 Code with GitHub cli via opencode subscription - at $10/month gives you $60 worth of usage (for now) - you get $5 usage credits per day (with some weekly / monthly limits) ps opencode cli is quite nice too

If you want to get an extra $5 off for the first month (I'll get $5 too) https://opencode.ai/go?ref=XDHX30HEFB

Re: Kimi K2.7 Code is generally available in GitHub Copilot

#155
post #98

Earlier quoted context omitted.

> I am a huge fan of Copilot CLI. It just feels so logical and low-friction to use compared to Claude Code. Honest question, can you ellaborate? If given the option, I use OpenCode but what do you find in Copilot CLI that makes you prefer it to Claude Code?

It's a combination of small things really. The mentioned ability to easily call on various models in the same prompt, having agent definitions be able to orchestrate other agents just by mentioning it in the description, doing things like goal/loop automatically. There is also IMO a distinct difference in "tone" in the dialogue. Claude seems to impersonate a human a bit more than I like. Claude is of course very good…

Same mindset here. I really like the ability of having OpenAI, Anthropic and other models available.

For my personal work, I still use Claude Code as its cheaper and the limits don't bother me to much, but it feels a bit like being handcuffed to Anthropic vs being at work and freely selecting models.

Re: Kimi K2.7 Code is generally available in GitHub Copilot

#156
post #122

Earlier quoted context omitted.

Unified memory feels like the future of consumer hardware, agreed! Do check out r/StrixHalo

Agreed, it was a bit of a pain to get running on my Ubuntu machine because I had old amdgpu-dkms-firmware packages installed without realizing it. But now that it's running it's amazing how well it works

Sounds like you got it sorted, but more generally this may be interesting: https://github.com/kyuz0/amd-strix-halo-toolboxes

Re: Kimi K2.7 Code is generally available in GitHub Copilot

#157
post #57

Gotta say, I've lost all interest in cloud-based AI products. Too many cool features and workflows that I was once excited about that I can't or don't use anymore for a variety of reasons (price hikes, subjectively nerfed, disappeared altogether, replaced,...) for me to even remember. It's tiring. I've set up a small rig, mostly settled on Qwen3.6 and I'm slowly adding features myself. It probably can't compete with…

This sounds very appealing. What size Mac mini would I need for that?

A 4-bit quantization of either Qwen 3.6 27b or Gemma 4 31b will run on a 32GB Mac with a decent-sized, but not full-sized, context. 64GB gets you the full ~256k context and you don't need to quantize your KV cache (though 8-bit quantization of KV may be worth it for performance). The 4-bit QAT version of Gemma 4 has practically identical performance to the full size version or the 8-bit version in most benchmarks and my tests, so there's no reason to run anything else. The 4-bit Qwen is a little bit lossy, as it hasn't gotten the QAT treatment, but not catastrophically lossy. A 6-bit dynamic quantization would be better for that model, but it's ~25GB on disk, and you'll need more than 32GB to run it with a big context.

I wrote up how I run local LLMs, with numbers and a focus on running Qwen 3.6 and Gemma 4. I prefer Gemma 4 31b, even though the general consensus is that Qwen 3.6 is better for code, and it is better on most coding focused benchmarks...it doesn't seem to be for my use cases, Gemma feels smarter. And, with QAT, you get more smarts in less memory, so it's fast and runs on more hardware.

https://swelljoe.com/post/how-i-run-local-llms/

Currently, the sweet spot for self-hosted models is either Qwen 3.6 or Gemma 4, and those top out at 31B (Gemma) and 35B (for Qwen, but you want the dense Qwen 3.6 27B if you can run it as reasonable speed...the dense models are much smarter), so for now, a system with 64GB or 128GB is going to be running the same models. Going to a bigger model doesn't get you better performance because there aren't any better models that are a little bigger. I wish there was a ~70B or even ~120B MoE in the Qwen 3.6 or Gemma 4 families, as I've got a Strix Halo running a model that leaves a lot of memory on the table (and it's not very fast, to boot...an MoE would be faster, and hopefully smarter if it's a much bigger model, like double or triple sized).

In short, right now, 64GB is all you need for the best models you can self-host on anything short of five-figure machines, but, I wouldn't buy any hardware right now, if you can wait a while. Tokens from DeepSeek are so cheap, you can wait out the memory shortage and get access to models you could never host locally. And, OpenRouter always has free models in preview or just because that you can use lightly, as they're rate-limited (but your self-hosted models are going to be rate-limited, too, because a Mac Mini can't run models very fast). Google AI Studio has the Gemma 4 models for free too, also rate/usage limited.

Re: Kimi K2.7 Code is generally available in GitHub Copilot

#158
post #126

Earlier quoted context omitted.

The biggest appeal of the frontier models is for those trying to get autonomous agentic systems running that do real work with minimal human input. I went down a rabbit hole trying that with frontier models, and after a lot of initial promise it ended up actually slowing me down.

We've all been through that no? In the beginning you can do a ton of stuff without reading code. But the LLMs miss all the good abstractions, they just push and push unmaintainable code until at some point you start having more bugs and then you NEED that LLM to fix the codebase you don't understand anymore. There are guardrails you can and must add to protect your team if you take the vibe approach: a good type syst…

They're insanely good for prototypes though. To be able to actually see something working before deciding whether it's worth investing the time to build it for real is invaluable.

Re: Kimi K2.7 Code is generally available in GitHub Copilot

#159
post #135
post #49

Earlier quoted context omitted.

The price hike was insane. My $dayjob is moving away from Copilot and into Claude Code subscriptions. In parallel we are testing AWS bedrock and Deepinfra for open weight models in preparation for when CC inevitably stops being such a good deal and aligns with actual token cost. Fun times.

The price hike was insane yes, but because they were eating the price difference. How exaclty does moving to a Claude sub is better, when it's actually more expensive ? At my company we did the comparison and Copilot still wins: for 20$ you get a seat and 20$ of usage, whereas with Claude enterprise you get a seat and then usage is completely added. Moreover usage in Copilot is exactly the price of the providers AND…

Last month we consumed all the subscription credits by the 7th day, and had to top the extra credits up every 2-3 days. Last month was definitely not cheaper than a CC subscription. It actually triggered a cost savings effort across the Engineering org (cancelling subscriptions, stopping environments,...) in order to be able to afford AI usage which was not appropriately budgeted for ¯\_(ツ)_/¯

Edit: wording on the cost saving effort

Re: Kimi K2.7 Code is generally available in GitHub Copilot

#160
post #71

Earlier quoted context omitted.

I am curious if you implicitly assumed they are Macs or if that's what you are looking for specifically?

I assumed the 27B dense model would be preferable to a MoE model, and that it wouldn’t fit into a consumer graphics card, which leaves the Macs. Then I assumed for cost and battery/heat reasons that a Mini would be better than a laptop.

The current dense models from Gemma 4 or Qwen 3.6 families will run well on a consumer GPU with 32GB in a 4-bit quantization (which is a little lossy for Qwen 3.6, not so much for Gemma 4, as it has a QAT 4-bit version). Even an Intel ARC B70 will work, though it's worth spending a little more for a the AMD Radeon AI Pro 9700, as it'll be like 40% faster, I think. A dedicated GPU will be faster and cheaper than a Mac Mini. But, nothing is a good deal right now, everything is overpriced (except DeepSeek tokens, which cost pennies to run a model that's better than anything you could self-host...DeepSeek V4 Flash, and even Pro, are absurdly cheap, made even cheaper by their bonkers cheap cached token pricing and uniquely effective caching).
Post reply on HN