A 1M Context Window Is the New Default — So I Built an Admission Policy Instead of Filling It

The measurement: my pipeline's degradation curve

Here is the result of running that probe with the material my article-generation job normally feeds in as the filler. Twelve preconditions as needles, Sonnet 5, median of three runs at each fill rate.

It was not a sharp cliff but a gentle downhill — which is exactly what makes it tricky. Up to around 50%, you cannot feel it. Past 60%, facts placed in the middle start dropping one by one. And the scary part is the 92% row: not just forgetting, but "recalled the fact but got the value wrong." A null would still be workable; a plausible wrong answer quietly breaks everything downstream.

The other thing I measured was cost. Once I no longer had to fit the window, I had carelessly removed the step that trimmed material. Across that change, mean input tokens per task had gone from about 48K to about 118K. Recall had not improved — only the bill had, more than doubling.

Those two measurements settled the direction. Do not fill just because the window allows it. Instead, put an explicit layer that vets "is this allowed in?" ahead of context construction.

An admission policy that vets each slot

The mechanism is simple. Gather the material you want in context as candidates, then decide what gets in based on priority and an effective fill cap. I set the cap just short of where recall began to break in the curve above — around 55% effective fill for my material. The point is to treat the range where recall holds, not the whole window, as your "effective window."

First, the old pass-through approach.

// Before: put in everything that fits (the window is wide, so why not)
function buildPromptBefore(candidates: Candidate[]): string {
  return candidates.map((c) => c.text).join("\n\n");
}

Replace it with a priority-aware admission gate.

// admission-policy.ts — vet slots before assembling context
interface Candidate {
  id: string;
  text: string;
  priority: number;   // higher is more important (see the table below)
  estTokens: number;  // pre-estimate (approx. via tiktoken etc.)
  pinned?: boolean;   // always include, e.g. preconditions
}
 
interface AdmissionResult {
  admitted: Candidate[];
  rejected: Candidate[];
  usedTokens: number;
  effectiveFill: number;
}
 
function admit(
  candidates: Candidate[],
  opts: { modelWindow: number; effectiveFillCap: number }
): AdmissionResult {
  const budget = Math.floor(opts.modelWindow * opts.effectiveFillCap);
  // reserve pinned first, then take the rest by priority then token efficiency
  const pinned = candidates.filter((c) => c.pinned);
  const rest = candidates
    .filter((c) => !c.pinned)
    .sort((a, b) => b.priority - a.priority || a.estTokens - b.estTokens);
 
  const admitted: Candidate[] = [];
  const rejected: Candidate[] = [];
  let used = 0;
 
  for (const c of [...pinned, ...rest]) {
    if (used + c.estTokens <= budget || c.pinned) {
      admitted.push(c);
      used += c.estTokens;
    } else {
      rejected.push(c);
    }
  }
  return {
    admitted,
    rejected,
    usedTokens: used,
    effectiveFill: used / opts.modelWindow,
  };
}
 
// After: build context only from what passed the gate
function buildPromptAfter(candidates: Candidate[]): string {
  const r = admit(candidates, { modelWindow: 1_000_000, effectiveFillCap: 0.55 });
  if (r.rejected.length > 0) {
    console.warn(
      `admission: rejected ${r.rejected.length} ` +
      `(effective ${(r.effectiveFill * 100).toFixed(0)}% / ${r.usedTokens} tok)`
    );
  }
  return r.admitted.map((c) => c.text).join("\n\n");
}

effectiveFillCap is not a magic number. It should sit just short of the fill rate where your own probe shows recall breaking. The best value shifts with the nature of your material — code-heavy versus prose-heavy, shallow needles versus deep ones. For me 0.55 was the safe side; for your material it will differ. That is exactly why the probe from the first half of this article comes first.

What to drop and what to keep

An admission gate is only as good as how you assign priority. The ordering I use across the four-site pipeline I run as an indie developer is roughly the following. Treat the numbers as a relative ranking, not absolute values.

What actually helped was being able to drop that bottom "just in case" row mechanically. People are bad at discarding "this might be relevant." Give the gate an ordering and a cap, and it makes that call the same way every time. On handling preconditions as state in long-running jobs, this connects to my notes on context budget and compaction for long-running agents.

Stop quiet cost creep with an effective-token-cost view

Overstuffing shows up not only in quality but in the bill. Here an "effective token cost" view helps. Instead of total input tokens, look at cost per token that actually contributed to the result. Using the probe's recall as a proxy, you can show at a glance that overstuffing is worsening your unit cost.

// effective-cost.ts — "effective token cost" using recall as a proxy
interface RunStat {
  inputTokens: number;
  recall: number;        // 0..1 (probe recall)
  inputPricePerMTok: number; // 2 at intro price, 3 at standard
}
 
function effectiveCostPer1kUseful(s: RunStat): number {
  const inputCost = (s.inputTokens / 1_000_000) * s.inputPricePerMTok;
  // "useful" input tokens = total tokens × recall
  const usefulTokens = s.inputTokens * s.recall;
  return (inputCost / usefulTokens) * 1000;
}
 
// Before (pass-through) versus After (admission)
const before: RunStat = { inputTokens: 118_000, recall: 0.75, inputPricePerMTok: 2 };
const after:  RunStat = { inputTokens: 62_000,  recall: 1.0,  inputPricePerMTok: 2 };
 
console.log("before", effectiveCostPer1kUseful(before).toFixed(5));
console.log("after ", effectiveCostPer1kUseful(after).toFixed(5));

After adding the admission policy, input tokens per task fell back from about 118K to about 62K, and probe recall recovered to 12/12. Even by raw input cost alone, that is roughly a 2.4x difference per task at the intro price. "The window is wide, so keep it in" turned out to be a doubly bad call — lowering quality while raising the bill.

Recording effective token cost over time lets you notice from the cost side when growing material starts slipping past the gate. Recall degradation and cost inflation share a cause (overstuffing), so watching one picks up the early signs of the other. For how to build the token accounting itself, see my Claude Code context budget optimization guide.

One thing to do once, after the default changes

When a model default switches quietly, the danger is that everything looks like it is still working. Without hard errors, we do not notice the change. In a case like this one — 1M becoming the default — running these three once will let you rest easier.

First, run the probe on your own real material and take the degradation curve. The fill rate where recall breaks differs per material, so you need your numbers, not someone else's. Second, put an admission gate capped just short of that point ahead of context construction. Design around the effective window where recall holds, not the width of the window. Third, keep effective token cost in your records so you can catch the early signs of quiet cost inflation.

The wider window is unmistakably progress. But progress did not, by itself, become a reason to relax. If anything, with the safety valve gone, the judgment of how much to pack came back to my own design. I let my guard down when things stopped crashing, and missed the silent degradation for a few days. I hope this helps you avoid the same stumble. Thank you for reading.