Cloudflare har lagt till cache-läs- och cache-skriv-tokenhastigheter till AI Gateways anpassade kostnadsredovisning, en liten ändringsloggpost med stora faktureringskonsekvenser för team som återförsäljer, dirigerar eller stämmer av modellanvändning mellan leverantörer.

Uppdateringen den 9 september innebär att utvecklare nu kan skicka per_cache_read_token_token_code och värden i rubriken cf-aig-custom-cost. När endera cache-specifik hastighet är närvarande, säger Cloudflare att AI Gateway aktiverar cache-tokenprissättning och tar hänsyn till leverantörsskillnader så att samma cacheanvändning inte räknas två gånger.

Det låter smalt. Det är det inte. Cacheprissättning har blivit en av de svårare delarna av unified AI API-fakturering, särskilt som leverantörer använder olika namn, enheter och faktureringsregler för återanvänd kontext. Att behandla varje cachad token som en normal indatatoken kan vara enkelt, men det kan vara tillräckligt fel för att radera återförsäljarmarginalen eller vilseleda kunder om vilka arbetsbelastningar som faktiskt är dyra.

Vad som ändrades

AI Gateway gjorde det redan möjligt för anpassade kostnadsdata att bifogas förfrågningar, vilket gav teamen ett sätt att representera förhandlade priser eller interna prisböcker endast på i stället för att tillhandahålla återkommande priser. Den nya förändringen utökar den mekanismen till cachespecifika tokenkategorier.

I praktiken kan en gatewayoperatör nu berätta för Cloudflare inte bara vad en in- eller utmatningstoken kostar, utan vad en cacheläsning eller cacheskrivning kostar. Den skillnaden är viktig eftersom leverantörer i allt högre grad prissätter prompt-cache som sitt eget ekonomiska lager. En cacheskrivning kan kosta mer än en cacheläsning. En cacheläsning kan vara dramatiskt billigare än ny indata. Vissa leverantörer kan exponera cacheskapande och cachehämtning på olika sätt i användningsposter.

Cloudflares notering att det hanterar leverantörsskillnader för att undvika dubbelräkning är också viktigt. Cachefält är inte alltid rent separerade från totalsummor för inmatningstoken. Om ett faktureringssystem på ett naivt sätt lägger till cache-tokens ovanpå leverantörsrapporterad indataanvändning, kan det överdebitera kunder eller öka de interna kostnaderna. Om den ignorerar cachefält kan den underskatta kostnaden för program med långa kontexter som ofta skapar cacheposter.

Varför cacheredovisning nu är viktig

Snabbcacheläggning brukade vara en optimeringsdetalj. För många produktionsbelastningar är det nu en del av prisarkitekturen.

Långa systemuppmaningar, hämtningsförstärkta sammanhang, kodningsagentförråd, juridiska dokumentpaket och supportkunskapsbaser drar nytta av att återanvända sammanhang. Ju mer upprepad kontext ett system skickar, desto mer cacheprissättning förändrar den verkliga enhetsekonomin. Två förfrågningar med liknande tokenantal kan ha mycket olika kostnader om en skriver en cachepost och en annan läser från den.

Det gör cachesynlighet till en ekonomisk fråga, inte bara en teknisk fråga. Ett team som kör interna agenter kan behöva veta om ett nytt arbetsflöde är dyrt eftersom det genererar för många nya uppmaningar, missar cachen eller skriver stora cacheblock för ofta. En återförsäljare kan behöva visa kunderna varför en applikations fakturerade användning är lägre än förväntat trots att den uppenbara promptstorleken är stor. En gateway-leverantör kan behöva bevara cachefält i loggar, analys- och reskontraposter så att månadsavstämning matchar leverantörsfakturor.

Det är också här AI API-kostnadsanalys blir mer krävande. Den sammanlagda kostnaden för begäran räcker inte längre. Teamen måste se indata, utdata, cacheskrivning och cacheläsbeteende separat, och sedan koppla dessa kategorier till API-nycklar, kunder, modeller och rutter.

Vem påverkas

Den omedelbara publiken är Cloudflare AI Gateway-användare som förlitar sig på anpassade kostnader snarare än offentliga standardpriser. Det inkluderar företag med förhandlade modellpriser, plattformar som markerar leverantörsanvändning för kunder och team som använder Cloudflare som ett delat kontrollplan mellan flera modellleverantörer.

Återförsäljare är särskilt utsatta. Om en återförsäljare debiterar kunder med en förenklad token-modell samtidigt som de betalar leverantörer under cache-medvetna priser, kan skillnaden lugnt ackumuleras. Underladdningscacheskrivningar eller överladdningscacheläsningar kanske inte visas i en enda begäran, men det kan ha betydelse för agentsessioner, batchbearbetning eller hämtning av hög volym.

Utvecklare som bygger OpenAI-kompatibla gatewaylager påverkas även när de inte använder Cloudflare direkt. Förändringen speglar en bredare riktning på marknaden: leverantörernas faktureringsytor blir mer detaljerade, medan kunderna fortfarande förväntar sig en ren faktura och förutsägbara användningsrapporter.Produkter som Model Gate måste behandla cache-tokenfält som förstklassig reskontradata om de vill ha korrekt kundavgränsad rapportering, användningsgränser och marginalanalys mellan flera leverantörer.

Praktiska konsekvenser

Gateway-team bör se över hur deras förfrågningsloggar, kostnadskalkylatorer och fakturor representerar cacheaktivitet. Om cacheläsning och skrivning plattas till vanliga prompt-tokens, kan analyser se enklare ut än den underliggande räkningen. Om leverantörsanvändningsposter innehåller cachefält som släpps under inmatning kommer senare avstämning att bli svår.

Prismotorer måste också stödja mer än en hastighet per riktning. Den gamla input-versus-output-fördelningen räcker inte längre för avancerad modellredovisning. En trovärdig modellbok behöver nu utrymme för nya indatatokens, utdatatokens, cacheskrivningar, cacheläsningar och möjligen leverantörsspecifika varianter av dessa kategorier.

Kundvända instrumentpaneler bör exponera dessa distinktioner noggrant. De flesta användare vill inte läsa rå leverantörstelemetri, men de behöver förstå varför kostnaderna förändras när en applikation börjar återanvända sammanhang mer effektivt. Det bästa gränssnittet kan vara en kostnadsuppdelning som visar cachebesparingar och kostnader för att skapa cache utan att tvinga kunderna att lära sig varje leverantörs terminologi.

Det finns också operativa konsekvenser för varningar och begränsningar. En kundbudgetgräns som endast baseras på totala tokens kan misslyckas med att fånga en arbetsbelastning som skriver dyra cacheposter. En marginalvarning som endast baseras på antalet förfrågningar kan missa en leverantörsprisfelmatchning. För team som säljer åtkomst via per-kundnycklar, bör cache-medveten redovisning kopplas tillbaka till samma kund-, projekt- eller applikationsidentifierare som används för utgiftskontroller.

Vad som förblir öppet

Ändringsloggen etablerar stöd för anpassade cache-läsning och cache-skriva priser, men den löser inte alla implementeringsfrågor för gateway-operatörer. Teamen behöver fortfarande testa hur deras specifika leverantörer rapporterar cacheanvändning, hur Cloudflares beräknade kostnader visas i loggar och exporter, och hur befintliga fakturor ska jämföras med de nya anpassade kostnadsfälten.

Den större riktningen är dock tydlig. AI-gatewayfakturering flyttas från en enkel token-mätare till en detaljerad användningsreskontra. Cacheprissättning är nu en del av den reskontran. Team som bevarar detaljerna kommer att få renare avstämning och bättre kundanalys. Team som kollapsar det kanske inte märker problemet förrän deras leverantörsfaktura och kundfaktura slutar berätta samma historia.