1M Context Is Not Memory: What the Qwen4 Hype Thread Gets Wrong

On October 29 a pull request in Qwen's qwen-code repo surfaced on r/LocalLLaMA with a simple claim: the Qwen4 generation ships with a 1 million token context window. The post collected 530 upvotes and 230 comments, most of them celebrating. The most instructive comments came from people who run these models all day, and their message was the opposite of the hype: bigger windows are welcome, and almost nobody intends to fill them.

The power users cap their own windows

One commenter with a heavy agentic workload put it plainly:

"Anytime I get 1m ctx I cap that bad boy to 512 and do other things with the space. Long ctx usually has less coherence in my experience."

Another refuses to trust even 262k: "I cap them at 160k just to avoid that long context degradation." And the thread carries the technical reason: "If a model isn't trained for it, extending the context is iffy. Qwen3.8 does okay to 512k, but I've heard attention collapses pretty bad after that."

The first thing the 1M celebration gets wrong is assuming capacity gets used. The people with the hardware and the workflows to use it deliberately don't, because quality past a few hundred thousand tokens is still uncertain territory.

The working set is smaller than the window

The comment that caps at 512k contains the most useful number in the thread:

"My software factory has an avg final ctx of 50k and with p99 at 75k (it optimizes for decomposition and sub-agents for discovery)."

A pipeline built around sub-agents, running daily, settles at 50 to 75 thousand tokens. That is five percent of the new window. One enthusiast gave the game away in a single line: "I want 1M context so I can compact on my own terms at 500k." Even the fans want the big window as room to postpone the decision about what to keep. That is a memory requirement wearing a capacity costume.

The window answers the wrong question

A context window answers how much fits right now. It says nothing about what should stay, what has expired, or what contradicts what. Shoving those questions into a bigger window makes them worse: everything competes for attention, stale facts never leave on their own, and you pay twice, once in quality and once in hardware.

That second cost showed up in its own thread this month. A developer running agentic coding sessions on a 64GB machine reported sessions at 100 to 200k tokens with "memory usage is in the 50 GB as the context starts building up"; another confirmed "full 256K context" eating 52GB on a different model. Long windows are RAM you rent per session, and the rent scales with hoarding.

What actually helps

The pattern across both threads: people who get real work done keep a bounded working set, delegate to sub-agents, and move the keep-or-discard decision out of the model's hands. The model sees a curated view; the full history lives somewhere queryable.

That somewhere is what we build. Uteke is an agent memory engine with hybrid recall (vector search fused with full-text) scoring 98.2% recall@5 on the public LongMemEval-S benchmark, raw outputs committed to the repo. It treats time as a first-class dimension, so last month's conclusion gets superseded instead of silently competing with this month's. It runs as a single offline binary you can self-host, or as a hosted cloud beta at uteke.app when you want one memory across machines. We are obviously partial; the receipts are public either way.

A 1M window is a genuinely good thing, and it will be wasted on anyone who treats it as a bigger shoebox. Capacity is how much fits. Memory is deciding what deserves to.

Related: the rot problem in saved AI knowledge, from a different angle, in "Your AI Notes Are Rotting".