--- title: "LLM-kosten per feature bijhouden: een uitgewerkt voorbeeld | Len P. van der Hof" description: Houd LLM-kosten per feature bij met routelabels, kosten per aanvraag en budgetalerts. Met een voorbeeld van een vlakke maandfactuur en een test voor vandaag. image: "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.wide.webp" --- [AI-systemen](https://lenvanderhof.com/nl/blog/categorie/ai-systemen/) Onderzoeksartikel # Kosten per route versus de maandfactuur: meet waar het geld naartoe gaat Een vlakke maandfactuur kan verbergen dat één route twee keer zo duur werd. Wijs elke kostenpost toe, scheid volume van kosten per aanvraag en geef de route een eigenaar. Len P. van der HofGepubliceerd 7 november 202611 min. leestijd Vier meters, elk met een eigen wijzerplaat. Meet elke route, niet alleen het totaal. Direct antwoord Wil je LLM-kosten per feature bijhouden, geef dan elke modelpoging, retry's inbegrepen, een label mee voor route, feature en oorspronkelijk aanvraag-ID. Leg model, aanbieder, gefactureerd verbruik, tarieven en latentie vast. Tel elke kostenpost één keer op per route en daarna per feature, en sluit het totaal aan op de factuur. Vergelijk routetotalen met hun budget, houd volume en kosten per aanvraag ernaast en geef elke alert een vaste eigenaar. ## Belangrijkste inzichten - Wijs modeluitgaven eerst toe aan de routingregel en tel ze daarna op per feature en per budgeteigenaar. Een modelnaam alleen vertelt je niet welk werk het geld heeft uitgegeven. - Zet het aanvraagvolume altijd naast de totale kosten en de kosten per aanvraag. Meer verkeer en een duurdere aanvraag vragen om een ander onderzoek. - Tel elke gefactureerde poging één keer mee, inclusief retry's en escalaties. Totalen per route, feature en team zijn telkens dezelfde kostenposten, op een hoger niveau opgeteld. - Hoofdstuk 9 van Het model-portfolio stelt een waarschuwing voor bij 75% van het weekbudget van een route. Een route die volgens plan draait, passeert die grens pas laat in de week; een vroege overschrijding is het signaal. De waarschuwing bewijst geen verspilling en dwingt geen plafond af. - Lees kosten samen met latentie en toets de kwaliteit apart. Een goedkopere route heeft haar plek pas verdiend als ze nog steeds aan de eisen van de taak voldoet. **Een maandfactuur voor AI vertelt je hoeveel je hebt uitgegeven; meten per route vertelt je welk werk dat geld uitgaf.** Eén route kan twee keer zo duur worden terwijl een daling elders het totaal vlak houdt. En stijgt de rekening wel, dan weet je nog steeds niet wat er gebeurde: meer aanvragen, meer tokens per aanvraag, vaker een retry of een ander model op de route? Hoofdstuk 9 van [Het model-portfolio](https://lenvanderhof.com/boeken/the-model-portfolio/) bouwt dat onderscheid op rond kostenattributie: meet eerst de routingregel die het geld uitgaf en koppel die daarna aan de feature en het team dat ervoor verantwoordelijk is. Zo wordt een vage opdracht om te bezuinigen een review van één benoemde route. De meter wijst aan waar je moet zoeken; logs en tests moeten de oorzaak daarna vaststellen. ## Hoe houd je LLM-kosten per feature bij in plaats van op één maandfactuur? Geef elke modelaanroep een routelabel, een featurelabel en een eigenaar. Leg verbruik en doorlooptijd vast, reken de kosten uit en tel ze over een vaste periode op per route. Tel daarna de kosten van alle routes van een feature op voor het featuretotaal. Een **route** is hier een benoemde routingregel of een taaktype, zoals `kennis.antwoord`. Een **feature**, in het boek een productoppervlak, is wat dat werk bedient, bijvoorbeeld een interne kennisassistent. Eén feature kan meerdere routes gebruiken. Bedient een route meerdere features, geef dan bij elke aanroep het featurelabel mee, zodat je de kosten zuiver kunt verdelen. Je kijkt steeds naar dezelfde kosten, op een hoger niveau opgeteld: **poging → route → feature → budgeteigenaar**. Tel het subtotaal van een route dus niet nog eens op bij dat van de feature, want dan tel je hetzelfde geld dubbel. ‘Kosten per route’ is hier het totaal van een route over een gekozen periode; ‘kosten per aanvraag’ is een aparte deling. Houd de routenaam gelijk als het model eronder wisselt, en leg het model in een apart veld vast. Anders wordt elke maandvergelijking een zoektocht naar werk dat onderweg van naam veranderde. In [Wat is modelroutering?](https://lenvanderhof.com/nl/blog/wat-is-modelroutering/) lees je wat zo’n beleid per route vastlegt; hier gaat het om het meten van de gevolgen. Leg in je bestaande logs deze groepen velden vast: OnderdeelWat je vastlegtWat je ermee controleertAttributieRoute, feature, budgeteigenaarWelk werk de kosten veroorzaakteIdentiteitOorspronkelijk aanvraag-ID, poging-ID, tijdstempelWelke aanroepen bij dezelfde aanvraag horenToewijzingWerkelijk model, aanbieder en serviceniveauOf de toewijzing is veranderdVerbruikInput, output en relevante factuurcategorieënWelke verbruikspost is gegroeidDoorlooptijdTotale tijd van begin tot eind; tijd tot eerste token bij streamingOf gebruikers langer wachtenUitvoeringResultaat, aantal retry’s en escalatievlagOf extra pogingen de uitgaven verklaren Een overzicht per model kan deze toewijzing niet maken zodra meerdere features hetzelfde model delen. Een spreadsheet op basis van gelabelde logexports kan dat wel. Begin bij de labels en bij het besluit dat je ermee wilt nemen. ## Hoe bereken je de kosten per route en per aanvraag? Deel per gefactureerde verbruikscategorie het aantal door de rekeneenheid van het tarief en vermenigvuldig met het geldende tarief. Tel de categorieën één keer op. Bewaar het tarief en de ingangsdatum bij de berekening, zodat je kunt zien of je verbruik veranderde of de prijs. Maak factuurregels die elkaar niet overlappen, volgens de definities van je aanbieder. Een totaal en de uitsplitsing ervan zijn geen losse bedragen om bij elkaar op te tellen. Kijk eerst hoe je aanbieder input uit de cache en redeneertokens meetelt voordat je er een prijs aan hangt; [Zo lees je een AI-rekening](https://lenvanderhof.com/nl/blog/ai-tokenprijzen-uitgelegd/) legt die soorten tokens uit. Tel elke gefactureerde poging op die aan de route is toegewezen en voeg tijdgebonden routekosten toe, zoals cache-opslag per uur. Ook een mislukte poging waarvoor je betaalt, hoort in het totaal. Ontbreekt een verbruiksveld, dan is dat verbruik onbekend, niet nul. Houd de noemer expliciet: **Kosten per route-aanvraag = alle toegewezen routekosten ÷ oorspronkelijke aanvragen op die route.** Gefactureerde retry’s en escalaties tellen mee in de kosten; de oorspronkelijke aanvraag telt één keer in de noemer. Pogingen volg je apart. Voor de **kosten per afgeronde taak van een feature** tel je alle kosten op die via de routes van die feature zijn toegewezen, en deel je door het aantal afgeronde taken in dezelfde periode. Zet bij elk getal door welke eenheid je deelt: een aanvraag, een poging en een afgeronde taak zijn verschillende maten. Sluit de toegewezen totalen aan op de factuur van je aanbieder, over dezelfde periode en op dezelfde grondslag. Zet toeslagen, tegoeden en onverklaarde verschillen op aparte regels. Missen oudere logregels een featurelabel, markeer een verdeling achteraf dan als schatting en laat het niet-toegewezen deel apart staan. Een exact maandtotaal maakt een geschatte verdeelsleutel niet exact. ## Wat kan een vlakke maandfactuur verbergen? Een hypothetisch voorbeeld Neem een klein softwareproduct met drie routes. Alle cijfers hieronder zijn verzonnen. Elke aanvraag doet één geslaagde, gefactureerde modelaanroep; er zijn geen retry’s, geen caching, geen verborgen redeneertokens en geen andere kosten. Elke route bedient één feature. RouteAanvragen vorige maandKosten vorige maandAanvragen deze maandKosten deze maandsupport.chat40.000€ 80040.000€ 800kennis.antwoord10.000€ 60010.000€ 1.200catalogus.verrijk20.000€ 1.60020.000€ 1.000Totaal70.000€ 3.00070.000€ 3.000 Factuur en totaal aantal aanvragen zijn gelijk gebleven. Toch zijn de kosten per aanvraag op `kennis.antwoord` verdubbeld, van € 0,06 naar € 0,12. De besparing van € 600 op `catalogus.verrijk` valt precies weg tegen de stijging van € 600 op `kennis.antwoord`. Reken de kennisroute door met verzonnen tarieven van € 2 per miljoen inputtokens en € 6 per miljoen outputtokens, in beide maanden gelijk. Vorige maand gebruikte elke aanvraag 24.000 inputtokens en 2.000 outputtokens: **24.000 ÷ 1.000.000 × € 2 + 2.000 ÷ 1.000.000 × € 6 = € 0,06.** Nu stuurt elke aanvraag 54.000 inputtokens mee, terwijl de output op 2.000 blijft: **54.000 ÷ 1.000.000 × € 2 + 2.000 ÷ 1.000.000 × € 6 = € 0,12.** Bij 10.000 aanvragen is dat € 600 en € 1.200. Omdat het volume gelijk bleef, valt meer verkeer in dit voorbeeld af als verklaring. De uitsplitsing per categorie wijst naar de input. Stel dat je in de logs een contextblok van 30.000 tokens vindt dat een promptwijziging heeft toegevoegd. Hoofdstuk 9 opent met een samengestelde casus van hetzelfde type: een herstructurering van de prompt voegde bij elke aanvraag op een interne kennisroute een volledige documentsamenvatting toe, en wekenlang merkte niemand het, omdat de antwoorden er voor gebruikers hetzelfde uitzagen. Toets of het blok nodig is voor goede antwoorden voordat je het weghaalt. De rekensom laat zien wat het kost, niet wat het waard is. Was het aantal aanvragen verdubbeld bij gelijke kosten per aanvraag, dan zou je eerst uitzoeken waar het extra verkeer vandaan kwam. Sleutelen aan het model lost dan het verkeerde probleem op. ## Welke signalen horen naast de kosten? Hoofdstuk 9 bundelt de operationele metingen in vijf signalen: tokenvolume, kosten, latentiepercentielen, het aantal routingbeslissingen en het escalatiepercentage. Houd ze bij elkaar. Kosten laten zien waar het geld zit; de andere vier helpen verklaren wat er verschoof. Geef elke route één rij op het dashboard: de kosten van de afgelopen zeven dagen tegen het weekbudget, de p95-latentie tegen de SLO, het escalatiepercentage waar dat van toepassing is en de volumetrend. Zet erbij hoe lang een overschrijding al duurt, wie de eigenaar is en wanneer de volgende review is. De **p95-latentie** is de doorlooptijd waarbinnen ongeveer 95% van de gemeten aanvragen klaar is. Meet de hele route, van binnenkomst tot afgeleverd antwoord. Houd p50 en p99 achter de hand voor diagnose en leg bij gestreamde antwoorden de tijd tot het eerste token apart vast. Kies een meetvenster en een minimale steekproef die passen bij het verkeer op de route. Terug naar het hypothetische product. Stel dat `support.chat` nog steeds € 800 kost, maar dat de p95 oploopt van 0,8 naar 1,4 seconden bij een SLO van één seconde. De kostenregel is onveranderd; de latentieregel vraagt aandacht. Wie alleen naar kosten kijkt, mist die achteruitgang. Escaleert een route aanvragen naar een ander model, leg dan vast welk deel escaleert en wat beide stappen kosten. Een stijging wijst op veranderde input, kwaliteit of escalatiecriteria, zonder te zeggen welke van de drie. ## Wanneer moet een route-alert tot een review leiden? Leid het budget af uit het verwachte verkeer en het beoogde verbruik, inclusief geplande retry’s en escalaties. Maak van wat de route nu kost niet ongemerkt de norm, want dan budgetteer je bestaande verspilling mee. Tel de routebudgetten over dezelfde periode op en controleer of ze binnen het totale modelbudget van het product passen. Hoofdstuk 9 gebruikt **75% van het weekbudget van een route** als illustratieve vroege waarschuwing: laag genoeg om nog in te grijpen voordat het budget op is. Stel dat de hypothetische route `kennis.antwoord` per week 2.500 aanvragen verwerkt tegen de beoogde € 0,06 per stuk. Het budget is dan € 150 en de waarschuwing ligt op € 112,50. Leg eerst de klok vast. Tel je vanaf het begin van de budgetweek, dan passeert een route die gelijkmatig volgens plan uitgeeft € 112,50 op dag zes. Gebeurt dat al halverwege de week, dan geeft de route veel sneller uit dan gepland: dat is het signaal. Op een voortschrijdend totaal over zeven dagen, de weergave in het dashboard van het hoofdstuk, staat een route volgens plan elke dag rond € 150, en dan gaat een waarschuwing op 75% nooit meer uit. Zet de waarschuwing daarom op de budgetweek. Ze vraagt iemand om naar de route te kijken; ze bewijst geen verspilling. Als eerste vuistregel voor een review noemt het hoofdstuk een budgetoverschrijding die langer dan 72 uur aanhoudt. Die klok start pas als de uitgaven boven het budget zelf komen, niet bij de waarschuwing op 75%. Pas het venster aan op het volume, de latentieklasse en het risico van de route. Een duidelijke ontsporing pak je meteen aan. Latentie heeft een eigen waarschuwing: het hoofdstuk begint bij 80% van de p95-SLO en stelt die drempel bij na valse alarmen en gemiste incidenten. Een overschrijding van de SLO zelf die gedurende het hele venster van de route aanhoudt, van uren bij real-time routes tot zeven dagen bij batch, leidt tot een review. Dat geldt ook voor een escalatiepercentage dat zeven dagen of langer boven 150% van de basislijn ligt, en voor elke nieuwe route of elk nieuw model zonder budget en SLO. Die horen vast te staan vóór er productieverkeer komt, of uiterlijk binnen 24 uur als de route ongemerkt langs de poort glipte. Geef elke alert een eigenaar en een vaste eerste stap: vergelijk volume, tokencategorieën, modeltoewijzing en retry’s met de vorige periode. Sluit de review af met wat er veranderde, waarom, en wanneer je opnieuw kijkt. Een alert meldt een toestand. Een bestedingsplafond afdwingen is een aparte maatregel; hoe je dat per taak inricht, lees je in [Agent-runtimebudget: houd retry’s binnen hetzelfde plafond](https://lenvanderhof.com/nl/blog/agent-runtimebudget/). ## Welke vragen laat dit dashboard open? De duurste route is een goed startpunt, maar niet automatisch de slechtste besteding. Misschien doet juist die route het waardevolste werk. Een goedkoper model, een kortere prompt of een andere escalatieregel heeft eerst een eigen kwaliteitstest nodig voordat je de wijziging accepteert. Modelkosten laten bovendien veel van wat een feature kost buiten beeld, tenzij je het expliciet toevoegt: infrastructuur, betaalde tools en menselijke controle, bijvoorbeeld. Houd die afbakening zichtbaar. Noem je een totaal aan modelkosten ‘winstgevendheid’, dan claim je meer dan je hebt gemeten. In het bewijsregister van het boek staat dit dashboard als ontwerp van de auteur zelf, zonder vrijgegeven claim dat het kosten bespaart. Beoordeel een eerste versie dus op de vraag of die toewijsbare kostenregels en bruikbare alerts oplevert; meet een eventuele besparing apart. ## Probeer dit vandaag Splits de modeluitgaven van vorige maand uit naar route of feature, desnoods grofweg. Zet de routes op volgorde en geef de duurste deze week de startdrempel uit het boek. 1. **Maak je eerste attributietabel.** Koppel de factuur- en verbruiksregels van vorige maand aan route- en featurelabels. Schrijf per route één rij met kosten, oorspronkelijke aanvragen, eigenaar en of het bedrag gemeten of geschat is. Zet kosten zonder onderbouwd label op een aparte regel voor niet-toegewezen verbruik en sluit het totaal op dezelfde grondslag aan op de factuur. 2. **Zet de rijen op volgorde.** Sorteer op totale kosten en reken daarna de kosten per aanvraag uit. Kies de duurste route. Heb je alleen totalen per feature, kies dan de duurste feature en bepaal welke routelabels daaronder nodig zijn. 3. **Stel een beoogd weekbudget vast.** Reken met het verwachte aantal aanvragen en het beoogde verbruik tegen de geldende tarieven, extra aanroepen inbegrepen. Leg het naast de werkelijke uitgaven. Controleer of de routebudgetten en het plafond van het product over dezelfde periode gaan. 4. **Schrijf de waarschuwing op 75% uit.** Noteer de klok (uitgaven sinds het begin van de budgetweek), het drempelbedrag, de eigenaar en de eerste onderzoeksstap. Voeg de p95-SLO en een reviewdatum toe. Ontbreken historische labels, begin ze dan nu te verzamelen en laat de verdeling over het verleden als schatting staan. 5. **Test de grens offline.** Neem de drempel van € 112,50 uit het voorbeeld en geef een testkopie van je regel achtereenvolgens een weekstand van € 112,49, € 112,50 en € 112,51 als invoer. Bij een regel die afgaat *boven* de drempel mag alleen het derde bedrag een waarschuwing geven. Controleer of de melding de juiste route, het juiste bedrag en de juiste eigenaar noemt. Noteer dit als test van de rekenregel, niet als bewijs dat productie gedekt is. 6. **Volg één echte aanvraag.** Loop via het aanvraag-ID alle gefactureerde pogingen na tot in het route- en featuretotaal. Controleer verbruik, tarieven en aantal retry’s tegen de bronregistraties. Elke kostenpost moet in elk overzicht precies één keer meetellen. Lukt het niet om die aanvraag te volgen, noteer dan welk label of verbruiksveld ontbreekt en wijs iemand aan die het toevoegt. Sluiten de totalen niet aan, laat het verschil dan zichtbaar staan. Aan het eind heb je één route met een eigenaar en een eerlijk overzicht van wat de meter wel en nog niet laat zien. Citeer deze pagina:Kosten per route versus de maandfactuur: meet waar het geld naartoe gaat.Len P. van der Hof. [https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/](https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/) · Gepubliceerd 7 november 2026. ## Bronnen 1. [Het model-portfolio, hoofdstuk 9: volg kosten en latentie](https://lenvanderhof.com/boeken/the-model-portfolio/) 2. [Wat betekent '$ 3 per miljoen tokens'? Zo lees je een AI-rekening](https://lenvanderhof.com/nl/blog/ai-tokenprijzen-uitgelegd/) 3. [Agent-runtimebudget: houd retry's binnen hetzelfde plafond](https://lenvanderhof.com/nl/blog/agent-runtimebudget/) 4. [Wat is modelroutering? Een beleid, geen standaardkeuze](https://lenvanderhof.com/nl/blog/wat-is-modelroutering/) ## Verder lezen - [Wat betekent '$ 3 per miljoen tokens'? Zo lees je een AI-rekening](https://lenvanderhof.com/nl/blog/ai-tokenprijzen-uitgelegd/) - [Agent-runtimebudget: houd retry's binnen hetzelfde plafond](https://lenvanderhof.com/nl/blog/agent-runtimebudget/) - [Wat is modelroutering? Een beleid, geen standaardkeuze](https://lenvanderhof.com/nl/blog/wat-is-modelroutering/) - [Het model-portfolio](https://lenvanderhof.com/boeken/the-model-portfolio/) Over de auteur ## [Len P. van der Hof](https://lenvanderhof.com/nl/auteurs/len-p-van-der-hof/) Ondernemer, AI-innovator en venture builder Len P. van der Hof bouwt praktische AI-systemen, digitale ventures en evidence-informed hulpmiddelen voor founders. ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Person", "@id": "https://lenvanderhof.com/#person", "name": "Len P. van der Hof", "alternateName": [ "Len van der Hof", "L.P. van der Hof", "Leendert Pieter van der Hof" ], "honorificSuffix": "MSc", "url": "https://lenvanderhof.com/", "image": [ "https://lenvanderhof.com/photos/len-portrait-1.jpg", "https://lenvanderhof.com/photos/len-portrait-2.jpg", "https://lenvanderhof.com/photos/len-portrait-3.jpg", "https://lenvanderhof.com/photos/len-portrait-4.jpg", "https://lenvanderhof.com/photos/len-speaking.jpg", "https://lenvanderhof.com/photos/len-hero.jpg" ], "jobTitle": "Ondernemer, AI-innovator en venture builder", "description": "Len P. van der Hof, MSc, is een Nederlandse ondernemer en AI-innovator in Zwijndrecht. Hij bouwt ReasonKit, MindSesh, Undominated.ai, boeken onder zijn eigen naam, het fictie-imprint LPH98.lifestyle en technologieventures via LPH98.ventures. Elf titels in Systems for the Strategic Self zijn nu verkrijgbaar, in het Engels en het Nederlands.", "address": { "@type": "PostalAddress", "addressLocality": "Zwijndrecht", "addressCountry": "NL" }, "alumniOf": { "@type": "CollegeOrUniversity", "name": "Rotterdam School of Management, Erasmus University" }, "knowsAbout": [ "Artificial intelligence", "AI agents", "Agentic AI systems", "LLM routing", "SEO", "Generative engine optimization", "Answer engine optimization", "Venture building", "Founder performance", "Founder psychology", "Evidence-based decision-making" ], "sameAs": [ "https://www.linkedin.com/in/lenvanderhof/", "https://x.com/LenvanderHof", "https://www.youtube.com/channel/UCTG20buKqYYbitqqf7l3zJA", "https://www.instagram.com/Lenvanderhof/", "https://www.threads.com/@lenvanderhof", "https://github.com/Lenvanderhof", "https://huggingface.co/LPH98", "https://www.npmjs.com/~lenvanderhof", "https://www.goodreads.com/author/show/70983905.Len_P_van_der_Hof", "https://www.amazon.com/author/lenvanderhof", "https://www.bol.com/nl/nl/b/len-p-van-der-hof-msc/609879394/", "https://bsky.app/profile/lenvanderhof.com", "https://mastodon.social/@Lenvanderhof", "https://crates.io/users/Lenvanderhof", "https://cursor.com/@Lenvanderhof", "https://medium.com/@Lenvanderhof", "https://gitlab.com/Lenvanderhof", "https://hub.docker.com/u/lenvanderhof/", "https://dev.to/lenvanderhof", "https://www.facebook.com/Lenvanderhof", "https://soundcloud.com/Lenvanderhof" ], "affiliation": [ { "@id": "https://lenvanderhof.com/#publisher" }, { "@id": "https://lenvanderhof.com/#mindsesh" }, { "@id": "https://lenvanderhof.com/#lifestyle" } ] }, { "@type": "WebSite", "@id": "https://lenvanderhof.com/#website", "url": "https://lenvanderhof.com/", "name": "Len P. van der Hof", "description": "Len P. van der Hof, MSc, is een Nederlandse ondernemer en AI-innovator in Zwijndrecht. Hij bouwt ReasonKit, MindSesh, Undominated.ai, boeken onder zijn eigen naam, het fictie-imprint LPH98.lifestyle en technologieventures via LPH98.ventures. Elf titels in Systems for the Strategic Self zijn nu verkrijgbaar, in het Engels en het Nederlands.", "inLanguage": [ "en", "nl" ], "publisher": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#publisher", "name": "LPH98.ventures", "url": "https://lph98.ventures", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#mindsesh", "name": "MindSesh", "url": "https://mindsesh.net", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "SoftwareApplication", "@id": "https://lenvanderhof.com/#reasonkit", "name": "ReasonKit", "url": "https://reasonkit.sh", "creator": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "SoftwareApplication", "@id": "https://lenvanderhof.com/#undominated", "name": "Undominated.ai", "url": "https://undominated.ai", "creator": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#lifestyle", "name": "LPH98.lifestyle", "url": "https://lph98.lifestyle", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "ImageObject", "@id": "https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/#primaryimage", "url": "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.wide.webp", "contentUrl": "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.wide.webp", "representativeOfPage": true }, { "@type": "BreadcrumbList", "@id": "https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://lenvanderhof.com/nl/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://lenvanderhof.com/nl/blog/" }, { "@type": "ListItem", "position": 3, "name": "AI-systemen", "item": "https://lenvanderhof.com/nl/blog/categorie/ai-systemen/" }, { "@type": "ListItem", "position": 4, "name": "Kosten per route versus de maandfactuur: meet waar het geld naartoe gaat", "item": "https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/" } ] }, { "@type": "WebPage", "@id": "https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/#webpage", "url": "https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/", "name": "Kosten per route versus de maandfactuur: meet waar het geld naartoe gaat", "description": "Houd LLM-kosten per feature bij met routelabels, kosten per aanvraag en budgetalerts. Met een voorbeeld van een vlakke maandfactuur en een test voor vandaag.", "isPartOf": { "@id": "https://lenvanderhof.com/#website" }, "primaryImageOfPage": { "@id": "https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/#primaryimage" }, "breadcrumb": { "@id": "https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/#breadcrumb" }, "inLanguage": "nl-NL" }, { "@type": "BlogPosting", "@id": "https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/#article", "mainEntityOfPage": { "@id": "https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/#webpage" }, "headline": "Kosten per route versus de maandfactuur: meet waar het geld naartoe gaat", "description": "Houd LLM-kosten per feature bij met routelabels, kosten per aanvraag en budgetalerts. Met een voorbeeld van een vlakke maandfactuur en een test voor vandaag.", "datePublished": "2026-11-07T15:05:00.000Z", "author": { "@id": "https://lenvanderhof.com/#person" }, "publisher": { "@id": "https://lenvanderhof.com/#person" }, "image": [ "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.square.webp", "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.landscape.webp", "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.wide.webp" ], "articleSection": "AI-systemen", "inLanguage": "nl-NL" } ] } ```