# Does optimizing context actually make a reasoning model think less?


## Introduction

LLMs have become very popular, with one big use case being people asking questions by just providing the context along with them. In this article, we analyze how Gemini's frontier reasoning models behave when we give them long-form documents with varying length and quality of context, to see whether optimizing that context has any effect on how much the model actually has to reason.

To test this, we took documents from three very different domains:

*   Company earnings calls (across five companies: AAON, AAPL, ACMR, AIRS, BMI)
    
*   Cyber security logs (for Android, Hadoop, and Windows systems respectively)
    
*   Legal documents (IP protection and franchise agreements from three different companies)
    

## Methodology

The most important part of the experiment was the prompt design. For each dataset, we prepared a set of questions derived from a given document with predetermined answers. These questions were written so they couldn't be answered by just copying a line straight out of the context; They needed some reasoning (or at least some digging) from the model. We then gave each question, along with the context, to the model to find the answer.

For every question, the model received three different versions of the context:

*   **Tight :** only the context needed to answer the question directly. For example, when looking at the cyber security logs and asking the model to find the root cause of a system failure, instead of giving all the logs for the day or the hour, we gave it only the logs needed to identify that root cause.
    
*   **Bloated :** the needed context buried in a lot of extra, irrelevant context. For the same failure question, instead of the logs going back a few minutes, we'd give it logs going back days, essentially overloading the context.
    
*   **Adversarial :** the needed context and a lot of deliberate, confusing information added in to try and throw the model off the rails. For example, when asking about a growth metric for a specific quarter from a company's earnings call, we'd also drop in the same metric from a different quarter for the same company, without making it obvious which was which.
    

We ran all of this on Gemini 3.1 Pro, at two thinking settings (low and high) with every question-and-context combination was run three times and averaged.

Using this setup, I measured the input tokens, the reasoning tokens (what the model spent on thinking), and the output tokens ,cost and latency for each run. The idea was to see two things: when we deliberately try to derail the model with the adversarial context, does it catch on quickly or does it burn extra thinking working through it? And when we simply hand it a lot of extra context, does it have to think harder to answer, and does any of this differ across the three domains?

## Results

The intuitive prediction is that padding or poisoning the context makes a reasoning model work harder, this claim could not be verified emperically, as this stood true for only one of the three dataset domains

Reasoning tokens, normalized to the Tight baseline (Tight = 1.00×). Values above 1.00× mean the condition made the model think more than tight context; below 1.00× means it thought less.

| Domain | Thinking | Tight | Bloated | Adversarial |
| --- | --- | --- | --- | --- |
| Earnings calls | HIGH | 1.00× | 0.77× | 0.84× |
| Earnings calls | LOW | 1.00× | 0.93× | 1.00× |
| Security logs | HIGH | 1.00× | 1.80× | 2.00× |
| Security logs | LOW | 1.00× | 1.49× | 1.53× |
| Legal docs | HIGH | 1.00× | 0.72× | 0.78× |
| Legal docs | LOW | 1.00× | 1.05× | 0.93× |

TLDR:

*   Security logs behave like a search problem; Adding hours or days of extra logs, or near-duplicate error lines, leads to model using more reasoning token in fact, doubles under adversarial context at the high budget.
    
*   Earnings and legal were more of a generation task; In the Tight condition the model is handed a few hundred tokens and has to reason to bridge the gap; given the full document it can often just locate the relevant passage and reason less. So at the high budget, more context lowers reasoning effort. The distractors barely move it.
    

So context engineering does help but only for simpler tasks like retrival.

Across every condition, moving from LOW to HIGH thinking multiplies reasoning tokens by roughly 1.6–1.7×, a larger and more consistent effect than anything the context manipulation produces.

Even where extra context reduces reasoning, it never reduces cost — the input tokens dominate the bill. Bloating security-log context raises cost by roughly 10× (mostly input), while doing nothing good for the model.

![](https://cdn.hashnode.com/uploads/covers/614b6092c790e72dddca6a1d/18d05c64-66ea-43c4-876b-5f43a5252879.png align="center")

Figure 1: Token count for hadoop based system context q and a

![](https://cdn.hashnode.com/uploads/covers/614b6092c790e72dddca6a1d/fe0a68f4-1d1e-42f2-a1e2-aea8659740c6.png align="center")

Figure 2: Token count for a Legal IP document context q and a

![](https://cdn.hashnode.com/uploads/covers/614b6092c790e72dddca6a1d/4b9599f0-e57c-44f5-81c8-8718da8ecbc0.png align="center")

Figure 3: Token count for Earnings call based context q and a

Full breakdown over Conditions: Tight / Bloated / Adversarial.

| Domain | Cond | Think | Input tok | Reasoning tok | Output tok | Cost (USD) | Latency (s) |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Earnings calls | Tight | HIGH | 309 | 588 | 83 | 0.0087 | 7.2 |
| Earnings calls | Tight | LOW | 309 | 369 | 86 | 0.0061 | 5.7 |
| Earnings calls | Bloated | HIGH | 7,809 | 456 | 85 | 0.0176 | 6.3 |
| Earnings calls | Bloated | LOW | 7,809 | 342 | 83 | 0.0164 | 5.4 |
| Earnings calls | Adversarial | HIGH | 8,151 | 492 | 87 | 0.0181 | 6.7 |
| Earnings calls | Adversarial | LOW | 8,151 | 369 | 85 | 0.0168 | 6.2 |
| Security logs | Tight | HIGH | 1,730 | 1,181 | 424 | 0.0227 | 14.8 |
| Security logs | Tight | LOW | 1,730 | 675 | 297 | 0.0151 | 9.6 |
| Security logs | Bloated | HIGH | 145,038 | 2,131 | 400 | 0.2211 | 28.0 |
| Security logs | Bloated | LOW | 145,038 | 1,004 | 301 | 0.2102 | 18.4 |
| Security logs | Adversarial | HIGH | 145,280 | 2,367 | 400 | 0.2850 | 30.5 |
| Security logs | Adversarial | LOW | 145,280 | 1,033 | 299 | 0.2066 | 17.2 |
| Legal docs | Tight | HIGH | 1,905 | 819 | 743 | 0.0225 | 16.2 |
| Legal docs | Tight | LOW | 1,905 | 444 | 402 | 0.0140 | 9.8 |
| Legal docs | Bloated | HIGH | 24,287 | 587 | 353 | 0.0413 | 11.2 |
| Legal docs | Bloated | LOW | 24,287 | 465 | 324 | 0.0384 | 10.0 |
| Legal docs | Adversarial | HIGH | 24,368 | 635 | 368 | 0.0348 | 11.7 |
| Legal docs | Adversarial | LOW | 24,368 | 411 | 205 | 0.0340 | 7.8 |

Key takeaways:

*   Near-duplicate distractors(e.g. earnings call facts from earlier quarters or similar bugs etc) reliably raise reasoning where the task is to locate a specific fact and are nearly free where the task is interpretive.
    
*   The thinking budget is a cheaper lever to pull than the context size
    

Detailed results and code can be found at my repo over on https://github.com/shreshtha48/Does-optimizing-context-actually-make-a-reasoning-model-think-less-/

## Limitations

There are a few things I want to be clear about so the results are read for what they are.

Everything here ran on a single model, Gemini 3.1 Pro, at two thinking settings, so I cannot really say whether these patterns hold for other sizes of Gemini or for models from other providers without actually running them too. On top of that there were only a handful of questions per document and three runs per combination, which is enough to see the big trends but not enough to make strong claims about the smaller differences.

A couple of smaller caveats as well. The reasoning token count is a number the model reports, so I am using it as a stand in for how hard the model thought, which is reasonable but it is not a direct look at what the model actually did inside. The bloated and adversarial contexts were also fairly close in length, which is actually good because it means the extra reasoning in the security logs came from the confusion and not just from more tokens, but it does mean I am not cleanly separating length from confusion in every case. And finally the cached tokens showed up inconsistently across the repeated runs, which adds a bit of noise to the cost numbers specifically, though the token counts themselves are clean.

* * *