Imaginez un taxi dont le compteur ne s'arrête jamais — même quand vous êtes coincé dans les embouteillages, même quand le chauffeur réfléchit à voix haute à votre itinéraire, même quand il relit en boucle toutes les adresses précédentes avant de vous déposer à la suivante. Chaque seconde d'hésitation, chaque reformulation, chaque rappel du trajet depuis le début : tout est facturé.
C'est exactement ainsi que fonctionne un agent IA en production. Et si personne ne vous l'a jamais expliqué en ces termes, c'est probablement parce que l'industrie préfère parler de "puissance" et de "fenêtre de contexte" plutôt que de vous montrer la facture en train de s'accumuler.
L'atome qu'on ne voit pas
Avant de comprendre pourquoi ça coûte cher et pourquoi ça plante, il faut comprendre ce qu'est un token — vraiment.
Un modèle de langage ne lit pas des mots. Il ne lit pas des lettres non plus. Il lit des tokens : des fragments de texte, d'une longueur variable, qui correspondent à des unités fréquentes dans son corpus d'entraînement. Le mot "chat" est probablement un seul token. Le mot "tokenisation" pourrait en être deux ou trois. Un emoji, quatre.
La règle approximative pour l'anglais : un token ≈ 4 caractères, soit environ trois quarts d'un mot. Mais cette règle est très occidentalo-centrée. Et c'est là que les choses deviennent politiquement inconfortables.
Une phrase simple en espagnol consomme 50% de tokens en plus qu'en anglais pour transmettre le même sens. En coréen ou en arabe, la consommation peut tripler. Ce n'est pas qu'une question de coût — c'est une question de capacité de raisonnement. Si un modèle peut analyser un document de 100 pages en anglais, il ne peut en analyser que 33 dans ces langues avec la même fenêtre de contexte. La fenêtre de raisonnement effectif est structurellement plus étroite pour certaines cultures que pour d'autres.
Ce biais n'est pas intentionnel. Il est architectural. Et il est invisible pour la plupart des utilisateurs.
Trois algorithmes dominent la tokenisation : le BPE (Byte-Pair Encoding), utilisé par GPT et Llama, qui fusionne itérativement les paires de caractères les plus fréquentes dans un corpus ; WordPiece, employé par BERT, qui utilise un modèle probabiliste pour maximiser la compréhension sémantique ; et SentencePiece, utilisé par Gemini et T5, qui traite le texte comme une séquence brute d'octets — particulièrement robuste pour les langues sans espaces comme le japonais, ou pour le code informatique.
Le choix du vocabulaire impose un compromis technique déterminant : un vocabulaire large produit des séquences courtes (moins de tokens, plus rapide, moins cher) mais exige plus de mémoire vive pour stocker les tables d'embeddings. Un vocabulaire restreint produit des séquences longues qui saturent le contexte plus vite. Ce n'est pas un détail d'implémentation — c'est un choix d'architecture aux conséquences financières et cognitives directes.
Ce que vous payez vraiment — et ce que vous ne voyez pas
Quand vous utilisez l'API d'OpenAI, d'Anthropic ou de Google, la facture distingue deux types de tokens : les tokens d'entrée (votre prompt) et les tokens de sortie (la réponse générée). Les tokens de sortie coûtent systématiquement de 3 à 5 fois plus cher — parce que les générer est computationnellement plus coûteux que de simplement encoder votre question.
Jusque-là, c'est logique. Mais il y a deux lignes moins visibles sur cette facture.
La première : les tokens de cache. Lorsqu'une partie de votre prompt est identique à une requête précédente — des instructions système, un document de référence — les fournisseurs peuvent récupérer ces tokens depuis un cache, réduisant leur coût d'entrée de 90% et la latence de façon significative. C'est une technique d'optimisation majeure que la plupart des développeurs n'utilisent pas par défaut.
La seconde, et la plus surprenante : les tokens de raisonnement. Les modèles de la série o1 d'OpenAI, et leurs équivalents chez d'autres fournisseurs, "pensent avant de répondre" via une chaîne de pensée interne. Ces étapes de réflexion ne sont jamais affichées à l'utilisateur — mais elles occupent de l'espace dans la fenêtre de contexte et sont facturées au tarif des tokens de sortie. C'est pourquoi certains modèles semblent "consommer" un budget considérable sans produire de longues réponses : leur réflexion invisible est la partie la plus coûteuse.
| Type de token | Facturation | Visible ? | Rôle |
|---|---|---|---|
| Prompt (entrée) | Standard | ✓ | Instructions, contexte, exemples |
| Completion (sortie) | Élevée (3×–5×) | ✓ | Réponse finale |
| Cache | Réduite (−90%) | ✗ | Historique et instructions récurrents |
| Raisonnement | Élevée | ✗ | Étapes de réflexion interne |
Quand le taxi prend un détour de 90% du trajet
Jusqu'ici, nous parlions d'un échange simple : vous posez une question, l'IA répond. Dans un agent IA autonome — un système qui planifie, utilise des outils, fait des recherches, agit sur plusieurs étapes — la dynamique change radicalement.
Le paradigme dominant s'appelle ReAct (Reasoning + Acting). À chaque étape, l'agent verbalise sa pensée ("Je dois d'abord vérifier l'état du serveur, puis consulter les logs..."), utilise un outil, observe le résultat, et recommence. Ce cycle est conçu pour la fiabilité : en rendant le raisonnement explicite, on permet au modèle de s'auto-corriger.
Le coût caché : à chaque nouvelle étape, l'intégralité de la trace des étapes précédentes est renvoyée au modèle. Si l'agent effectue dix itérations pour résoudre un problème, le dixième appel contient les neuf premières traces complètes. L'accumulation est implacable.
Les données sont saisissantes : dans les tâches complexes, 90% des tokens consommés sont dédiés au raisonnement interne et aux logs d'outils — pas à la réponse finale que vous lisez. Vous payez le trajet en entier pour n'utiliser que les dix derniers mètres.
Ce phénomène a un nom technique : le Context Rot — la pourriture du contexte. La fenêtre disponible se transforme progressivement en dépotoir d'informations accumulées, les nouvelles instructions se retrouvent noyées dans le bruit des anciennes observations, et l'agent commence à perdre de vue son objectif initial. Les symptômes : des boucles répétitives, des actions contradictoires, des oublis d'instructions pourtant explicites.
Le paradoxe de la mémoire
Voici l'intuition raisonnable que tout le monde a en découvrant ce problème : "Il suffit de donner une mémoire externe à l'agent — une base de données — pour qu'il n'ait plus besoin de tout garder dans son contexte."
C'est partiellement faux. Et comprendre pourquoi est peut-être la révélation la plus contre-intuitive de cet article.
Un modèle de langage est sans état (stateless). Entre deux appels, il ne se souvient de rien. Sa "mémoire" n'est pas un stockage interne — c'est de l'information externe convertie en tokens de prompt à chaque nouvel appel. Quand vous ajoutez un système RAG (Retrieval-Augmented Generation) pour donner de la mémoire à un agent, vous récupérez des fragments de documents depuis une base vectorielle et vous les ajoutez au prompt actuel. La mémoire ne remplace pas les tokens : elle en ajoute.
Pire : certaines architectures de mémoire (comme la méthode Parent-Child, qui récupère des blocs de 2000 tokens pour préserver le contexte) consomment encore plus d'espace pour être plus précises. Plus la mémoire est riche, plus elle alourdit le prompt, plus elle accélère la saturation.
La mémoire n'est pas un substitut aux tokens. C'est une source supplémentaire d'inflation.
La progression du coût dans une conversation multi-tours illustre ce mécanisme avec une clarté brutale.
Au premier tour : 100 tokens d'entrée + 100 de sortie = 200 tokens facturés. Au deuxième : 200 d'historique + 100 nouveaux + 100 de sortie = 400 tokens. Au troisième : 400 d'historique + 100 nouveaux + 100 de sortie = 600 tokens.
En trois tours seulement, le système a traité 1 200 tokens pour une conversation qui n'en contient réellement que 600 du point de vue humain. Dans un agent effectuant des dizaines d'itérations, ce re-traitement constant de l'historique est la principale cause de l'explosion des factures et des erreurs par dépassement de limite.
Le défi ne passe donc pas d'une limite de stockage à une limite de filtrage : comment identifier le 1% de mémoire le plus pertinent à injecter à chaque étape, sans saturer le contexte ni perdre les informations critiques ?
La limite physique qu'on ne peut pas contourner
Au-delà des choix d'architecture, il y a des contraintes qui relèvent de la physique.
L'attention — le mécanisme central des transformeurs — a une complexité de calcul de O(n²). Doubler la taille du contexte ne double pas la charge de calcul : elle la quadruple. Pour 100 000 tokens, le nombre de calculs d'attention atteint 10 milliards. C'est pour cette raison que les longs contextes sont exponentiellement plus lents et coûteux à traiter.
Sur le plan matériel, le goulot d'étranglement n'est pas la puissance brute des processeurs — c'est la mémoire vidéo (VRAM). Chaque token généré doit être stocké dans le cache KV (Key-Value), qui conserve les représentations mathématiques de tous les tokens précédents. Dans un modèle de 70 milliards de paramètres, ce cache peut occuper 40 gigaoctets de VRAM pour un contexte étendu — dépassant parfois le poids du modèle lui-même. Quand la VRAM est saturée, le système doit soit rejeter la requête, soit transférer vers la RAM système, ce qui multiplie la latence.
Et même quand la fenêtre de contexte est techniquement immense — Gemini 1.5 Pro supporte jusqu'à 2 millions de tokens — l'efficacité n'est pas uniforme. Les recherches ont documenté l'effet "Lost in the Middle" : les modèles accordent une attention disproportionnée aux informations situées au début et à la fin de la séquence, négligeant ce qui est au centre. Résultat : les développeurs multiplient les répétitions d'instructions pour compenser — ce qui réduit encore l'espace disponible et accélère l'épuisement.
La taxe d'infidélité
Il y a un coût supplémentaire que l'industrie évoque rarement dans ses communications : l'Unreliability Tax — la taxe d'infidélité.
Pour compenser la nature probabiliste des LLM, les ingénieurs en production ajoutent des couches de sécurité : des boucles de réflexion (Reflexion loops) où l'agent critique sa propre réponse avant de la valider, des validateurs externes, des vérificateurs de cohérence. Chaque couche consomme des tokens.
Une boucle de réflexion qui s'exécute sur dix cycles peut consommer cinquante fois plus de tokens qu'une seule passe linéaire. Ce surcoût est souvent nécessaire pour atteindre les niveaux de précision exigés par les entreprises (généralement 95% ou plus). Mais il porte le coût d'un simple correctif logiciel à 5 à 8 dollars par tâche. Pour des systèmes qui traitent des milliers de tâches par jour, la facture est rapidement astronomique.
Les solutions qui fonctionnent vraiment
Face à cette accumulation de contraintes, l'ingénierie moderne a développé des réponses concrètes. Elles ne résolvent pas les limites physiques — mais elles permettent de travailler avec elles plutôt que contre elles.
Le masquage d'observations plutôt que le résumé. La méthode classique consiste à demander à un LLM de résumer les tours de parole anciens pour libérer de l'espace. Le problème : résumer est lossy — il efface les nuances et les préférences subtiles. Une alternative plus efficace est le masquage d'observations : supprimer les sorties brutes et volumineuses des outils tout en conservant intactes les traces de raisonnement de l'agent. Des études montrent que cette approche est 52% moins coûteuse que le résumé tout en offrant une meilleure stabilité du raisonnement.
LangGraph plutôt que LangChain pour les agents complexes. LangChain, le framework de première génération, accumule l'historique de manière indifférenciée dans un objet unique — ce qui conduit inévitablement à l'explosion. LangGraph introduit un graphe d'états où le développeur définit précisément ce qui doit être transmis d'un nœud à l'autre. Un résultat de recherche volumineux peut être stocké dans l'état interne du graphe ; seul un identifiant ou un résumé est transmis au LLM à l'étape suivante. Ce contrôle granulaire permet à un agent de fonctionner sur des centaines de cycles sans saturer son contexte.
Le Prompt Caching pour les systèmes multi-agents. Dans une architecture où dix agents spécialisés reçoivent chacun les mêmes 20 pages d'instructions système, sans caching ces tokens sont facturés dix fois. Avec le Prompt Caching bien structuré, ils ne sont calculés qu'une seule fois pour le cluster entier — réduction de 90% des coûts d'instruction et latence divisée de façon significative.
La hiérarchisation de la mémoire. Les systèmes les plus robustes organisent la mémoire sur trois niveaux : une mémoire de travail (le contexte immédiat, quelques milliers de tokens dans le prompt), une mémoire épisodique (les interactions passées dans une base vectorielle, récupérées par similarité sémantique uniquement quand elles sont pertinentes), et une mémoire sémantique (les faits stabilisés et préférences utilisateur stockés sous forme structurée JSON/YAML, bien plus denses que du texte brut). Cette segmentation garantit que le prompt ne contient que le strict nécessaire à chaque étape.
StreamingLLM pour les séquences très longues. Une technique émergente a résolu partiellement le problème des contextes quasi-infinis. Les chercheurs ont observé que les modèles accordent une attention considérable aux tout premiers tokens d'une séquence — des caractères initiaux qui agissent comme des "puits d'attention" stabilisateurs. En conservant systématiquement ces tokens d'ancrage et en utilisant une fenêtre glissante pour les tokens récents, StreamingLLM permet de traiter des millions de tokens sans explosion de calcul, même si la mémoire active reste limitée à la fenêtre d'entraînement.
L'intelligence de ne pas tout penser à voix haute
Il y a une leçon de conception qui traverse toutes ces optimisations. Les architectures les plus efficaces ne cherchent pas à donner plus de mémoire aux agents — elles cherchent à leur donner moins d'information mieux choisie.
Les modèles de raisonnement intenses (comme la série o1) sont excellents pour les tâches de haute complexité qui méritent une réflexion approfondie. Ils sont désastreusement coûteux pour la coordination simple et les décisions routinières. Les systèmes bien conçus réservent ces modèles aux nœuds critiques et utilisent des modèles légers pour l'orchestration.
De même, l'idée d'un contexte "le plus grand possible" est une intuition trompeuse. Un contexte de 100 000 tokens avec l'information bien structurée surpasse systématiquement un contexte de 200 000 tokens mal filtré — parce que le modèle sait où regarder, et que l'effet "Lost in the Middle" n'érode pas son attention.
L'avenir des agents IA ne réside pas dans des contextes plus grands. Il réside dans la sobriété contextuelle : chaque token injecté doit gagner sa place.
La facture que personne ne vous montre
Retour au taxi. Le compteur tourne depuis le début de cet article. Chaque token de raisonnement que votre agent produit sans vous en informer, chaque historique de conversation re-traité intégralement à chaque tour, chaque document vectoriel injecté dans le prompt "au cas où" — tout cela s'accumule dans une facture que peu d'organisations mesurent vraiment avant que ça ne devienne un problème.
La bonne nouvelle : les outils pour contrôler cette facture existent. Le caching, LangGraph, le masquage d'observations, la mémoire hiérarchique — ce sont des décisions d'architecture, pas des patchs. Elles demandent de comprendre le système en profondeur avant de construire dessus.
La mauvaise nouvelle : la complexité quadratique de l'attention, les limites physiques de la VRAM, la nature stateless des modèles — ces contraintes ne disparaîtront pas avec la prochaine version d'un modèle. Elles sont dans la structure même de la technologie. L'efficacité, dans ce contexte, n'est pas une optimisation de confort. C'est une condition de viabilité.
Picture a taxi whose meter never stops running — even when you're stuck in traffic, even when the driver thinks out loud about your route, even when they reread every previous address before dropping you at the next one. Every second of hesitation, every reformulation, every recap of the full journey from the start: all billed.
That's exactly how an AI agent works in production. And if nobody has explained it in those terms, it's probably because the industry prefers to talk about "power" and "context windows" rather than show you the accumulating bill.
The atom nobody sees
Before understanding why it's expensive and why it breaks, you need to understand what a token actually is — really.
A language model doesn't read words. It doesn't read letters either. It reads tokens: text fragments of variable length corresponding to frequent units in its training corpus. The word "chat" is probably one token. The word "tokenization" might be two or three. An emoji, four.
The rough rule for English: one token ≈ 4 characters, roughly three-quarters of a word. But this rule is highly Western-centric. And that's where things become politically uncomfortable.
A simple sentence in Spanish consumes 50% more tokens than in English to convey the same meaning. In Korean or Arabic, consumption can triple. This isn't just a cost issue — it's a reasoning capacity issue. If a model can analyze a 100-page document in English, it can only analyze 33 pages in those languages with the same context window. The effective reasoning window is structurally narrower for certain cultures than for others.
This bias isn't intentional. It's architectural. And it's invisible to most users.
Three algorithms dominate tokenization: BPE (Byte-Pair Encoding), used by GPT and Llama, which iteratively merges the most frequent character pairs in a corpus; WordPiece, used by BERT, which employs a probabilistic model to maximize semantic understanding; and SentencePiece, used by Gemini and T5, which treats text as a raw byte sequence — particularly robust for languages without spaces like Japanese, or for code where indentation is meaningful.
The vocabulary size choice imposes a decisive technical trade-off: a large vocabulary produces short sequences (fewer tokens, faster, cheaper) but requires more RAM to store embedding tables. A small vocabulary produces longer sequences that saturate context faster. This isn't an implementation detail — it's an architectural choice with direct financial and cognitive consequences.
What you're actually paying for — and what you can't see
When you use the OpenAI, Anthropic, or Google API, the bill distinguishes two token types: input tokens (your prompt) and output tokens (the generated response). Output tokens cost systematically 3 to 5 times more — because generating them is computationally more expensive than simply encoding your question.
So far, logical. But there are two less visible line items on this bill.
First: cached tokens. When part of your prompt is identical to a previous request — system instructions, reference documents — providers can retrieve those tokens from cache, reducing input cost by 90% and significantly reducing latency. It's a major optimization technique that most developers don't use by default.
Second, and most surprising: reasoning tokens. OpenAI's o1 series models, and their equivalents at other providers, "think before responding" through an internal chain of thought. These reflection steps are never shown to the user — but they occupy space in the context window and are billed at output token rates. This is why some models appear to "consume" considerable budget without producing long responses: their invisible reasoning is the most expensive part.
| Token type | Billing | Visible? | Role |
|---|---|---|---|
| Prompt (input) | Standard | ✓ | Instructions, context, examples |
| Completion (output) | High (3×–5×) | ✓ | Final response |
| Cache | Reduced (−90%) | ✗ | Recurring history and instructions |
| Reasoning | High | ✗ | Internal reflection steps |
When the taxi takes a 90% detour
Until now, we were talking about a simple exchange: you ask a question, the AI responds. In an autonomous AI agent — a system that plans, uses tools, researches, acts across multiple steps — the dynamics change radically.
The dominant paradigm is called ReAct (Reasoning + Acting). At each step, the agent verbalizes its thinking ("I need to first check the server status, then consult the logs..."), uses a tool, observes the result, and repeats. This cycle is designed for reliability: making reasoning explicit allows the model to self-correct.
The hidden cost: at each new step, the complete trace of all previous steps is sent back to the model. If the agent performs ten iterations to solve a problem, the tenth call contains the nine previous complete traces. The accumulation is relentless.
The numbers are striking: in complex tasks, 90% of consumed tokens are dedicated to internal reasoning and tool logs — not the final response you read. You're paying for the entire journey to use only the last ten meters.
This phenomenon has a technical name: Context Rot — context decay. The available window progressively transforms into an information dump, new instructions get buried under the noise of old observations, and the agent begins losing sight of its original objective. Symptoms: repetitive loops, contradictory actions, forgetting explicitly stated instructions.
The memory paradox
Here's the reasonable intuition everyone has upon discovering this problem: "Just give the agent external memory — a database — so it doesn't need to keep everything in its context."
This is partially wrong. And understanding why is perhaps the most counter-intuitive revelation in this article.
A language model is stateless. Between two calls, it remembers nothing. Its "memory" isn't internal storage — it's external information converted into prompt tokens with each new call. When you add a RAG system (Retrieval-Augmented Generation) to give an agent memory, you retrieve document fragments from a vector database and add them to the current prompt. Memory doesn't replace tokens: it adds them.
Worse: some memory architectures (like the Parent-Child method, which retrieves 2,000-token blocks to preserve context) consume even more space to be more precise. The richer the memory, the heavier the prompt, the faster the saturation.
Memory isn't a substitute for tokens. It's an additional source of token inflation.
The cost progression in a multi-turn conversation illustrates this mechanism with brutal clarity.
Turn 1: 100 input tokens + 100 output = 200 tokens billed. Turn 2: 200 history + 100 new input + 100 output = 400 tokens. Turn 3: 400 history + 100 new + 100 output = 600 tokens.
In just three turns, the system processed 1,200 tokens for a conversation that humanly contains only 600. In an agent performing dozens of iterations, this constant re-processing of history is the primary cause of exploding bills and limit-exceeded errors.
The challenge therefore shifts from a storage limit to a filtering limit: how do you identify the most relevant 1% of memory to inject at each step, without saturating the context or losing critical information?
The physical limit you can't engineer around
Beyond architectural choices, some constraints are matters of physics.
Attention — the central mechanism of transformers — has a computational complexity of O(n²). Doubling context size doesn't double the computational load: it quadruples it. For 100,000 tokens, the number of attention calculations reaches 10 billion. This is why long contexts are exponentially slower and more expensive to process.
On the hardware side, the bottleneck isn't raw processor power — it's video memory (VRAM). Each generated token must be stored in the KV cache (Key-Value), which holds the mathematical representations of all previous tokens. In a 70-billion-parameter model, this cache can occupy 40 gigabytes of VRAM for extended context — sometimes exceeding the model's own weight. When VRAM saturates, the system must either reject the request or offload to system RAM, multiplying latency dramatically.
And even when the context window is technically immense — Gemini 1.5 Pro supports up to 2 million tokens — efficiency isn't uniform. Research has documented the "Lost in the Middle" effect: models pay disproportionate attention to information at the beginning and end of sequences, neglecting what sits in the center. Result: developers multiply instruction repetitions to compensate — which further reduces available space and accelerates token exhaustion.
The unreliability tax
There's an additional cost the industry rarely mentions in its communications: the Unreliability Tax.
To compensate for the probabilistic nature of LLMs, production engineers add safety layers: reflection loops where the agent critiques its own response before validating, external validators, coherence checkers. Each layer consumes tokens.
A reflection loop running across ten cycles can consume fifty times more tokens than a single linear pass. This overhead is often necessary to reach the precision levels enterprises require (typically 95% or above). But it pushes the cost of a simple software fix to $5 to $8 per task. For systems processing thousands of tasks per day, the bill becomes astronomical quickly.
The solutions that actually work
Against this accumulation of constraints, modern engineering has developed concrete responses. They don't solve the physical limits — but they allow working with them rather than against them.
Observation masking over summarization. The classic method asks an LLM to summarize old conversation turns to free space. The problem: summarizing is lossy — it erases subtle nuances and user preferences. A more effective alternative is observation masking: removing bulky raw tool outputs while preserving the agent's reasoning traces intact. Studies show this approach is 52% cheaper than summarization while offering better reasoning stability.
LangGraph over LangChain for complex agents. LangChain, the first-generation framework, accumulates history indiscriminately in a single object — inevitably leading to explosion. LangGraph introduces a state graph where the developer precisely defines what should pass from one node to the next. A voluminous search result can be stored in the graph's internal state; only an identifier or summary is transmitted to the LLM at the next step. This granular control lets an agent run for hundreds of cycles without saturating its context.
Prompt Caching for multi-agent systems. In an architecture where ten specialized agents each receive the same 20 pages of system instructions, without caching those tokens are billed ten times. With well-structured Prompt Caching, they're only computed once for the entire cluster — 90% reduction in instruction costs and dramatically lower latency.
Memory hierarchy. The most robust systems organize memory across three levels: working memory (immediate context, a few thousand tokens in the prompt), episodic memory (past interactions in a vector database, retrieved by semantic similarity only when relevant), and semantic memory (stabilized facts and user preferences stored in structured JSON/YAML format — far denser than raw text). This segmentation ensures the prompt only contains the absolute minimum at each step.
StreamingLLM for very long sequences. An emerging technique has partially solved the quasi-infinite context problem. Researchers observed that models pay considerable attention to the very first tokens of a sequence — initial characters acting as stabilizing "attention sinks." By systematically preserving these anchor tokens and using a sliding window for recent tokens, StreamingLLM enables processing millions of tokens without computational explosion, even though active memory remains bounded by the training window.
The intelligence of not thinking everything out loud
There's a design principle running through all these optimizations. The most efficient architectures don't try to give agents more memory — they try to give them less information, better chosen.
Intensive reasoning models (like the o1 series) excel at high-complexity tasks that merit deep reflection. They're disastrously expensive for simple coordination and routine decisions. Well-designed systems reserve these models for critical nodes and use lightweight models for orchestration.
Similarly, the intuition of "the largest possible context" is misleading. A 100,000-token context with well-structured information systematically outperforms a 200,000-token context with poor filtering — because the model knows where to look, and the "Lost in the Middle" effect doesn't erode its attention.
The future of AI agents isn't larger contexts. It's contextual sobriety: every injected token must earn its place.
The bill nobody shows you
Back to the taxi. The meter has been running since the beginning of this article. Every reasoning token your agent produces without informing you, every conversation history re-processed in full at each turn, every vector document injected into the prompt "just in case" — all of it accumulates in a bill that few organizations truly measure before it becomes a problem.
The good news: the tools to control this bill exist. Caching, LangGraph, observation masking, hierarchical memory — these are architecture decisions, not patches. They require understanding the system deeply before building on it.
The bad news: the quadratic complexity of attention, the physical limits of VRAM, the stateless nature of models — these constraints won't disappear with the next model release. They're embedded in the technology's very structure. Efficiency, in this context, isn't a comfort optimization. It's a viability condition.