Tech

The Big Context Window Was Never the Prize

July 4, 2026 · Marcus Webb, The Beauty of Mathematics~5 min read

Here's the thing about the million-token context window everybody bragged about all year: you can fill the whole thing, and your coding agent gets dumber. Not slower. Dumber. Somebody finally put it in a newsletter this spring, plain as a flat tire — bigger context windows stopped helping. And the fix, it turns out, is a lesson a search-engine guy could've told you twenty years ago.

More stuff in the box, less work out of it

Claude Opus 4.6 shipped February 5 with a 1-million-token window. A million tokens is a lot of room. The pitch was obvious: dump the whole repo in, hand the agent everything, watch it soar. Except that's not what happened. Stuff the window and the thing loses the plot — misses what's sitting right in the middle, wanders off, hands you code that ignores the one file that mattered. There's a name for it going around now: context rot. More tokens, less signal. The bench got bigger and the work got worse.

I've seen this movie before, in a different shop. You don't help a mechanic by wheeling every tool he's ever owned into the bay and dumping them on the floor. Now he's standing in a pile, kicking wrenches, looking for the one 10-millimeter he actually needs. The tools didn't help. The pile hurt. That's your million-token prompt: a bigger pile is not a better answer.

An old search guy already solved this

Twenty-some years back, Jun Wu wrote a book called The Beauty of Mathematics, mostly about how search engines actually work under the hood. And the spine of the whole thing is one idea that lands like a slap here: more words is not more information. Information is the surprise you didn't already have. Pile on a hundred documents that say nothing new, and you haven't added information — you've added noise. The signal-to-noise ratio drops. The prompt gets fatter and carries less you can actually use.

Search engines figured this out the hard way, decades ago. Nobody wins by handing you all ten million pages that mention your search. The whole trick — the part Wu spends the book on — is ranking. TF-IDF, that clunky little formula: a word that shows up everywhere tells you nothing, a word that's rare tells you what the page is actually about. The engine's real job isn't finding pages. It's throwing almost all of them away and surfacing the three that matter. That's not a side feature. That's the engine.

The teams shipping fast are doing subtraction

So watch what the fast teams in 2026 quietly stopped doing. They stopped running bigger prompts. They built memory stacks that pull only the relevant slice and leave the rest on the shelf. Four layers, roughly: a map of the repo — which symbols call which, what imports what, where the tests are; a record of why the code looks the way it does, the decisions nobody wrote down; a scratchpad the agent keeps for the length of one job; and a shared team memory with permissions on it. None of that is "more context." All of it is better-ranked context.

And the numbers back the plain-English version. One 2026 memory benchmark clocked a token-efficient setup at 92.5 on the LoCoMo test while pulling only about 6,956 tokens per call. Read that twice. High accuracy, on a sliver of the context. It didn't win by seeing more. It won by seeing the right part. That's the whole game, and it's exactly the game the search engines have been playing since before any of us had a coding agent.

What this means for you on Monday

If you've been jamming your whole codebase into the prompt because the window finally lets you — stop. That's the pile-of-tools move, and it's costing you accuracy you can't see. The better instinct is the search engine's instinct: what are the three files this task actually touches? Feed those. Leave the rest on the shelf.

Turns out the skill that separates a working setup from a bloated one isn't cramming. It's cutting. Knowing what to leave out is the job — same as it was for the search guys, same as it's always been. A great model, like a great search engine, isn't a great memory. It's a great filter. The pipe that flows is the one that isn't clogged.

The win isn't a bigger window; it's a better filter

Stuffing more context in lowers the signal — the teams pulling ahead surface only the relevant slice, which is the oldest trick in the search-engine book.

Here's the plain version of it. For a year the pitch was capacity — look how much fits now. Capacity was never the constraint. Relevance was. The million-token window is a bigger warehouse, and a bigger warehouse full of junk is still full of junk. The move that pays is the boring one Jun Wu wrote down decades ago: rank hard, keep the three that matter, throw the rest back. Do the subtraction. That's not a smaller job. That's the whole one.

Framing drawn from Jun Wu, The Beauty of Mathematics. Benchmark and product figures reflect 2026 reporting (a coding-agent newsletter and a memory benchmark report) — treat them as the read on a fast-moving field, not settled engineering law. This is one working engineer's take, not a verdict on any specific tool.

Brute force fills the million-token window and the signal ratio collapses ("context rot" / lost in the middle); retrieval ranks the context and surfaces only the relevant slice — one 2026 memory benchmark hit LoCoMo 92.5 at ~6,956 tokens per call. Framework: Jun Wu, The Beauty of Mathematics. One reading of a fast-moving field, not settled law.

技术

那个百万级上下文窗口，从来就不是奖品

2026年7月4日 · 陈志远，《数学之美》约 4 分钟

你别看大家吹了一整年的百万 token 窗口——真把它塞满，你的编程智能体反而变笨了。不是变慢，是变笨。今年春天终于有人把这话写进 newsletter 里，说得跟车胎没气一样干脆：上下文窗口更大，不管用了。而解药呢，是个搞搜索的人二十年前就能告诉你的老道理。

箱子里塞得越多，干出来的活越少

Claude Opus 4.6 是 2026 年 2 月 5 日发的，带 100 万 token 的窗口。100 万 token，地方大得很。当时的说法明摆着：把整个代码库一股脑倒进去，全喂给它，看它起飞。结果没起飞。窗口一塞满，这东西就找不着北了——正中间摆着的东西它反倒漏了，越跑越偏，吐给你的代码把那个唯一要紧的文件当没看见。现在大家给这毛病起了个名，叫「上下文腐烂」。token 越多，信号越稀。台子铺大了，活儿反倒糙了。

这场面我见过，在另一个铺子里。你想帮修车师傅，不是把他这辈子攒的工具全推进车位、往地上一倒。这下他站在一堆家伙里，拿脚踢着扳手，找那把他真正要用的 10 毫米套筒。工具没帮上忙，那一堆反而碍事。你那百万 token 的 prompt 就是这么回事：堆得更大，不等于答得更好。

一个搞搜索的老手早解过这道题

二十多年前，吴军写过一本《数学之美》，讲的多半是搜索引擎底层到底怎么转。整本书的脊梁就一句话，搁这儿一巴掌拍得人清醒：词多不等于信息多。信息，是你原本没有的那点意外。你堆上一百篇啥新东西都没有的文档，你没加信息，你加的是噪声。信噪比往下掉。prompt 越喂越胖，你真正能用的反倒越少。

搜索引擎几十年前就吃过这个亏、想明白了。没人是靠把提到你关键词的一千万个页面全甩给你才赢的。真正的诀窍——吴军拿大半本书讲的那个——是排序。TF-IDF，那个土里土气的小公式：一个到处都出现的词啥也说明不了，一个罕见的词才告诉你这页到底在讲啥。引擎真正的活儿不是找页面，是把几乎所有页面全扔掉，只把那三个要紧的顶上来。这不是附加功能，这就是引擎本身。

跑得快的团队，在做减法

所以你看 2026 年那些跑得快的团队，悄悄不干什么了。他们不再堆更大的 prompt。他们搭的是「记忆栈」，只把相关的那一薄片拽出来，其余的留在架子上不动。大概四层：一张代码库的地图——哪个符号调哪个、谁 import 谁、测试在哪；一份「为什么代码长这样」的记录，那些没人写下来的决策；一块智能体在一次任务里自己用的草稿；再加一层带权限的团队共享记忆。这些没一样是「更多上下文」，全是「排得更好」的上下文。

数字也给这大白话撑了腰。2026 年有个记忆基准测试，一套省 token 的方案在 LoCoMo 上打到 92.5 分，每次调用只拽出约 6,956 个 token。这句你读两遍。高准确率，只用了上下文里薄薄一层。它不是靠看得多赢的，是靠看对了那部分。这就是全部的门道，也正是搜索引擎在我们还没编程智能体那会儿就一直在玩的门道。

这事儿周一上班对你意味着啥

要是你一直因为窗口终于够大了，就把整个代码库往 prompt 里硬塞——打住。那就是「一地工具」那一招，正在悄悄吃掉你看不见的准确率。更靠谱的直觉是搜索引擎那套：这个任务真正碰到的是哪三个文件？就喂那三个，其余的留在架子上。

说白了，把一套能干活的配置和一套虚胖的配置分开的本事，不是往里塞，是往外砍。知道该把啥扔出去，这才是活儿——搞搜索那帮人当年就是这样，从来就是这样。一个好模型，跟一个好搜索引擎一样，赢的不是记性，是过滤。水管能出水，靠的是它没堵。

赢的不是更大的窗口，是更好的过滤器

往里塞更多上下文，只会把信号压稀；跑在前头的团队只把相关那一薄片顶上来——这是搜索引擎书里最老的一招。

掰开揉碎就一句话。吹了一年的都是「容量」——你看现在装得下多少了。可容量从来就不是卡脖子的地方，相关性才是。百万 token 的窗口是个更大的仓库，一个更大的仓库塞满破烂，那还是一仓库破烂。真正划算的，是吴军几十年前写下的那招不起眼的：狠狠排序，留住要紧的那三个，剩下的扔回去。做减法。这不是把活儿做小了，这就是活儿的全部。

框架取自吴军《数学之美》。文中基准测试与产品数字反映 2026 年报道（一份编程智能体 newsletter 与一份记忆基准报告）——把它们当作对一个快速演进领域的解读，别当成板上钉钉的工程定律。这只是一个一线工程师的看法，不是对任何具体工具下的判决。

蛮力法塞满百万 token 窗口，信噪比崩塌（「上下文腐烂」/迷失在中间）；检索法给上下文排序，只顶上相关那一薄片——2026 年一个记忆基准在 LoCoMo 上打到 92.5，每次调用只用约 6,956 token。框架：吴军《数学之美》。这是对一个快速演进领域的一种解读，不是板上钉钉的定律。

テクノロジー

あの百万トークンの窓は、そもそも賞品じゃなかった

2026年7月4日 · 藤井亮、『数学の美しさ』約 6 分

一年みんなが自慢していた百万トークンの文脈窓、あれって、本当に満杯まで詰めると、コーディングのエージェントがむしろ「バカ」になるんですよね。遅くなるんじゃなくて、バカに。今年の春、ようやく誰かがニュースレターにこう書きました。パンクしたタイヤみたいに、あっさりと——文脈窓は、大きくしても効かなくなった、と。で、その処方箋が、検索エンジンをやってた人なら二十年前に教えてくれたはずの、古い話なんですよね。

箱に詰めるほど、出てくる仕事は減る

Claude Opus 4.6 は 2026 年 2 月 5 日にリリースされて、100 万トークンの窓を積んでいます。100 万トークン、場所はたっぷりある。当時の売り文句は分かりやすかった。リポジトリを丸ごと放り込んで、全部渡して、飛び立つのを見よう、と。でも飛びませんでした。窓を満杯にすると、こいつは筋を見失うんですよね——ど真ん中に置いてあるものを取りこぼして、あさっての方へ流れて、たった一つ大事だったファイルを無視したコードを返してくる。今この症状に名前がついていて、「文脈の腐敗（context rot）」と呼ばれています。トークンが増えて、信号が薄まる。作業台は広がったのに、仕事は雑になった。

この光景、別の店で見たことがあります。整備士を助けようとして、その人が一生かけて集めた工具を全部ピットに運び込んで床にぶちまける、なんてことはしないんですよね。彼はいま道具の山に立って、レンチを蹴っ飛ばしながら、本当に要る 10 ミリのソケットを探している。工具は助けにならなかった。山が邪魔をした。あなたの百万トークンのプロンプトも同じで、大きく積んだからって、良い答えになるわけじゃないんですよね。

検索の職人が、とっくに解いていた

二十数年前、呉軍が『数学の美しさ』という本を書きました。中身の多くは、検索エンジンが裏側で実際どう回っているか。その背骨が一つあって、ここに置くと頬を張られる感じがします——言葉が多いことは、情報が多いこととは違う。情報とは、あなたがまだ持っていなかった意外さのこと。新しいことを何も言わない文書を百も積んでも、情報は増えていない。増えたのは雑音です。信号対雑音比が下がる。プロンプトは太っていくのに、実際に使える分は減っていく。

検索エンジンは何十年も前、痛い目を見てそこに気づきました。あなたの検索語を含む一千万ページを全部渡して勝つ人なんて、いないんですよね。本当のコツは——呉軍が本の大半を割いて語るのは——順位づけです。TF-IDF、あの野暮ったい小さな式。どこにでも出る語は何も教えてくれず、めったに出ない語こそ、そのページの中身を教えてくれる。エンジンの本当の仕事はページを見つけることじゃなくて、ほぼ全部を捨てて、大事な三つだけを浮かび上がらせること。おまけ機能じゃありません。それがエンジンそのものなんですよね。

速く出しているチームは、引き算をしている

だから 2026 年に速く出しているチームが、そっと「やめたこと」を見てください。彼らは大きいプロンプトを回すのをやめました。組んだのは「記憶スタック」で、関係のある薄い一枚だけを引き出して、残りは棚に置いたまま。ざっと四層。リポジトリの地図——どの記号がどれを呼び、何が何を import し、テストがどこにあるか。「なぜコードがこの形なのか」の記録、誰も書き残さなかった判断。エージェントが一つの作業のあいだ自分で使う下書き。そして権限のついたチーム共有の記憶。どれも「もっと文脈」ではなくて、全部「より良く並べた」文脈なんですよね。

数字もこの素朴な話を裏づけています。2026 年のある記憶ベンチマークで、トークンを節約する構成が LoCoMo テストで 92.5 を出しつつ、一回の呼び出しで引くのは約 6,956 トークンだけ。ここ、二回読んでください。高い精度を、文脈のほんの一枚で。多く見て勝ったんじゃなくて、正しい部分を見て勝った。これが全部の勝負どころで、検索エンジンが、僕らにコーディングのエージェントなんて無かった頃からずっとやってきた勝負なんですよね。

月曜、これがあなたにとって何を意味するか

窓がやっと大きくなったからと、コードベースを丸ごとプロンプトに押し込んでいるなら——やめましょう。それが「道具の山」の一手で、目に見えない精度を静かに削っています。もっと頼れる直感は、検索エンジンのそれ。この作業が実際に触るのはどの三つのファイルか。それを渡す。残りは棚に置く。

正直なところ、動く構成とぶくぶく膨れた構成を分ける腕は、詰め込みじゃなくて、削ることなんですよね。何を外すかを分かっていること——それが仕事で、検索の人たちが昔からやってきたのと同じ。良いモデルは、良い検索エンジンと同じで、良い記憶じゃなくて、良いフィルターです。水が流れる管は、詰まっていない管なんですよね。

勝ち筋は大きな窓じゃなくて、良いフィルター

文脈を詰め込むほど信号は薄まる——先を行くチームは関係のある一枚だけを浮かせる、検索エンジンの本にある一番古い手なんですよね。

噛み砕くと、一言なんですよね。一年間、売り文句は「容量」でした——ほら、これだけ入るようになった、と。でも容量は、そもそも詰まっていた場所じゃなかった。詰まっていたのは関連性のほう。百万トークンの窓は、大きい倉庫。がらくたで満杯の大きい倉庫は、やっぱり満杯のがらくたなんですよね。割に合うのは、呉軍が何十年も前に書き留めた地味な一手。きっちり並べて、大事な三つを残し、あとは返す。引き算をする。それは仕事を小さくすることじゃなくて、仕事の全部なんですよね。

枠組は呉軍『数学の美しさ』から。本文中のベンチマークと製品の数値は 2026 年の報道（コーディングエージェントのニュースレターと記憶ベンチマークのレポート）を反映しています——動きの速い分野の一つの読み方として扱い、確定した工学の法則としては扱わないでください。これは現場の一エンジニアの見方であり、特定の道具への判決ではありません。

力任せは百万トークンの窓を満杯にし、信号対雑音比が崩れる（「文脈の腐敗」/真ん中で迷子）。検索は文脈を並べ替え、関係のある一枚だけを浮かせる——2026 年のある記憶ベンチマークは LoCoMo で 92.5 を、一回あたり約 6,956 トークンで出した。枠組：呉軍『数学の美しさ』。動きの速い分野の一つの読み方で、確定した法則ではない。