Gemini can take a million tokens. That does not mean every token receives equal attention

A million-token context window changes what can be submitted in one request. It does not turn a model into a database that reads every item with equal attention, equal latency or equal cost. Google’s own guidance says to omit unnecessary material, place the question at the end of a long prompt in most cases and expect longer inputs to increase time to first token.[1]

The distinction matters because capacity is the easiest number to advertise. Retrieval quality, relevant-position effects, multimodal tokenisation, tool limits and the price of repeatedly sending the same material determine whether the capacity improves a real workflow.

One hour of media can nearly fill the window

Using 263 video tokens per second as an explicit assumption, a 60-minute recording would consume 263 × 3,600 = 946,800 input tokens. At the documented audio rate, 60 minutes gives 32 × 3,600 = 115,200 tokens. These are arithmetic illustrations, not measured requests. Because video usage depends on the selected processing settings, use Google’s token-counting method for the actual input and inspect reported usage rather than treating the video illustration as a guaranteed allowance.[2]

The calculation shows why multimodal capacity can disappear faster than a file count suggests. Ten short PDFs may occupy less context than one long video. An application that displays “one file uploaded” without showing tokens conceals the resource that actually governs the request.

Fitting the evidence is not the same as finding every answer

Google says Gemini is highly capable at extracting information from large contexts and cites up to 99% accuracy in many cases. The same guidance still recommends avoiding irrelevant tokens. A benchmark built around locating one known fact is different from a task that must find every exception, reconcile many definitions or notice an omission across hundreds of documents.[1]

For completeness-sensitive work, divide the evaluation into claims. Seed known facts in early, middle and late positions; include near-duplicates and contradictions; ask for all qualifying items; then score missed evidence as well as fabricated evidence. The context window tells you the test can be attempted in one request. The result tells you whether it should be.

Caching changes the invoice, not the evidence

Context caching can reduce the cost of reusing the same long material across requests. It does not verify that the cached material is still current, that the right version was uploaded or that a later question used the right passage. A cache hit is a computational event, not a source-quality judgement.[5]

URL context introduces a separate access boundary. The tool can retrieve supported public pages and returns retrieval status plus citation annotations, but inaccessible, unsafe or unsupported content is not transformed into reliable context simply because its URL was included. The application should inspect retrieval results before treating the answer as a review of every requested source.[3]

Gemini’s long context is a genuine capability: it reduces the need to split some tasks across many requests or build a retrieval system first. Its limitation is the temptation to collapse several engineering questions into one large number. The dependable design treats context length, retrieval quality, latency, access and cost as separate measurements.

Report an error or suggest a correction