Wanneer je AI ondervraagt, verzamelt het relevante informatie om je te antwoorden. Maar, hoeveel informatie heeft het model nodig? Gesprekken met praktijkmensen onthulden hun intuïtie: de invoer was ~20x groter dan de uitvoer. Maar mijn experimenten met de Gemini-tool commandoregelinterface, die gedetailleerde tokenstatistieken weergeeft, toonden aan dat het veel hoger is. Gemiddeld 300x en tot 4000x. Hier is waarom deze hoge invoer-naar-uitvoer verhouding belangrijk is voor iedereen die met AI bouwt: Kostenbeheer draait helemaal om de invoer. Met API-aanroepen die per token worden geprijsd, betekent een verhouding van 300:1 dat de kosten worden bepaald door de context, niet door het antwoord. Deze prijsdynamiek geldt voor alle grote modellen. Op de prijs pagina van OpenAI zijn uitvoertokens voor GPT-4.1 4x zo duur als invoertokens. Maar wanneer de invoer 300x volumineuzer is, zijn de invoerkosten nog steeds 98% van de totale rekening. Latentie is een functie van de contextgrootte. Een belangrijke factor die bepaalt hoe lang een gebruiker wacht op een antwoord, is de tijd die het model nodig heeft om de invoer te verwerken. Het herdefinieert de technische uitdaging. Deze observatie bewijst dat de kernuitdaging van bouwen met LLM's niet alleen het aansteken is. Het is contextengineering. De kritieke taak is het bouwen van efficiënte gegevensophaling en context - het creëren van pijplijnen die de beste informatie kunnen vinden en deze kunnen destilleren tot de kleinste mogelijke tokenvoetafdruk. Caching wordt cruciaal. Als 99% van de tokens in de invoer zitten, verschuift het bouwen van een robuuste cachinglaag voor vaak opgehaalde documenten of veelvoorkomende querycontexten van een "mooi om te hebben" naar een kernarchitectuurvereiste voor het bouwen van een kosteneffectief en schaalbaar product. Voor ontwikkelaars betekent dit dat de focus op invoeroptimalisatie een kritieke hefboom is voor het beheersen van kosten, het verminderen van latentie en uiteindelijk het bouwen van een succesvol AI-gestuurd product.