Vind de cache-miss achter je OpenAI-rekening

Bijgewerkt September 26, 2026 · eerst gepubliceerd September 26, 2026

Een dashboard voor promptcaching kan melden dat hergebruik is gedaald. Het kan zelf niet zeggen welke requestwijziging de daling veroorzaakte of wat die kostte. De release van 8 september 2026 van OpenAI maakte Prompt Cache Diagnostics algemeen beschikbaar in de Responses API voor GPT-5.6 en latere ondersteunde modellen. De nuttige FinOps-zet is om een daling in gecachete tokens om te zetten in een korte, herhaalbare analyse.

Vergelijk het request dat misliep

Bewaar de ID van een recente, afgeronde response waarvan je verwachtte dat de prefix zou worden hergebruikt. Zet bij het volgende vergelijkbare Responses API-request van dezelfde organisatie prompt_cache_options.comparison_response_id op die ID. Lees daarna prompt_cache_diagnostics op de nieuwe response, naast usage.input_tokens_details.cached_tokens. De vergelijkingsoptie vraagt om een diagnose; ze laadt het eerdere gesprek niet en verandert het cachegedrag niet. De diagnosegids van OpenAI bevat werkende requestvoorbeelden.

const next = await client.responses.create({
  model: model,
  instructions: stableInstructions,
  input: nextInput,
  tools: stableTools,
  prompt_cache_options: { comparison_response_id: baseline.id }
});
console.log(next.prompt_cache_diagnostics);
console.log(next.usage.input_tokens_details.cached_tokens);

Het fragment gaat ervan uit dat baseline een recente afgeronde response is en dat de overige variabelen je eigen requestdata zijn. Houd een stabiele prefix aan die lang genoeg is om te cachen: OpenAI documenteert een minimum van 1.024 tokens voor GPT-5.6 en later. Een kleine of radicaal andere prompt is geen zinvolle test voor een cache-miss.

Herstel de oorzaak, niet de metriek

Een cache_miss-resultaat kan wijzen op een gewijzigd model, servicetier, tooldefinities of de volgorde ervan, cachesleutel, responseformaat, redeneerinspanning, verbositeit of gecomprimeerde context. Een onschuldig ogende hernoeming in een toolschema kan bijvoorbeeld de herbruikbare prefix ongeldig maken. Vergelijk de requestconfiguratie en de vroegste prompt-bytes, herstel de stabiliteit waar de wijziging onbedoeld was en draai de vergelijking opnieuw tegen dezelfde baseline. OpenAI meldt de eerste oorzaak die het vindt, dus na de eerste fix kan er een andere oorzaak verschijnen.

Forceer geen treffer als de wijziging bewust was. Een ander model kan de totale taakkosten verlagen, ook al gaat cachehergebruik verloren; compactie kan toekomstige context verkleinen. Beoordeel het hele request en de hele taak, niet het cachetreffer-percentage afzonderlijk. Een verlopen baseline of een unavailable-resultaat is niet doorslaggevend en geen bewijs dat caching faalde.

Reken de bevinding om in geld

cache_missed_tokens schat de herbruikbare tokens die verloren gingen ten opzichte van de vergelijkingsresponse. Het is geen aantal gefactureerde tokens. Een cache_hit-resultaat bewijst evenmin dollarbesparingen. Verzamel voor de gerealiseerde inputkosten per response de totale input_tokens, cached_tokens en cache_write_tokens en pas het actuele tarief voor dat model en die verwerkingstier toe. Voor GPT-5.6 en later stelt de promptcachinggids van OpenAI dat cache-reads 0,1 keer het ongecachete inputtarief kosten en cache-writes 1,25 keer dat tarief.

ordinary = input_tokens - cached_tokens - cache_write_tokens
weighted_input = ordinary + 0.1 * cached_tokens + 1.25 * cache_write_tokens
input_cost = weighted_input * input_price_per_million / 1_000_000

Dit zijn elkaar uitsluitende tokencategorieën: tel geen cache-writetoeslag op bij tokens die al tegen het writetarief zijn geteld. Deze formule dekt alleen input; neem output, tools, nieuwe pogingen en andere kosten mee bij het berekenen van de kosten per geslaagde taak. Gebruik de actuele prijslijst van de aanbieder in plaats van een vast ingecodeerde artikelprijs.

Een nuttige wekelijkse controle

1. Groepeer vergelijkbaar verkeer per workload, model en servicetier; zet het aandeel gecachete tokens en de inputkosten per afgeronde taak in een grafiek.
2. Neem een steekproef van een plotselinge regressie, vergelijk die met een recente baseline en leg de diagnostische reden en de verantwoordelijke codewijziging vast.
3. Herstel onbedoelde prefix- of configuratiedrift; behoud bewuste kwaliteits- of routingwijzigingen als de totale taakeconomie verbetert.
4. Valideer het resultaat op representatief productieverkeer en stem de waargenomen besparingen af met de facturering.

De diagnostiek zelf kost geen extra featurevergoeding, maar extra testrequests worden gewoon gefactureerd. De winst is niet een mooiere treffergrafiek. Het is een verdedigbare verklaring waarom de inputkosten van een bepaalde workload veranderden, en of de voorgestelde fix de rekening echt verlaagde.

Vragen van teams

Bewijst een cache-hitdiagnose dat een request goedkoper was?

Nee. Ze zegt dat er geen miss is gedetecteerd tegen de gekozen baseline. Controleer de werkelijke cached_tokens en de geprijsde tokencategorieën van het request voordat je besparingen claimt.

Kan diagnostiek twee willekeurige OpenAI-requests vergelijken?

Nee. Gebruik een recente afgeronde baseline van dezelfde organisatie en verwacht deze workflow alleen op ondersteunde Responses API-modellen vanaf GPT-5.6. Een vergelijkingsrecord kan verlopen.

Moet elke cache-miss worden weggewerkt?

Nee. Een modelwissel, een andere servicetier of gecomprimeerde context kan bewust zijn. Vergelijk kwaliteit, latentie en kosten per geslaagde taak voordat je de wijziging terugdraait.

Gerelateerd

• Economie van promptcaching
• Attributie van promptcache
• Kosten per geslaagde taak

Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit →

Terug naar finopsllm.com