Gemini 2.5 made long context feel operational

Gemini 2.5 Pro made long context feel operational.

the prompt is now a working set

The step from “this model can take a huge prompt” to “a product team can actually plan around this” is bigger than it sounds.

Gemini 2.5 moved the conversation from novelty to routing: what should be included, what should stay out, how much reasoning effort to spend, and when retrieval still wins.

Repositories are the easiest way to see it. A codebase is noisy by default, which means the interesting problem is not raw capacity. It is deciding which files, tests, docs, and dependencies belong together in one working set.

For a planning task, I would want something like this:

{
  "task": "update auth callback behavior",
  "context_strategy": "large_curated_context",
  "sources": [
    { "path": "src/routes/auth/callback.ts", "role": "target" },
    { "path": "src/lib/session.ts", "role": "dependency" },
    { "path": "tests/auth/callback.test.ts", "role": "verification" },
    { "path": "docs/auth-flow.md", "role": "domain_context" }
  ],
  "excluded": [
    { "path": "dist/", "reason": "generated" },
    { "path": ".env", "reason": "secret" }
  ]
}

That is the part I mean by operational. The model should not just receive tokens. It should receive a source manifest, a permission boundary, and a reason for why this slice of the world deserves to be in front of it.

The manifest is also what keeps the omission visible. If the answer is wrong, I can inspect the slice and ask whether the callback file, the session helper, the tests, or the docs were missing. Without that, the model just saw “a lot of code” and the reviewer gets to guess why the result feels thin.

For a real repo task, I want the slice to be small but complete:

target: src/routes/auth/callback.ts
dependencies: src/lib/session.ts, src/lib/oauth/*
verification: tests/auth/callback.test.ts
domain context: docs/auth-flow.md
excluded: dist/, .env, generated files

That is not a giant context dump. It is a working set that explains itself.

a planner should know when to say no

The long-context win, in other words, is not “send everything.” It is “make the system smarter about what is worth carrying.”

If I am deciding whether to keep a repo slice whole or fetch pieces on demand, I still care about freshness, permissions, and cost. Long context is the right tool when the question depends on keeping the source together. Retrieval is the right tool when the source is too large, too stale, or too sensitive to carry whole.

I also want the planner to refuse junk. If the model can hold more, that does not mean it should hold everything. A good planner can say “this log directory adds noise” or “that generated bundle does not belong in the working set” without needing a human to trim it by hand.

That is the part that makes 2.5 feel operational instead of theatrical. The window is bigger, but the real win is that the system can start treating context as a budget with structure instead of a blob with a token count.

The better system is the one that can do both without pretending they are the same thing.