AI Agents
Optimising context window size in LLMs: between cognitive dilution and hardware constraints
· 26 min read · Paul-Antoine Tual
The context window size dilemma
Deploying large language models (LLMs) in production is governed by a fundamental trade-off between data-absorption capacity and computational efficiency. Contemporary architectures offer ever-larger context windows (from 128,000 tokens to more than a million for some frontier models), but simply expanding these windows quantitatively guarantees no proportional improvement in application-level performance.
Two opposing pitfalls await the engineer designing an LLM-based system:
- Context insufficiency, which deprives the model of the factual anchors essential to answer accuracy and pushes it back onto its parametric knowledge, which is prone to hallucination.
- Context dilution, a pathology where an excess of redundant or extraneous information saturates the transformer’s attentional mechanisms and actively degrades reasoning quality, even when the sought-after information is genuinely present in the prompt.
This trade-off becomes critical in two very different operating contexts. For models run locally on resource-constrained hardware, managing the memory footprint of the Key-Value (KV) cache is a hard physical bottleneck: a GPU’s VRAM is a finite resource, not a dial you can turn up by changing a setting. For frontier models billed by the token, ingesting superfluous data drives up cost and latency directly proportional to the injected noise. In both cases, optimising context window size is a matter of precision engineering, not empirical tuning.
The critical zone of context insufficiency
When a model is given too little information for the task at hand, it loses its ability to ground its answers in verifiable data. Absent explicit reference data in the prompt, the system falls back entirely on knowledge memorised in its parameters during pre-training, with three direct consequences for enterprise use:
Dependence on the training power law. A model’s ability to reproduce a specific fact depends directly on how frequently documents associated with that fact appeared in its training corpus. “Long-tail” information (niche data, highly specialised facts, an SME’s confidential technical documentation) is poorly represented there and so prone to outright retrieval failure.
Factual hallucination drift. Without grounding context, the model fills the gaps by generating statistically probable but factually wrong sequences of tokens. This is precisely the point of retrieval-augmented generation (RAG): reduce that dependency by injecting relevant documents into the prompt rather than relying on raw memorisation.
Failed semantic pivots. If the context window is too small to hold all the logical elements needed to solve a complex problem (the dependencies of a symbolic graph, the full history of a transaction), the model fails to establish the required connections, producing coherence breaks or incomplete answers.
| Context level | Cognitive behaviour | Operational risks | Production usefulness |
|---|---|---|---|
| Meagre (< 1,000 tokens) | Exclusive reliance on parametric weights | High hallucination rate, stale facts, inability to handle private data | Low: limited to generic requests |
| Optimal (high density) | Precise alignment on re-injected sources, reasoning capabilities activated | Minimal risk of factual error, controlled latency | Maximal: precision RAG, specialised decision-making agents |
| Overloaded (> 32,000 tokens of noise) | Attentional dilution, “Lost in the Middle”, reasoning shift | Latency explosion, accuracy degradation, prohibitive costs | Low: wasted hardware resources |
Context dilution and the “Lost in the Middle” pathology
At the other end of the spectrum, massively and indiscriminately injecting data into the input window produces a cognitive pathology known as context dilution. Work by Nelson F. Liu and coauthors (Stanford; Liu et al., TACL 2024; originally published on arXiv in July 2023) revealed a U-shaped positional bias: language models are highly effective at exploiting data located right at the start or end of the context window, but their performance collapses when critical information sits in the middle of a lengthy prompt, even for models explicitly built for long context.
Several physical and structural factors explain this systematic degradation.
Zero-sum softmax normalisation. The self-attention mechanism computes similarity scores that are converted into probabilities via the softmax function, whose central property is that total attention allocated across the sequence must sum to exactly 1. Every irrelevant token injected into the prompt therefore “steals” a fraction of the attention that should have concentrated on the key information, degrading the signal-to-noise ratio of the internal representations.
Attention sinks. Xiao et al. (“Efficient Streaming Language Models with Attention Sinks”, arXiv:2309.17453, ICLR 2024) show that models develop, during training, a tendency to over-allocate attention weights to the very first tokens of a sequence, regardless of their semantic relevance. These initial tokens act as a dumping ground for surplus attention, which artificially exacerbates the primacy bias at the expense of central data.
Semantic distraction. Introducing off-topic but thematically adjacent information (entities sharing similar roles, comparable ranges of numeric values) disrupts the selection of reasoning paths. The GSM-IC benchmark (Grade-School Math with Irrelevant Context, built on GSM8K by Shi et al., “Large Language Models Can Be Easily Distracted by Irrelevant Context”, ICML 2023, arXiv:2302.00093) shows that arithmetic accuracy and the selection of solution trajectories drop sharply when facing this kind of interference.
Raw length-driven degradation. Even in the total absence of semantic distraction (and even when irrelevant tokens are masked or replaced with blanks), simply increasing input length imposes a cognitive tax on the model. A recent study (Du et al., “Context Length Alone Hurts LLM Performance Despite Perfect Retrieval”, arXiv:2510.05381, Findings of EMNLP 2025; tested on Llama 3.1 8B Instruct, Mistral 7B v0.3 Instruct, GPT-4o, Claude 3.7 Sonnet and Gemini 2.0 across GSM8K, MMLU, HumanEval and a synthetic task) measures a performance degradation of 13.9% to 85% as prompt size grows, despite perfect retrieval.
Reasoning shift. Faced with large prompts containing long histories or dense background data, models trained for test-time-scaling reasoning sometimes shift behaviour in ways that are easy to miss. A 2026 preprint not yet peer-reviewed (Rodionov, Garipov and Yakushev, “Reasoning Shift: How Context Silently Shortens LLM Reasoning”, arXiv:2604.01161) observes a reduction of up to 65% in the length of internal reasoning traces (“thinking traces”) when the model is faced with context weighed down by irrelevant text, multi-turn conversations, or nested sub-tasks, without this necessarily degrading accuracy on easy tasks. This compression comes with a measurable drop in self-verification behaviour, which makes it more damaging on complex logical or mathematical problems. Treat this as an early, preliminary research signal rather than an established result.
Hardware impact on local LLMs: hitting the VRAM wall and the physics of the KV cache
For practitioners running LLMs locally, context window size isn’t just a logical tuning parameter: it’s a hard hardware ceiling, set by the video memory (VRAM) available on the graphics card. During inference, a model’s memory footprint has two components: a static load (the model’s weights) and a highly volatile dynamic load, the Key-Value (KV) cache.
For every token processed, the transformer architecture computes and stores Key and Value vectors for each attention layer. This cache avoids recomputing the full set of attention relationships quadratically (O(n²)) on every new generated token, bringing the decoding phase down to linear complexity (O(n)). But its size grows strictly linearly with sequence length and batch size.
The memory footprint of the KV cache is calculated precisely via the following formula:
M_KV = 2 × L × H_kv × D_head × N_seq × B × P_bytes
where L is the model’s number of attention layers, H_kv the number of attention heads allocated to keys and values (sharply reduced in modern architectures using Grouped-Query Attention, GQA, compared with classic multi-head attention), D_head the dimension of each head, N_seq the cumulative sequence length, B the batch size, and P_bytes the number of bytes per element depending on precision (2 bytes for FP16/BF16, 1 byte for INT8, 0.5 byte for INT4). The multiplier 2 corresponds to the separate storage of the Key and Value tensors.
As an illustration, Llama 3.1 8B Instruct exposes a GQA configuration of 32 layers, 8 KV heads and a head dimension of 128 [6]. For a single request (batch = 1) over a 32,768-token context in native BF16, the calculation gives:
M_KV = 2 × 32 × 8 × 128 × 32,768 × 1 × 2 bytes = 4,294,967,296 bytes = 4 GiB, exactly.
This calculation illustrates why the residual space available for the KV cache shrinks dramatically the moment you run a larger model on a consumer GPU with 12 or 16 GB of VRAM, or significantly extend the context. The moment the sum of model weights and KV cache exceeds physical VRAM capacity, execution spills over into the CPU’s system memory, a crossover from the GPU’s ultra-fast HBM to conventional DRAM access lanes, whose bandwidth is an order of magnitude lower. Decoding speed then collapses almost instantly.
| Reference model | Weights (quantisation) | Context | KV cache (calculated) | Estimated total | Status on a consumer GPU (RTX 4090, 24 GB) |
|---|---|---|---|---|---|
| Llama 3.1 8B Instruct [6] | ~16 GB (native BF16) | 4,096 tokens | ~0.5 GB | ~16.5 GB | Optimal operation, comfortable margin |
| Llama 3.1 8B Instruct [6] | ~16 GB (native BF16) | 32,768 tokens | 4 GB (exact calculation above) | ~20 GB | Tight but stable |
| Phi-4, 14B [7] | ~8-9 GB (INT4) | 16,384 tokens (maximum native context) | ~2.5 GB (BF16) | ~11.5 GB | Comfortable |
| Qwen 3 32B [8] | ~19.8 GB (GGUF Q4_K_M, weights only) | 40,960 tokens (native context) | 10 GiB ≈ 10.7 GB (calculation: 2×64×8×128×2 B = 256 KiB/token) | ~30.5 GB | Already over budget on a 24 GB GPU, weights alone near the limit; requires more aggressive quantisation (Q3/Q2), at the cost of quality |
| Llama 3.3 70B [9] | ~40-46 GB (INT4, method-dependent) | 128,000 tokens | ≈ 39 GiB ≈ 42 GB (BF16) | ~75-90 GB | Impossible without enterprise-class hardware (multi-GPU or data-centre-class VRAM) |
To work around this bottleneck, KV cache quantisation stands out as an essential technique: converting Keys and Values to INT8 or INT4 mechanically reduces memory usage by 50% to 75% (a direct consequence of the P_bytes term in the formula above), for a perplexity degradation generally described as minor across most tasks. The figure most commonly cited is 1% to 3%, though no single source is authoritative for this exact range across every architecture.
To optimise these savings without excessively degrading generation fidelity, one avenue explored by research is to quantise deeper layers of the network more aggressively than the earlier ones, a depth-based adaptation documented notably by PyramidKV [11], which shows that a reduced cache budget in the upper layers affects quality less than in the early layers. This is a distinct approach from the per-channel/per-token 2-bit quantisation proposed by KIVI [10], which targets precision rather than depth. The two techniques are complementary rather than competing.
Financial impact on frontier models: prompt caching and economies of scale
For teams using frontier-model APIs, every token sent in the input window represents a direct financial charge. The standard billing model imputes a cost for processing the prompt (the prefill phase) and a higher cost for generating output tokens (decode). In autonomous agent systems, enterprise RAG, or coding assistants, repeatedly ingesting long, identical context (typing rules, a reference codebase, system instructions) generates massive budget waste if nothing is done to prevent it.
Prompt caching consists of retaining, server-side, the KV cache corresponding to the pre-fill of a stable prompt prefix. When successive requests share that same prefix, the API bills processing those tokens at a heavily reduced rate. Access and pricing conditions vary considerably from one provider to the next.
Anthropic requires explicit cache_control markers to be inserted into the request structure to indicate which sections of the context should be cached. It is a manual approach that offers fine-grained control, with an eligibility threshold that varies by model (2,048 tokens minimum for Claude Sonnet 4.6, 4,096 tokens for the Opus family). A 90% discount applies to tokens read from cache, with a modest write penalty: a 25% surcharge on a prefix cached for the first time (5-minute TTL), amortised from the second identical request onward.
OpenAI automatically detects prefix matches on incoming requests, with no marker and no caching surcharge: if the first 1,024 tokens of the prompt match a sequence submitted recently, the system applies a 90% discount with no application-code changes required. This mechanism, confirmed on GPT-5.5 (April 2026), has since evolved: as of 9 July 2026, GPT-5.6 (which succeeded GPT-5.5 just days before this article’s publication) introduces a 1.25× cache-write surcharge, ending fully free caching at OpenAI. A signal worth watching: providers’ pricing terms shift almost as fast as the models themselves.
Google actually runs two distinct mechanisms, a nuance often overlooked. Automatic implicit caching applies by default from 4,096 tokens of shared prefix (no configuration required), while explicit caching, activated manually via the API, guarantees a fixed retention period (TTL) for large, stable RAG contexts, with a considerably higher eligibility threshold, starting at 32,768 tokens. On Gemini 3.1 Pro (still in Preview as of mid-2026), the discount reaches 90% in both cases for prompts up to 200,000 tokens.
DeepSeek offers the most aggressive mechanism: prefix detection is automatic and free to write, with a minimal eligibility threshold of just 64 tokens, far more permissive than the four-digit thresholds of other providers. On DeepSeek-V4-Flash, a cache read costs $0.0028 per million tokens against $0.14 for a standard write, a 98% discount.
| Provider | Reference model | Standard input price (/1M tokens) | Cached input price (/1M tokens) | Discount | Activation | Minimum threshold |
|---|---|---|---|---|---|---|
| Anthropic | Claude Sonnet 4.6 | $3.00 | $0.30 | -90% | Manual (cache_control) | 2,048 tokens |
| OpenAI | GPT-5.5 (April 2026) | $5.00 | $0.50 | -90% | Automatic (prefix) | 1,024 tokens |
| Gemini 3.1 Pro (Preview) | $2.00 (≤ 200K) | $0.20 | -90% | Automatic (implicit) or manual (explicit, guaranteed TTL) | 4,096 tokens (implicit) / 32,768 tokens (explicit) | |
| DeepSeek | DeepSeek-V4-Flash | $0.14 | $0.0028 | -98% | Automatic (prefix) | 64 tokens |
To make the most of these pricing structures, the semantic layout of requests must be rigorously ordered: global instructions, stable background data and output schemas at the top of the prompt; dynamic content (timestamps, user IDs, the user’s question) at the end of the message. Any change to the prefix, however small, invalidates the downstream cache and triggers a costly cache miss. By combining carefully ordered requests with batch-processing pipelines (Batch APIs, which grant an additional flat discount at several providers), teams can meaningfully cut their inference bill.
Towards an optimal context architecture: reranking, compression and multi-agent systems
To resolve the tension between the need for factual data and the risk of attentional dilution or hardware overspend, modern architectures apply successive refinement passes to the incoming information flow, rather than saturating the context window with a brute-force approach.
Precision reranking. In a standard RAG system, vector embedding models perform a first, fast pass at selecting relevant documents, but these bi-encoder models don’t analyse the fine-grained interaction between the question and each individual passage. A cross-encoder reranker model precisely scores the relative relevance of each excerpt against the question asked, keeps only the highest-scoring passages, then deliberately places the most critical excerpts at the very start and end of the prompt, leaving the centre of the window empty of any medium-importance content, directly working around the Lost in the Middle phenomenon documented in Figure 1.
Algorithmic prompt compression. Three tools in the LLMLingua family (Microsoft Research), often conflated, address distinct needs:
- LLMLingua [16] (the original version) uses a small local language model to compute the perplexity of each segment of the prompt: highly predictable words (low perplexity) are dropped, while syntactic and semantic pivots carrying meaning (high perplexity) are preserved. Microsoft Research’s benchmarks report compression of up to 20× with limited performance loss.
- LLMLingua-2 [17] abandons the perplexity-based approach in favour of a binary (keep/drop) BERT-style classifier, trained via data distillation from GPT-4. Explicitly built to be task-agnostic (it compresses without ever seeing the final question), it targets a more modest compression range (roughly 2× to 5×) but is faster and more robust than the perplexity-based approach.
- LongLLMLingua [18] is the variant built specifically for long-context and RAG scenarios: unlike LLMLingua-2, it is question-aware. It reorders and coarsely filters document segments by their relevance to the question asked, ahead of fine-grained compression, and includes an explicit document-reordering strategy to reduce positional bias. Alongside reranking, it is one of the few techniques designed to tackle the Lost in the Middle phenomenon head-on.
Multi-agent topologies. To work around the degradation of self-verification capabilities and the compression of reasoning traces induced by large contexts (see the previous section), a complex task can be split across a network of specialised agents. Instead of routing one global request to a single model equipped with a window spanning hundreds of thousands of tokens, the problem is broken into independent sub-goals handed to autonomous instances, each receiving an ultra-targeted, tightly filtered context, ideally under the 25,000-token mark, the “optimal” zone identified in Figure 2. Orchestrating these agents and synthesising their output aims for processing that is both complete and robust on logical accuracy.
| Optimisation approach | Goal | Trade-off / implementation cost |
|---|---|---|
| Reranking | Eliminate noise, position the essentials at the edges of the prompt | Additional latency from the cross-encoder pass |
| Prompt compression (LLMLingua) [16][17] | Eliminate linguistic redundancy via perplexity analysis or token-by-token classification | Requires running a small compression model upstream; up to 20× for LLMLingua, 2-5× for LLMLingua-2 |
| Question-aware compression (LongLLMLingua) [18] | Reorder and filter segments by their relevance to the question asked | Adds a per-request scoring step; specifically targets positional bias |
| Multi-agent architecture | Split a massive context across specialised agents with limited memory (ideally < 25,000 tokens) | Increased orchestration complexity and message-routing overhead |
Conclusions and strategic recommendations
Managing context window size has become a pillar of AI systems engineering. Haphazardly saturating a transformer’s input window damages its real cognitive capabilities: attention is a zero-sum resource, sensitive to positional bias and vulnerable to semantic interference. At the opposite extreme, excessively reducing context produces factual drift and hallucination.
Reconciling logical accuracy, the responsiveness of local systems, and the profitability of distributed architectures requires dynamic, qualitative context management: reranking to place critical information at the edges of the sequence, compression to eliminate unnecessary linguistic redundancy, and multi-agent architectures to break large tasks into low-memory-footprint sub-problems. By rigorously structuring input data to make the most of prompt-caching technologies, teams can build solutions that are robust and high-value, on both the hardware and the financial side.
That is exactly the logic behind the MATIA Method™: context window size isn’t a dial you push to the maximum by reflex. It’s an engineering variable you size to the task.
Going further
The AI Express Audit (a 60-minute video session, free, no obligation) includes a review of your context and inference-cost architecture: context window, KV cache, prompt caching and model choice.
On the FinOps side (token budgets, LLM gateways, dynamic routing), see Token budgets and AI APIs: the FinOps guide for SMEs (French original; English summary available on request).
The white paper “AI Maturity of French SMEs 2025-2026” is available at croissance-transitions.fr.
Sources
[1] Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang, Lost in the Middle: How Language Models Use Long Contexts (TACL 2024, vol. 12, pp. 157-173; arXiv:2307.03172, July 2023), U-shaped positional bias in long-context information retrieval. https://arxiv.org/abs/2307.03172
[2] Guangxuan Xiao, Yuandong Tian, Beidi Chen, Song Han, Mike Lewis, Efficient Streaming Language Models with Attention Sinks (ICLR 2024; arXiv:2309.17453, Sept. 2023), over-allocation of attention to the first tokens of a sequence. https://arxiv.org/abs/2309.17453
[3] Freda Shi, Xinyun Chen, Kanishka Misra, Nathan Scales, David Dohan, Ed H. Chi, Nathanael Schärli, Denny Zhou, Large Language Models Can Be Easily Distracted by Irrelevant Context (ICML 2023; arXiv:2302.00093, Feb. 2023), GSM-IC benchmark, semantic distraction. https://arxiv.org/abs/2302.00093
[4] Yufeng Du, Minyang Tian, Srikanth Ronanki, Subendhu Rongali, Sravan Bodapati, Aram Galstyan, Azton Wells, Roy Schwartz, Eliu A. Huerta, Hao Peng, Context Length Alone Hurts LLM Performance Despite Perfect Retrieval (Findings of EMNLP 2025; arXiv:2510.05381, Oct. 2025), 13.9% to 85% degradation despite perfect retrieval, tested across 5 models. https://arxiv.org/abs/2510.05381
[5] Gleb Rodionov, Roman Garipov, George Yakushev, Reasoning Shift: How Context Silently Shortens LLM Reasoning (preprint, not yet peer-reviewed; arXiv:2604.01161, April-June 2026), reduction of up to 65% in internal reasoning traces under heavy context. Preliminary result, treat with caution. https://arxiv.org/abs/2604.01161
[6] Meta, Llama 3.1 8B Instruct, model configuration (32 layers, 8 GQA KV heads, head dimension 128); KV cache calculation derived from this configuration.
[7] Microsoft, Phi-4 Technical Report (arXiv:2412.08905, Dec. 2024), 14B parameters, 40 layers, 8 KV heads, native context of 16,384 tokens.
[8] Alibaba, Qwen3-32B, model card (April 2025, Apache 2.0 licence; 64 layers, 8 KV heads, head dimension 128, native context of 40,960 tokens).
[9] Meta, Llama 3.3 70B, model configuration (Dec. 2024; 80 layers, 8 KV heads, head dimension 128, 128,000-token context).
[10] Zirui Liu et al., KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache (arXiv:2402.02750, Feb. 2024), 2-bit quantisation, per-channel (keys) / per-token (values).
[11] Zefan Zhang et al., PyramidKV: Dynamic KV Cache Compression based on Pyramidal Information Funneling (arXiv:2406.02069, 2024), cache compression adapted to layer depth.
[12] Anthropic documentation, Prompt Caching, per-model thresholds, 90% read discount, 25% write surcharge (5-min TTL) or 100% (1h TTL).
[13] OpenAI documentation, Prompt Caching + GPT-5.6 announcement (9 July 2026), automatic prefix detection, introduction of a 1.25× write surcharge on GPT-5.6.
[14] Google DeepMind, Gemini 3.1 Pro, model card (19 February 2026, Preview status); implicit and explicit caching documentation.
[15] DeepSeek documentation, pricing and context caching, DeepSeek-V4-Flash (April 2026), minimum threshold of 64 tokens.
[16] Huiqiang Jiang, Qianhui Wu, Chin-Yew Lin, Yuqing Yang, Lili Qiu, LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models (EMNLP 2023; arXiv:2310.05736), perplexity-based compression, up to 20×. https://arxiv.org/abs/2310.05736
[17] Zhuoshi Pan, Qianhui Wu, Huiqiang Jiang et al., LLMLingua-2: Data Distillation for Efficient and Faithful Task-Agnostic Prompt Compression (ACL 2024 Findings; arXiv:2403.12968), GPT-4-distilled BERT classifier, task-agnostic. https://arxiv.org/abs/2403.12968
[18] Huiqiang Jiang, Qianhui Wu, Xufang Luo, Dongsheng Li, Chin-Yew Lin, Yuqing Yang, Lili Qiu, LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression (arXiv:2310.06839, 2024), question-aware compression and document reordering. https://arxiv.org/abs/2310.06839
Written by Paul-Antoine TUAL, AI Transformation Leader, creator of the MATIA Method™.
Frequently asked questions
- What is "context dilution" in a large language model?
- It's a degradation of an LLM's reasoning ability caused by an excess of irrelevant information injected into the prompt, not by its absence. Because the attention mechanism is a zero-sum resource (the softmax normalisation forces total attention across the sequence to sum to 1), every superfluous token siphons off attention that should have gone to the useful data, degrading accuracy even when the information being sought is genuinely present in the context.
- Why does a model struggle more with information in the middle of a long context than at the start or end?
- This phenomenon, documented by Liu et al. as "Lost in the Middle" (TACL 2024), combines several effects: models develop "attention sinks" that over-weight the very first tokens regardless of relevance, the end position benefits from proximity to the generated answer, and middle positions are structurally disadvantaged by both biases combined. Techniques such as reranking or LongLLMLingua work around this bias by deliberately placing critical information at the edges of the prompt.
- How is KV cache size calculated, and why does it saturate a GPU's VRAM?
- The formula M_KV = 2 × L × H_kv × D_head × N_seq × B × P_bytes shows that the cache grows linearly with context length and batch size. For Llama 3.1 8B at 32,768 tokens in BF16, that works out to exactly 4 GiB, on top of the model's roughly 16 GB of weights. Once the sum exceeds the physical VRAM available, execution spills over into system RAM (CPU spill), and decoding speed collapses.
- Does prompt caching work the same way across every API provider?
- No. Anthropic requires explicit cache_control markers and a minimum threshold of 2,048 tokens on Claude Sonnet 4.6, with a 90% discount and a 25% write penalty. OpenAI automatically detects prefixes from 1,024 tokens. Google combines automatic implicit caching (from 4,096 tokens) with manual explicit caching (from 32,768 tokens, guaranteed retention). DeepSeek goes as low as a 64-token threshold with a 98% discount. The eligibility threshold and activation method vary sharply from one provider to the next.
- Should you always fill the context window to its maximum available size?
- No, and that's precisely the mistake to avoid. Response reliability isn't monotonic with context size: it climbs as relevant data is added, plateaus in a dense, tightly-scoped zone, and then falls again once the volume of noise outweighs the volume of useful signal. The goal isn't to maximise context, but to size it to the task, even if that means splitting it across several specialised agents rather than concentrating it in a single window.
Paul-Antoine Tual
AI Transformation Leader · MATIA Method™ · Transition manager specialising in AI for French SMEs and mid-caps. Engineer from the École des Mines de Nantes, lawyer, developer since 1993.