Bij LLM-verrijking bestaat de rekening uit tokens. Entity Enricher is gebouwd om zo min mogelijk in rekening gebrachte tokens te versturen zonder in te leveren op nauwkeurigheid — aangevoerd door prompt caching, en ondersteund door schema-scoping, slimme gating en minder verspilde retries. Het meeste gebeurt automatisch; niets hiervan vereist extra configuratie.
Elke verrijkingsaanroep betaalt voor invoertokens (je prompt, schema en eventuele bijgevoegde documenten), uitvoertokens (het gestructureerde resultaat) en — indien ingeschakeld — websearch-query's. Het grootste, meest herhaalde deel is meestal de invoer: dezelfde systeeminstructies, schemabeschrijving en brondocumenten worden bij elke aanroep opnieuw verstuurd. Die gedeelde invoer cachen is de grootste hefboom, dus die komt eerst.
Prompt + schema + bijlagen. Groot en zeer repetitief over calls heen — het belangrijkste doelwit voor caching en scoping.
Het gestructureerde resultaat. Compact gehouden door elk model alleen de velden te vragen die het daadwerkelijk beheert.
Mislukte nieuwe pogingen, rate-limitconflicten en het verrijken van de verkeerde entity. Vooraf geëlimineerd in plaats van betaald.
Wanneer een multi-expertise verrijking wordt uitgevoerd, doet die meerdere LLM-aanroepen voor dezelfde entiteit — één per expertisedomein. Al die aanroepen delen dezelfde beginContext: de generieke systeeminstructies en eventuele inline-tekstdocumenten die je hebt bijgevoegd. Entity Enricher houdt dat gedeelde voorvoegsel byte-voor-byte identiek over alle aanroepen en markeert het als cachebaar, zodat de provider het één keer opslaat en bij elke volgende aanroep opnieuw leest tegen ongeveer een tiende van de normale invoerprijs.
Elk van de N aanroepen stuurt de volledige gedeelde context opnieuw tegen de volle inputprijs. Vijf expertises betekent dat je vijf keer voor dat grote gedeelde blok betaalt.
Het gedeelde blok wordt één keer naar de cache geschreven en vervolgens bij de andere vier calls teruggelezen tegen ~10% van de invoerprijs. De besparing groeit met elke extra expertise, taal en bijgevoegd document.
Providercaches zijn pas leesbaar nadat het eerste verzoek dat ze wegschrijft is voltooid. Als alle expertise domain-aanroepen tegelijk zouden afgaan, zou geen enkele een warme cache vinden en zou elke overbodig zijn eigen kopie wegschrijven. Wanneer caching van toepassing is, draait de eerste aanroep daarom apart, krijgt de cache even de tijd om zich te verspreiden, en pas daarna worden de overige aanroepen parallel gestart — zodat elke aanroep de warme cache leest in plaats van te betalen om deze opnieuw te schrijven.
Anthropic-modellen cachen de gedeelde instructies expliciet; bijgevoegde PDF's en afbeeldingen worden ter plekke gecachet; en providers met automatische prefix-caching (OpenAI, xAI, DeepSeek en andere) profiteren van dezelfde byte-identieke prefix. Caching loont het meest juist wanneer de input groot is — veel expertises, meerdere talen of bijgevoegde documenten.
Kostenberekening is cache-bewust: gecachte invoertokens worden gefactureerd tegen het cache-leestarief van het model (een fractie van het invoertarief), en alleen de echt nieuwe tokens worden tegen de volle prijs gefactureerd. De besparingen zie je direct terug in je kostenanalyses, niet alleen in theorie.
Naast het cachen van de gedeelde prefix verkleint Entity Enricher het deel van elke aanroep dat niet wordt gedeeld.
Elke expertise-aanroep ontvangt alleen het deel van het schema waarvoor ze verantwoordelijk is, niet het volledige schema.
Een financieel expert ziet nooit de regelgevingsvelden. Minder velden betekent minder tokens in en uit — en het antwoord wordt weer teruggebracht tot zijn deel vóór het samenvoegen.
Wanneer er documenten zijn bijgevoegd en je niet hebt gekozen voor een strikte gestructureerde-uitvoermodus, staat de veldenlijst alleen in de leesbare prompt — er wordt geen schema gedupliceerd over de verbinding.
Dit laat de schema-tokens volledig weg en houdt de gedeelde prefix identiek (waardoor deze beter cachet). Het antwoord wordt nog steeds client-side gevalideerd, met automatische zelfcorrectie bij afwijkingen.
Optionele pre-flight-classificatie voert één goedkoop, snel model uit om te controleren of een entiteit daadwerkelijk overeenkomt met je schema voordat er dure verrijking met meerdere modellen begint. Een mismatch — zoals een maan die naar een “Planeet”-schema wordt gestuurd — wordt voor een fractie van een cent opgemerkt in plaats van een volledige verrijking over meerdere premiummodellen te verspillen.
Het is niet-blokkerend (als de controle mislukt, gaat de enrichment toch door) en annuleerbaar, zodat je nooit begint te betalen voor modellen die je hebt besloten over te slaan.
Een mislukte validatieronde is een LLM-aanroep tegen de volle prijs zonder resultaat. Twee mechanismen houden herhalingen zeldzaam en productief.
Veelvoorkomende eigenaardigheden in LLM-uitvoer — objecten met indexsleutels die arrays zouden moeten zijn, de tekenreeks 'null', losse ge-escapete aanhalingstekens — worden gecorrigeerd voordat de validatie draait.
Veel potentiële validatiefouten worden stilletjes hersteld, zodat ze nooit een betaalde nieuwe poging veroorzaken.
Wanneer een nieuwe poging echt nodig is, wordt de exacte validatiefout teruggekoppeld naar het model zodat het dat specifieke probleem kan oplossen.
Duidelijke, specifieke feedback vergroot de kans dat de volgende poging slaagt, in plaats van pogingen te verspillen aan vage aanwijzingen.
Enkele doorloop is het goedkoopst voor kleine schema's; multi-expertise is gebouwd voor grote schema's, waar caching plus scoping per expertise ruimschoots opwegen tegen de extra aanroepen. Zie Strategieën voor wanneer je welke gebruikt.
Een gelijktijdigheidslimiet per provider voorkomt dat taken een provider in rate-limitfouten drijven, wat anders backoff en herhalingen zou activeren — verspilde tokens en doorlooptijd. Afgeknepen, gelijkmatige gelijktijdigheid is goedkoper dan vechten tegen 429's.
Elke verrijking registreert de werkelijke tokenaantallen — inclusief gecachte reads — en de bijbehorende kosten. Het Kostendashboard zet dat om in tijdreeksgrafieken en uitsplitsingen per model, zodat je precies ziet waar de uitgaven heen gaan en kunt bevestigen dat caching en scoping hun werk doen. De prijs die je ziet is de prijs die je in rekening wordt gebracht; ruwe providerkosten en eventuele platformmarge blijven transparant.