Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kimi K3-256k

kimi.com

Post reply on HN
Print view View original

131–140 of 172 posts

Re: Kimi K3-256k

#131

Post by versteegen »

verdverm wrote: post #101
okrad wrote: post #61

Earlier quoted context omitted.

I believe Codex harness is pretty sticky though I haven’t tried many others. Does anyone else provide a harness of that quality?

opencode is highly regarded, I use it exclusively

...but we're talking about compaction, and opencode's compaction is (or was) terrible. I've seen so many horrible problems that I keep it disabled (with an envvar flag, because even the config flag to turn it off was broken).

Re: Kimi K3-256k

#132

Post by k__ »

HawtAds wrote: post #5

This is just an API level change right? The model itself should be the same I think.

As I understand it, they would have to train a whole knew model to hard cap it's context to different lengths. That would be cheaper to train and had cheaper inf, but still a huge investment.

So I'd guess it's API level.

Re: Kimi K3-256k

#133

Post by k__ »

Gigachad wrote: post #130
trollbridge wrote: post #102

Earlier quoted context omitted.

It's pretty handy for have very long contexts for long running agents, or else when doing literary analysis to simply be able to load the entire book in.

Don’t they compact context to remove irrelevant details automatically?

They remove potentially irrelevant details.

Re: Kimi K3-256k

#135

Post by k__ »

jsemrau wrote: post #95
timcobb wrote: post #88

Codex uses 256k masterfully, 1M is luxurious but still quite expensive and seems not necessary as a default.

Needing large context windows is an illusion.

While I tend to clear my session after every task, I feel less stressed when my context is as 10% than when it's at 30%

Re: Kimi K3-256k

#136

Post by Mastodo »

cybersec47 wrote: post #106
timcobb wrote: post #88

Codex uses 256k masterfully, 1M is luxurious but still quite expensive and seems not necessary as a default.

> Codex uses 256k masterfully This. When working on hard problems (not "vibecode me a script to show an alert box", but e.g. "let's see what this three-level LUT-state-machine obfuscated binary does"), hitting the 1M (!) context window with Claude Code feels like you were talking to Claude Claudewski when his shift just abruptly ends, he packs his things, throws the office keys at Claude Claudeson in-between the fron…

[flagged]

Re: Kimi K3-256k

#137

Post by SwellJoe »

I make a point of never going beyond about 220k, unless absolutely necessary (and it's almost never necessary), anyway, even with models that degrade more slowly, so this is just a discount.

Re: Kimi K3-256k

#138

Post by 3836293648 »

jscott817 wrote: post #49

Can we assume that model performance at 90% of the 256k limit != 90% of 1M token limit? Is this the exact same model just with less VRAM allocated for context window?

No, you can't assume it. You can trust them as they made that claim outright. Or you can choose to not trust them, I guess

Re: Kimi K3-256k

#140

Post by dandaka »

pertymcpert wrote: post #83
dandaka wrote: post #77

Earlier quoted context omitted.

Models work best when they have short instructions and no noise. "Conversation [may] contain" also means "conversation has a lot of noise". It degrades performance and increases cost. I use handoff skill to ask model to write a prompt for itself.

The applicability of your advice is very model dependent. Some like Claude have very good long context performance, whereas others they fall off much quicker past some threshold.

I am not only talking about "long context" performance (context rot), but also about noise that is confusing model about its goal (from correctly extracting operator's intent). I think every model will get confused to a degree, so clearing up irrelevant information from context helps a lot.
Post reply on HN