Så beräknar du tokenförbrukningen i Responses API: indata, utdata, cache och resonemang

Kontrollera besparingen efter att du har kortat prompten genom att granska usage för varje svar och kostnaden för hela uppgiften. Ett kort svar kan innebära en betydande kostnad för resonemang, och när en konversation fortsätter kan historiken räknas på nytt. Håll isär tokenvolym, priskategorier och antalet anrop som krävdes för resultatet för att kunna följa upp budgeten.

Fyra räknare och hur de hänger ihop

I exemplet på usage-objektet visar OpenAI indata, utdata och en uppdelning av båda räknarna. Läs dem så här:

• input_tokens — det totala antalet indatatoken i anropet, inklusive kontext som används för att fortsätta en konversation.
• input_tokens_details.cached_tokens — den del av indata som hanterades från cachen. Den ingår redan i input_tokens.
• output_tokens — det totala antalet genererade token, inklusive resonemang.
• output_tokens_details.reasoning_tokens — den del av utdata som gick åt till resonemang.

Reasoning-token ingår redan i output_tokens; lägg inte till dem en gång till. OpenAI debiterar dem enligt priset för utdata-token. På samma sätt innebär det att lägga till cached_tokens till indata att samma del av begäran räknas två gånger. Använd total_tokens eller summan input_tokens + output_tokens för den totala volymen.

Kostnad: dela upp indata i kategorier

På den aktuella prissidan visas vanlig indata, cachad indata, cachelagring och utdata separat. Välj priser för den modell, det bearbetningsläge och den kontextlängd som faktiskt gäller. Lagra de exakta värdena i en versionshanterad beräkningskonfiguration.

En viktig detalj i den aktuella dokumentationen om cachelagring: för GPT-5.6 och nyare modeller redovisas input_tokens_details.cache_write_tokens. Om din modell har en separat avgift för cachelagring drar du av den kategorin från vanlig indata och tillämpar dess pris.

I = input_tokens
C = input_tokens_details.cached_tokens
W = input_tokens_details.cache_write_tokens
O = output_tokens

ordinary_input = I - C - W
cost = ((I - C - W) * P_input
        + C * P_cached
        + W * P_write
        + O * P_output) / 1_000_000

Här anges priserna per miljon token; om modellen saknar en separat kategori för cachelagring använder du W = 0. Formeln omfattar de angivna tok kategorierna. Lägg till betalda verktyg på separata rader enligt deras debiteringsvillkor.

Exempel med hypotetiska värden: indata — 4000, cachad indata — 3000, cachelagring — 500, utdata — 1000, varav 600 reasoning-token. Det ger 500 vanliga indatatoken och totalt 5000 token. Utdata debiteras för 1000 token; värdet 600 sparas för diagnostik.

Att fortsätta en konversation förbrukar indata igen

När historiken hanteras manuellt skickar programmet tidigare meddelanden tillsammans med den nya inmatningen. Meddelanden som ingår i nästa begäran blir åter indatakontext. Därför missar du kostnaden för historiken om du bara mäter den senaste användarrepliken.

Med previous_response_id skickar programmet en referens till föregående svar, och API:t kopplar samman kontexten. Enligt reglerna för debitering av fortsättningar debiteras föregående indatatoken i kedjan åter som indata. Cachelagring kan ändra priskategorin för en del av dessa indata; kontrollera faktisk cacheträff i cached_tokens för varje svar.

Så kontrollerar du optimeringsresultatet

1. Spara ett basurval. Jämför likadana uppgifter, samma modell och framgångskriterium samt jämförbara konversationslängder.
2. Logga varje anrop. Registrera identifierare för svar och uppgift, modell, reasoning-inställningar, status, svarstid och fullständigt usage. Spara versionen av prompten och priskonfigurationen.
3. Summera kostnaden per uppgift. Ta med alla dess anrop och svar från omförsök. Det viktigaste måttet är kostnaden för en framgångsrikt slutförd uppgift.
4. Skilj mellan orsakerna till förändringen. Följ vanlig indata, cacheläsning och cachelagring, utdata och andelen reasoning. Beräkna den aggregerade cacheandelen genom att dividera summan av C med summan av I.
5. Kontrollera kvalitet och fördelningens svans. Jämför p95, antal försök och andel lyckade uppgifter tillsammans med den genomsnittliga kostnaden.

Parametern max_output_tokens begränsar genereringen tillsammans med resonemanget. Om gränsen nås kan svaret få statusen incomplete, även utan synlig text men med förbrukade token. Ta med sådana svar när du kontrollerar besparingen: optimeringen har nått målet när jämförbara uppgifter slutförs framgångsrikt till en lägre totalkostnad.