Cloudflare heeft tokensnelheden voor cache-lezen en cache-schrijven toegevoegd aan de aangepaste kostenberekening van AI Gateway, een klein changelog-item met grote gevolgen voor de facturering voor teams die het modelgebruik tussen providers doorverkopen, routeren of afstemmen.
De update van 9 september betekent dat ontwikkelaars nu de waarden per_cache_read_token en per_cache_write_token kunnen doorgeven in de cf-aig-custom-cost header. Als een van beide cachespecifieke snelheden aanwezig is, zegt Cloudflare dat AI Gateway cache-tokenprijzen activeert en rekening houdt met providerverschillen, zodat hetzelfde cachegebruik niet twee keer wordt geteld.
Dat klinkt smal. Dat is het niet. Cacheprijzen zijn een van de moeilijkere onderdelen van uniforme AI API-facturering geworden, vooral omdat providers verschillende namen, eenheden en factureringsregels gebruiken voor hergebruikte context. Het behandelen van elk in het cachegeheugen opgeslagen token als een normaal invoertoken kan eenvoudig zijn, maar het kan verkeerd genoeg zijn om de marge van de reseller te wissen of klanten te misleiden over de vraag welke werklasten eigenlijk duur zijn.
Wat er is veranderd
AI Gateway maakte het al mogelijk om aangepaste kostengegevens aan verzoeken toe te voegen, waardoor teams een manier kregen om onderhandelde tarieven of interne prijslijsten weer te geven in plaats van alleen te vertrouwen op openbare leveranciersprijzen. De nieuwe wijziging breidt dat mechanisme uit naar cachespecifieke tokencategorieën.
In de praktijk kan een gateway-operator Cloudflare nu niet alleen vertellen wat een invoer- of uitvoertoken kost, maar ook wat een cache-lees- of cache-schrijfkosten zijn. Dat onderscheid is van belang omdat aanbieders prompt caching steeds vaker als hun eigen economische laag beschouwen. Het schrijven in de cache kan meer kosten dan het lezen in de cache. Het lezen van een cache kan aanzienlijk goedkoper zijn dan nieuwe invoer. Sommige providers kunnen het maken en ophalen van caches verschillend weergeven in gebruiksrecords.
De opmerking van Cloudflare dat het omgaat met providerverschillen om dubbeltellingen te voorkomen, is ook belangrijk. Cachevelden zijn niet altijd netjes gescheiden van de totalen van de invoertokens. Als een factureringssysteem naïef cachetokens toevoegt aan het door de provider gerapporteerde invoergebruik, kan het klanten te veel in rekening brengen of de interne kosten opdrijven. Als het cachevelden negeert, kan het de kosten onderschatten van lange-context-applicaties die regelmatig cache-items creëren.
Waarom cache-accounting er nu toe doet
Prompt caching was vroeger een optimalisatiedetail. Voor veel productieworkloads is het nu onderdeel van de prijsarchitectuur.
Lange systeemprompts, context die is aangevuld met ophaalmogelijkheden, opslagplaatsen voor coderingsagenten, juridische documentpakketten en ondersteunende kennisbanken profiteren allemaal van het hergebruik van context. Hoe meer herhaalde context een systeem verzendt, hoe meer cacheprijzen de werkelijke eenheidseconomie veranderen. Twee verzoeken met vergelijkbare tokenaantallen kunnen heel verschillende kosten met zich meebrengen als de ene een cache-item schrijft en de andere ervan leest.
Dat maakt de zichtbaarheid van de cache een financiële kwestie, en niet alleen een technische kwestie. Een team met interne agents moet mogelijk weten of een nieuwe workflow duur is omdat deze te veel nieuwe aanwijzingen genereert, de cache mist of te vaak grote cacheblokken schrijft. Het kan zijn dat een reseller klanten moet laten zien waarom het gefactureerde gebruik van een applicatie lager is dan verwacht, ook al is de schijnbare promptgrootte groot. Een gatewayleverancier moet mogelijk cachevelden bewaren in logboeken, analyses en grootboekrecords, zodat de afstemming aan het einde van de maand overeenkomt met de facturen van de provider.
Dit is ook waar AI API-kostenanalyse veeleisender wordt. De totale aanvraagkosten zijn niet langer voldoende. Teams moeten invoer-, uitvoer-, cache-schrijf- en cache-leesgedrag afzonderlijk zien en deze categorieën vervolgens verbinden met API-sleutels, klanten, modellen en routes.
Wie wordt beïnvloed
De directe doelgroep bestaat uit Cloudflare AI Gateway-gebruikers die vertrouwen op aangepaste kosten in plaats van op standaard openbare prijzen. Dat geldt ook voor ondernemingen met onderhandelde modeltarieven, platforms die het providergebruik voor klanten markeren, en teams die Cloudflare gebruiken als gedeeld controlevlak voor meerdere modelproviders.
Vooral wederverkopers worden blootgesteld. Als een reseller klanten kosten in rekening brengt met behulp van een vereenvoudigd tokenmodel terwijl ze aan providers betalen met cachebewuste prijzen, kan het verschil zich stilletjes opstapelen. Het is mogelijk dat te weinig cache-schrijfbewerkingen of te hoge cache-leesbewerkingen in één enkel verzoek worden weergegeven, maar het kan van belang zijn voor agentsessies, batchverwerking of ophaalwerklasten met grote volumes.
Ontwikkelaars die OpenAI-compatibele gateway-lagen bouwen, worden getroffen, zelfs als ze Cloudflare niet rechtstreeks gebruiken. De verandering weerspiegelt een bredere richting in de markt: factureringsoppervlakken voor leveranciers worden gedetailleerder, terwijl klanten nog steeds een schone factuur en voorspelbare gebruiksrapporten verwachten.Producten zoals Model Gate moeten cachetokenvelden behandelen als eersteklas grootboekgegevens als ze nauwkeurige klantgerichte rapportage, gebruikslimieten en margeanalyse bij meerdere providers willen.
Praktische gevolgen
Gatewayteams moeten beoordelen hoe hun verzoeklogboeken, kostencalculators en facturen de cache-activiteit vertegenwoordigen. Als lees- en schrijfbewerkingen in de cache worden samengevoegd tot gewone prompttokens, kunnen analyses er eenvoudiger uitzien dan de onderliggende rekening. Als de gebruiksrecords van de provider cachevelden bevatten die tijdens de opname worden verwijderd, zal latere afstemming moeilijk zijn.
Prijsmachines moeten ook meer dan één tarief per richting ondersteunen. De oude scheiding tussen input en output is niet langer voldoende voor geavanceerde modelboekhouding. Een geloofwaardig modelgrootboek heeft nu ruimte nodig voor nieuwe invoertokens, uitvoertokens, cacheschrijfbewerkingen, cacheleesbewerkingen en mogelijk providerspecifieke varianten van deze categorieën.
Klantgerichte dashboards moeten dit onderscheid zorgvuldig blootleggen. De meeste gebruikers willen geen onbewerkte providertelemetrie lezen, maar ze moeten wel begrijpen waarom de kosten veranderen wanneer een applicatie context effectiever gaat hergebruiken. De beste interface kan een kostenoverzicht zijn dat cachebesparingen en cache-aanmaakkosten laat zien zonder klanten te dwingen de terminologie van elke provider te leren.
Er zijn ook operationele implicaties voor waarschuwingen en limieten. Een klantbudgetlimiet die alleen op het totale aantal tokens is gebaseerd, kan er mogelijk niet in slagen een werklast op te vangen die dure cachegegevens schrijft. Een margewaarschuwing die uitsluitend op het aantal verzoeken is gebaseerd, kan een discrepantie met de prijs van de provider over het hoofd zien. Voor teams die toegang verkopen via sleutels per klant, moet cache-bewuste boekhouding worden gekoppeld aan dezelfde klant-, project- of applicatie-ID's die worden gebruikt voor uitgavencontrole.
Wat open blijft
De changelog biedt ondersteuning voor aangepaste cache-lees- en cache-schrijf-tarieven, maar lost niet alle implementatievragen voor gateway-operators op. Teams moeten nog testen hoe hun specifieke providers het cachegebruik rapporteren, hoe de berekende kosten van Cloudflare verschijnen in logboeken en exports, en hoe bestaande facturen moeten worden vergeleken met de nieuwe aangepaste kostenvelden.
De grotere richting is echter duidelijk. AI-gatewayfacturering evolueert van een eenvoudige tokenmeter naar een gedetailleerd gebruiksgrootboek. Cacheprijzen maken nu deel uit van dat grootboek. Teams die de details behouden, zullen een betere afstemming en betere klantanalyses realiseren. Teams die het probleem weggooien, merken het probleem mogelijk pas op als de factuur van de leverancier en de factuur van de klant niet meer hetzelfde verhaal vertellen.