Slik beregner du tokenbruk i Responses API: input, output, hurtigbuffer og resonnering

Etter at du har forkortet prompten, bør du kontrollere besparelsene med usage for hvert svar og kostnaden for hele oppgaven. Et kort svar kan likevel innebære betydelig forbruk til resonnering, og når en samtale fortsetter, kan historikken bli tatt med i beregningen på nytt. For å holde oversikt over budsjettet bør du skille mellom tokenmengde, priskategorier og antall kall som trengs for å få et resultat.

Fire tellere og hvordan de henger sammen

I eksempelet på et usage-objekt viser OpenAI input, output og detaljene for begge tellerne. Slik leser du dem:

• input_tokens — det samlede antallet input-tokens for dette kallet, inkludert kontekst som brukes til å fortsette samtalen.
• input_tokens_details.cached_tokens — delen av inputen som ble levert fra hurtigbufferen. Den inngår allerede i input_tokens.
• output_tokens — det samlede antallet genererte tokens, inkludert resonnering.
• output_tokens_details.reasoning_tokens — delen av outputen som ble brukt til resonnering.

Resonneringstokens inngår allerede i output_tokens; ikke legg dem til outputen en gang til. OpenAI fakturerer dem etter prisen for output-tokens. Tilsvarende vil det å legge cached_tokens til inputen føre til at samme del av forespørselen telles to ganger. Bruk total_tokens eller summen av input_tokens + output_tokens for å få totalmengden.

Kostnad: Del opp inputen etter kategori

Den gjeldende prissiden viser vanlig input, hurtigbufret input, skriving til hurtigbufferen og output som separate kategorier. Velg satsene som gjelder for den faktiske modellen, behandlingsmodusen og kontekstlengden. Oppbevar de nøyaktige verdiene i en versjonskontrollert beregningskonfigurasjon.

En viktig detalj i den gjeldende dokumentasjonen om hurtigbufring er at input_tokens_details.cache_write_tokens telles for GPT-5.6 og nyere modeller. Hvis oppsettet ditt fakturerer skriving til hurtigbufferen separat, trekker du denne kategorien fra vanlig input og bruker satsen for den.

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

Her er prisene oppgitt per million tokens. Hvis oppsettet ikke har en egen kategori for skriving, bruker du W = 0. Formelen dekker de oppførte tokategoriene. Legg til betalte verktøy som egne linjer i henhold til prisvilkårene deres.

Et hypotetisk eksempel: 4000 input-tokens, 3000 hurtigbufrede input-tokens, 500 tokens brukt til å skrive til hurtigbufferen og 1000 output-tokens, hvorav 600 er resonneringstokens. Da får du 500 vanlige input-tokens og 5000 tokens totalt. Du betaler for 1000 output-tokens; verdien 600 beholdes for feilsøking.

Videreføring av en samtale bruker input på nytt

Når programmet håndterer historikken manuelt, sender det tidligere meldinger sammen med den nye inputen. Meldinger som tas med i den neste forespørselen, blir dermed inputkontekst på nytt. Hvis du bare måler den siste brukermeldingen, overser du derfor kostnaden for historikken.

Med previous_response_id sender programmet en referanse til det forrige svaret, og API-et kobler sammen konteksten. I henhold til reglene for fakturering av videreføringer faktureres tidligere input-tokens i kjeden på nytt som input. Hurtigbufferen kan endre priskategorien for deler av denne inputen; kontroller cached_tokens for hvert svar for å se hva som faktisk ble hentet fra hurtigbufferen.

Slik kontrollerer du resultatet av optimaliseringen

1. Lagre et utgangspunkt. Sammenlign oppgaver av samme type, samme modell, samme kriterier for suksess og samtaler med omtrent samme lengde.
2. Loggfør hvert kall. Registrer ID-er for svar og oppgaver, modell, innstillinger for resonnering, status, forsinkelse og hele usage-objektet. Lagre versjonen av prompten og priskonfigurasjonen.
3. Summer kostnadene per oppgave. Ta med alle kallene og svarene fra eventuelle nye forsøk. Hovedmålet er kostnaden per fullført oppgave.
4. Skill mellom årsakene til endring. Følg med på vanlig input, lesing fra og skriving til hurtigbufferen, output og andelen resonnering. For den samlede andelen hurtigbufret input deler du summen av C på summen av I.
5. Kontroller kvaliteten og ytterpunktene i fordelingen. Sammenlign p95, antall forsøk og andelen oppgaver som lykkes, i tillegg til gjennomsnittskostnaden.

Parameteren max_output_tokens begrenser genereringen, inkludert resonnering. Når grensen nås, kan svaret få statusen incomplete, også uten synlig tekst, men med tokenforbruk. Ta med slike svar når du vurderer besparelser: Optimaliseringen har nådd målet når sammenlignbare oppgaver fullføres med lavere samlet kostnad.