Cloudflare har tilføjet cache-read og cache-write token-hastigheder til AI Gateways brugerdefinerede omkostningsregnskab, et lille changelog-element med store faktureringskonsekvenser for teams, der videresælger, ruter eller afstemmer modelbrug på tværs af udbydere.

Opdateringen den 9. september betyder, at udviklere nu kan videregive per_cache_read_token_token_code> og værdier i cf-aig-custom-cost overskriften. Når en af ​​cache-specifikke rater er til stede, siger Cloudflare, at AI Gateway aktiverer cache-token-priser og tager højde for udbyderforskelle, så den samme cachebrug ikke tælles to gange.

Det lyder smalt. Det er det ikke. Cachepriser er blevet en af ​​de sværere dele af unified AI API-fakturering, især da udbydere bruger forskellige navne, enheder og faktureringsregler til genbrugt kontekst. At behandle hvert cachelagret token som et normalt inputtoken kan være simpelt, men det kan være forkert nok til at slette forhandlermarginen eller vildlede kunder om, hvilke arbejdsbelastninger der faktisk er dyre.

Hvad ændrede sig

AI Gateway tillod allerede, at brugerdefinerede omkostningsdata blev knyttet til anmodninger, hvilket gav teams en måde at repræsentere forhandlede priser eller interne prisbøger kun på i stedet for at levere igen. Den nye ændring udvider denne mekanisme til cache-specifikke token-kategorier.

I praksis kan en gateway-operatør nu fortælle Cloudflare ikke kun, hvad et input- eller outputtoken koster, men hvad en cache-læsning eller cache-skrivning koster. Denne sondring er vigtig, fordi udbydere i stigende grad prissætter prompt-caching som sit eget økonomiske lag. En cacheskrivning kan koste mere end en cachelæsning. En cache-læsning kan være dramatisk billigere end frisk input. Nogle udbydere kan eksponere cache-oprettelse og cache-hentning forskelligt i brugsregistreringer.

Cloudflares bemærkning om, at den håndterer udbyderforskelle for at undgå dobbelttælling er også vigtig. Cache-felter er ikke altid rent adskilt fra input-token-totaler. Hvis et faktureringssystem naivt tilføjer cache-tokens oven på udbyder-rapporteret inputforbrug, kan det overopkræve kunder eller øge interne omkostninger. Hvis den ignorerer cachefelter, kan den undervurdere omkostningerne ved programmer med lang kontekst, der ofte skaber cacheposter.

Hvorfor cacheregnskab nu er vigtigt

Prompt-caching plejede at være en optimeringsdetalje. For mange produktionsarbejdsbelastninger er det nu en del af prisarkitekturen.

Lange systemprompter, genfindingsforstærkede kontekster, kodningsagentlagre, juridiske dokumentpakker og supportvidenbaser har alle gavn af at genbruge kontekst. Jo mere gentagne kontekst et system sender, jo mere cachepriser ændrer den reelle enhedsøkonomi. To anmodninger med lignende tokenantal kan have meget forskellige omkostninger, hvis den ene skriver en cachepost, og en anden læser fra den.

Det gør cachesynlighed til et finansielt problem, ikke kun et teknisk problem. Et team, der kører interne agenter, skal muligvis vide, om en ny arbejdsgang er dyr, fordi den genererer for mange nye prompter, går glip af cachen eller skriver store cacheblokke for ofte. En forhandler skal muligvis vise kunderne, hvorfor en applikations fakturerede brug er lavere end forventet, selvom dens tilsyneladende promptstørrelse er stor. En gateway-leverandør skal muligvis bevare cachefelter i logfiler, analyser og finansposter, så månedsafstemning matcher udbyderfakturaer.

Det er også her, AI API-omkostningsanalyse bliver mere krævende. Samlede anmodningsomkostninger er ikke længere nok. Teams skal se input, output, cacheskrivning og cache-læseadfærd separat, og derefter forbinde disse kategorier til API-nøgler, kunder, modeller og ruter.

Hvem er berørt

Den umiddelbare målgruppe er Cloudflare AI Gateway-brugere, der er afhængige af tilpassede omkostninger frem for standard offentlige priser. Det omfatter virksomheder med forhandlede modelpriser, platforme, der markerer udbyderbrug for kunder, og teams, der bruger Cloudflare som et delt kontrolplan på tværs af flere modeludbydere.

Forhandlere er særligt udsatte. Hvis en forhandler opkræver kunder ved hjælp af en forenklet token-model, mens de betaler udbydere under cache-bevidste priser, kan forskellen stille og roligt akkumuleres. Underopladning af cache-skrivninger eller overopladning af cache-læsninger vises muligvis ikke i en enkelt anmodning, men det kan have betydning på tværs af agentsessioner, batchbehandling eller højvolumen-hentningsarbejdsbelastninger.

Udviklere, der bygger OpenAI-kompatible gateway-lag, påvirkes, selv når de ikke bruger Cloudflare direkte. Ændringen afspejler en bredere retning på markedet: udbydernes faktureringsflader bliver mere detaljerede, mens kunderne stadig forventer en ren faktura og forudsigelige brugsrapporter.Produkter såsom Model Gate skal behandle cache-tokenfelter som førsteklasses finansdata, hvis de ønsker nøjagtig kundespecifik rapportering, brugsgrænser og marginanalyse på tværs af flere udbydere.

Praktiske konsekvenser

Gateway-teams bør gennemgå, hvordan deres anmodningslogfiler, omkostningsberegnere og fakturaer repræsenterer cacheaktivitet. Hvis cachelæsninger og -skrivninger er fladtrykte til almindelige prompt-tokens, kan analyser se enklere ud end den underliggende regning. Hvis udbyderbrugsregistreringer indeholder cachefelter, der slettes under indlæsning, vil senere afstemning være vanskelig.

Prismotorer skal også understøtte mere end én pris pr. retning. Den gamle input-versus-output-split er ikke længere nok til avanceret modelregnskab. En troværdig modelbog har nu brug for plads til nye inputtokens, outputtokens, cacheskrivninger, cachelæsninger og muligvis udbyderspecifikke varianter af disse kategorier.

Kundevendte dashboards bør blotlægge disse sondringer omhyggeligt. De fleste brugere ønsker ikke at læse rå udbydertelemetri, men de har brug for at forstå, hvorfor omkostningerne ændrer sig, når en applikation begynder at genbruge kontekst mere effektivt. Den bedste grænseflade kan være en omkostningsopdeling, der viser cachebesparelser og omkostninger til oprettelse af cache uden at tvinge kunderne til at lære hver udbyders terminologi.

Der er også operationelle konsekvenser for advarsler og begrænsninger. En kundebudgetgrænse, der kun er baseret på det samlede antal tokens, kan muligvis ikke fange en arbejdsbelastning, der skriver dyre cacheposter. En marginalarm, der kun er baseret på antallet af anmodninger, kan gå glip af en udbyders prismismatch. For teams, der sælger adgang via nøgler pr. kunde, bør cache-bevidst regnskab være bundet tilbage til de samme kunde-, projekt- eller applikations-id'er, der bruges til forbrugskontrol.

Hvad forbliver åbent

Ændringsloggen etablerer understøttelse af cache-læse og cache-skrive tilpassede priser, men den løser ikke alle implementeringsspørgsmål for gateway-operatører. Hold skal stadig teste, hvordan deres specifikke udbydere rapporterer cachebrug, hvordan Cloudflares beregnede omkostninger vises i logfiler og eksporter, og hvordan eksisterende fakturaer skal sammenlignes med de nye brugerdefinerede omkostningsfelter.

Den større retning er dog klar. AI-gateway-fakturering bevæger sig fra en simpel token-måler til en detaljeret forbrugsbog. Cache-priser er nu en del af denne hovedbog. Teams, der bevarer detaljerne, vil have renere afstemning og bedre kundeanalyse. Teams, der kollapser det væk, bemærker muligvis ikke problemet, før deres udbyderregning og kundefaktura holder op med at fortælle den samme historie.