Context window, token-kulut ja lasku mitattuina

Tämän alan kallein väärinkäsitys on se, että malli muistaisi keskustelun.

Se ei muista, ja luvun 13 mekanismi kertoo täsmälleen miksi. Transformer-mallin tila generoinnin aikana on KV cache: avaimet ja arvot, jotka on laskettu jokaiselle sekvenssin tokenille. Tämä cache elää yhden pyynnön ajan. Kun pyyntö päättyy, sitä pitänyt prosessi voi palvella jotakuta muuta, ja cache on poissa. Toisella puolella ei ole käyttäjäkohtaista tallennetta eikä sessiota.

Siksi seuraavan pyynnön on saavuttava mukanaan kaikki, mitä mallin oletetaan tietävän, ja malli rakentaa tilan uudelleen ajamalla forward passin koko promptin yli ennen kuin se tuottaa yhtään uutta tokenia. Luku 15 kutsui promptia ”koko tilaksi”. Tämä on fyysinen syy: prompt on täydellinen tila, koska mikään muu ei selviä kutsun yli.

Context window on promptin ja sen vastauksen enimmäispituus. Se on yläraja sille, kuinka paljon tilaa voit rakentaa uudelleen, ei säiliö, joka pitäisi mitään tallessa pyyntöjen välillä. Sen kutsuminen ”mallin muistiksi” kääntää kausaliteetin väärin päin — et täytä muistia, vaan maksat sellaisen uudelleen luomisesta.

Siitä kahdenkymmenenkahden kerroin tulee. Vuoro $n$ kantaa kaikki $n-1$ aiemmat vuorot, joten $n$ vuoron keskustelun kokonais-input on kasvavan sarjan summa, eli neliöllinen:

missä $s$ on system prompt ja $h_i$ historia vuorolla $i$. Kun mitattu kumulatiivinen input sovitetaan $an^2 + bn$-muotoon neljänkymmenen vuoron yli, saadaan $60.22\,n^2 + 432.25\,n$, joka ennustaa 113 645 token vuorolla 40 verrattuna mitattuun 112 617:ään. Neliöllinen termi hallitsee, ja lineaarinen termi on se, mitä käyttäjä todella kirjoitti.

Tämän luvun tärkein lause on tämä: laskusi kasvaa keskustelun neliössä, ei viimeisen kysymyksen mukaan. Samat neljäkymmentä kysymystä ilman mitään historiaa maksavat $0.066036. Historian pitäminen maksoi $0.274386. Historia kertoi laskun 4,2:lla, ja se jatkaa kertomista, koska kerroin on keskustelun pituus.

Ikkuna on rajallinen kahdesta syystä, jotka vetävät samaan suuntaan. Ensimmäinen on luvun 9 syy: attention vertaa jokaista tokenia jokaiseen muuhun tokeniin, joten kyseisen kerroksen työ kasvaa sekvenssin pituuden neliössä. Toinen on muisti: KV cache kasvaa lineaarisesti sekvenssin pituuden kanssa, ja luku 13 teki tämän laskun — pitkillä sekvensseillä se on suurempi kuin painot.

Molempia rajoja on yritetty murtaa, eikä kumpaakaan ole poistettu. FlashAttention¹ järjestää laskennan uudelleen niin, että se lukee ja kirjoittaa paljon vähemmän korkean kaistanleveyden muistiin, mikä tekee pitkistä sekvensseistä käytännöllisiä muuttamatta asymptoottista kustannusta. Position Interpolation² ja YaRN³ laajentavat koulutetun mallin käyttökelpoista ikkunaa skaalaamalla luvun 9 paikkaenkoodauksia uudelleen sen sijaan, että malli koulutettaisiin uudelleen. Yhdessä ne ovat syy siihen, miksi ikkunat kasvoivat viidessä vuodessa 2K:sta 1M:ään.

Ne eivät kuitenkaan tehneet pitkistä konteksteista ilmaisia. Ne nostivat kattoa ja loivensivat kulmakerrointa. Kulmakerroin on yhä olemassa, ja sitä tämän luvun myöhemmät hintatasot mittaavat.

Lähes jokainen internetin kustannuslaskuri mallintaa API-kutsun niin, että input tokens kerrotaan input-hinnalla ja output tokens output-hinnalla. Se piti paikkansa vuonna 2023. Nyt se on väärin tavalla, joka voi tehdä laskuista kaksinkertaisesti tai enemmän pielessä kumpaankin suuntaan.

Veloitettavia token-luokkia on viisi:

Kolme näistä viidestä ei ollut erillisiä rivejä kaksi vuotta sitten, ja kaksi cache-riviä ovat ne, joissa ihmiset erehtyvät, koska cache write maksaa enemmän kuin tavallinen input, ei vähemmän. Maksat lisähintaa jonkin tallentamisesta, jotta voit maksaa alennettua hintaa sen lukemisesta takaisin, ja se kannattaako vaihto riippuu täysin siitä, kuinka monta kertaa luet sen.

Reasoning-lokero on luvun 12 asia, nyt hinnan kanssa, ja siihen liittyy yksityiskohta, joka kannattaa sanoa suoraan: Googlen dokumentaatio sanoo, että hinnoittelu ”perustuu täysiin thought tokens -määriin, jotka mallin täytyy generoida, vaikka API palauttaa vain yhteenvedon”.⁴ Sinua laskutetaan tokeneista, joita sinulle ei koskaan lähetetä. Se on ainoa lokero, jonka sisältöä et voi laskea, tarkastaa tai todentaa.

Nyt se osa, joka tekee tästä normalisointiongelman eikä kertolaskuongelman. Jokainen palveluntarjoaja raportoi nämä lokerot eri nimillä, ja — tämä on ansa — kaksi niistä käyttää samaa sanaa kahdesta eri suureesta.

Otetaan yksi kutsu: 4 837 token luettu cachesta, 110 tuoretta, 142 näkyvää output tokenia, 300 reasoning tokenia.

// OpenAI-compatible
{ "usage": { "prompt_tokens": 4947,
             "prompt_tokens_details": { "cached_tokens": 4837 },
             "completion_tokens": 442,
             "completion_tokens_details": { "reasoning_tokens": 300 } } }

// Anthropic
{ "usage": { "input_tokens": 110,
             "cache_read_input_tokens": 4837,
             "cache_creation_input_tokens": 0,
             "output_tokens": 442 } }

// Gemini
{ "usageMetadata": { "promptTokenCount": 4947,
                     "cachedContentTokenCount": 4837,
                     "candidatesTokenCount": 142,
                     "thoughtsTokenCount": 300 } }

Katso kenttiä prompt_tokens: 4947 ja input_tokens: 110. Molemmat kentät ovat input token -määrä samalle promptille. OpenAI:n kenttä sisältää cached tokens; Anthropic:n kenttä ei sisällä niitä — sen dokumentaatio ilmaisee identiteetin eksplisiittisesti, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ Anthropic:n input_tokens tarkoittaa ”tokeneita viimeisen cache breakpointisi jälkeen”.

Katso myös outputia. OpenAI ja Anthropic raportoivat molemmat 442, joka sisältää jo 300 reasoning tokenia. Gemini raportoi 142 ja laittaa 300 omaan kenttäänsä. Luku 12 nosti tämän esiin yhteensopimattomuutena kahden samaa työtä laskevan tavan välillä; tässä näkyy, mitä se maksaa.

Normalisoija on kolmekymmentä riviä, eikä se ole valinnainen:

export interface Usage {
  promptTokens?: number;        // input, NOT cached
  cachedInputTokens?: number;   // read from cache
  cacheWriteTokens?: number;    // written to cache on this call
  completionTokens?: number;    // output
  reasoningTokens?: number;     // billed apart from output (Gemini only)
}

const num = (v: unknown) => (typeof v === "number" && isFinite(v) ? v : 0);

export const fromOpenAI = (raw: any): Usage => {
  const u = raw.usage ?? {}, d = u.prompt_tokens_details ?? {};
  const cached = num(d.cached_tokens), write = num(d.cache_write_tokens);
  return {
    promptTokens: Math.max(0, num(u.prompt_tokens) - cached - write), 
    cachedInputTokens: cached,
    cacheWriteTokens: write,
    completionTokens: num(u.completion_tokens),   // reasoning already inside
    reasoningTokens: 0,
  };
};

export const fromAnthropic = (raw: any): Usage => {
  const u = raw.usage ?? {};
  return {
    promptTokens: num(u.input_tokens),            // already excludes cache
    cachedInputTokens: num(u.cache_read_input_tokens),
    cacheWriteTokens: num(u.cache_creation_input_tokens),
    completionTokens: num(u.output_tokens),
    reasoningTokens: 0,
  };
};

export const fromGemini = (raw: any): Usage => {
  const m = raw.usageMetadata ?? {}, cached = num(m.cachedContentTokenCount);
  return {
    promptTokens: Math.max(0, num(m.promptTokenCount) - cached),
    cachedInputTokens: cached,
    cacheWriteTokens: 0,
    completionTokens: num(m.candidatesTokenCount), // EXCLUDES thinking
    reasoningTokens: num(m.thoughtsTokenCount),    // billed at output rate
  };
};

Aja yllä olevat kolme payloadia kolmen lukijan läpi, ja kaikki kolme tuottavat saman Usage-arvon ja siksi saman numeron: $0.006491. Tämä yhtäpitävyys on koko kerroksen kirjoittamisen pointti.

Jos teet sen väärin, tässä on hinta samalla kutsulla:

Kolmas on vaarallinen, koska se epäonnistuu hiljaa hyvien uutisten suuntaan. Dashboard näyttää reasoning-mallin maksavan alle puolet todellisesta hinnastaan, eikä mikään missään nosta virhettä.

Kun lokerot on normalisoitu, kustannusfunktio on lyhyt. Ainoa ei-ilmeinen osa on tier-haku, jonka seuraava osio selittää:

export interface Tier { maxPromptTokens: number | null; price: number }
export interface Pricing {
  input: Tier[]; output: Tier[];
  cachedInput?: Tier[]; cacheWrite?: Tier[]; reasoning?: Tier[];
}

const tierPrice = (tiers: Tier[] | undefined, contextSize: number, fallback?: Tier[]) => {
  const table = tiers ?? fallback;
  if (!table?.length) return 0;
  const sorted = [...table].sort(
    (a, b) => (a.maxPromptTokens ?? Infinity) - (b.maxPromptTokens ?? Infinity));
  for (const t of sorted)
    if (t.maxPromptTokens === null || contextSize <= t.maxPromptTokens) return t.price;
  return sorted[sorted.length - 1].price;
};

export function computeCost(pricing: Pricing, usage: Usage): number {
  const fresh = usage.promptTokens ?? 0;
  const read  = usage.cachedInputTokens ?? 0;
  const write = usage.cacheWriteTokens ?? 0;
  const out   = usage.completionTokens ?? 0;
  const think = usage.reasoningTokens ?? 0;
  const contextSize = fresh + read + write;   // the tier depends on the WHOLE prompt
  return fresh * tierPrice(pricing.input, contextSize)
       + read  * tierPrice(pricing.cachedInput, contextSize, pricing.input)
       + write * tierPrice(pricing.cacheWrite,  contextSize, pricing.input)
       + out   * tierPrice(pricing.output, contextSize)
       + think * tierPrice(pricing.reasoning, contextSize, pricing.output);
}

Kaksi suunnittelupäätöstä siinä ovat puolustamisen arvoisia. Fallbackit — cache-hintojen putoaminen inputiin, reasoning outputiin — koodaavat sen, mitä puuttuva taulukko tarkoittaa: Gemini:n reasoning tokens laskutetaan output-hinnalla, joten puuttuva reasoning-hinta ei ole nolla, se on output-hinta. Ja contextSize summaa kaikki kolme input-lokeroa eikä vain tuoreita, koska tier valitaan promptin pituuden mukaan, ei sen mukaan, kuinka suuresta osasta sinua veloitettiin täydellä hinnalla.

Prompt caching tallentaa mallin lasketun tilan promptisi prefixille, jotta myöhempi pyyntö samalla prefixillä voi ohittaa sen uudelleen laskemisen. Sanasta ”prefix” seuraa neljä ominaisuutta, ja kaikki neljä yllättävät ihmisiä.

Break-even on riittävän pieni pidettäväksi mielessä, ja OpenAI:n dokumentaatio tekee laskun: prefixin kirjoittaminen kerran ja uudelleenkäyttö kerran maksaa 1.35× sen tavallisen input-kustannuksen, kun sen käsittely kahdesti uncached maksaisi 2×; kymmenen pyynnön yli yksi write ja yhdeksän readia maksavat 2.15× verrattuna 10×:ään. Yksi uudelleenkäyttö maksaa writen takaisin. Anthropic päätyy samaan: yksi read viiden minuutin cachelle, kaksi tunnin cachelle.

Nyt neljänkymmenen vuoron keskustelu uudelleen, caching päällä ja prefix vakaana:

Kuusikymmentäkahdeksan prosenttia halvempi, ja kolme numeroa taulukossa ansaitsee huomion.

Cache ei aktivoidu ennen vuoroa 6. Prompt ei saavuta 1 024 tokenia ennen sitä, joten ensimmäiset viisi vuoroa laskutetaan täsmälleen kuten ennen — ja kuudes laskutetaan pahemmin, 1.25\u00d7 write -lisähinnalla, koska se on vuoro, joka täyttää cachen. Ensimmäinen read saapuu vuorolla 7. Taulukon 2 887 uncached tokenia ovat aritmetiikkaa: viiden vuoron verran, ei kuuden. Caching on alennus pitkistä prompteista, eikä lyhyt keskustelu saa siitä mitään.

Write-lisähinta on $0.002474, mikä on 2,8 % cached-laskusta. Jokainen vuoro kirjoittaa uuden häntänsä, neljäkymmentä kertaa, ja koko write-lisähinta on pyöristysvirhe verrattuna siihen, mitä readit säästivät. Write-veloitus kannattaa ymmärtää tarkasti, jotta lakkaat murehtimasta sitä.

Vain 2 887 tokenia veloitettiin täydellä input-hinnalla 112 617:stä. Se on toimivan cachen muoto: lähes kaikki on readia.

Tässä on epäonnistuminen, joka maksaa oikeaa rahaa, ja se on yhden rivin bugi.

Laita promptin alkuun jotain, joka muuttuu joka kutsulla — timestamp, request id, käyttäjän nimi, ”tänään on” -rivi, juuri haettu dokumentti — ja prefix eroaa ensimmäisestä tavusta. Mikään ei täsmää. Jokainen kutsu on miss. Ja koska jokainen kutsu esittää uuden prefixin, jokainen kutsu myös kirjoittaa.

Sama keskustelu, samat neljäkymmentä vuoroa, caching käytössä, ja system promptin yläosassa per-call timestamp:

Prompt cachingin ottaminen käyttöön teki keskustelusta kaksikymmentä prosenttia kalliimman kuin ilman sitä. Maksoit 1.25× write -lisähinnan 109 730 tokenista ja luit takaisin nolla. Ei virhettä, ei varoitusta, ja ominaisuus on päällä.

Sääntö, ja se on koko prompt caching yhdessä rivissä: vakaa sisältö eteen, muuttuva sisältö taakse. System-ohjeet, tool-määrittelyt ja viitemateriaali ensin; timestampit, käyttäjän identiteetti ja nykyinen kysymys viimeiseksi. Anthropic tekee hierarkian eksplisiittiseksi — cache seuraa järjestystä tools → system → messages, ja muutos millä tahansa tasolla invalidoi kyseisen tason ja kaiken sen jälkeen, joten yhden tool-kuvauksen muokkaaminen invalidoi koko cachen.⁵

Kaksi seurausta kompastuttaa ihmisiä. Se, mitkä tools ovat käytössä, muuttaa tool-määrittelyjä, joten feature flag, joka lisää toolin joillekin käyttäjille, jakaa cachesi kahtia. Ja Anthropic:lla web-haun tai sitaattien kytkeminen päälle tai pois muokkaa system promptia, mikä invalidoi system- ja message-cachet ilman että kosket yhteenkään omaan tekstiriviisi.

Ilmeinen vastaus neliölliseen laskuun on lopettaa koko historian lähettäminen: pidä viimeiset tusina viestiä ja pudota loput. Se kyllä pienentää laskua, ja se on yleensä väärä liike, ja mittaus kertoo miksi.

Katkaisu kahdentoista viestin ikkunaan on 57 % halvempi kuin kaiken lähettäminen uncached — vertailu, jonka kaikki tekevät, ja syy tekniikan suosioon. Mutta se on 39 % kalliimpi kuin kaiken lähettäminen toimivalla cachella, ja cachingin kytkeminen päälle truncationin rinnalla tekee siitä hieman huonomman eikä paremman.

Mekanismi on jälleen prefix. Sliding window pudottaa vanhimman viestin joka vuorolla, joten prompt ei enää ala samasta kohdasta kuin viimeksi ja jokainen vuoro esittää uuden prefixin. OpenAI:n ohje sanoo täsmälleen tämän: ”summarisation, compaction, or context truncation can change the prefix and reset cache reuse.”⁶ Vuorolla 40 ikkunoitettu prompt on 813 tokenia, alle 1 024 tokenin minimin, joten sitä ei voi cached lainkaan.

Ja raha on kustannuksen halpa puoli. Pudottamasi asia on ohje, jonka käyttäjä antoi vuorolla 2 ja jota malli tarvitsi vuorolla 40. Truncation vaihtaa laskun, jonka näet, epäonnistumiseen, jota et näe, ja sen tekeminen oikein — compaction, rakenteiset muistiinpanot ikkunan ulkopuolella, historian hakeminen tarpeen mukaan — on luvun 24 aihe.

Pitkät kontekstit eivät ole kalliimpia vain siksi, että ne ovat pidempiä. Raja-arvon jälkeen ne ovat kalliimpia per token, ja raja koskee takautuvasti koko promptia.

OpenAI:n mallisivu mallille gpt-5.6-terra sanoo sen yhdessä lauseessa: ”Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request.”⁷ Ei ylimenevälle osalle. Koko asialle.

prompt 271,999 + 500 output  ->  $0.5500
prompt 272,000 + 500 output  ->  $0.5500
prompt 272,001 + 500 output  ->  $1.0970

Yksi token, viisikymmentäviisi senttiä. Jos palvelusi rakentaa promptit haetuista dokumenteista, joiden kokoa et hallitse, kustannusmallissasi on jyrkänne rajalla, jota kukaan tiimissäsi ei ole kirjannut ylös.

Googlen hinnoittelu toimii samalla tavalla 200 000 tokenin rajalla: Gemini 2.5 Pro on $1.25 per miljoona input tokenia enintään 200K promptille ja $2.50 sen yli, outputin noustessa $10.00:sta $15.00:aan.⁸ Anthropic meni toiseen suuntaan — 6. syyskuuta 2026 sen dokumentaatio sanoo, että Claude 4.6 ja uudemmat sisältävät täyden miljoonan tokenin ikkunan vakiohinnoittelulla, joten ”a 900k-token request is billed at the same per-token rate as a 9k-token request.”⁹ Aiemmissa malleissa lisämaksu säilyi.

Siksi hinta ei ole numero. Hinta on promptin pituuden mukaan indeksoitu tier-taulukko, mitä varten Tier[] kustannusfunktiossa on, ja siksi computeCost valitsee tierin koko promptin eikä kunkin lokeron perusteella erikseen.

Viisi lokeroa mapataan luvun 13 kahteen vaiheeseen, ja kun näet mapituksen, hintasuhteet lakkaavat näyttämästä mielivaltaisilta.

Input tokens ovat prefill. Koko prompt kulkee mallin läpi yhdessä passissa, rinnakkain käsiteltynä — suuria matriisikertolaskuja, compute-bound. Kustannus per token on matala, ja tämä vaihe määrittää time to first token -ajan: 4 947 tokenin promptissa on tehtävä 4 947 tokenin prefill ennen kuin ensimmäinen sana ilmestyy.

Output tokens ovat decode. Ne tuotetaan yksi kerrallaan, jokainen täysi forward pass, joka lukee koko KV cache -tilan, GPU:n enimmäkseen odottaessa muistia laskemisen sijaan. Tämä vaihe määrittää tokens per second -nopeuden, sitä ei voi rinnakkaistaa yhden vastauksen sisällä, ja siksi output maksaa tässä hinnoitellulla mallilla noin kuusi kertaa inputin: $12.00 verrattuna $2.00 per miljoona tokenia.

Tästä seuraa suoraan kolme asiaa. Cache read korvaa prefill-työtä, joten se ostaa latenssia ja rahaa yhtä aikaa — sama alennus näkyy pienempänä laskuna ja lyhyempänä odotuksena ensimmäiseen tokeniin. Reasoning tokens ovat decodea, jota et koskaan näe, minkä vuoksi reasoning-malli ei streamaa mitään useaan sekuntiin ja vastaa sitten nopeasti: luku 12 varoitti käyttöliittymäseurauksesta, ja tämä on laskuseuraus. Ja streamin keskeyttäminen ei pysäytä generointia — luku 14 rakensi peruutuksen ja jätti hinnan tähän lukuun, ja hinta on täysi output-määrä, koska tokens tuotetaan ja laskutetaan riippumatta siitä, kuunteleeko kukaan. Sama pätee vastaukseen, jota kukaan ei säilytä: vuoron 40 vastauksen generointi uudelleen viisi kertaa maksaa $0.057990 siitä yhdestä, joka jää näytölle.

Luvun 7 tokenizer oli Pythonia ja jäi sinne. Budjetointi tapahtuu palvelimella, joka rakentaa pyynnön, joten sen on tapahduttava täällä, ja tarkkuustasoja on täsmälleen kolme.

Taso yksi: laske paikallisesti. js-tiktoken toimittaa samat BPE merge -taulukot kuin Pythonin tiktoken, joten saat byte-for-byte identtisen laskennan OpenAI-enkoodauksille ilman verkkokutsua:

import { getEncoding } from "js-tiktoken";

const enc = getEncoding("o200k_base");
const PER_MESSAGE = 4;   // role and delimiters added by the chat template
const PER_REPLY = 3;     // priming for the assistant turn

export function promptTokens(messages: { role: string; content: string }[]) {
  return messages.reduce(
    (sum, m) => sum + enc.encode(m.content).length + PER_MESSAGE, PER_REPLY);
}

Kaksi vakiota ovat tärkeitä, ja niissä paikalliset laskennat alkavat ajautua. Tekstisi ei ole se, mikä tokenisoidaan — luvun 11 chat-template käärii jokaisen viestin ensin role-markereihin, ja ne ovat tokens, joista maksat. Neljä per viesti ja kolme vastauksen primingiin on OpenAI chat -mallien tavanomainen approksimaatio; yllä olevan keskustelun kahdeksankymmenenyhden viestin yli niistä kertyy 324 tokenia, 6,4 % sen pituudesta. Tässä olevat laskennat ristiintarkistettiin luvun 7 Pythonin tiktoken-tuloksia vasten kaikilla kahdeksallakymmenelläyhdellä merkkijonolla ja ne ovat identtiset.

Taso kaksi: kysy palveluntarjoajalta. Anthropic tarjoaa /v1/messages/count_tokens-rajapinnan ja Google count_tokens-rajapinnan, jotka molemmat hyväksyvät saman pyyntömuodon kuin oikea kutsu ja palauttavat input token -määrän ilmaiseksi. Käytä niitä, kun et voi laskea paikallisesti — etkä voi laskea paikallisesti Anthropicille, jonka tokenizeria ei ole julkaistu. Anthropic:n dokumentaatio on tarkka siitä, mitä se antaa: laskenta ”is an estimate”, ja se ”may include tokens added automatically by Anthropic for system optimizations”, joista ”you are not billed”.¹⁰

Taso kolme: lue usage vastauksesta. Se on totuus, ja se saapuu sen jälkeen, kun rahat on käytetty. Juuri siksi kaksi ensimmäistä tasoa ovat olemassa — jotta voidaan päättää, lähetetäänkö pyyntö, ei jotta sillä laskutettaisiin.

Neljä rivikohtaa, jotka eivät näy rivikohtina.

System prompt, maksetaan jokaisella kutsulla. Yllä oleva on 192 tokenia template-overheadin kanssa. Neljänkymmenen kutsun yli se on 7 680 tokenia — 5,6 % koko tämän keskustelun laskusta, kahdeksasta rivistä, jotka kirjoitettiin kerran. Se on myös paras mahdollinen cache-ehdokas, koska se on sekä vakaa että ensimmäisenä.

Tool-määrittelyt. Jokaisen toolin nimi, kuvaus ja JSON-schema lähtevät jokaisella pyynnöllä, ja palveluntarjoajat lisäävät scaffoldingia päälle. Anthropic julkaisee luvun: tools-toimintojen käyttöönotto ylipäätään lisää piilotetun system promptin, 496 tokenia Claude Sonnet 4.5:llä kun tool_choice on auto, tai 588 kun käytössä on any tai nimetty tool.⁹ Tämä on ennen omia schemojasi. Luku 18 rakentaa katalogin; luku 24 mittaa, mitä se syö.

Jokainen generointi, myös ne jotka hylkäät. Viisi uudelleengenerointia maksaa viisinkertaisesti. Chat näyttää yhden.

Thoughts, joita sinulle ei näytetä. Laskutus perustuu täysiin thought tokens -määriin, vaikka vain yhteenveto palautetaan, eikä oma kirjanpitosi voi auditoida sitä lukua.

Yksi varoitus lopuksi, koska se on luonnollinen seuraava ajatus eikä vastaus ole ilmeinen.

Miljoonan tokenin ikkuna ei tarkoita miljoonaa käyttökelpoista tokenia. Retrieval-tarkkuus heikkenee sijainnin mukaan: Liu et al. havaitsivat, että mallit löytävät informaation luotettavasti pitkän inputin alusta ja lopusta ja paljon heikommin keskeltä.¹¹ Isompi ikkuna ostaa kyvyn lähettää enemmän, ei varmuutta siitä, että se luetaan.

Tämä ilmiö mitataan tässä kurssissa kerran — retrieval rate yhdeksässä sijainnissa samassa 853 tokenin promptissa — ja se kuuluu lukuun 24, jossa se muuttaa sitä, mitä agent tekee. Se mainitaan tässä, koska se muuttaa sitä, mitä sinun pitäisi ostaa: halvin token on se, jota et lähettänyt.

Voit nyt ennustaa, mitä kutsu maksaa ennen kuin teet sen, lukea jälkikäteen mitä se maksoi ja erottaa nämä kaksi toisistaan. Se kattaa pyynnöstä kaiken paitsi sen osan, johon et ole koskenut: säätimet.

Luku 17 käsittelee samplingia — temperature, top-p, top-k, penalties ja determinismiä, jota sinulla ei ole. Se alkaa purkamalla alan yleisimmän virheen: että temperature olisi luovuussäädin. Ei ole: temperature jakaa luvun 4 logits ennen softmaxia, eikä sen nostaminen tee mallista mielikuvituksellista, vaan nostaa sellaisten tokenien todennäköisyyttä, jotka malli itse arvioi huonommiksi. Siitä eteenpäin: miksi greedy decoding tuottaa mitattavasti huonompaa tekstiä kuin sampling, miksi top-k ja top-p epäonnistuvat jakauman vastakkaisissa muodoissa, ja kokeilu, joka päättää luvun: kaksikymmentä identtistä forward passia temperature 0:ssa palaavat bit-for-bit identtisinä, kun malli ajaa yksin, ja saman promptin laittaminen batchiin jonkun toisen pyyntöjen rinnalle liikuttaa 97 % sen logits-arvoista.

Ne eivät kaikki täsmää. Syy alkaa luvun 2 liukulukulaatikosta.

Kaikki tämän luvun hinnat, rajat ja kertoimet luettiin palveluntarjoajien omilta sivuilta 6. syyskuuta 2026, ja ne ilmoitetaan päivämäärän kanssa, koska ne muuttuvat. Menetelmä on lukuja tärkeämpi: lokerot, prefix-sääntö ja tier-aritmetiikka ovat olleet vakaita kaksi vuotta, vaikka jokainen niiden sisällä oleva numero on liikkunut.

Stanford CS336 lecture 2, Resource accounting, on lähin akateeminen käsittely tälle materiaalille ja oikea seuraava luettava: se tekee koulutuspuolella saman aritmetiikan kuin tämä luku tekee inference-puolella. Tämän luvun token-määrät tuotettiin js-tiktoken 1.0.21:llä käyttäen o200k_base- ja cl100k_base-enkoodauksia, neljänkymmenen vuoron keskustelusta, jonka pituus on 5 090 tokenia; per-message template overhead on tavanomainen neljä-plus-kolme-approksimaatio ja ilmoitetaan kaikkialla, missä se sisältyy. Cache-, tier- ja truncation-luvut ovat dokumentoituja hinnoittelusääntöjä sovellettuna mitattuihin token-määriin, eivät live-API-vastausten havaintoja — tämän luvun tuottamiseen ei tehty maksullista kutsua, mikä on myös rehellinen syy siihen, että latenssiväitteet ovat laadullisia ja kustannusväitteet eivät.